本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 制定您的标记策略 与许多运营实践一样，实施标记策略也是*一个不断迭代和改进的过程*。先从当务之急的小处着手，然后根据需要发展标记方案。 ![\[显示标记策略迭代和改进周期的图示\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) 在整个过程中，所有权是问责制和取得进展的关键。由于标签可以用于不同用途，因此可以将总体标记策略划分为组织内部的责任领域。通过标记，可以对依赖于资源特征的活动采取程序化方法。可以从标记中受益的利益相关者的范围取决于组织的规模和运营方式。明确界定参与构建和实施标记战略的团队的职责，可使规模较大的组织从中受益。一些利益相关者可以负责确定标记需求（定义用例）；另一些利益相关者可以负责维护、实施和改进标记策略。 通过分配所有权，您可以很好地实施策略的各个方面。在适当情况下，可以将这种所有权正式确定为策略，并记录在责任矩阵（例如，RACI：负责、问责、咨询和知情）或责任共担模式中。在规模较小的组织中，团队可能在标记策略中扮演多重角色，从需求定义到实施和执行。 # 定义需求和用例 开始构建您的策略时，首先应与具有使用元数据基本需求的利益相关者进行互动。这些团队定义了资源需要标记的元数据，以支持其活动，例如报告、自动化和数据分类。他们概述了需要如何组织资源以及这些资源需要与哪些策略相对应。这些利益相关者在组织中的角色和职能示例包括： + **财务部门**和**业务部门**需要了解投资的价值，将其与成本挂钩，以便在解决低效率问题时优先考虑需要采取的行动。了解*成本与所产生价值*的对比有助于识别不成功的业务部门或产品供应。这样可以就继续提供支持、采用替代方案（例如，使用 SaaS 产品或托管服务）或淘汰没有利润的业务产品作出明智的决策。 + **治理**和**合规部门**需要了解数据的分类（例如，公开、敏感或机密）、特定工作负载是否在特定标准或法规的审计范围内，以及服务的关键性（服务或应用程序是否对业务至关重要），以便应用适当的控制和监督，例如权限、策略和监控。 + **运营**和**开发部门**需要了解工作负载生命周期、所支持产品的实施阶段、发布阶段的管理（例如，开发、测试、生产拆分）及其相关的支持优先级和利益相关者管理要求。还需要定义和理解备份、补丁、可观察性和报废等职责。 + **信息安全 (InfoSec)** 和**安全操作 (SecOps)** 概述了必须应用哪些控制措施以及推荐使用哪些控制措施。 InfoSec 通常定义控制措施的实施情况，并 SecOps 通常负责管理这些控制措施。 根据您的用例、优先级、组织规模和运营实践，您可能需要组织内不同团队的代表，例如财务（包括采购）、信息安全、云支持和云运营。您还需要应用程序和流程所有者的代表，以实现补丁、备份和恢复、监控、任务调度和灾难恢复等功能。这些代表有助于推动标记策略的定义、实施和效果评估。他们应从利益相关者及其用例出发[https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM)，并且开展跨职能研讨会。在研讨会上，他们有机会分享自己的观点和需求，并帮助制定整体战略。本白皮书稍后将举例说明各种用例中的参与者及其参与情况。 利益相关者还可以定义和验证强制性标签的密钥，并就可选标签的范围提出建议。例如，财务团队可能需要将资源与内部成本中心、业务部门或两者相关联。因此，他们可能会要求将某些标签密钥（例如 `CostCenter` 和 `BusinessUnit`）设为强制性。个别开发团队可能会决定使用其他标签来实现自动化，例如 `EnvironmentName`、`OptIn` 或 `OptOut`。 主要利益相关者需要就标记策略方法达成共识，并记录合规性和治理相关问题的答案，例如： + 需要解决哪些用例？ + 谁负责标记资源（实施）？ + 如何执行标签，将使用哪些方法和自动化（主动或被动）？ + 如何衡量标记的有效性和目标？ + 应多久审查一次标记策略？ + 谁来推动改进？ 如何做到这一点？ 然后，云赋能、云业务办公室和云平台工程等业务职能部门可以在制定标记策略的过程中发挥促进者的作用，通过衡量进度、消除障碍和减少重复工作等方面帮助推动标记策略的采用并确保应用的一致性。 # 定义和发布标记方案 使用一致的方法对 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 | 否 | 全部 | 全部 | 可选 | | 自动化 | example-inc:automation:EnvironmentId | 实施测试和开发环境调度，也称为软件开发生命周期 (SDLC) 阶段 | Prod, Dev, Test, Sandbox | N | EC2、RDS、EBS | 全部 | 强制性 | | DevOps | example-inc:operations:Owner | team/squad 它负责资源的创建和维护 | Squad01 | 否 | 全部 | 全部 | 强制性 | | 灾难恢复 | example-inc:disaster-recovery:rpo | 定义资源的恢复点目标 (RPO) | 6h, 24h | N | S3、EBS | Prod | 强制性 | | 数据分类 | example-inc:data:classification | 对数据进行分类以实现合规性和治理 | Public, Private, Confidential, Restricted | N | S3、EBS | 全部 | 强制性 | | 合规 | example-inc:compliance:framework | 确定工作负载所遵循的合规性框架 | PCI-DSS, HIPAA | 否 | 全部 | Prod | 强制性 | 定义标记方案后，应在版本控制的存储库管理方案，所有相关利益相关者都可以访问该存储库，以便于参考和跟踪更新。这种方法提高了效率，实现了灵活性。 # 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_cn/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) 和持续 integration/continuous 交付 (CI/CD)。这些方法的关键在于部署的频率越来越高。 ## 手动托管的资源 这些通常是属于[采用基础或迁移阶段](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)的工作负载。通常，这些工作负载基本上是静态的，是使用传统的书面程序构建的，或者*是*使用诸如 AWS Application Migration Service 本地环境之类的工具按原样迁移的工作负载。迁移工具（例如 Migration Hub 和应用程序迁移服务）可以在迁移过程中应用标签。但是，如果在原始迁移期间未应用标签，或者此后标记架构发生了变化，则[标签编辑器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)（的功能 AWS 管理控制台）允许您使用各种搜索条件搜索资源并批量添加、修改或删除标签。搜索条件可以包括带有或不带有特定标签或值的资源。 AWS 资源标记 API 允许您以编程方式执行这些功能。 随着这些工作负载的现代化，引入了诸如自动扩缩组等资源类型。这些资源类型具有更大的弹性和更强的故障恢复能力。自动扩缩组代表您管理 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)提供了指定自动扩缩应应用于其创建的实例的标签的方法。 当手动管理工作负载的资源时，自动标记资源会很有帮助。目前有多种解决方案。一种方法是使用 AWS Config 规则，它可以检查`required_tags`并启动 Lambda 函数来应用它们。 AWS Config 规则 稍后将在本白皮书中详细介绍。 ## 基础设施即代码 (IaC) 托管资源 AWS CloudFormation 提供了一种通用语言，用于在您的 AWS 环境中配置所有基础架构资源。 CloudFormation 模板是以自动方式创建 AWS 资源的 JSON 或 YAML 文件。使用 CloudFormation模板创建 AWS 资源时，您可以使用 CloudFormation 资源标签属性在创建时将标签应用于支持的资源类型。使用 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::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)需要在 AWS CloudFormation 模板的 Auto Scaling 组定义中进行设置。另外，如果您使用的是带有自动扩缩组的 [EC2 启动模板](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)，则可以在其定义中定义标签。建议将 [EC2 启动模板](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)与 Auto Scaling 群组或 AWS 容器服务一起使用。这些服务有助于确保对 Amazon EC2 实例进行一致的标记，还支持[跨多种实例类型和购买选项的自动扩缩](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)，从而提高故障恢复能力并优化计算成本。 [AWS CloudFormation Hooks](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 防护规则集。 ## 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` ## 执行 如前所述，R **esource Groups & Tag Editor** 提供了一种方法来识别您的资源无法满足应用于组织的标签策略中定义 OUs 的标记要求的地方。从 Organization 成员账户访问**资源组和标签编辑器**控制台工具，会显示适用于该账户的策略，以及该账户中不符合标签策略要求的资源。如果通过管理账户进行访问（如果**标签策略**已在下属的服务中*启用了访问*权限 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-成本分配.json 以下是报告 and/or 强制执行成本分配标签的标签策略示例： ``` { "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 采用过程中通常承担的唯一额外责任。对开发和运行其应用程序的安全性和成本承担更多责任也很重要。Organizations 经常使用目标和指标作为激励采用新实践的手段，因此这也适用于此处。