

# 支出和使用情况意识
<a name="a-expenditure-and-usage-awareness"></a>

**Topics**
+ [COST 2. 如何管理使用情况？](cost-02.md)
+ [COST 3. 如何监控成本和使用情况？](cost-03.md)
+ [COST 4. 如何停用资源？](cost-04.md)

# COST 2. 如何管理使用情况？
<a name="cost-02"></a>

制定各种策略和机制，确保花费适当的成本来达到目标。采用制约与平衡方法，您可以在不超支的情况下进行创新。

**Topics**
+ [COST02-BP01 根据组织的要求制定各种策略](cost_govern_usage_policies.md)
+ [COST02-BP02 实施方向性目标和执行性目标](cost_govern_usage_goal_target.md)
+ [COST02-BP03 实施账户结构](cost_govern_usage_account_structure.md)
+ [COST02-BP04 实施组和角色](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 实施成本控制](cost_govern_usage_controls.md)
+ [COST02-BP06 跟踪项目生命周期](cost_govern_usage_track_lifecycle.md)

# COST02-BP01 根据组织的要求制定各种策略
<a name="cost_govern_usage_policies"></a>

制定策略，确定组织应该如何管理资源，并定期执行检查。策略应该涵盖资源和工作负载的成本，包括在资源生命周期内的创建、修改和停用。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

了解组织的成本和驱动因素，对于有效管理成本和使用情况以及找到降低成本的机会至关重要。在组织中，通常会有多个团队运行多个工作负载。这些团队可能在不同的组织单位，每个单位都有自己的收入来源。将资源成本分摊到工作负载、各个组织或产品负责人，这样既推动更高效的资源使用模式，又能减少浪费。准确的成本和使用情况监控有助于您了解如何优化工作负载，以及各部门和产品的盈利能力。利用这些知识，可以就在组织内的何处分配资源作出更明智的决策。组织中各层级的人员都了解使用情况是推动变化的关键，因为使用情况变化会导致成本变化。考虑采用多元方法来了解使用情况和支出情况。

执行治理的第一步是按照组织要求来针对云的使用制定策略。这些策略定义组织如何使用云以及如何管理资源。策略应涵盖与成本或使用情况有关的资源和工作负载的所有方面，包括资源生命周期内的创建、修改和停用。确认云环境中的任何更改都是遵循相应策略和程序实施的。在 IT 变更管理会议期间，提出问题以了解计划变更的成本影响（无论是增加还是减少）、业务理由以及预期结果。

策略应该简单易懂，能够在整个组织中有效实施。策略还需要易于遵守和解释（以便落实），并且要具体（不会在各团队之间造成误解）。此外，需要定期审查这些策略（例如我们的机制），并在客户业务状况或业务优先级发生变化时及时更新策略，以免导致策略过时。

 从广泛的、高层级的策略开始，例如使用哪个地理区域，或者一天中应该运行资源的时间。逐步为各组织单位和工作负载细化策略。常见策略包括可以使用哪些服务和功能（例如，测试和开发环境中性能较低的存储），哪些类型的资源可供不同团队使用（例如，开发账户中最大规模的资源为中等大小），以及这些资源将使用多长时间（可能是临时使用、短期使用或在特定时间段内使用）。

 **策略示例** 

 以下是侧重于成本优化的策略示例，可以参考该策略来创建自己的云治理策略。请确保根据组织和利益相关方的要求调整策略。
+  **策略名称：**定义清晰的策略名称，例如“资源优化和成本削减策略”。
+  **目的：**解释为什么应使用此策略以及预期结果如何。此策略的目标是确认，在为了满足业务要求而部署和运行所需工作负载方面，有最低的成本要求。
+  **范围：**明确定义谁应使用此策略以及何时应使用此策略，例如 DevOps X 团队，为美国东部的客户在 X 环境（生产或非生产）中使用此策略。

 **策略声明** 

1.  根据工作负载的环境和业务要求（开发、用户验收测试、预生产或生产），选择 us-east-1 或多个美国东部区域。

1.  安排 Amazon EC2 和 Amazon RDS 实例在早上 6 点到晚上 8 点 [美国东部标准时间（EST）] 之间运行。

1.  在处于不活动状态 8 小时之后，停止所有未使用的 Amazon EC2 实例，在处于不活动状态 24 小时之后，停止未使用的 Amazon RDS 实例。

1.  在非生产环境中处于不活动状态 24 小时之后，终止所有未使用的 Amazon EC2 实例。提醒 Amazon EC2 实例拥有者（根据标签）查看其生产环境中已停止的 Amazon EC2 实例，并告知他们，如果其 Amazon EC2 实例在 72 小时内未使用，将会被终止。

1.  使用通用实例系列和大小（如 m5.large），然后使用 AWS Compute Optimizer，根据 CPU 和内存利用率调整实例大小。

1.  优先使用自动扩缩，根据流量动态调整运行的实例数量。

1.  为非关键工作负载使用竞价型实例。

1.  查看容量需求，为可预测的工作负载使用节省计划或预留实例，并通知云财务管理团队。

1.  使用 Amazon S3 生命周期策略，将不经常访问的数据移动到更便宜的存储层。如果未定义保留策略，请使用 Amazon S3 Intelligent Tiering，自动将对象移动到存档层。

1.  使用 Amazon CloudWatch 监控资源利用率并设置警报来触发扩展事件。

1.  对于每个 AWS 账户，使用 AWS Budgets，根据成本中心和业务单位为您的账户设置成本和使用情况预算。

1.  使用 AWS Budgets 为账户设置成本和使用情况预算，有助于您控制支出和避免意外账单，从而更好地控制成本。

 **程序：**提供实施此策略的详细过程，或参考介绍如何实施各个策略声明的其他文档。此部分应提供关于如何执行策略要求的分步说明。

 要实施此策略，可以使用各种第三方工具或 AWS Config 规则来检查是否符合策略声明，并使用 AWS Lambda 函数触发自动修复操作。您也可以使用 AWS Organizations 来强制执行策略。此外，您应定期查看资源使用情况，并在必要时调整策略，以确认策略继续满足业务需求。

