本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 建置您的標記策略 如同許多操作實務，實作標記策略*是反覆運算和改善的過程*。從您立即的優先順序開始，並根據需要擴展標記結構描述。 ![\[圖表顯示標記策略反覆運算和改善週期的圖形表示\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) 在整個過程中，擁有權是責任和進展的關鍵。由於標籤可用於各種用途，因此整體標記策略可以分割為組織內的責任領域。標記允許以程式設計方式處理取決於資源特性的活動。可以從標記中受益的利益相關者範圍取決於組織的大小和操作實務。較大的組織可以從明確定義參與建立和實作標記策略之團隊的責任中受益。有些利益相關者可以負責識別標記的需求 （定義使用案例）；有些利益相關者可以負責維護、實作和改善標記策略。 透過指派擁有權，您可以很好地實作策略的個別層面。在適當的情況下，此所有權可以正式化為政策，並記錄在責任矩陣中 （例如 RACI：Responsible、accounted、Conchoned 和 Informed)，或在共同責任模型中。在較小的組織中，團隊可能會在標記策略中扮演多個角色，從需求定義到實作和強制執行。 # 定義需求和使用案例 與基本需要取用中繼資料的利益相關者互動，開始建置您的策略。這些團隊會定義資源需要加上標籤以支援其活動的中繼資料，例如報告、自動化和資料分類。它們概述了如何組織資源，以及它們需要映射到哪些政策。這些利益相關者在組織中可以擁有的角色和職能範例包括： + **財務**和**業務單位**需要透過將其映射到成本來了解投資價值，以排定解決效率低下時需要採取的動作的優先順序。了解*產生的成本與價值*有助於識別業務或產品供應項目的不成功線。這會導致有關持續支援、採用替代方案 （例如，使用 SaaS 服務或受管服務） 或淘汰無獲利商業產品的明智決策。 + **治理**和**合規**需要了解資料的分類 （例如公有、敏感或機密）、特定工作負載是否在或超出特定標準或法規的稽核範圍，以及服務的重要性 （無論服務或應用程式是否業務關鍵），以套用適當的控制和監督，例如許可、政策和監控。 + **操作**和**開發**需要了解工作負載生命週期、其支援產品的實作階段，以及發行階段 （例如，開發、測試、生產分割） 的管理，及其相關的支援優先順序和利益相關者管理需求。備份、修補、可觀測性和棄用等職責也需要定義和了解。 + **資訊安全 (InfoSec)** 和**安全操作 (SecOps)** 概述了必須套用哪些控制項，以及建議使用哪些控制項。InfoSec 通常會定義控制項的實作，SecOps 通常負責管理這些控制項。 根據您的使用案例、優先順序、組織大小和營運實務，您可能需要組織內各種團隊的代表，例如財務 （包括採購）、資訊安全、雲端啟用和雲端營運。您也需要應用程式和程序擁有者的代表，才能執行修補、備份和還原、監控、任務排程和災難復原等功能。這些代表可協助推動定義、實作，並衡量標記策略的有效性。他們應該從利益相關者及其使用案例[https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM)，並進行跨職能研討會。在研討會中，他們有機會分享他們的觀點和需求，並協助推動整體策略。本白皮書稍後將說明參與者及其參與各種使用案例的範例。 利益相關者也會定義和驗證強制標籤的金鑰，並且可以建議選用標籤的範圍。例如，財務團隊可能需要將資源與內部成本中心、業務單位或兩者相關聯。因此，他們可能需要強制某些標籤金鑰`BusinessUnit`，例如 `CostCenter`和 。個別開發團隊可能會決定將其他標籤用於自動化目的，例如 `EnvironmentName`、 `OptIn`或 `OptOut`。 主要利益相關者需要同意標記策略方法，並記錄合規和控管相關問題的答案，例如： + 需要解決哪些使用案例？ + 誰負責標記資源 （實作）？ + 如何強制執行標籤，以及將使用哪些方法和自動化 （主動或被動）？ + 如何衡量標記有效性和目標？ + 應該多久檢閱一次標記策略？ + 誰推動改進？ 如何完成此操作？ 然後，Cloud Enablement、Cloud Business Office 和 Cloud Platform Engineering 等業務職能可以扮演促進者的角色，以建置標記策略、協助推動採用，並透過測量進度、移除障礙和減少重複的工作來確保應用程式的一致性。 # 定義和發佈標記結構描述 使用一致的方法來標記您的 AWS 資源，包括強制性和選用的標籤。全面的標記結構描述可協助您實現此一致性。下列範例可協助您開始使用： + 同意強制性標籤索引鍵 + 定義可接受的值和標籤命名慣例 （大寫或小寫、破折號或底線、階層等） + 確認值不會構成個人身分識別資訊 (PII) + 決定誰可以定義和建立新的標籤索引鍵 + 同意如何新增強制性標籤值，以及如何管理選用標籤 檢閱下列[標記類別](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)表，其可做為標記結構描述中可能包含內容的基準。您仍然需要判斷您將用於標籤金鑰的慣例，以及每個慣例允許哪些值。標記結構描述是您為環境定義此項目的文件。 *表 6 – 最終標記結構描述的範例* | 使用案例 | 標籤索引鍵 | 理由 | 允許的值 （列出或值字首/尾） | 用於成本分配 | 資源類型 | Scope (範圍) | 必要 | | --- | --- | --- | --- | --- | --- | --- | --- | | 成本分配 | example-inc:cost-allocation:ApplicationId | 追蹤每行業務所產生的成本與價值 | DataLakeX, RetailSiteX | Y | 全部 | 全部 | 強制性 | | 成本分配 | example-inc:cost-allocation:BusinessUnitId | 依業務單位監控成本 | Architecture, DevOps, Finance | Y | 全部 | 全部 | 強制性 | | 成本分配 | example-inc:cost-allocation:CostCenter | 依成本中心監控成本 | 123-\$1 | Y | 全部 | 全部 | 強制性 | | 成本分配 | example-inc:cost-allocation:Owner | 哪些預算持有者負責此工作負載 | Marketing, RetailSupport | Y | 全部 | 全部 | 強制性 | | 存取控制 | example-inc:access-control:LayerId | 識別SubComponent/層，以根據角色授予對資源的存取權 | DB\$1Layer, Web\$1Layer, App\$1Layer | N | 全部 | 全部 | 選用 | |  自動化 | example-inc:automation:EnvironmentId | 實作測試和開發環境的排程，也稱為軟體開發生命週期 (SDLC) 階段 | Prod, Dev, Test, Sandbox | N | EC2、RDS、EBS | 全部 | 強制性 | | DevOps | example-inc:operations:Owner | 哪個團隊/小組負責資源的建立和維護 | Squad01 | N | 全部 | 全部 | 強制性 | | 災難復原 | example-inc:disaster-recovery:rpo | 定義資源的復原點目標 (RPO) | 6h, 24h | N | S3、EBS | 生產 | 強制性 | | 資料分類 | example-inc:data:classification | 分類資料以進行合規和管理 | Public, Private, Confidential, Restricted | N | S3、EBS | 全部 | 強制性 | | 合規 | example-inc:compliance:framework | 識別工作負載受制於的合規架構 | PCI-DSS, HIPAA | N | 全部 | 生產 | 強制性 | 定義標記結構描述後，請在版本控制的儲存庫中管理結構描述，讓所有相關利益相關者都能存取，以便於參考和追蹤更新。這種方法可提高效率並實現敏捷性。 # AWS Organizations – 標籤政策 中的政策 AWS Organizations 可讓您將其他類型的控管套用至組織中的 AWS 帳戶 。[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)是以 JSON 格式表達標記結構描述的方式，讓平台可以在 AWS 您的環境中報告並選擇性地強制執行結構描述。標籤政策會定義特定資源類型上標籤索引鍵可接受的值。此政策可以是值清單的形式，或是前綴加上萬用字元 (`*`)。簡單字首方法不如分散的值清單嚴格，但需要的維護較少。 下列範例示範如何定義標記政策，以驗證指定金鑰可接受的值。使用結構描述的人類友好表格式定義，您可以將此資訊轉錄為一或多個標籤政策。個別政策可用於支援委派所有權，或某些政策可能僅適用於特定案例。 ## ExampleInc-CostAllocation.json 以下是報告成本分配標籤的標籤政策範例： ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc-DisasterRecovery.json 以下是報告災難復原標籤的標籤政策範例： ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` 在此範例中，`ExampleInc-CostAllocation`標籤政策會連接至 `Workloads` OU，因此適用於 `Prod`和`Test`子 OUs 中的所有帳戶。同樣地，`ExampleInc-DisasterRecovery`標籤政策會連接至 `Prod` OU，因此僅適用於低於此 OU 的帳戶。[使用多個帳戶組織您的環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)白皮書會更詳細地探索建議的 OU 結構。 ![\[顯示標籤政策連接至 OU 結構和有效政策的圖表\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) 查看圖表中的`marketing-prod`帳戶，這兩個標籤政策都適用於此帳戶，因此我們有*有效政策*的概念，這是適用於帳戶之指定類型政策的卷積。如果您主要手動管理您的資源，則可以造訪 主控台中的[資源群組和標籤編輯器：標籤政策來檢閱有效政策](https://console.aws.amazon.com/resource-groups/tag-policies)。如果您使用基礎設施做為程式碼 (IaC) 或指令碼來管理您的資源，您可以使用 [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) API 呼叫。 # 實作和強制執行標記 在本節中，我們將介紹下列資源管理策略可用的工具：手動、基礎設施即程式碼 (IaC) 和持續整合/持續交付 (CI/CD)。這些方法的關鍵維度是部署頻率越來越頻繁。 ## 手動管理的資源 這些通常是屬於[採用基礎或遷移階段的](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)工作負載。通常，這些是使用傳統寫入程序建置的簡單主要靜態工作負載，或是**使用 AWS Application Migration Service 內部部署環境等工具遷移的工作負載。遷移工具，例如 Migration Hub 和 Application Migration Service，可以套用標籤作為遷移程序的一部分。不過，如果在原始遷移期間未套用標籤，或標記結構描述自那時起已變更，[標籤編輯器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) ( 的功能 AWS 管理主控台) 可讓您使用各種搜尋條件搜尋資源，並大量新增、修改或刪除標籤。搜尋條件可以包含有或沒有特定標籤或值的資源。 AWS 資源標記 API 可讓您以程式設計方式執行這些函數。 隨著這些工作負載的現代化，會推出 Auto Scaling 群組等資源類型。這些資源類型可提高彈性並改善彈性。自動擴展群組會代表您管理 Amazon EC2 執行個體，不過，您可能仍希望 EC2 執行個體與手動建立的資源一致地加上標籤。[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)提供指定 Auto Scaling 應套用至其建立之執行個體的標籤的方法。 手動管理工作負載的資源時，自動化資源標記會很有幫助。有各種可用的解決方案。其中一種方法是使用 AWS Config 規則，它可以檢查 `required_tags`，然後啟動 Lambda 函數來套用它們。本白皮書稍後 AWS Config 規則 會更詳細地說明 。 ## 基礎設施即程式碼 (IaC) 受管資源 AWS CloudFormation 提供常見的語言，用於佈建 AWS 環境中的所有基礎設施資源。CloudFormation 範本是以自動化方式建立 AWS 資源的 JSON 或 YAML 檔案。使用 CloudFormation 範本建立 AWS 資源時，您可以使用 CloudFormation Resource Tags 屬性，在建立時將標籤套用至支援的資源類型。使用 IaC 管理標籤和資源有助於確保一致性。 建立資源時 AWS CloudFormation，服務會自動將一組 AWS 定義的標籤套用至 AWS CloudFormation 範本建立的資源。這些時間為： ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` 您可以根據 AWS CloudFormation 堆疊輕鬆定義資源群組。這些 AWS 定義的標籤由堆疊建立的資源繼承。不過，對於 Auto Scaling 群組中的 Amazon EC2 執行個體，需要在 AWS CloudFormation 範本中 Auto Scaling 群組的定義中設定 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)。或者，如果您使用 [EC2 啟動範本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)搭配 Auto Scaling 群組，您可以在其定義中定義標籤。建議搭配 Auto Scaling 群組或 AWS 容器服務使用 [EC2 啟動範本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)。這些服務可協助確保 Amazon EC2 執行個體的一致標記，也支援[跨多個執行個體類型和購買選項的 Auto Scaling](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)，可改善彈性並最佳化運算成本。 [AWS CloudFormation 勾點](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/)為開發人員提供了一種方法，使其應用程式的關鍵層面與其組織的標準保持一致。勾點可設定為提供*警告*或*防止部署*。此功能最適合用於檢查範本中的金鑰組態元素，例如 Auto Scaling 群組是否設定為將客戶定義的標籤套用至其啟動的所有 Amazon EC2 執行個體，或確保所有 Amazon S3 儲存貯體都使用必要的加密設定建立。在這兩種情況下，此合規的評估都會在部署之前透過掛 AWS CloudFormation 鉤推送至部署程序的早期 。 AWS CloudFormation 提供偵測從範本佈建的資源 （請參閱[支援偏離偵測的資源](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) 何時已修改，且資源不再符合其預期的範本組態的功能。這稱為*偏離*。如果您使用自動化將標籤套用至透過 IaC 管理的資源，則您正在修改它們，並引入偏離。使用 IaC 時，目前建議在 IaC 範本中管理任何標記需求、實作 AWS CloudFormation 勾點，以及發佈可供自動化使用的 AWS CloudFormation Guard 規則集。 ## CI/CD 管道受管資源 隨著工作負載的成熟度增加，可能會採用持續整合和持續部署 (CI/CD) 等技術。這些技術透過提高測試自動化，讓部署小型變更更頻繁，協助降低部署風險。偵測部署引入之非預期行為的可觀測性策略，可以在使用者影響最小的情況下自動復原部署。隨著您進入每天部署數十次的階段，追溯套用標籤不再實際。所有內容都必須以程式碼或組態、版本控制，並盡可能在部署到生產環境之前進行測試和評估。在合併[開發和操作 (DevOps) 模型](https://aws.amazon.com/devops/what-is-devops/)中，許多實務將操作考量事項視為程式碼，並在部署生命週期的早期進行驗證。 理想情況下，您希望儘早推送這些檢查 （如 AWS CloudFormation 勾點所示），以便您可以確信 AWS CloudFormation 範本在離開開發人員的機器之前符合您的政策。 [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) 提供撰寫預防性合規規則的方法，讓您使用 CloudFormation 定義任何內容。範本會根據開發環境中的規則進行驗證。顯然，此功能有一系列的應用程式，但在本白皮書中，我們將查看一些範例，以確保始終使用 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)。 以下是 CloudFormation Guard 規則的範例： ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` 在程式碼範例中，我們為類型為 的所有資源篩選範本`AutoScalingGroup`，然後有兩個規則： + **`tags_asg_automation_EnvironmentId`** - 檢查具有此索引鍵的標籤是否存在、在允許的值清單中具有值，且`PropagateAtLaunch`設定為 `true` + **`tags_asg_costAllocation_CostCenter`** - 檢查標籤是否存在於此索引鍵，其值開頭為定義的字首值，且`PropagateAtLaunch`設定為 `true` ## 強制執行 如前所述，**資源群組和標籤編輯器**提供識別資源無法滿足套用至組織 OUs 之標籤政策中定義的標記要求的方法。從組織成員帳戶內存取**資源群組和標籤編輯器**主控台工具，會顯示套用至該帳戶的政策，以及帳戶內不符合標籤政策需求的資源。如果從管理帳戶存取 （如果**標籤政策**已在 下的服務中*啟用存取* AWS Organizations)，則可以檢視[組織中所有連結帳戶的標籤政策合規性](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 在標籤政策本身中，您可以針對特定資源類型啟用強制執行。在下列政策範例中，我們新增了強制執行，以便類型 `ec2:instance`和 的所有資源`ec2:volume`都必須符合政策。有一些已知的限制，例如資源上必須有標籤，才能由標籤政策評估。如需清單[，請參閱支援使用標籤政策強制執行的資源](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)。 ### ExampleInc-Cost-Allocation.json 以下是報告和/或強制執行成本分配標籤的標籤政策範例： ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config 是一項服務，可讓您評估、稽核和評估 AWS 資源的組態 （請參閱 [支援的資源類型 AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html))。在標記的情況下，我們可以使用 `required_tags`規則 （請參閱 [required\$1tags 支援的資源類型） 來識別缺少具有特定金鑰之標籤的資源](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)。從先前的範例中，我們可能會在所有 Amazon EC2 執行個體上測試金鑰是否存在。在金鑰不存在的情況下，執行個體會註冊為不合規。此 AWS CloudFormation 範本描述 AWS Config 規則，以測試資料表、Amazon S3 儲存貯體、Amazon EC2 執行個體和 Amazon EBS 磁碟區中描述的強制性金鑰是否存在。 ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` 對於手動管理資源的環境，可以增強 AWS Config 規則，以透過 AWS Lambda 函數使用自動修復自動將遺失的標籤索引鍵新增至資源。雖然這適用於靜態工作負載，但在您開始透過 IaC 和部署管道管理 資源時，其效率會逐漸降低。 **AWS Organizations – 服務控制政策 SCPs)** 是一種組織政策，可用來管理組織中的許可。SCPs可讓您集中控制組織或組織單位 (OU) 中所有帳戶的可用許可上限。SCPs只會影響由屬於組織一部分的帳戶管理的使用者和角色。雖然它們不會直接影響資源，但會限制使用者和角色的許可，其中包含標記動作的許可。在標記方面，除了標籤政策可以提供的標籤之外，SCPs 還可以為標籤強制執行提供額外的精細程度。 在下列範例中，政策會拒絕不存在`example-inc:cost-allocation:CostCenter`標籤的`ec2:RunInstances`請求。 以下是拒絕 SCP： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ 無法依設計擷取套用至連結帳戶的有效服務控制政策。當您使用 SCPs 強制執行標記時，開發人員需要提供文件，以確保其資源符合已套用至其帳戶的政策。在其帳戶中提供 CloudTrail 事件的唯讀存取權，可以支援開發人員在其資源不合規時進行偵錯任務。 # 測量標記有效性並推動改進 實作標記策略之後，請務必針對目標使用案例衡量其有效性。有效性的衡量方式會因使用案例而有所不同。例如： + **成本歸因** - 您可以根據使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)或 [AWS 成本和用量報告](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)等工具的支出來衡量資源的標記涵蓋範圍。例如，您可以追蹤產生費用*的已標記或未標記資源百分比*，特別是監控特定標籤金鑰。 + **自動化** - 如果達到所需的結果，您可能想要稽核。例如，是否在營業時間外暫停非生產 Amazon EC2 執行個體，稽核執行個體開始和停止時間。 管理帳戶中[的資源群組和標籤編輯器](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html)提供額外的功能，以分析組織中所有連結帳戶的標籤政策合規性。 根據標記有效性的測量結果，識別是否需要在任何步驟中進行任何改善或變更，例如使用案例定義、標記結構描述實作或強制執行。進行必要的變更並重複週期，直到達到所需的有效性為止。在成本歸因範例中，您可以查看百分比改善。 由於開發人員和運算子需要執行資源的實際標記，因此讓他們取得所有權至關重要。這並非團隊在 AWS 採用過程中通常承擔的唯一額外責任。提高開發和操作其應用程式的安全性和成本也很重要。組織通常會使用目標和目標做為鼓勵採用新實務的方式，因此也可以在此處套用。