本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 标记用例
**Topics**
+ [成本分配和财务管理的标签](tags-for-cost-allocation-and-financial-management.md)
+ [运营和支持的标签](tags-for-operations-and-support.md)
+ [数据安全、风险管理和访问控制的标签](tags-for-data-security-risk-management-and-access-control.md)
# 成本分配和财务管理的标签
组织通常首先要解决的一个标记用例就是成本和使用情况的可见性和管理。这通常有几个原因：
+ **这通常是一个很好理解的场景，需求也是众所周知的。**例如，财务团队希望查看跨多个服务、特征、账户或团队的工作负载和基础设施的总成本。实现成本可见性的方法之一是对资源进行一致的标记。
+ **明确定义标签及其值。**通常，组织的财务系统中已经存在成本分配机制，例如，按成本中心、业务部门、团队或组织职能进行跟踪。
+ **快速、可观的投资回报。**当资源标记一致时，就可以跟踪一段时间内的成本优化趋势，例如，对资源进行调整、自动扩展或列入计划。
了解自己是如何产生成本的， AWS 可以做出明智的财务决策。了解您在资源、工作负载、团队或组织层面上产生的成本，就能更好地理解与所取得的业务成果相比，在适用层面上所实现的价值。
工程团队可能没有资源财务管理的经验。聘请具有 AWS 财务管理专业技能的人才，能够对工程和开发团队进行 AWS 财务管理基础知识培训，并在财务和工程之间建立关系以培育企业文化， FinOps 这将有助于为业务取得可衡量的成果，并鼓励团队在建设时考虑成本。“架构完善框架的[成本优化支柱](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html)”详细介绍了建立良好的财务实践，但我们将在本白皮书中介绍一些基本原则。
# 成本分配标签
成本分配是指按照既定流程，将发生的成本分配或分发给这些成本的使用者或受益人。在本白皮书的背景下，我们将成本分配分为两种类型：*对账*和*扣款*。
*对账*工具和机制有助于提高成本意识。*扣款*有助于收回成本并提高成本意识。*对账*是关于特定实体（例如业务部门、应用程序、用户或成本中心）产生的成本的列报、计算和报告。例如：“基础设施工程团队负责上个月的 AWS 支出中的 X 美元”。*扣款*是指通过组织的内部会计流程（例如财务系统或会计凭证）将发生的成本实际记入这些实体的账上。例如：“从基础设施工程团队的 AWS 预算中扣除了 X 美元。” 在这两种情况下，对资源进行适当标记都有助于将成本分配给实体，唯一的区别在于是否有人要付款。
贵组织的财务管理部门可能需要对应用程序、业务部门、成本中心和团队层面产生的成本进行透明核算。在[成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)的支持下进行成本归属，可为您提供必要的数据，以准确归属实体从适当标记的资源中产生的成本。
+ **问责制** - 确保将成本分配给负责资源使用的人员。可由单一服务点或小组负责支出审查和报告。
+ **财务透明度** - 通过为领导层创建有效的控制面板和有意义的成本分析，清晰地了解用于 IT 的现金分配情况。
+ **明智的 IT 投资** - 根据项目、应用程序或业务范围跟踪投资回报率，使团队能够做出更好的业务决策，例如，为创收应用程序分配更多资金。
总之，成本分配标签有助于您了解：
+ 谁拥有支出并负责对其进行优化？
+ 哪些工作负载、应用程序或产品产生了支出？ 在哪个环境或阶段？
+ 哪些支出领域增长最快？
+ 根据过去的趋势，可以从 AWS 预算中扣除多少支出？
+ 特定工作负载、应用程序或产品中的成本优化工作会产生什么影响？
为成本分配激活资源标签有助于定义组织内部的衡量实践，这些做法可用于提供 AWS 使用情况的可见性，从而提高支出问责制的透明度。它还侧重于在成本和使用情况可见性方面创建适当的粒度水平，并通过成本分配报告和 KPI 跟踪来影响云使用行为。
# 制定成本分配策略
## 定义和实施成本分配模型
为部署在中的资源创建账户和成本结构 AWS。确定 AWS 支出成本、这些成本是如何产生的，以及这些成本的产生者或原因之间的关系。常见的成本结构基于 AWS Organizations AWS 账户、、环境和组织内的实体，例如业务线或工作负载。成本结构可以基于多种属性，以便以不同方式或不同粒度水平审查成本，例如将单个工作负载的成本汇总到其所服务的业务范围。
在选择与预期成果相一致的成本结构时，应根据*实施的难易程度*和*预期的准确性*来评估成本分配机制。这可能包括问责制、工具可用性和文化变革方面的考虑因素。 AWS 客户通常从三种流行的成本分配模型开始：
+ **基于账户** — 此模型所需的工作量最少，并且可以提供高精度的倒账和退单，适用于具有明确账户结构的组织（并且与《[使用多个账户组织您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)》白皮书中的建议一致）。这样，每个账户的成本都一目了然。在成本可见性和分配方面，您可以使用 [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)、[成本和使用情况报告](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)以及 [AWS 预算](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)进行成本监控和跟踪。这些工具通过以下方式提供筛选和分组选项 AWS 账户。从成本分配的角度来看，这种模式不必依赖于对单个资源的准确标记。
+ **业务部门或基于团队** - 成本可分配给企业内部团队、业务部门或组织。这种模式所需的工作量适中，对账和扣款的准确性较高，适用于具有明确账户结构（通常使用 AWS Organizations）、不同团队、应用程序和工作负载类型之间分开的组织。这为各团队和应用程序提供了清晰的成本可视性，并降低了在单个 AWS 账户内达到 [AWS 服务限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)的风险。例如，每个团队可能有五个帐户（`prod`、`staging`、`test`、`dev`、`sandbox`），并且任何两个团队和应用程序都不会共用同一个账户。拥有这样的结构，[AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 就可以提供将账户或其他标签（“元标记”）归类的功能，并可通过上例中提到的工具进行跟踪。请务必注意， AWS Organizations 允许对账户和组织单位 (OUs) 进行标记，但是这些标签不适用于成本分配和账单报告（也就是说，您不能 AWS Cost Explorer 按组织单位对成本进行分组或筛选）。 AWS 为此应使用 Cost Categories。
+ **基于标签** - 与前两种模式相比，这种模式需要更多的工作量，但可以根据要求和最终目标提供高高准确性的对账和扣款。虽然我们强烈建议您采用 “[使用多个账户组织 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)” 白皮书中概述的做法，但实际上，客户往往会发现自己的账户结构混合而复杂，需要一段时间才能迁移出去。在这种情况下，实施严格有效的标签策略是关键，然后在Billing and Cost Management控制台中[激活相关标签以进行成本分](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)配（在中 AWS Organizations，只能从管理付款人账户激活标签以进行成本分配）。在激活用于成本分配的标签后，就可以使用前面方法中提到的成本可见性和分配工具进行对账和扣款。请注意，成本分配标签不具有追溯性，只有在激活用于成本分配的账单报告和成本跟踪工具后，它们才会出现在账单报告和成本跟踪工具中。
[总而言之，如果您需要按业务部门跟踪成本，则可以使用AWS Cost Categories 对 AWS 组织内的关联账户进行相应的分组，并在账单报告中查看此分组。](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)在为生产环境和非生产环境分别创建账户后，您还可以在 [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html) 等工具中筛选与环境相关的成本，或使用 [AWS 预算](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)跟踪这些成本。最后，如果您的用例需要更精细的成本跟踪，例如按单个工作负载或应用程序进行成本跟踪，则可以对这些账户中的资源进行相应标记，在管理账户上[激活这些用于成本分配的标签密钥](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)，然后在账单报告工具中按标签密钥筛选该成本。
## 建立成本报告和监测程序
首先确定对内部利益相关者重要的成本类型（例如，每日支出、按账户计算的成本、按 X 计算的成本、摊销成本）。这样，与等待最终 AWS 发票相比，您可以更快地降低与意外或异常支出相关的预算风险。标签提供了实现这些报告方案的属性。从报告中获得的洞察力可以为您的行动提供依据，以减轻异常和意外支出对财务预算的影响。当成本出现意外激增时，一定要评估交付的价值是否出现意外激增，这样您就可以确定是否需要采取行动以及需要采取哪些行动。
在制定支持成本分配的标记策略时，应牢记以下要素：
+ **AWS Organizations** - 多个账户内的成本分配可按账户、账户组或为这些账户上的资源创建的标签组进行。为驻留在中的个人账户中的资源创建的标签 AWS Organizations 只能用于管理账户的成本分配。
+ **AWS 账户**-一个账户内的成本分配 AWS 账户 可以通过其他维度（例如服务或区域）来执行。还可以进一步标记账户内的资源，并使用这些资源标签组。
+ **成本分配标签** - 必要时，用户创建的标签和 AWS 生成的标签都可激活，用于成本分配。在账单控制台（中管理账号的 AWS Organizations）中启用成本分配标签有助于处理倒退和退款。
+ C@@ **ost** Categories- AWS Cost Categories 允许在 AWS 组织内对账户进行分组和分组标签（“元标记”），这进一步提供了通过 AWS 预算和 AWS 成本和使用情况报告等 AWS Cost Explorer工具分析与这些类别相关的成本的功能。
## 为企业内的业务部门、团队或组织进行对账和扣款
在成本结构和成本分配标签的支持下，使用成本分配流程进行成本分配。标签可用于向不直接负责支付成本但对产生这些成本负责的团队提供反馈。这种方法使人们了解他们对支出的贡献以及这些费用是如何产生的。向直接负责成本的团队执行扣款，以收回他们所消耗的资源支出，并让他们了解这些成本及其产生的方式。
## 衡量和循环效率或价值 KPIs
商定一组单位成本或 KPI 指标，以衡量您的云财务管理投资的影响。这项工作为技术和业务利益相关者创造了一种共同语言，并讲述了一个基于效率的故事，而不是一个只关注绝对总支出的故事。如需了解更多信息，请查看此博客，其中介绍了[单位指标如何有助于在业务职能之间建立一致性](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/)。
## 分配不可分配的支出
根据组织的会计惯例，不同的收费类型可能需要不同的处理方法。确定无法标记的资源或成本类别。根据所使用的服务和计划使用的服务，商定如何处理和衡量此类不可分配支出的机制。例如，请查看《AWS Resource Groups 和标签用户指南》**中 [AWS Resource Groups 和标签编辑器](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html)支持的资源列表。
无法标记的成本类别的一个常见例子是一些基于承诺的折扣的一些成本，如预留实例 (RI) 和节省计划 (SP)。虽然订阅费用和未使用的 SP 和 RI 成本无法在账单报告工具中提前标记，但您可以在事后跟踪 RI 和 SP 折扣如何应用于 AWS Organizations 中的账户、资源及其标签。例如，可以查看摊销成本，按相关的标签键对支出进行分组，并应用与您的用例相关的筛选条件。 AWS Cost Explorer 在 AWS 成本和使用情况报告 (CUR) 中，您可以筛选出与 RI 和 SP 折扣所涵盖的使用情况相对应的行（请在 [CUR 文档](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)的用例部分中阅读更多内容），然后选择仅与您相关的列。为成本分配而激活的每个标签密钥都将显示在 CUR 报告末尾的单独一栏中，这与其他传统账单报告（例如[月度成本分配报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html)）中的显示方式类似。如需更多参考信息，请查看 [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/) ，了解从 CUR 数据中获取成本和使用情况洞察力的示例。
## 报告
除了可用的 AWS 工具来帮助处理对账和信用卡拒付外，还有一系列其他已 AWS 创建的和第三方的解决方案可以帮助监控标记资源的成本，并衡量标签策略的有效性。根据组织的要求和最终目标，可以投入时间和资源来构建定制的解决方案，也可以购买 [AWS 云 管理工具能力合作伙伴提供的工具](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall)。如果您决定创建自己的*单一真实来源成本分配工具，其中*包含与业务相关的受控参数，则 AWS 成本和使用情况报告 (CUR) 可提供最详细的成本和使用情况数据，并允许创建自定义优化仪表板，允许按账户、服务、成本类别、成本分配标签和其他多个维度进行筛选和分组。在由其开发的基于 CUR 的解决方案中 AWS ，可以用作这些工具之一，请在 Well-Ar AWS chitected Labs 网站上查看[云智能仪表板](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)。
# 运营和支持的标签
一个 AWS 环境将有多个账户、资源和工作负载，其操作要求各不相同。标签可用于提供上下文和指导，以支持运营团队加强对服务的管理。标签还可用于为托管资源提供运营治理的透明度。
推动一致定义运营标签的一些主要因素是：
+ **在自动基础设施活动期间筛选资源。**例如，在部署、更新或删除资源时。另一个是扩大资源规模，以优化成本并减少非工作时间的使用量。有关工作示例，请参阅 [AWS 实例调度程序](https://aws.amazon.com/solutions/implementations/instance-scheduler/)解决方案。
+ **识别孤立或已弃用的资源。**应适当标记已超过规定使用期限或已被内部机制标记为需要隔离的资源，以协助支持人员进行调查。在隔离、存档和删除之前，应标记已弃用的资源。
+ **一组资源的支持要求。**资源通常有不同的支持要求，例如，这些要求可以在团队之间协商确定，也可以作为应用程序关键性的一部分来设定。有关运营模式的更多指导，请参阅[卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)。
+ **加强事件管理流程。**通过对资源进行标记，提高事件管理流程的透明度，支持团队和工程师以及重大事件管理 (MIM) 团队可以更有效地管理事件。
+ **备份。**标签还可用于确定需要备份资源的频率、备份副本的去向或恢复备份的位置。有关 [Backup 和恢复方法的规范性指导。 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html)
+ **修补。**修补运行中的可变实例 AWS 对于您的总体修补策略和修补未修补漏洞都至关重要。有关更广泛的修补策略的更深入的指导，请参阅[规范性指南](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)。本[博客](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)中讨论了修补未修补漏洞的问题。
+ **运营可观察性**。将运营关键绩效指标策略转换为资源标签，有助于运营团队更好地跟踪目标是否得到满足，从而提高业务需求。制定关键绩效指标策略是一个单独的话题，但往往侧重于处于稳定状态的业务运营，或者在哪里衡量变革的影响和成果。[KPI 仪表板](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/)（Wel AWS l-Architected 实验室）和运营 KPI 研讨会（[AWS 企业支持主动](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)服务）都解决了衡量稳定状态下的绩效问题。 AWS 企业战略博客文章[《衡量转型的成功](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/)》探讨了转型计划的关键绩效指标，例如 IT 现代化或从本地迁移到。 AWS
# 自动基础设施活动
在管理基础设施时，标签可用于各种自动化活动。例如，通过使用 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html)，您可以在您创建的已定义密钥值对指定的资源上管理自动化和运行手册。对于托管式节点，您可以定义一组标签，按操作系统和环境跟踪或锁定节点。然后，您可以为组中的所有节点运行更新脚本，或查看这些节点的状态。还可以 [Systems Manager Resources](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html) 进行标记，以进一步完善和跟踪您的自动化活动。
自动化环境资源的启动和停止生命周期可以显著降低任何组织的成本。[AWS上的实例调度程序](https://aws.amazon.com/solutions/implementations/instance-scheduler/)是一个解决方案示例，它可以在不需要时启动和停止 Amazon EC2 和 Amazon RDS 实例。例如，使用 Amazon EC2 或 Amazon RDS 实例的开发人员环境，如果不需要在周末运行，就无法利用关闭这些实例所带来的成本节约潜力。通过分析团队及其环境的需求，并对这些资源进行正确标记以实现自动化管理，就能有效利用预算。
*实例调度程序在 Amazon EC2 实例上使用的调度标签示例：*
```
{
"Tags": [
{
"Key": "Schedule",
"ResourceId": "i-1234567890abcdef8",
"ResourceType": "instance",
"Value": "mon-9am-fri-5pm"
}
]
}
```
# 工作负载生命周期
**审查支持性运营数据的准确性。**确保定期审查与工作负载生命周期相关的标签，并确保相应的利益相关者参与这些审查。
*表 7 - 查看作为工作负载生命周期一部分的运营标签*
| 用例 | 标签密钥 | 理由 | 示例值 |
| --- | --- | --- | --- |
| 账户所有者 | example-inc:account-owner:owner | 账户的所有者及其包含的资源。 | ops-center, dev-ops, app-team |
| 账户所有者审查 | example-inc:account-owner:review | 审查账户所有权详细信息是否最新且正确。 | <以标签库中定义的正确格式表示的审查日期> |
| 数据所有者 | example-inc:data-owner:owner | 存放数据的账户的数据所有者。 | bi-team, logistics, security |
| 数据所有者审查 | example-inc:data-owner:review | 审查数据所有权详细信息是否最新且正确。 | <以标签库中定义的正确格式表示的审查日期> |
## 在迁移到暂停的 OU 之前为暂停的账户分配标签
按照《[使用多个账户组织您的 AWS 环境》白皮书中所述，在暂停账户](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)并进入已暂停的 OU 之前，应在账户中添加标签，以帮助您对账户的生命周期进行内部跟踪和审计。例如，组织的 ITSM 票务系统上的相对网址或票务参考，可显示被暂停的应用程序的审计跟踪记录。
*表 8 - 在工作负载生命周期进入新阶段时添加操作标签*
| 用例 | 标签密钥 | 理由 | 示例值 |
| --- | --- | --- | --- |
| 账户所有者 | example-inc:account-owner:owner | 账户的所有者及其包含的资源。 | ops-center, dev-ops, app-team |
| 数据所有者 | example-inc:data-owner:owner | 存放数据的账户的数据所有者。 | bi-team, logistics, security |
| 暂停状态 | example-inc:suspension:date | 账户被暂停的日期 | <以标记库中定义的正确格式表示的暂停日期> |
| 暂停批准 | example-inc:suspension:approval | 账户暂停批准链接 | workload/deprecation |
# 事件管理
从事件记录、优先级排序、调查、沟通、解决到关闭，标签在事件管理的各个阶段都能发挥重要作用。
标签可详细说明应在何处记录事件、应将事件通知哪个团队或哪些团队，以及定义的上报优先级。请务必记住，标签未加密，因此请考虑您在标签中存储了哪些信息。此外，在组织、团队和报告关系中，职责会发生变化，因此请考虑存储安全门户网站的链接，以便更有效地管理这些信息。这些标签不一定是排他性的。例如，应用程序 ID 可用于在 IT 服务管理门户网站中查找上报路径。请确保在操作定义中明确说明该标签有多种用途。
还可以详细列出操作要求标签，以帮助事件管理人员和操作人员进一步完善应对事件或活动的目标。
[运行手册](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html)和[操作手册](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html)的相关链接（指向知识系统库网址）可作为标签纳入，以帮助响应团队识别相应的流程、程序和文档。
*表 9 - 使用操作标签为事件管理提供信息*
| 用例 | 标签密钥 | 理由 | 示例值 |
| --- | --- | --- | --- |
| 事件管理 | example-inc:incident-management:escalationlog | 支持团队使用的事件记录系统 | jira, servicenow, zendesk |
| 事件管理 | example-inc:incident-management:escalationpath | 上报路径 | ops-center, dev-ops, app-team |
| 成本分配和事件管理 | example-inc:cost-allocation:CostCenter | 按成本中心监控成本。这是一个双重用途标签的示例，其中成本中心被用作事件记录的应用程序代码 | 123-\$1 |
| 备份计划 | example-inc:backup:schedule | 资源备份计划 | Daily |
| 操作手册/事件管理 | example-inc:incident-management:playbook | 有记录的操作手册 | webapp/incident/playbook |
# 修补
通过使用 AWS Systems Manager Patch Manager 和 AWS Lambda，组织可以自动执行针对可变计算环境的修补策略，并使可变实例与该应用环境中定义的补丁基准保持一致。通过将上述实例分配到**补丁组**和**维护**窗口，可以管理这些环境中可变实例的标记策略。有关开发 → 测试 → 生产拆分，请参阅以下示例。[可变实例的补丁管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)有 AWS 规范性指导。
*表 10 — 操作标签可能因环境而异*
| 开发 | 生产前调试 | 生产 |
| --- | --- | --- |
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| {
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
|
也可以通过定义标签来管理未修补漏洞，以补充修补策略。有关详细指导，请参阅使用 [S AWS ystems Manager 进行当天安全修补以避免未修补漏洞](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)。
# 运营可观察性
需要具备可观察性，才能深入了解环境的性能，并帮助您发现和调查问题。它还有一个次要用途，允许您定义和衡量关键性能指标 (KPIs) 和服务级别目标 (SLOs)，例如正常运行时间。对于大多数组织来说，重要的操作 KPIs 是平均检测时间 (MTTD) 和平均事件恢复时间 (MTTR)。
在整个可观察性过程中，上下文非常重要，因为数据收集后，相关的标签也会被收集。无论您关注的是哪种服务、应用程序或应用程序层，您都可以针对特定数据集进行筛选和分析。标签可用于自动加入 CloudWatch 警报，以便在突破某些指标阈值时可以向正确的团队发出警报。例如，标签键`example-inc:ops:alarm-tag`及其值可能表示 CloudWatch 警报已创建。[使用标签为 Amazon EC2 实例创建和维护 Amazon CloudWatch 警报中描述了演示这一点的](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)解决方案。
配置过多的警报很容易造成警报风暴 - 大量警报或通知迅速压垮操作员，降低他们的整体效率，同时操作员还要手动分类各个警报并确定其优先级。可以通过标签的形式提供警报的其他背景，这意味着可以在Amazon内部定义规则， EventBridge 以帮助确保将重点放在上游问题而不是下游依赖关系上。
运营的作用常常 DevOps 被忽视，但是对于许多组织来说，中央运营团队仍然在正常工作时间之外提供关键的第一响应。（有关该模式的更多详细信息，请参阅[卓越运营白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)。） 与负责工作负载的 DevOps 团队不同，他们的知识深度通常不一样，因此标签在仪表板和警报中提供的上下文可以将他们引导到正确的问题运行手册，或者启动自动运行手册（请参阅博客文章 “自动[化 A CloudWatch mazon](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/) Alarms”）。 AWS Systems Manager
# 数据安全、风险管理和访问控制的标签
在妥善处理数据存储和处理方面，Organizations 有不同的需求和义务需要履行。数据分类是访问控制、数据留存、数据分析和合规性等多个用例的重要先决条件。
# 数据安全和风险管理
在一个 AWS 环境中，您的账户可能会有不同的合规性和安全要求。例如，您可能有一个开发人员沙盒和一个托管生产环境的账户，用于处理付款等高度受监管的工作负载。通过将它们隔离到不同的账户中，您可以[应用不同的安全控制措施](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment)，[限制对敏感数据的访问](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data)，并缩小受监管工作负载的审计范围。
对所有工作负载采用单一标准可能会带来挑战。虽然许多控制措施同样适用于整个环境，但对于不需要满足特定监管框架的账户和不会出现个人身份数据的账户（例如，开发人员沙盒或工作负载开发账户）来说，有些控制措施过多或无关紧要。这通常会导致假阳性安全发现，必须在不采取任何行动的情况下对这些调查发现进行分类和关闭，这就占用了本应调查的调查发现的精力。
*表 11 - 数据安全和风险管理标签示例*
| 用例 | 标签密钥 | 理由 | 示例值 |
| --- | --- | --- | --- |
| 事件管理 | example-inc:incident- management:escalationlog | 支持团队使用的事件记录系统 | jira, servicenow, zendesk |
| 事件管理 | example-inc:incident- management:escalationpath | 上报路径 | ops-center, dev-ops, app-team |
| 数据分类 | example-inc:data:classification | 对数据进行分类以实现合规性和治理 | Public, Private, Confidential, Restricted |
| 合规 | example-inc:compliance:framework | 确定工作负载所遵循的合规性框架 | PCI-DSS, HIPAA |
在 AWS 环境中手动管理不同的控件既耗时又容易出错。下一步是自动部署适当的安全控制措施，并根据该账户的分类配置对资源的检查。通过对账户及其中的资源应用标签，可以自动部署控制措施，并根据工作负载进行适当配置。
**示例：**
工作负载包括一个 Amazon S3 存储桶，其标签为 `example-inc:data:classification`，值为 `Private`。安全工具自动部署 AWS Config 规则`s3-bucket-public-read-prohibited`，该规则会检查 Amazon S3 存储桶的阻止公共访问设置、存储桶策略和存储桶访问控制列表 (ACL)，确认存储桶的配置适合其数据分类。为了确保存储桶的内容与分类一致，可以将 [Amazon Macie 配置为检查个人身份信息 (PII)](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/)。在[使用 Amazon Macie 验证 S3 存储桶数据分类](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/)的博客中更深入地探讨了这种模式。
某些监管环境，例如保险和医疗保健，可能需要遵守强制性的数据留存政策。使用标签进行数据留存，再加上 Amazon S3 生命周期策略，可以有效而简单地将对象转移到不同的存储层。Amazon S3 生命周期规则也可用于在强制保留期到期后使对象过期以进行数据删除。有关此过程的深入指南，请参阅[使用 Amazon S3 生命周期对象标签简化数据生命周期](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/)。
此外，在对安全调查发现进行分类或处理时，标签可以为调查人员提供重要的上下文信息，有助于确定风险的性质，并有助于让适当的团队参与调查或减轻调查发现的影响。
# 身份管理和访问控制的标签
在使用管理 AWS 环境中的访问控制时 AWS IAM Identity Center，标签可以启用多种扩展模式。有几种授权模式可以应用，其中一些基于标记。我们将逐一讨论，并提供进一步阅读的链接。
# 单独资源的 ABAC
IAM Identity Center 用户和 IAM 角色支持基于属性的访问权限控制 (ABAC)，允许您根据标签定义对操作和资源的访问。ABAC 有助于减少更新权限策略的需求，并帮助您根据公司目录中的员工属性进行访问。如果您已经在使用多账户策略，则除了基于角色的访问权限控制 (RBAC) 外，还可以使用 ABAC 为在同一账户中操作的多个团队提供对不同资源的精细访问权限。例如，IAM Identity Center 用户或 IAM 角色可以包含限制访问特定 Amazon EC2 实例的条件，否则这些实例必须在每个策略中明确列出才能访问。
由于 ABAC 授权模型依赖标签来访问操作和资源，因此提供防护栏以防止意外访问非常重要。 SCPs 仅允许在特定条件下修改标签，从而可用于保护整个组织的标签。[在 AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/)和 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)中使用服务控制策略确保用于授权的资源标签安全的博客中，提供了有关如何实施的信息。
如果使用使用期长的 Amazon EC2 实例来支持更传统的操作实践，则可以使用这种方法，在[为 Amazon EC2 实例和系统管理器会话管理器配置 IAM Identity Center ABAC](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) 的博客中更详细地讨论了这种基于属性的访问控制形式。如前所述，并非所有资源类型都支持标记，而在支持标记的资源类型中，也并非所有资源类型都支持使用标记策略来执行，因此在 AWS 账户上开始实施这一策略之前，最好先对此进行评估。
要了解支持 ABAC 的服务，请参阅与 IAM 一起使用的 [AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。