## 实施步骤
<a name="implementation-steps"></a>
+  **与利益相关方交流：**要制定策略，让组织内的利益相关方（云业务办公室、工程师或实施策略的职能部门决策者）详细说明他们的要求并记录下来。采用迭代方法，首先大致进行，然后在每一步中不断细化到最小单元。团队成员包括与工作负载切身相关的人员（例如组织单位或应用程序负责人）以及支持小组（例如安全和财务团队）。
+  **获得确认：**确保团队就哪些人可以访问和部署到 AWS 云 的策略达成一致。确保这些人遵守组织的策略，并确认其资源创建符合商定的策略和程序。
+  **创建入职培训课程：**要求新组织成员完成入职培训课程，以建立成本意识并了解组织要求。他们可能会采取不同于以往经验的策略，或者根本不考虑这些策略。
+ **定义运行工作负载的位置：**定义工作负载的运行位置，包括国家/地区以及国家/地区中的区域。此信息用于映射到 AWS 区域 和可用区。
+ **定义服务和资源并对其进行分组：**定义工作负载所需的服务。对于每项服务，指定类型、大小和所需资源数量。按职能定义资源组，如应用程序服务器或数据库存储。资源可属于多个组。
+  **定义用户并按职能对其进行分组：**定义与工作负载交互的用户，侧重于用户的工作范畴及其使用工作负载的方式，而不是侧重于他们的身份或其在组织中的职位。将类似用户或职能分组在一起。可以使用 AWS 托管式策略作为指南。
+ **定义操作：**使用前面确定的位置、资源和用户，定义每项在其生命周期（开发、运行和停用）内实现工作负载成果所需的操作。根据每个位置的组（而不是组中的个别元素）确定操作。首先广泛读写，然后细化到每项服务的具体操作。
+ **定义审核期：**工作负载和组织要求可能会随着时间的推移而发生变化。定义工作负载审核计划，确保其与组织优先事项保持一致。
+  **记录策略：**确认已定义的策略是否可按组织的要求访问。这些策略用于实施、维护和审核对环境的访问。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [云中的变更管理](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html) 
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [AWS 服务的操作、资源和条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) 
+  [AWS 管理和治理](https://aws.amazon.com/products/management-and-governance/) 
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [全球基础设施区域和可用区](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 

 **相关视频：**
+  [大规模的 AWS 管理和治理](https://www.youtube.com/watch?v=xdJSUnPcPPI) 

# COST02-BP02 实施方向性目标和执行性目标
<a name="cost_govern_usage_goal_target"></a>

 实施工作负载的成本和使用情况方向性目标和执行性目标。方向性目标为组织在预期结果方面指明了方向，而执行性目标则提供了要为工作负载实现的具体可衡量结果。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 为组织制定成本和使用情况方向性目标和执行性目标。作为一个在 AWS 上不断发展壮大的组织，针对成本优化设定方向性目标并进行跟踪，这一点非常重要。这些目标或[关键绩效指标（KPI）](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/)可以是按需支出百分比等内容，也可以是采用某些优化服务（比如 AWS Graviton 实例或 gp3 EBS 卷类型）。设定可衡量且可实现的方向性目标，有助于您衡量效率的提高情况，这对于业务运营不可或缺。方向性目标为组织提供有关预期结果的指引和方向。

 执行性目标则明确要实现的具体可衡量的结果。简言之，方向性目标是指您前进的方向，而执行性目标就是在这个方向上的进展情况，以及应何时实现这个目标（使用具体、可衡量、可分配、切合实际、适时的指导原则，即 SMART 指导原则）。方向性目标的一个示例是：在略微（非线性）增加成本的情况下，显著提升平台使用量。执行性目标的一个示例是：在成本增长不到 5% 的情况下，将平台使用量提升 20%。另一个常见的方向性目标是每 6 个月提高一次工作负载的效率。相应的执行性目标则是，需要每 6 个月将各项业务指标的成本缩减 5%。使用正确的指标，合理计算来为组织设定 KPI。可以从基本 KPI 开始，以后再根据业务需求进行改进。

 就成本优化而言，其方向性目标是提高工作负载效率，这对应于逐步降低每项业务成果的工作负载成本。为所有工作负载实施此方向性目标，并设定执行性目标，例如每 6 至 12 个月将效率提高 5%。在云端，可以通过培养成本优化能力以及发布新服务和功能来做到这一点。

 执行性目标是您为实现方向性目标而要达到的可量化基准，这些基准将您的实际结果与执行性目标进行比较。使用 KPI 为计算服务（例如竞价型实例采用、Graviton 采用、最新实例类型和按需覆盖范围）、存储服务（例如 EBS GP3 采用、过时的 EBS 快照和 Amazon S3 Standard 存储）或数据库服务使用情况（例如 RDS 开源引擎、Graviton 采用和按需覆盖范围）的单位成本建立基准。这些基准和 KPI 有助于验证您是否通过最经济高效的方式使用 AWS 服务。

 下表提供了标准 AWS 指标列表以供参考。每个组织都可以为这些 KPI 设定不同的执行性目标值。


|  类别  |  KPI  |  描述  | 
| --- | --- | --- | 
|  计算  |  EC2 使用情况覆盖率  |  使用 SP\$1RI\$1Spot 的 EC2 实例（以成本或小时计）与 EC2 实例的总计（以成本或小时计）的比较  | 
|  计算  |  计算 SP/RI 使用率  |  使用的 SP 或 RI 小时数与可用 SP 或 RI 总小时数的比较  | 
|  计算  |  EC2/小时成本  |  EC2 成本除以该小时内运行的 RDS 实例数量  | 
|  计算  |  vCPU 成本  |  所有实例每个 vCPU 的成本  | 
|  计算  |  最新一代实例  |  Graviton（或其他现代实例类型）上的实例百分比  | 
|  数据库  |  RDS 覆盖率  |  使用 RI 的 RDS 实例（以成本或小时计）与 RDS 实例的总计（以成本或小时计）的比较  | 
|  数据库  |  RDS 使用率  |  使用的 RI 小时数与可用 RI 总小时数的比较  | 
|  数据库  |  RDS 正常运行时间  |  RDS 成本除以该小时内运行的 RDS 实例数量  | 
|  数据库  |  最新一代实例  |  Graviton（或其他现代实例类型）上的实例百分比  | 
|  存储  |  存储使用率  |  优化的存储成本（例如 Glacier、Deep Archive 或不频繁访问）除以总存储成本  | 
|  标记  |  未标记的资源  |   Cost Explorer：  1. 筛选出服务抵扣金、折扣、税款、退款、商城，并复制最新的月度成本   2. 在 Cost Explorer 中选择**仅显示未标记的资源**   3. 将**未标记资源**中的数字除以每月成本。  | 

 此表包含执行性目标值或基准值，这些值应根据您的组织目标计算得出。您需要衡量业务的某些指标，并了解该工作负载的业务成果，以便确立准确、切合实际的 KPI。在评估组织内部的绩效指标时，要区分用于不同目的的各类指标。这些指标主要衡量技术基础设施的性能和效率，而不是直接衡量总体业务影响。例如，它们可能会跟踪服务器响应时间、网络延迟或系统正常运行时间。要评测基础设施能否有效支持组织的技术运营，这些指标必不可少。但是，您无法通过它们直接了解更广泛的业务目标，例如客户满意度、收入增长或市场份额。要全面了解业务绩效，请使用与业务成果直接相关的战略业务指标，补充这些效率指标。

 您需要能够近乎实时地监控 KPI 及相关的成本节省机会，并不断跟踪进度。要着手定义和跟踪 KPI 目标，我们建议使用 [Cloud Intelligence Dashboard](https://wellarchitectedlabs.com/cloud-intelligence-dashboards/)（CID）中的 KPI 控制面板。根据来自成本和使用情况报告（CUR）的数据，KPI 控制面板提供了一系列建议的成本优化 KPI，能够设定自定义的方向性目标并不断跟踪进度。

 如果通过其他解决方案来设定和跟踪 KPI 方向性目标，请务必让组织中的所有云财务管理利益相关方都采用这些方法。

### 实施步骤
<a name="implementation-steps"></a>
+  **定义预期使用量：**首先，重点关注使用水平。与应用程序负责人、营销团队和更大的业务团队交流，了解工作负载的预期使用水平。客户需求可能如何随时间而变化？会因季节性增长或营销活动发生哪些变化？ 
+  **定义工作负载资源和成本:**定义使用水平后，量化满足这些使用量所需的工作负载资源变化。您可能需要增加工作负载组件的资源大小或数量，增加数据传输，或者在特定级别将工作负载组件更改为不同的服务。明确每个关键点的成本，并预测使用情况发生变化时的成本变化。
+  **定义业务目标：**从预期的使用情况和成本变化中获取输出，将其与预期的技术变化或正在开展的任何计划相结合，制定工作负载目标。方向性目标必须阐明使用情况和成本，以及两者之间的关系。方向性目标必须简明扼要，并能让人们了解企业对结果的期望（例如，确保未使用的资源保持在一定的成本水平以下）。您不需要为每种未使用的资源类型定义方向性目标，也不需要定义会导致方向性目标和执行性目标损失的成本。确认制定有组织计划（例如培训和教育等能力培养计划），以防成本呈预期变化，而使用情况无变化。
+  **定义执行性目标：**对于定义的每个方向性目标，指定一个可衡量的执行性目标。如果方向性目标是提高工作负载的效率，则执行性目标将量化改进量（通常为每一美元支出的业务产出）及获益时间。例如，可以设定一个方向性目标，最大限度地减少因过度预置而造成的浪费。有了此方向性目标，执行性目标可以是，因第一层生产工作负载中的计算过度预置而造成的浪费不应超过层级计算成本的 10%。此外，第二个执行性目标可以是，因第二层生产工作负载中的计算过度预置而造成的浪费不应超过层级计算成本的 5%。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [S.M.A.R.T. 目标](https://en.wikipedia.org/wiki/SMART_criteria) 
+  [How to track your cost optimization KPIs with the CID KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/) 

 **相关视频：**
+  [Well-Architected Lab：方向性目标和执行性目标（第 100 级）](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/150-goals-and-targets) 

 **相关示例：**
+  [什么是单位指标？](https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/) 
+  [选择单位指标来支持您的业务](https://aws.amazon.com/blogs/aws-cost-management/selecting-a-unit-metric-to-support-your-business/) 
+  [实践中的单位指标 – 经验教训](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-in-practice-lessons-learned/) 
+  [单位指标如何有助于在业务职能之间建立一致性](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-help-create-alignment-between-business-functions/) 

# COST02-BP03 实施账户结构
<a name="cost_govern_usage_account_structure"></a>

 实施与组织对应的账户结构。这有助于在整个组织内分摊和管理成本。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 AWS Organizations 允许创建多个 AWS 账户，这有助于在扩展 AWS 上的工作负载时集中管理环境。可以通过在组织单位（OU）结构中分组 AWS 账户，并在每个 OU 下创建多个 AWS 账户，对组织层次结构进行建模。要创建账户结构，首先需要确定哪个 AWS 账户 将成为管理账户。之后，可以按照[管理账户最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成员账户最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)，根据设计的账户结构创建新 AWS 账户 或选择现有账户作为成员账户。

 建议无论组织规模或使用情况如何，始终至少有一个管理账户和一个与之链接的成员账户。所有工作负载资源应仅驻留在成员账户中，不应在管理账户中创建任何资源。对于您应该拥有多少个 AWS 账户 这一问题，没有标准答案。评测当前和未来的运营和成本模型，确保 AWS 账户 结构反映了组织的目标。有些公司出于业务原因会创建多个 AWS 账户，例如：
+ 需要在组织部门、成本中心或特定工作负载之间实施管理或财务和计费隔离。
+ AWS 服务限制设置为针对特定工作负载。
+ 必须对工作负载和资源进行隔离和分离。

 在 [AWS Organizations](https://aws.amazon.com/organizations/) 内，[整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)会在一个或多个成员账户与管理账户之间创建结构。通过成员账户，可以按组隔离和区分成本和使用情况。常见做法是每个组织部门（如财务、营销和销售）、每个环境生命周期（如开发、测试和生产）或每个工作负载（工作负载 a、b 和 c）具有单独的成员账户，然后使用整合账单将这些关联账户汇总在一起。

 通过整合账单，可以将多个成员 AWS 账户 的付款整合至一个管理账户下，同时仍可查看每个关联账户的活动。由于成本和使用情况在管理账户中汇总，因此，可以最大限度地提高服务量折扣，并最大限度地利用承诺折扣（节省计划和预留实例）来获得最高折扣。

 下图显示了如何对组织单位（OU）使用 AWS Organizations，以对多个账户进行分组，并在每个 OU 下放置多个 AWS 账户。建议将 OU 用于各种应用场景和工作负载，这提供了组织账户的模式。

![\[树状图中显示了如何在组织单位下对多个账户进行分组。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/aws-organizations-ou-grouping.png)


 [AWS Control Tower](https://aws.amazon.com/controltower/) 可以快速设置和配置多个 AWS 账户，确保治理符合组织要求。

**实施步骤** 
+  **定义分离要求：**分离要求涉及多项因素，包括安全性、可靠性和财务结构。按顺序阐明每项因素，并详细说明工作负载或工作负载环境是否应与其他工作负载分开。安全性有助于满足访问和数据要求。可靠性管理限制，以便环境和工作负载不会影响其他项。定期查看 Well-Architected Framework 的安全性和可靠性支柱，并遵循提供的最佳实践。财务结构创建严格的财务分离（不同的成本中心、工作负载所有权和问责制）。常见的分离示例包括在单独的账户中运行生产和测试工作负载，或使用单独的账户，以便可以将发票和账单数据提供给组织中的单个业务单位或部门，或拥有该账户的利益相关方。
+  **定义分组要求：**分组要求并不覆盖分离要求，而是用于协助管理。将无需分离的类似环境或工作负载分组在一起。例如，将一个或多个工作负载的多个测试或开发环境分组在一起。
+  **定义账户结构：**使用这些分离和分组，为每个组指定一个账户，并确保持续满足分离要求。这些账户有成员账户或关联账户。通过将这些成员账户分组到一个管理账户或付款人账户下，可以合并使用量，从而可以跨所有账户享有更大的批量折扣，这为所有账户提供一个账单。可以分离账单数据，并为每个成员账户提供其账单数据的单独视图。如果成员账户不能让任何其他账户看到自己的使用情况或账单数据，或者，如果需要 AWS 提供单独的账单，请定义多个管理账户或付款人账户。在这种情况下，每个成员账户都有自己的管理账户或付款人账户。资源应始终放置在成员账户或关联账户中。管理账户或付款人账户应只用于管理。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [使用成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Control Tower](https://aws.amazon.com/controltower/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  [管理账户](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)和[成员账户](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)的最佳实践 
+  [使用多个账户整理您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) 
+  [开启共享的预留实例和节省计划折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 
+  [整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 
+  [整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 

 **相关示例：**
+  [拆分 CUR 并共享访问权限](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html) 

 **相关视频：**
+ [AWS Organizations 简介](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [为 AWS Organizations 设置使用最佳实践的多账户 AWS 环境](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)

 **相关示例：**
+  [为电信公司定义 AWS 多账户策略](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/) 
+  [Best Practices for Optimizing AWS 账户](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/) 
+  [Best Practices for Organizational Units with AWS Organizations](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) 

# COST02-BP04 实施组和角色
<a name="cost_govern_usage_groups_roles"></a>

 实施与策略一致的组和角色，控制每个组中谁可以创建、修改或停用实例和资源。例如，实施开发组、测试组和生产组。这适用于 AWS 服务和第三方解决方案。

 **在未建立这种最佳实践的情况下暴露的风险等级：**低 

## 实施指导
<a name="implementation-guidance"></a>

用户角色和组是设计和实施安全、高效的系统的基本构件。角色和组有助于组织在控制力需求与灵活性和生产率要求之间取得平衡，最终满足组织目标和用户需求。正如 AWS Well-Architected Framework 安全性支柱的[身份与访问管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html)部分所建议的那样，您需要强大的身份管理和权限，以便在适当的条件下为合适的人员提供对正确资源的访问权限。用户仅获得完成任务所需的访问权限。这可最大限度地降低与未经授权访问或滥用相关的风险。

 制定策略后，可以在组织内创建逻辑组和用户角色。这让您可以分配权限、控制使用情况，并有助于实施强健的访问控制机制，防止未经授权访问敏感信息。从大致的人员分组开始，这通常与组织单位和岗位角色（例如，IT 部门的系统管理员、财务主管或业务分析师）对应。这些组将执行相似任务并需要相似访问权限的人员划分在一起。角色定义组必须做什么。管理组和角色的权限比管理单个用户的权限更容易。角色和组可一致且系统性地为所有用户分配权限，防止出现错误和不一致。

 当用户的角色发生变化时，管理员可以在角色或组级别上调整访问权限，而不是重新配置单个用户账户。例如，IT 部门的系统管理员需要创建所有资源的权限，而分析团队成员仅需要创建分析资源。

### 实施步骤
<a name="implementation-steps"></a>
+ **实施组：**如有必要，请使用组织策略中定义的用户组实施相应的组。有关用户、组和身份验证的最佳实践，请参阅 AWS Well-Architected Framework 的[安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。
+ **实施角色和策略：**使用组织策略中定义的操作，创建所需的角色和访问策略。有关角色和策略的最佳实践，请参阅 AWS Well-Architected Framework 的[安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/iam/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [AWS Well-Architected Framework 安全性支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) 
+ [AWS Identity and Access Management（IAM）](https://aws.amazon.com/iam/)
+ [AWS Identity and Access Management 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)

 **相关视频：**
+ [为何使用身份与访问管理](https://www.youtube.com/watch?v=SXSqhTn2DuE)

 **相关示例：**
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [开启您的云财务管理之旅：云成本运营](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)

# COST02-BP05 实施成本控制
<a name="cost_govern_usage_controls"></a>

 根据组织策略以及定义的组和角色来实施控制。这样可以确保成本只根据组织要求的规定产生，例如，控制用户对区域或资源类型的访问。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

实施成本控制的第一步通常是进行相关通知设置，以便在发生成本或使用情况超出策略的事件时触发通知。可以迅速采取行动，并验证是否需要采取纠正措施，而不会限制工作负载或新活动，抑或是对它们产生负面影响。了解工作负载和环境限制后，就可以强制实施治理。[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 允许您为 AWS 成本、使用情况和承诺折扣（节省计划和预留实例）设置通知和定义每月预算。可以在总成本级别（如所有成本）创建预算，也可以在更细粒度的级别创建预算，其中只包含特定的维度，如关联的账户、服务、标签或可用区。

 使用 AWS Budgets 设置预算限制后，请使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 来降低意外成本。AWS Cost Anomaly Detection 是一种成本管理服务，它使用机器学习来持续监控成本和使用情况，以检测异常支出。它可以帮助您识别异常支出和根本原因，以便您可以快速采取行动。首先，在 AWS Cost Anomaly Detection 中创建成本监控，然后通过设置美元阈值来选择提醒首选项（例如，对影响大于 1000 美元的异常情况发出提醒）。收到提醒后，可以分析造成异常情况的根本原因，以及对成本的影响。您还可以在 AWS Cost Explorer 中监控并执行自己的异常分析。

 在 AWS 中通过 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 和 [AWS Organizations 服务控制策略（SCP）强制执行治理策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html)。借助 IAM，可以安全地管理对 AWS 服务和资源的访问。可以使用 IAM 控制谁能创建或管理 AWS 资源、可创建的资源类型，以及可在何处创建。这最大限度地降低了在定义的策略之外创建资源的可能性。使用先前创建的角色和组，并分配 [IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)以强制实施正确的使用量。SCP 用于集中管控组织中所有账户的最大可用权限，从而确保账户始终在访问控制准则允许的范围内。SCP 仅在启用了所有功能的组织中可用，并且可以将 SCP 配置为默认情况下拒绝或允许对成员账户执行操作。有关实施访问管理的更多详细信息，请参阅《[Well-Architected 安全性支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)》。

 也可以通过 [AWS 服务配额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)管理实施治理。通过确保为服务配额设置最低开销并进行准确维护，可以最大限度地减少组织要求以外的资源创建。要实现这一点，必须了解要求的改变速度、正在进行的项目（资源的创建和停用），并考虑配额更改的实施速度。必要时，[服务配额](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)可用于增加配额。

**实施步骤**
+ **实施支出通知：**使用定义的组织策略，创建 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 以在支出超出策略时收到通知。配置多个成本预算，每个账户一个，以通知您账户的总支出情况。在每个账户中为该账户内的较小单元配置额外的成本预算。这些单元因账户结构而异。一些常见示例包括 AWS 区域、工作负载（使用标签）或 AWS 服务。将电子邮件通讯组列表配置为通知的收件人，而不是个人的电子邮件账户。可以为超出金额的情况配置实际预算，或者使用预测预算通知预测使用情况。还可以预配置 AWS Budgets 操作，以强制实施特定 IAM 或 SCP 策略，或停止目标 Amazon EC2 或 Amazon RDS 实例。可以自动执行预算操作，也可以要求工作流程审批。
+  **对异常支出实施通知：**使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 降低组织中的意外成本，并分析潜在异常支出的根本原因。创建成本监控来以指定粒度识别异常支出，并在 AWS Cost Anomaly Detection 中配置通知后，它会在检测到异常支出时向您发送提醒。这将让您能够分析导致异常的根本原因，并了解对成本的影响。配置 AWS Cost Anomaly Detection 时使用 AWS 成本类别来确定哪个项目团队或业务部门团队可以分析导致意外成本的根本原因，并及时采取必要的措施。
+ **实施使用情况控制：**使用定义的组织策略，实施 IAM 策略和角色，指定用户可执行和无法执行的操作。一个 AWS 策略中可能包含多个组织策略。采用定义策略时所用的方式，首先大致进行，然后在每一步施加更细粒度的控制。服务限制也是一种有效的使用情况控制措施。对所有账户实施正确的服务限制。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 
+  [AWS 多账户计费策略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/) 
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 
+  [控制您的 AWS 成本](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/) 

 **相关视频：**
+  [如何使用 AWS Budgets 来跟踪我的支出和使用情况](https://www.youtube.com/watch?v=Ris23gKc7s0) 

 **相关示例：**
+  [IAM 访问管理策略示例](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) 
+  [服务控制策略示例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [AWS Budgets 操作](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/) 
+  [创建 IAM 策略以使用标签控制对 Amazon EC2 资源的访问权限](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/) 
+  [限制 IAM Identity 对特定 Amazon EC2 资源的访问权限](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) 
+  [Slack integrations for Cost Anomaly Detection using Amazon Q Developer in chat applications](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) 

# COST02-BP06 跟踪项目生命周期
<a name="cost_govern_usage_track_lifecycle"></a>

 跟踪、衡量并审核项目、团队和环境的生命周期，以避免使用不必要的资源并为此付费。

 **在未建立这种最佳实践的情况下暴露的风险等级：**低 

## 实施指导
<a name="implementation-guidance"></a>

 通过有效地跟踪项目生命周期，组织可以加强规划、管理和资源优化，进而更好地控制成本。通过跟踪获得的见解对于作出明智的决策非常宝贵，有助于提高项目的成本效益和整体成功率。

 跟踪工作负载的整个生命周期，有助于您了解何时不再需要工作负载或工作负载组件。现有的工作负载和组件可能看起来仍在使用中，但是当 AWS 发布新的服务或功能时，它们可能会被停用或采用。检查工作负载的先前阶段。在工作负载进入生产之后，可以停用以前的环境或大幅降低其容量，直到再次需要它们为止。

 可以用时间范围或提醒标记资源，以便确定工作负载的审核时间。例如，如果上一次审核开发环境是在几个月前，现在可能非常适合再次审核该环境，以探究是否能采用新服务或该环境是否在使用中。可以在 AWS 上使用 [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) 对应用程序进行分组和标记，以管理和跟踪元数据，例如重要性、环境、上次审查时间和成本中心。您既可以跟踪工作负载的生命周期，也可以监控和管理应用程序的成本、运行状况、安全态势和性能。

 AWS 提供了各种可用于实体生命周期跟踪的管理和治理服务。可以使用 [https://aws.amazon.com/config/](https://aws.amazon.com/config/) 或 [https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) 提供一份详尽的 AWS 资源和配置清单。建议集成现有项目或资产管理系统，以跟踪组织内的活动项目和产品。将当前系统与 AWS 提供的丰富事件和指标集结合起来，您就可以构建重要生命周期事件的视图并主动管理资源，以减少不必要的成本。

 与[应用程序生命周期管理（ALM）](https://aws.amazon.com/what-is/application-lifecycle-management/)类似，跟踪项目生命周期应涉及多个流程、工具、团队协同工作，例如设计和开发、测试、生产、支持及工作负载冗余。

 通过仔细监控项目生命周期的每个阶段，组织可以获得重要的见解并增强掌控力，从而促进成功的项目规划、实施和完成。这种仔细的监督可以确保项目不仅符合质量标准，而且在预算范围内按时交付，从而提高总体成本效率。

 有关实施实体生命周期跟踪的更多详细信息，请参阅《[https://aws.amazon.com/architecture/well-architected/](https://aws.amazon.com/architecture/well-architected/)》。

### 实施步骤
<a name="implementation-steps"></a>
+  **建立项目生命周期监控流程：**[云卓越中心团队](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)必须建立项目生命周期监控流程。建立结构化的系统化方法来监控工作负载，以改善项目的控制、可见性和性能。使监控过程透明化、协作化并注重持续改进，以最大限度地提高其有效性和价值。
+  **执行工作负载审查：**根据组织策略的定义，定期安排时间审核现有项目并执行工作负载审查。在审核方面投入的工作量应与组织的大致风险、价值或成本成比例。主要审核领域包括组织面临的意外事件或中断风险，或对组织所做的贡献（以收入或品牌声誉进行衡量）、工作负载的成本（以资源的总成本和运营成本进行衡量）和工作负载的使用情况（以单位时间的组织产出量进行衡量）。如果这些领域在生命周期内发生变化，则需要对工作负载进行调整，例如全部停用或部分停用。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [Guidance for Tagging on AWS](https://aws.amazon.com/solutions/guidance/tagging-on-aws/) 
+  [什么是 ALM（应用程序生命周期管理）？](https://aws.amazon.com/what-is/application-lifecycle-management/) 
+  [针对工作职能的 AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 

 **相关示例：**
+  [使用 IAM 策略控制对 AWS 区域 的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 

 **相关工具** 
+  [AWS Config](https://aws.amazon.com/config/) 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS Organizations](https://aws.amazon.com/organizations/) 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/?c=mg&sec=srv) 

# COST 3. 如何监控成本和使用情况？
<a name="cost-03"></a>

建立策略和程序以便监控并适当分配您的成本。这让您能够衡量和改进此工作负载的成本效益。

**Topics**
+ [COST03-BP01 配置详细信息源](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 在成本和使用情况中添加组织信息](cost_monitor_usage_org_information.md)
+ [COST03-BP03 确定成本归属类别](cost_monitor_usage_define_attribution.md)
+ [COST03-BP04 建立组织指标](cost_monitor_usage_define_kpi.md)
+ [COST03-BP05 配置账单和成本管理工具](cost_monitor_usage_config_tools.md)
+ [COST03-BP06 根据工作负载指标分配成本](cost_monitor_usage_allocate_outcome.md)

# COST03-BP01 配置详细信息源
<a name="cost_monitor_usage_detailed_source"></a>

设置成本管理和报告工具，进一步分析成本和使用情况数据并提高透明度。配置工作负载以创建日志条目，便于跟踪和分割成本和使用情况。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 利用成本管理工具中的详细账单信息（如每小时粒度），组织能够更详细地跟踪使用情况，并有助于组织找出成本增加的一些原因。这些数据来源最确切地反映了整个组织中的成本和使用情况。

 可以使用 AWS Data Exports 创建 AWS 成本和使用情况报告（CUR）2.0 的导出。这是从 AWS 接收详细的成本和使用情况数据的新推荐方式。这种方法可以提供所有收费 AWS 服务的每日或每小时使用粒度、费率、成本和使用属性（与 CUR 的信息相同），以及一些改进。CUR 中包括所有可能的维度，例如标签、位置、资源属性和账户 ID。

 根据要创建的导出的类型，有三种导出类型：标准数据导出、导出到集成 Quick 的成本与使用情况控制面板，或旧版数据导出。
+  **标准数据导出**：定期交付到 Amazon S3 的表的自定义导出。
+  **成本与使用情况控制面板：**导出到 Quick 和与之集成，用于部署预构建的成本与使用情况控制面板。
+  **旧版数据导出：**旧版 AWS 成本和使用情况报告（CUR）的导出。

 可以使用以下自定义项创建数据导出：
+  包括资源 ID 
+  拆分成本分配数据 
+  每小时粒度 
+  版本控制 
+  压缩类型和文件格式 

 对于在 Amazon ECS 或 Amazon EKS 上运行容器的工作负载，启用拆分成本分配数据，以便可以根据容器工作负载使用共享计算和内存资源的方式，将容器成本分配给各个业务部门和团队。拆分成本分配数据将新的容器级资源的成本和使用情况数据引入 AWS 成本和使用情况报告。拆分成本分配数据通过计算集群上运行的各个 ECS 服务和任务的成本来计算。

 成本与使用情况控制面板定期将成本与使用情况控制面板表导出到 S3 存储桶，并将预构建的成本与使用情况控制面板部署到 Quick。如果您想快速部署包含成本和使用情况数据的控制面板，且不需要自定义功能，请使用此选项。

 如果需要，您仍然可以导出旧版 CUR，并可在其中集成其他处理服务（例如 [AWS Glue](https://aws.amazon.com/glue/)）来准备数据以供分析，并使用 [Amazon Athena](https://aws.amazon.com/athena/) 进行数据分析，通过 SQL 查询数据。

### 实施步骤
<a name="implementation-steps"></a>
+  **创建数据导出：**使用所需数据创建自定义导出并控制导出的架构。使用基本 SQL 创建账单和成本管理数据导出，并通过与 Quick 集成来实现账单和成本管理数据的可视化。您还能以标准模式导出数据，以使用 Amazon Athena 等其他处理工具来分析数据。
+  **配置成本和使用情况报告：**使用账单控制台，配置至少一个成本和使用情况报告。配置采用每小时粒度的报告，以便包括所有标识符和资源 ID。还可以创建采用不同粒度的其他报告，以提供概括性摘要信息。
+  **在 Cost Explorer 中配置每小时粒度：**要以每小时粒度访问过去 14 天的成本和使用情况数据，请考虑在账单控制台中启用每小时和资源级别数据。
+  **配置应用程序日志记录：**确认应用程序记录所交付的每项业务成果，以便进行跟踪和衡量。确保该数据的粒度至少为每小时一次，以便与成本和使用情况数据匹配。有关日志记录和监控的更多详细信息，请参阅《[Well-Architected 卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)》。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Data Exports](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [AWS 成本管理定价](https://aws.amazon.com/aws-cost-management/pricing/) 
+  [为 AWS 资源添加标签](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 
+  [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [管理 AWS 成本和使用情况报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **相关示例：**
+  [AWS 账户设置](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+ [Data Exports for AWS Billing and Cost Management ](https://aws.amazon.com/blogs/aws-cloud-financial-management/introducing-data-exports-for-billing-and-cost-management/)
+  [AWS Cost Explorer 常见应用场景](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/) 

# COST03-BP02 在成本和使用情况中添加组织信息
<a name="cost_monitor_usage_org_information"></a>

根据组织、工作负载属性和成本分配类别定义标记方案，以便可以在成本管理工具中筛选和搜索资源或监控成本和使用情况。在可能的情况下，根据目的、团队、环境或与业务相关的其他标准，在所有资源中应用一致的标签。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

在 AWS 中应用[标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)以将组织信息添加到资源中，然后将该信息添加到成本和使用情况信息中。标签是键值对：键经过定义，必须在整个组织中唯一，值则对于一组资源唯一。键值对的一个示例是键为 `Environment`，值为 `Production`。生产环境中的所有资源都有这个键值对。借助标签，可以使用有意义、相关的组织信息对成本进行分类和跟踪。可以应用代表组织类别（例如成本中心、应用程序名称、项目或负责人）的标签，标识工作负载和工作负载的特征（例如测试或生产），在整个组织中对成本和使用情况进行归属。

当您将标签应用于 AWS 资源（如 Amazon Elastic Compute Cloud 实例或 Amazon Simple Storage Service 存储桶）并激活标签后，AWS 会将此信息添加到成本和使用情况报告中。可以在带标签和无标签的资源上运行报告并执行分析，以更好地遵守内部成本管理策略，并确保准确归属。

跨组织账户创建和实施 AWS 标签标准之后，您将能够一致且统一地管理和治理 AWS 环境。使用 AWS Organizations 中的[标签策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)定义有关如何在 AWS Organizations 账户的 AWS 资源上使用标签的规则。借助标签策略，可以采用标准化方法轻松标记 AWS 资源

[AWS 标签编辑器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)可用于为多个资源添加、删除和管理标签。通过使用标签编辑器，您可以搜索要标记的资源，然后在搜索结果中管理这些资源的标签。

[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 可用于向成本分配组织含义，而无需在资源上添加标签。可以将成本和使用情况信息映射到唯一的内部组织结构。可以定义类别规则，以使用账单维度（例如账户和标签）对成本进行映射和分类。除了标记之外，这还提供了另一个级别的管理能力。您还可以将特定账户和标签映射到多个项目。

**实施步骤**
+  **定义标记方案：**召集整个企业的所有利益相关方来定义方案。这通常包括担任技术、财务和管理角色的人员。定义所有资源必须具有的标签列表，以及资源应该具有的标签列表。确认标签名称和值在整个组织中是否一致。
+ **标签资源：**使用定义的成本归属类别，根据类别在工作负载中的所有资源上[放置标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。使用 CLI、标签编辑器或 AWS Systems Manager 等工具提高效率。
+  **实施 AWS Cost Categories：**无需应用标签即可创建[成本类别](https://aws.amazon.com/aws-cost-management/aws-cost-categories/)。Cost Categories 使用现有的成本和使用情况维度。根据方案创建类别规则，并在 Cost Categories 中加以实施。
+  **实现标记自动化：**为确保对所有资源保持高水平的标记，请自动进行标记，以便在创建资源时自动对其进行标记。使用诸如 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 之类的服务来验证资源在创建时是否已标记。还可以创建自定义解决方案以便使用 Lambda 函数实现自动标记，或使用微服务定期扫描工作负载并删除没有标记的任何资源，此方法非常适合测试和开发环境。
+ **监控和报告标记：**为确保在整个组织中保持高水平的标记，请跨工作负载报告和监控标签。可以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 查看带标签和无标签的资源的成本，也可以使用[标签编辑器](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)等服务。定期审核无标签的资源的数量，并执行操作添加标签，直到达到所需的标记级别。

## 资源
<a name="resources"></a>

 **相关文档：**
+ [标记最佳实践](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+  [AWS CloudFormation 资源标签](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) 
+  [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [为 AWS 资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [管理 AWS 成本和使用情况报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **相关视频：**
+ [如何标记 AWS 资源，以便按成本中心或项目划分账单](https://www.youtube.com/watch?v=3j9xyyKIg6w)
+ [标记 AWS 资源](https://www.youtube.com/watch?v=MX9DaAQS15I)

# COST03-BP03 确定成本归属类别
<a name="cost_monitor_usage_define_attribution"></a>

 确定组织类别，例如业务单位、部门或项目，这些类别可用于在组织中按照内部使用实体分配成本。利用这些类别来执行支出问责制，树立成本意识，并推动高效的使用行为。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 成本分类过程在预算编制、会计、财务报告、决策、基准测试和项目管理中至关重要。通过对费用进行分级和分类，团队可以更好地了解自己整个云之旅中会产生的成本类型，从而有助于团队作出明智的决策并有效地管理预算。

 云支出问责制为严明的需求和成本管理提供了强有力的激励措施。最终，组织在将大部分云支出分配到使用这些资源的业务单位或团队后，可以显著地节省云成本。此外，通过分配云支出，有助于组织采用更多集中式云治理的最佳实践。

 与财务团队和其他相关利益相关方合作，在定期沟通通话期间，了解必须如何在组织内部分配成本的要求。必须将工作负载成本分配至整个生命周期，包括开发、测试、生产和停用。了解组织如何对学习、员工培养和创意构思进行成本归类。这有助于将用于此目的的账户正确分配给培训和开发预算，而不是一般的 IT 成本预算。

 与组织中的利益相关方一起定义成本归属类别后，使用 [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 将成本和使用情况信息分组为 AWS 云 中有意义的类别，例如特定项目的成本、部门或业务部门的 AWS 账户。可以创建自定义类别，并根据使用各种维度（如账户、标签、服务或费用类型）定义的规则，将成本和使用情况信息映射到这些类别中。设置成本类别后，可以按这些类别查看成本和使用情况信息，从而让组织能够作出更好的战略和采购决策。这些类别也可在 AWS Cost Explorer、AWS Budgets 和 AWS 成本和使用情况报告 中查看。

 例如，为业务部门（DevOps 团队）创建成本类别，并在每个类别下创建多个规则（每个子类别的规则），这些规则具有基于所定义分组的多个维度（AWS 账户、成本分配标签、服务或费用类型）。通过 Cost Categories，您可以使用基于规则的引擎来组织您的成本。您配置的规则按类别组织您的成本。在这些规则中，可以对每个类别使用多个维度进行筛选，例如特定的 AWS 账户、AWS 服务或费用类型。可以在 [AWS 账单与成本管理 和成本管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html)[控制台](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html)中跨多个产品使用这些类别。这包括 AWS Cost Explorer、AWS Budgets、AWS 成本和使用情况报告 和 AWS Cost Anomaly Detection。

 下图举例说明了如何通过多个团队（成本类别）、多个环境（规则）以及每个环境具有多个资源或资产（维度），对组织中的成本和使用情况信息进行分组。

![\[流程图详细说明了组织内成本与使用情况之间的关系。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/cost-usage-organization-chart.png)


 

 您也可以使用成本类别创建成本分组。创建成本类别后（为使用情况记录创建成本类别之后，允许在 24 小时内更新相应的值），这些类别将显示在 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)、[AWS 成本和使用情况报告](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 和 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 中。在 AWS Cost Explorer 和 AWS Budgets 中，成本类别显示为额外的计费维度。您可以使用此项筛选特定成本类别值，或者按成本类别分组。

### 实施步骤
<a name="implementation-steps"></a>
+  **定义组织类别：**与内部利益相关方和业务部门会面，确定反映组织结构和要求的类别。这些类别应直接对应于现有财务类别的结构，例如业务部门、预算、成本中心或部门。了解云为您带来的业务成果（例如培训或教育），因为这些也是组织类别。
+  **定义职能类别：**与内部利益相关方和业务部门会面，确定反映业务所含职能的类别。这可以是工作负载名称或应用程序名称以及环境类型（例如生产、测试或开发）。
+  **定义 AWS Cost Categories：**使用 [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 创建成本类别以整理成本和使用情况信息，并将 AWS 成本和使用情况映射到[有意义的类别](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html)。可以将多个类别分配给一个资源，并且一个资源可以位于多个不同的类别中，因此可以根据需要定义任意数量的类别，以便可以使用 AWS Cost Categories 在分类的结构中[管理成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [为 AWS 资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [使用成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) () 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [管理 AWS 成本和使用情况报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 
+  [AWS Cost Categories](https://docs.aws.amazon.com/wellarchitected/latest/framework/aws-cost-management/aws-cost-categories/) 
+  [使用 AWS Cost Categories 管理成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 
+  [创建成本类别](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html) 
+  [标记成本类别](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tag-cost-categories.html) 
+  [在成本类别中拆分费用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html) 
+  [AWS Cost Categories 的功能](https://aws.amazon.com/aws-cost-management/aws-cost-categories/features/) 

 **相关示例：**
+  [使用 AWS Cost Categories 整理成本和使用情况数据](https://aws.amazon.com/blogs/aws-cloud-financial-management/organize-your-cost-and-usage-data-with-aws-cost-categories/) 
+  [使用 AWS Cost Categories 管理成本](https://aws.amazon.com/aws-cost-management/resources/managing-your-costs-with-aws-cost-categories/) 

# COST03-BP04 建立组织指标
<a name="cost_monitor_usage_define_kpi"></a>

 建立此工作负载需要的组织指标。生成的客户报告或提供给客户的 Web 页面都属于工作负载指标。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

了解如何根据业务成功来衡量工作负载的输出。每个工作负载通常有一组表示性能的主要输出。如果您的工作负载复杂且包含许多组件，则可以对列表进行优先级排序，或者为每个组件定义和跟踪指标。与团队合作，了解要使用哪些指标。此部分将用于了解工作负载的效率，或每项业务产出的成本。

**实施步骤**
+  **定义工作负载成果：**与业务利益相关方召开会议，定义工作负载成果。这些主要用于衡量客户使用情况，因此必须是业务指标，而不是技术指标。每个工作负载应该有少量的概要指标（少于 5 个）。如果工作负载针对不同的应用场景产生多个结果，请将其分组为一个指标。
+  **定义工作负载组件指标：**如果工作负载大而复杂，或者可以轻松地将工作负载分为输入和输出定义明确的多个组件（例如微服务），则可以选择为每个组件定义指标。这项工作应反映组件的价值和成本。按照从大到小的顺序，从最大的组件开始，逐步处理较小的组件。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [为AWS资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [管理 AWS 成本和使用情况报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

# COST03-BP05 配置账单和成本管理工具
<a name="cost_monitor_usage_config_tools"></a>

 根据组织的策略配置成本管理工具，以管理和优化云支出。这包括用于整理和跟踪成本和使用情况数据的服务、工具和资源，通过整合账单和访问权限增强控制，通过预算编制和预测改进规划，接收通知或提醒，并通过资源和定价优化降低成本。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 为了建立强有力的问责制，首先将您的账户策略视为成本分配策略的一部分。做好这一点，可能会为您省下许多工作。否则就会出现意识不足的情况，造成更多痛点。

 为了鼓励针对云支出建立问责制，应向用户授予权限，允许他们使用可查看其成本和使用情况的工具。AWS 建议您出于以下目的配置所有工作负载和团队：
+  **整理：**使用您自己的标记策略和分类方法，建立成本分配和治理基准。使用 AWS Control Tower 或 AWS Organization 等工具创建多个 AWS 账户。标记支持的 AWS 资源，并根据组织结构（业务部门、部门或项目）对资源进行有目的性的分类。为特定成本中心标记账户名称，并将其与 AWS Cost Categories 对应起来，以便为业务部门就其成本中心进行账户分组，这样业务部门负责人就可以在一个位置查看多个账户的使用情况。
+  **访问权限：**在整合账单中跟踪组织范围的账单信息。确认相应的利益相关方和业务负责人是否拥有访问权限。
+  **控制：**使用服务控制策略（SCP）、标签策略、IAM 策略和预算警报时，使用适当的防护机制建立有效的治理机制，以防止出现意外情况。例如，可以使用有效的控制机制，仅允许团队在首选区域内创建特定资源，并防止没有特定标签（例如成本中心）的资源创建。
+  **当前状态：**配置显示当前成本和使用情况水平的控制面板。该控制面板应位于工作环境中的显眼位置，类似于操作控制面板。可以导出数据，并使用 AWS 成本优化中心中的成本与使用情况控制面板或任何支持的产品来实现此可见性。您可能需要为不同的角色创建不同的控制面板。例如，管理器控制面板可能不同于工程控制面板。
+  **通知：**当成本或使用情况超过定义的限制并且 AWS Budgets 或 AWS 异常检测出现异常时，提供通知。
+  **报告：**汇总所有成本和使用情况信息。通过详细的、可归因的成本数据，提高对云支出的认识，加强问责制。创建报告（这些报告与其使用团队相关）并包含建议。
+  **跟踪：**对照配置的方向性目标或执行性目标显示当前的成本和使用情况。
+  **分析：**允许团队成员使用不同的筛选条件（资源、账户、标签等）执行自定义和深入分析，精确到每小时、每天或每月的粒度。
+  **检查：**随时了解最新的资源部署和成本优化机会。使用 Amazon CloudWatch、Amazon SNS 或 Amazon SES 获取组织级别的资源部署的通知。使用 AWS Trusted Advisor 或 AWS Compute Optimizer 审核成本优化建议。
+  **趋势报告：**以所需的粒度显示所需期限内成本和使用情况的变化。
+  **预测：**使用您创建的预测控制面板，显示估计的未来成本、估计资源使用情况和支出。

 可以使用 [AWS 成本优化中心](https://aws.amazon.com/aws-cost-management/cost-optimization-hub/)来了解从集中位置整合的潜在成本节约机会，并创建数据导出以与 Amazon Athena 集成。还可以使用 AWS 成本优化中心来部署成本与使用情况控制面板，该控制面板利用 Quick 进行交互式成本分析和安全的成本洞察共享。

 如果组织不具备必备技能或带宽，则可以与 [AWS ProServ](https://aws.amazon.com/professional-services/)、[AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)或 [AWS 合作伙伴](https://aws.amazon.com/partners/)合作。您也可以使用第三方工具，但请务必验证价值主张。

### 实施步骤
<a name="implementation-steps"></a>
+  **允许对工具进行基于团队的访问：**配置账户并创建组，这些组可以访问所需的成本和使用情况报告来了解其使用情况，并使用 [AWS Identity and Access Management](https://aws.amazon.com/iam/) [控制对 AWS Cost Explorer 等工具的访问权限](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html)。这些组必须包括负责或管理应用程序的所有团队的代表。这证明每个团队都可以访问他们的成本和使用情况信息，以跟踪使用情况。
+  **整理成本标签和类别：**跨团队、业务部门、应用程序、环境和项目整理成本。使用资源标签来按成本分配标签整理成本。使用标签、账户、服务等，根据维度创建成本类别，以映射成本。
+  **配置 AWS Budgets：**在所有账户中为工作负载配置 [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)。使用标签和成本类别，设置账户总支出预算和工作负载预算。在 AWS Budgets 中配置通知，以便在您超出预算金额或估计成本超出预算时收到警报。
+  **配置 AWS 成本异常检测：**针对您的账户、核心服务或成本类别使用 [AWS 成本异常检测](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)，以监控成本和使用情况，并检测异常支出。可以在汇总的报告中单独收到警报，以及在电子邮件或 Amazon SNS 主题中收到警报，以便您分析和确定异常的根本原因，并确定导致成本增加的原因。
+  **使用成本分析工具：**为工作负载和账户配置 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)，实现成本数据可视化，以便进一步分析。为工作负载创建一个控制面板，用于跟踪总体支出、工作负载的关键使用指标，以及基于历史成本数据的未来成本预测。
+  **使用成本节省分析工具：**通过 AWS 成本优化中心利用量身定制的建议（包括删除未使用的资源、合理调整大小、节省计划和预留）和 Compute Optimizer 建议来发现可节省成本的机会。
+  **配置高级工具：**可以选择创建视觉对象以促进交互式分析和成本洞察的分享。借助 AWS 成本优化中心上的数据导出功能，可以为组织创建由 Quick 提供支持的成本与使用情况控制面板，从而提供更多详细信息和粒度。还可以通过使用 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) 中的数据导出来实现高级分析功能以进行高级查询，并在 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) 上创建控制面板。与 [AWS 合作伙伴](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management)合作，将云管理解决方案用于整合的云账单监控和优化。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [What is AWS 账单与成本管理 and Cost Management](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html)?
+  [建立您的最佳实践 AWS 环境](https://aws.amazon.com/organizations/getting-started/best-practices/) 
+  [标记 AWS 资源的最佳实践](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) 
+  [对AWS资源加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 AWS Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [What is AWS Data Exports](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html)?

 **相关视频：**
+  [Deploying Cloud Intelligence Dashboards](https://www.youtube.com/watch?v=FhGZwfNJTnc) 
+  [Get Alerts on any FinOps or Cost Optimization Metric or KPI ](https://www.youtube.com/watch?v=dzRKDSXCtAs) 

 **相关示例：**
+  [Cost and Usage Dashboard powered](https://aws.amazon.com/blogs/aws-cloud-financial-management/new-cost-and-usage-dashboard-powered-by-amazon-quicksight/) by Quick 
+  [AWS Cost and Usage Governance 讲习会](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/20-cost-and-usage-governance) 

# COST03-BP06 根据工作负载指标分配成本
<a name="cost_monitor_usage_allocate_outcome"></a>

 根据使用情况指标或业务成果分配工作负载的成本，以便衡量工作负载的成本效率。实施一个流程，使用分析服务来分析成本和使用情况数据，以便深入了解成本因素和退款功能。

 **在未建立这种最佳实践的情况下暴露的风险等级：**低 

## 实施指导
<a name="implementation-guidance"></a>

 成本优化是指以最低的价格实现业务成果，这只能通过按工作负载指标分配工作负载成本（按工作负载效率衡量）来实现。通过日志文件或其他应用程序监控来监控定义的工作负载指标。将此数据与工作负载的成本（可通过查看具有特定标签值或账户 ID 的成本获得）相结合。每小时进行一次此分析。如果有静态成本要素（例如，持续运行的后端数据库）且请求率不同（例如，使用量高峰在上午 9 点至下午 5 点，晚间的请求数量很少），则效率通常会变化。了解静态成本和可变成本之间的关系，有助于您专注于优化活动。

 与 Amazon Elastic Container Service（Amazon ECS）和 Amazon API Gateway 上的容器化应用程序等资源相比，为共享资源创建工作负载指标可能并非易事。但是，您可以通过某些方法来分类使用情况并跟踪成本。如果您需要跟踪 Amazon ECS 和 AWS Batch 共享资源，则可以在 AWS Cost Explorer 中启用拆分成本分配数据。通过拆分成本分配数据，您可以了解并优化容器化应用程序的成本和使用情况，并根据共享计算和内存资源的使用情况，将应用程序成本分配给各个业务实体。

### 实施步骤
<a name="implementation-steps"></a>
+  **将成本分配到工作负载指标：**使用定义的指标和配置的标签，创建结合工作负载输出和工作负载成本的指标。使用 Amazon Athena 和 Amazon Quick 等分析服务，为整个工作负载和任何组件创建效率控制面板。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [为 AWS 资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [使用 AWS Budgets 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 
+  [使用 Cost Explorer 分析成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html) 
+  [管理 AWS 成本和使用情况报告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html) 

 **相关示例：**
+ [利用 AWS 拆分成本分配数据提高 Amazon ECS 和 AWS Batch 的成本可见性](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)

# COST 4. 如何停用资源？
<a name="cost-04"></a>

在从项目开始到结束的过程中实施变更控制和资源管理。这可以确保您关闭或终止未使用的资源，以便减少浪费。

**Topics**
+ [COST04-BP01 在资源生命周期内跟踪资源](cost_decomissioning_resources_track.md)
+ [COST04-BP02 实施停用流程](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 停用资源](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 自动停用资源](cost_decomissioning_resources_decomm_automated.md)
+ [COST04-BP05 执行数据留存策略](cost_decomissioning_resources_data_retention.md)

# COST04-BP01 在资源生命周期内跟踪资源
<a name="cost_decomissioning_resources_track"></a>

 制定和实施一种方法，在资源生命周期内跟踪资源及其与系统的关联。您可以使用标签来标识资源的工作负载或功能。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

停用不再需要的工作负载资源。一个常见的示例是用于测试的资源：在测试完成后，可以将资源删除。使用标签跟踪资源（并对这些标签运行报告），可以帮助您识别要停用的资产，因为将不会使用这些资产，或者这些资产的许可证将过期。使用标签是跟踪资源的一种有效方法，它通过标记资源的功能或资源的已知可停用日期来跟踪资源。然后，可以对这些标签运行报告。功能标签的示例值是 `feature-X testing`，用于根据工作负载生命周期标识资源的用途。另一个例子是对资源使用 `LifeSpan` 或 `TTL`，例如待删除的标签键名称和值，用于定义停用的时间段或具体时间。

**实施步骤**
+ **实施标记方案：**实施标记方案，标识资源所属的工作负载，从而确保相应地标记工作负载中的所有资源。标签可以帮助您按用途、团队、环境或与业务相关的其他条件对资源进行分类。有关标签应用场景、策略和技术的更多详细信息，请参阅 [AWS Tagging Best Practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。
+ **实施工作负载吞吐量或输出监控：**实施工作负载吞吐量监控或警报，在输入请求或输出完成时启动。将其配置为在工作负载请求或输出下降到零时发出通知，指示不再使用工作负载资源。如果在正常情况下，工作负载周期性地下降到零，则加入时间因素。有关未使用或未充分利用的资源的更多详细信息，请参阅 [AWS Trusted Advisor Cost Optimization checks](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)。
+  **为 AWS 资源分组：**为 AWS 资源创建组。可以使用 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) 来整理和管理同一个 AWS 区域 中的 AWS 资源。可以将标签添加到大多数资源中，帮助标识资源并对组织内的资源进行排序。使用[标签编辑器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)向支持的资源批量添加标签。考虑使用 [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) 创建、管理和向最终用户分发已批准的产品组合，并管理产品生命周期。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS Trusted Advisor Cost Optimization Checks](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html) 
+  [为AWS资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 
+  [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 

 **相关视频：**
+  [How to optimize costs using AWS Trusted Advisor](https://youtu.be/zcQPufNFhgg) 

 **相关示例：**
+  [组织 AWS 资源](https://aws.amazon.com/premiumsupport/knowledge-center/resource-groups/) 
+  [使用 AWS Trusted Advisor 优化成本](https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/) 

# COST04-BP02 实施停用流程
<a name="cost_decomissioning_resources_implement_process"></a>

 实施一个流程来确定和停用未使用的资源。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

在整个组织中实施标准化流程，以确定和删除未使用的资源。该流程应该定义执行搜索的频率以及删除资源的流程，以确认满足所有组织要求。

**实施步骤**
+  **创建并实施停用流程：**与工作负载开发人员和负责人合作，为工作负载及其资源构建停用流程。该流程应涵盖一种方法，验证工作负载是否正在使用以及每个工作负载资源是否正在使用。详细说明停用资源所需的步骤，将资源从服务中删除，同时确保符合所有法规要求。应包含任何关联的资源，例如许可证或附加的存储。向工作负载负责人发送已开启停用流程的通知。

   使用以下停用步骤来指导您确定在流程中应检查的内容：
  +  **确定要停用的资源：**确定 AWS 云 中符合停用条件的资源。记录所有必要的信息并安排停用。在您的时间表中，请务必考虑在此过程中是否（以及何时）会出现意外问题。
  +  **协调和沟通：**与工作负载负责人合作确认要停用的资源 
  +  **记录元数据并创建备份：**如果生产环境中的资源需要或它们是关键资源，请记录元数据（例如公有 IP、区域、可用区、VPC、子网和安全组），并创建备份（例如 Amazon Elastic Block Store 快照或取得 AMI、密钥导出和证书导出）。
  +  **验证基础设施即代码：**确定资源是使用 CloudFormation、Terraform、AWS Cloud Development Kit (AWS CDK) 还是任何其他基础设施即代码部署工具部署的，以便在必要时可以重新部署它们。
  +  **阻止访问：**在一段时间内应用限制性控制，以防止在确定是否需要资源时使用资源。验证资源环境是否可以在需要时恢复到其原始状态。
  +  **遵循内部停用流程：**遵循组织的管理任务和停用流程，例如从组织域中删除资源、删除 DNS 记录以及从配置管理工具、监控工具、自动化工具和安全工具中删除资源。

   如果资源是 Amazon EC2 实例，请参阅以下列表。[有关更多详细信息，请参阅《如何删除或终止我的 Amazon EC2 资源？》](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
  +  停止或终止您的所有 Amazon EC2 实例和负载均衡器。Amazon EC2 实例终止后可短时间内在控制台中看到。您不需要为任何未处于运行状态的实例付费 
  +  删除 Auto Scaling 基础设施。
  +  释放所有专属主机。
  +  删除所有 Amazon EBS 卷和 Amazon EBS 快照。
  +  释放所有弹性 IP 地址。
  +  取消注册所有亚马逊机器映像（AMI）。
  +  终止所有 AWS Elastic Beanstalk 环境。

   如果资源是 Amazon Glacier 存储中的对象，并且您在满足最短存储持续时间之前删除了归档，则将按比例收取提前删除费用。Amazon Glacier 的最短存储持续时间取决于所使用的存储类别。有关每种存储类的最短存储持续时间摘要，请参阅[跨 S3 存储类的性能](https://aws.amazon.com/s3/storage-classes/?nc=sn&loc=3#Performance_across_the_S3_Storage_Classes)。有关如何计算提前删除费用的详细信息，请参阅 [Amazon S3 定价](https://aws.amazon.com/s3/pricing/)。

 下面的简单停用过程流程图概述了停用步骤。在停用资源之前，请确认组织未使用已确定要停用的资源。

![\[流程图描述了资源停用的步骤。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/decommissioning-process-flowchart.png)


## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 

 **相关视频：**
+  [删除 CloudFormation 堆栈，但保留某些资源](https://www.youtube.com/watch?v=bVmsS8rjuwk) 
+  [Find out which user launched Amazon EC2 instance](https://www.youtube.com/watch?v=SlyAHc5Mv2A) 

 **相关示例：**
+  [删除或终止 Amazon EC2 资源](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/) 
+  [了解哪个用户启动了 Amazon EC2 实例](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-user-launched-instance/) 

# COST04-BP03 停用资源
<a name="cost_decomissioning_resources_decommission"></a>

 停用由定期审核或使用情况发生变化等事件启动的资源。停用通常定期执行，可以手动停用，也可以自动停用。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

搜索未使用资源的频率和工作量应反映潜在的节省额，因此，与成本较高的账户相比，对成本较低的账户进行分析的频率应该更低。搜索和停用事件可由工作负载中的状态更改启动，比如产品生命周期结束或产品被更换。搜索和停用事件也可由外部事件启动，如市场条件发生变化或产品终止。

**实施步骤**
+  **停用资源：**这是不再需要的 AWS 资源的折旧阶段或许可协议的终止。在进入处置阶段并停用资源之前完成所有最终检查，以防止任何意外中断，例如拍摄快照或备份。使用停用流程，停用每项被确定为未使用的资源。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# COST04-BP04 自动停用资源
<a name="cost_decomissioning_resources_decomm_automated"></a>

 设计您的工作负载，使其在您确定并停用非关键资源、不需要的资源或使用率低的资源时妥善处理资源的终止。

 **在未建立这种最佳实践的情况下暴露的风险等级：**低 

## 实施指导
<a name="implementation-guidance"></a>

使用自动化技术可以减少或消除停用流程中的相关成本。将工作负载设计为执行自动化停用，将减少工作负载在其整个生命周期内的总成本。您可以使用 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 或 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide) 来执行停用流程。还可以使用 [API 或 SDK](https://aws.amazon.com/developer/tools/) 来实施自定义代码，以自动停用工作负载资源。

 [现代应用程序](https://aws.amazon.com/modern-apps/)是以“无服务器为先”理念构建的，这种策略优先考虑采用无服务器服务。AWS 为堆栈的所有三个层开发了[无服务器服务](https://aws.amazon.com/serverless/)：计算、集成和数据存储。使用无服务器架构将允许您在低流量期间通过自动纵向扩展和缩减来节省成本。

**实施步骤**
+ **实施 Amazon EC2 Auto Scaling 或 Application Auto Scaling：**对于支持的资源，请使用 Amazon EC2 Auto Scaling 或 Application Auto Scaling 来配置它们。这些服务可以帮助您在使用 AWS 服务时优化使用率和成本效率。当需求下降时，这些服务将自动删除任何多余的资源容量，以避免超支。
+ **将 CloudWatch 配置为终止实例：**可以将实例配置为使用 [CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions)终止。使用停用流程的指标，实施包含 Amazon Elastic Compute Cloud 操作的警报。在推出之前，在非生产环境中验证操作。
+  **在工作负载中实现代码：**可以使用 AWS SDK 或 AWS CLI 停用工作负载资源。在与 AWS 集成的应用程序中实现代码，并终止或删除不再使用的资源。
+  **使用无服务器服务：**优先在 AWS 上构建[无服务器架构](https://aws.amazon.com/serverless/)和[事件驱动型架构](https://aws.amazon.com/event-driven-architecture/)，以构建和运行应用程序。AWS 提供多种无服务器技术服务，这些服务本质上可以自动优化资源利用率且具有自动停用功能（横向缩减和横向扩展）。通过无服务器应用程序，可自动优化资源利用率，您无需为过度预置付费。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 
+  [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [AWS 无服务器](https://aws.amazon.com/serverless/) 
+  [创建警报以停止、终止、重启或恢复实例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html) 
+  [在 Amazon CloudWatch 警报中添加终止操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions) 

 **相关示例：**
+  [Scheduling automatic deletion of AWS CloudFormation stacks](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/) 

# COST04-BP05 执行数据留存策略
<a name="cost_decomissioning_resources_data_retention"></a>

 在支持的资源上定义数据留存策略，以根据组织要求处理对象的删除事宜。确定并删除非必要的或不再需要的孤立资源和对象。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

 使用数据留存策略和生命周期策略，降低停用过程的相关成本以及已确定资源的存储成本。定义数据留存策略和生命周期策略来执行自动存储类迁移和删除，将会降低其生命周期内的总体存储成本。可以使用 Amazon Data Lifecycle Manager 来自动创建和删除 Amazon Elastic Block Store 快照及基于 Amazon EBS 的亚马逊机器映像（AMI），并使用 Amazon S3 Intelligent-Tiering 或 Amazon S3 生命周期配置来管理 Amazon S3 对象的生命周期。还可以使用 [API 或 SDK](https://aws.amazon.com/tools/) 实现自定义代码，为要自动删除的对象创建生命周期策略和策略规则。

 **实施步骤** 
+  **使用 Amazon Data Lifecycle Manager：**使用 Amazon Data Lifecycle Manager 上的生命周期策略，自动删除 Amazon EBS 快照和 Amazon EBS-backed AMI。
+  **在存储桶上设置生命周期配置：**根据业务要求，使用存储桶上的 Amazon S3 生命周期配置，定义 Amazon S3 在对象生命周期中要采取的操作以及对象生命周期结束时的删除操作。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/?icmpid=docs_homepage_mgmtgov) 
+  [如何在 Amazon S3 存储桶上设置生命周期配置](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) 

 **相关视频：**
+  [Automate Amazon EBS Snapshots with Amazon Data Lifecycle Manager](https://www.youtube.com/watch?v=RJpEjnVSdi4) 
+  [使用生命周期配置规则清空 Amazon S3 存储桶](https://www.youtube.com/watch?v=JfK9vamen9I) 

 **相关示例：**
+  [使用生命周期配置规则清空 Amazon S3 存储桶](https://aws.amazon.com/premiumsupport/knowledge-center/s3-empty-bucket-lifecycle-rule/) 