

# 成本优化
<a name="a-cost-optimization"></a>

成本优化支柱包括以最低价格运行系统来交付商业价值的能力。如需有关具体实施的说明性指导，请参阅 [部分](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)访问 AWS 资源。

**Topics**
+ [践行云财务管理](a-practice-cloud-financial-management.md)
+ [支出和使用情况意识](a-expenditure-and-usage-awareness.md)
+ [具有成本效益的资源](a-cost-effective-resources.md)
+ [管理需求和供应资源](a-manage-demand-and-supply-resources.md)
+ [持续优化](a-optimize-over-time.md)

# 践行云财务管理
<a name="a-practice-cloud-financial-management"></a>

**Topics**
+ [COST 1.如何实施云财务管理？](cost-01.md)

# COST 1.如何实施云财务管理？
<a name="cost-01"></a>

实施云财务管理有助于组织在 AWS 上优化成本和使用情况并进行扩展，从而实现商业价值和财务成功。

**Topics**
+ [COST01-BP01 确立成本优化的责任归属模式](cost_cloud_financial_management_function.md)
+ [COST01-BP02 在财务和技术人员之间建立合作关系](cost_cloud_financial_management_partnership.md)
+ [COST01-BP03 建立云预算和预测](cost_cloud_financial_management_budget_forecast.md)
+ [COST01-BP04 在组织流程中落实成本意识](cost_cloud_financial_management_cost_awareness.md)
+ [COST01-BP05 报告和通知成本优化](cost_cloud_financial_management_usage_report.md)
+ [COST01-BP06 主动监控成本](cost_cloud_financial_management_proactive_process.md)
+ [COST01-BP07 及时了解新发布的服务](cost_cloud_financial_management_scheduled.md)
+ [COST01-BP08 建立对成本敏感的文化](cost_cloud_financial_management_culture.md)
+ [COST01-BP09 量化通过成本优化实现的业务价值](cost_cloud_financial_management_quantify_value.md)

# COST01-BP01 确立成本优化的责任归属模式
<a name="cost_cloud_financial_management_function"></a>

 创建一个团队（云业务办公室、云卓越中心或 FinOps 团队），负责在整个组织内建立并维护成本意识。成本优化的负责人可以是了解整个组织和云财务的个人或团队（需要来自财务、技术和业务团队的人员）。 

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

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

 这是云业务办公室（CBO）或云卓越中心（CCoE）部门或团队的介绍，此部门或团队负责建立并维护一种对云计算成本敏感的文化。此部门可以是一个现有的个人、组织内的一个团队，也可以是一个由整个组织的关键财务、技术和组织利益相关者组成的新团队。 

 此部门（个人或团队）会排定成本管理和成本优化活动的优先级，并根据需要为这些活动投入一定比率的时间。相对于较大型企业中的全职部门，小型组织的这一部门在此方面花费的时间可能更少。 

 此部门（个人或团队）会排定成本管理和成本优化活动的优先级，并根据需要为这些活动投入一定比率的时间。相对于较大型企业中的全职部门，小型组织的这一部门在成本管理和优化活动方面花费的时间可能更少。 

 此部门需要采取多学科方法，并具备项目管理、数据科学、财务分析和软件或基础设施开发的能力。此部门可通过三种不同的责任归属模式来执行成本优化，以提高工作负载的效率： 
+  **集中式：** 通过 FinOps 团队、云财务管理（CFM）团队、云业务办公室（CBO）或云卓越中心（CCoE）等指定团队，客户可以设计和实施监管机制，并在全公司范围内推广最佳实践。 
+  **分散式：** 由具有影响力的技术团队执行成本优化。 
+  **混合式：** 同时利用集中式和分散式团队，两者可以合作执行成本优化。 

 可以对照成本优化目标（例如工作负载效率指标）来衡量此部门的执行和交付能力。 

 您必须为此部门获得高管支持，这是取得成功的一个关键因素。支持者负责倡导注重成本效益的云消费理念，为成本优化团队提供升级上报支持，确保按组织确定的优先级开展成本优化活动。否则，相关方面会忽视指导意见，并且不会优先考虑节省成本的机会。支持者与团队共同确保组织有效利用云资源并创造业务价值。 

 如果您制定了商业、企业入门或企业 [支持计划](https://aws.amazon.com/premiumsupport/plans/) ，并需要协助来建立此团队或部门，请通过您的客户团队联系云财务管理（CFM）专家。 

### 实施步骤
<a name="implementation-steps"></a>
+  **定义主要成员：** 组织的所有相关部门都应该关注成本管理，并做出自己的贡献。组织中的常见团队通常包括：财务、应用程序或产品负责人、管理和技术团队（DevOps）。有些是全职工作（财务或技术），另一些则是根据需要定期工作。执行 CFM 的个人或团队需要掌握以下技能： 
  +  **软件开发：** 在需要构建脚本和自动化流程时。
  +  **基础设施工程：** 部署脚本，自动化流程，并了解如何预置服务或资源。
  +  **运营敏锐性：** CFM 的宗旨是通过测量、监控、修改、规划和扩展对云的有效使用，在云上高效地运行。
+  **定义目标和指标： **该部门需要以不同的方式为组织创造价值。相关目标已确定，并将随着组织的发展而不断完善。常见活动包括：在整个组织内创建并执行关于成本优化的培训计划、制定组织范围标准，例如监控和报告成本优化，以及设置关于优化的工作负载目标。该部门还需要定期向组织报告其成本优化能力。 

   您可以定义基于价值或成本的关键绩效指标（KPI，Key Performance Indicator）。定义 KPI 时，可以根据效率和预期业务成果计算预期成本。基于价值的 KPI 将成本和使用情况指标与业务价值驱动因素联系起来，有助于合理调整 AWS 支出。获得基于价值的 KPI 的第一步是跨组织协作，选择并商定一组标准 KPI。 
+  **建立定期沟通机制：** 该小组（财务、技术和业务团队）应该定期开会，以审查目标和指标。典型的定期沟通机制包括审核组织的状态，审核当前执行的任何计划，审核整体财务和优化指标。随后，更详细地报告关键工作负载。 

   在这些定期审核中，您可以审核工作负载效率（成本）和业务成果。例如，工作负载的成本增加 20% 可能与客户使用量的增加相一致。在这种情况下，这 20% 的成本增加可以理解为一项投资。这些定期沟通通话有助于团队识别价值 KPI，为整个组织带来意义。 

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

 **相关文档：** 
+  [AWS CCOE 博客](https://aws.amazon.com/blogs/enterprise-strategy/tag/ccoe/) 
+  [创建云业务办公室](https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/) 
+  [CCOE - 云卓越中心](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html) 

 **相关视频：** 
+ [Vanguard CCOE 成功案例](https://www.youtube.com/watch?v=0XA08hhRVFQ)

 **相关示例：** 
+ [使用云卓越中心（CCoE）实现整个企业转型](https://aws.amazon.com/blogs/enterprise-strategy/using-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise/)
+ [构建 CCOE 以实现整个企业转型](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html)
+ [构建 CCOE 时应避免的 7 个陷阱](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)

# COST01-BP02 在财务和技术人员之间建立合作关系
<a name="cost_cloud_financial_management_partnership"></a>

在云之旅的所有阶段，都让财务和技术团队参与成本和使用情况的讨论。团队定期开会，讨论组织目标、成本和使用情况的当前状态以及财务和会计实务等主题。

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

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

由于缩短了审批、采购和基础设施部署周期，技术团队在云端的创新速度更快。这可能是对财务组织的一种调整，以前，他们习惯于执行耗时的资源密集型流程，以便在数据中心和本地环境中获取和部署资金，并且只在项目批准时进行成本分配。

从财务和采购组织的角度来看，资本预算编制、资本请求、审批、采购和安装物理基础设施这一流程是我们几十年来一直在学习和标准化的流程：
+ 工程团队或 IT 团队通常是请求者
+ 不同的财务团队充当审批者和采购者
+ 运营团队架设、堆叠并移交可供使用的基础设施

![\[Circular workflow diagram showing technology teams, procurement, supply chain, and operations interactions.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/cost01-bp02-finance-and-procurement-workflow.png)


随着云的采用，基础设施的采购和消费不再受制于一连串的依赖关系。在云模式下，技术和产品团队不再仅仅是构建者，还是产品的运营者和负责人，他们负责过去与财务和运营团队有关的大部分活动，包括采购和部署。

预置云资源真正需要的只是一个用户账户和一组正确的权限。这也有助于降低 IT 和财务风险，因为团队只需点击几下鼠标或进行几次 API 调用，就可以终止空闲或不必要的云资源。这也使技术团队能够更快创新，因为他们获得了启动实验以及之后拆除实验的敏捷性和能力。虽然从资本预算编制和预测的角度来看，云消费的可变性质可能会影响可预测性，但云为组织提供了降低过度预置成本的能力，以及降低与保守预置不足相关的机会成本的能力。

![\[Diagram showing Technology and Product teams deploying, Finance and Business teams operating, with optimization at the center.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/cost01-bp02-deploy-operate-optimize.png)


在关键的财务和技术利益相关者之间建立合作关系，让他们就组织目标达成共识，并开发在云计算的可变支出模型中获得财务成功的机制。组织内的相关团队必须在云之旅的各个阶段参与成本和使用量讨论，包括： 
+ ** 财务领导：** 首席财务官、财务总监、财务规划师、业务分析师、采购、供应商开发人员和应付账款负责人必须了解消费、采购选项和每月开票流程的云模型。财务部门需要与技术团队合作创建有关 IT 价值的沟通内容并广泛传播，帮助业务团队了解技术支出与业务成果之间的联系。这样，技术支出就不会被视为成本，而会被视为投资。由于云运营（如使用量的变化速率、即付即用的定价、分级定价、定价模型以及详细的计费和使用信息）与本地运营之间存在根本差异，财务组织必须了解云的使用对业务方面的影响，包括采购流程、激励跟踪、成本分配和财务报表。
+  **技术领导：** 技术领导（包括产品和应用程序负责人）必须了解财务要求（如预算限制）和业务要求（如服务水平协议）。如此才能实施工作负载并实现组织的预期目标。

财务与技术人员的合作可带来以下好处： 
+ 财务和技术团队几乎可以实时看到成本和使用量。
+ 财务和技术团队建立了标准的操作程序来处理云支出差异。
+ 在如何使用资本购买承诺折扣（例如预留实例或 AWS Savings Plans）以及如何使用云来发展组织方面，财务利益相关者充当战略顾问。
+ 将现有的应付账款和采购流程用于云部署。
+ 财务和技术团队协作预测未来的 AWS 成本和使用量，以调整和建立组织预算。
+ 通过共通的语言以及对财务概念的一致理解，更好地进行跨组织沟通。

组织中应参与成本和使用量讨论的其他利益相关者包括： 
+ **业务部门负责人：** 业务部门负责人必须了解云业务模式，从而为业务部门和整个公司提供指导。在需要预测增长和工作负载使用情况，以及评估不同购买选项（例如预留实例或 Savings Plans）时，这方面的云知识至关重要。
+ **工程团队： **在财务和技术团队之间建立合作关系对于建立对成本敏感的文化至关重要，这可以鼓励工程师在云财务管理（CFM）上采取行动。CFM 或财务运营从业者和财务团队的一个常见问题是让工程师了解云上的整个业务，遵循最佳实践，并采取建议的行动。
+ **第三方： **如果您的组织使用第三方（例如顾问或工具），请确保他们与您的财务目标一致，并且可以通过参与模式和投资回报（ROI）证明一致性。第三方通常会帮助报告和分析其管理的任何工作负载，并且提供他们设计的任何工作负载的成本分析。

要想实施 CFM 并取得成功，需要财务、技术和业务团队之间彼此协作，并在整个组织内就如何转变云支出进行沟通和评估。将工程团队包括在内，让他们在所有阶段参与这些成本和使用情况的讨论；还要鼓励他们遵循最佳实践并采取相应的商定行动。

**实施步骤**
+ **定义主要成员： **确认财务和技术团队的所有相关成员都参与合作。相关财务成员将是与云账单进行交互的人员。通常是首席财务官、财务总监、财务规划师、业务分析师和采购员。技术成员通常是产品和应用程序负责人、技术经理和所有在云上执行构建的团队的代表。其他成员可能包括业务部门负责人（例如影响产品使用的市场营销部门）和第三方（例如顾问），以确保与您的目标和机制保持一致，并协助进行报告。
+ **定义讨论主题：** 定义团队之间的共同主题，或者需要达成共识的主题。从生成成本之时跟踪成本，直到账单已付为止。请注意所涉及的任何成员，以及需要应用的组织流程。了解经过的每个步骤或流程以及相关信息，例如可用的定价模式、分级定价、折扣模型、预算和财务要求。
+ **建立定期沟通机制： **为了让财务和技术人员展开合作，建立定期沟通机制，以促进并保持一致。该小组需要定期聚在一起，讨论目标和指标。典型的定期沟通机制包括审核组织的状态，审核当前运行的任何计划，审核整体财务和优化指标。然后，更详细地报告关键工作负载。

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

 **相关文档：** 
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 

# COST01-BP03 建立云预算和预测
<a name="cost_cloud_financial_management_budget_forecast"></a>

 调整现有的组织预算和预测流程，使之适应云成本和使用情况的易变特性。流程必须是动态的，可以使用基于趋势或基于业务驱动因素的算法，也可以将两者结合使用。 

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

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

 客户使用云来提高效率、速度和敏捷性，这导致成本和使用量的变化速度极快。随着工作负载效率的提高或者新工作负载和功能的部署，成本可以降低（有时也会提高）。工作负载可以扩展以服务更多的客户，这会增加云的使用量和成本。现在比以前更容易获得资源。云的弹性也使成本和预测变得具有弹性。必须修改现有的组织预算流程，将这种变化因素考虑在内。 

 预算通常针对一年进行编制，并且保持固定，要求所有相关人员严格遵守。相比之下，预测更为灵活，可以在全年重新调整，并提供一年、两年或三年的动态预测。在确定各技术和业务利益相关者的财务预期方面，预算制定和预测都起着至关重要的作用。准确的预测和实施还要求直接负责预置成本的利益相关者承担责任，也能提高他们的整体成本意识。 

 使用基于趋势（将历史成本用作输入）的算法或者基于驱动因素（例如新产品发布、区域扩张或用于工作负载的新环境）的算法（适用于动态和可变支出环境），或者将趋势和业务驱动因素相结合，调整现有的预算和预测流程，使其更为灵活。 

 您可以使用 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) ，根据历史支出，对确定的未来时间范围进行基于趋势的预测。AWS Cost Explorer 的预测引擎会根据付费类型（例如，预留实例）对历史数据进行细分，并结合使用机器学习和基于规则的模型来分别预测所有付费类型的支出。 

 确定可能影响使用成本的业务驱动因素，并分别针对每个驱动因素进行预测，以确保提前计算出预期使用量。其中一些驱动因素与组织中的 IT 和产品团队有关。其他业务驱动因素（如营销活动、促销、合并和收购）则是销售、营销和业务领导者所了解的，因此与他们合作，将所有这些需求驱动因素考虑在内也很重要。您需要与他们密切合作，以了解对新的内部驱动因素的影响。 

 使用 Cost Explorer 或任何其他工具确定了基于趋势的预测后，请使用 [AWS 定价计算器](https://calculator.aws/#/) ，根据预期使用情况（流量、每秒请求数、所需 Amazon EC2 实例）估计 AWS 使用场景和未来成本。您也可以使用此工具来协助自己计划支出方式，找到节省成本的机会，并在使用 AWS 时做出明智的决定。跟踪预测的准确性非常重要，因为预算的制定需要基于这些预测计算和估算值。 

 使用 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)  设置精细的自定义预算，通过指定时间段、重复发生或金额（固定或可变），以及添加筛选条件（如服务、AWS 区域和标签）来实现。为了随时了解现有预算的执行情况，您可以创建 [AWS Budgets 报告](https://docs.aws.amazon.com/cost-management/latest/userguide/reporting-cost-budget.html) 并安排好时间表，定期以电子邮件的形式发送给您和您的利益相关者。您还可以创建 [AWS Budgets 警报，](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html) 该警报可以根据实际成本（本质上是被动的）创建或根据预测成本（从而留出时间缓解潜在的成本超支情况）创建。您的成本或使用量超出或预计将超出预算金额时，系统会向您发送警报。 

 使用 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)  防止或减少意外成本，加强控制，同时不放慢创新速度。AWS Cost Anomaly Detection 利用机器学习来识别异常支出并找出根本原因，使您能够快速采取行动。 [只需简单三步](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)，您就可以创建自己的情境化监控器，在检测到任何异常支出时接收警报。 

 正如 Well-Architected 成本优化支柱的 [“财务与技术人员合作”部分](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/finance-and-technology-partnership.html)所述，在 IT 部门、财务部门和其他利益相关者之间建立合作关系和沟通机制非常重要，以确保他们都使用相同的工具或流程来保持一致性。在预算可能需要更改的情况下，增加沟通机制接触点有助于更快地应对这些更改。 

### 实施步骤
<a name="implementation-steps"></a>
+  **分析基于趋势的预测：** 使用偏好的基于趋势的预测工具，例如 AWS Cost Explorer 和 Amazon Forecast。从服务、账户、标签和成本类别等不同维度分析使用成本。如果需要进行高级预测，请将 AWS 成本和使用情况报告 数据导入 Amazon Forecast（该工具将线性回归作为机器学习的一种形式应用于预测）。 
+  **分析基于驱动因素的预测：** 确定业务驱动因素对云使用情况的影响，并分别针对每个驱动因素进行预测，以预先计算预期的使用成本。与业务单位负责人和利益相关者密切合作，了解新驱动因素的影响，计算预期成本变化以确定准确的预算。 
+  **更新现有的预测和预算流程：** 根据所采用的预测方法（如基于趋势的预测方法、基于业务驱动因素的预测方法，或者结合使用两种预测方法），确定预测预算编制流程。预算应根据这些预测流程进行计算，并符合实际情况。 
+  **配置警报和通知：** 使用 AWS Budgets 警报和 AWS Cost Anomaly Detection 获取警报和通知。 
+  **与主要利益相关者定期审核： **例如，与 IT、财务、平台团队和其他业务领域的利益相关者进行定期审核，以与业务方向和使用方面的变化保持一致。 

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

 **相关文档：** 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?sc_channel=cfm-blog&sc_campaign=using-the-right-tools-for-your-cloud-cost-forecasting&sc_medium=plan-and-evaluate&sc_content=cfm-blog&sc_detail=link&sc_outcome=aw&sc_publisher=cfm-awareness&trk=using-the-right-tools-for-your-cloud-cost-forecasting_cfm-blog_link) 
+  [AWS 成本和使用情况报告](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [Quick 预测](https://docs.aws.amazon.com/quicksight/latest/user/forecasts-and-whatifs.html) 
+  [Amazon Forecast](https://aws.amazon.com/forecast/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 

 **相关视频：** 
+  [How can I use AWS Budgets to track my spending and usage](https://www.youtube.com/watch?v=Ris23gKc7s0) 
+  [AWS Cost Optimization Series: AWS Budgets](https://www.youtube.com/watch?v=5vYEVQzoMeM) 

 **相关示例：** 
+  [Understand and build driver-based forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/understand-and-build-driver-based-forecasting/) 
+  [How to establish and drive a forecasting culture](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-establish-and-drive-a-forecasting-culture/) 
+  [How to improve your cloud cost forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/forecasting-blog-series-1-3-ways-to-more-effectively-forecast-cloud-spend/) 
+  [Using the right tools for your cloud cost forecasting](https://aws.amazon.com/blogs/aws-cloud-financial-management/using-the-right-tools-for-your-cloud-cost-forecasting/) 

# COST01-BP04 在组织流程中落实成本意识
<a name="cost_cloud_financial_management_cost_awareness"></a>

在影响使用量的新流程或现有流程中落实成本意识、创建成本透明度和成本问责制，并利用现有流程提高成本意识。在员工培训中贯彻成本意识。

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

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

必须在新的和现有的组织流程中建立成本意识。它是其他最佳实践的基础性先决条件之一。建议在可能的情况下重用和修改现有流程，这可以更大限度地减少对敏捷性和速度的影响。向技术团队以及业务和财务团队的决策者报告云成本，以提高成本意识，并为财务和业务利益相关者建立效率关键性能指标（KPI）。以下建议有助您在工作负载中建立成本意识：
+ 验证变更管理包含成本度量，以量化变更对财务的影响。这有助于主动解决与成本相关的问题，并强调成本节省。
+ 验证成本优化是您运营能力的核心组成部分。例如，您可以利用现有的意外事件管理流程来调查和确定成本及使用量异常或成本超支的根本原因。
+ 通过自动化或工具加快节省成本和实现业务价值。在考虑实施成本时，请在对话中加入投资回报（ROI）信息，以证明投入时间或资金的合理性。
+ 通过对云支出（包括在基于承诺的购买选项、共享服务和市场购买上的支出）实施 showback 或 chargeback 来分配云成本，以推动极具成本意识的云消费。
+ 扩展现有的培训和发展计划，在整个组织中开展成本意识培训。建议在其中加入持续的培训和认证。这样有助建立一个能够自我管理成本和使用量的组织。
+ 利用免费的 AWS 原生工具，比如 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)，[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)和 [AWS Budgets 报告](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/).

当组织持续采用 [云财务管理](https://aws.amazon.com/aws-cost-management/) （CFM）实践时，这些行为就会在工作和决策过程中落地生根。最终带来的是在从架构新的云原生应用程序的开发人员，到分析这些新的云投资的 ROI 的财务经理之间建立起更加注重成本的企业文化。

**实施步骤**
+ ** 识别相关的组织流程： **每个组织单位审核自己的流程，并确定影响成本和使用情况的流程。任何导致资源创建或终止的流程都需要进行审核。查找能够在企业中支持成本意识的流程，例如事件管理和培训。
+ **建立自我维持的成本意识文化：** 确保所有相关的利益相关者都认同变更原因和影响是一种成本，这样他们就能理解云成本。这将使贵组织能够在创新方面建立一种自我维持的成本意识文化。
+ ** 更新流程，增加成本意识：** 每个流程都进行修改，将成本意识纳入其中。流程可能需要执行额外的预检查，例如评估成本的影响，或执行后期检查，以验证成本和使用情况是否发生了预期变化。可以扩展支持流程（如培训和事件管理），以包括成本和使用情况项目。

要获得帮助，请通过您的客户团队与 CFM 专家联系，或浏览以下资源和相关文档。

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

 **相关文档：** 
+ [AWS 云财务管理](https://aws.amazon.com/aws-cost-management/)

 **相关示例：** 
+  [高效云成本管理战略](https://aws.amazon.com/blogs/enterprise-strategy/strategy-for-efficient-cloud-cost-management/) 
+  [成本控制博客系列 3：如何应对成本冲击](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-control-blog-series-3-how-to-handle-cost-shock/) 
+  [AWS Cost Management 初学者指南](https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/) 

# COST01-BP05 报告和通知成本优化
<a name="cost_cloud_financial_management_usage_report"></a>

 设置云预算并配置检测异常使用情况的机制。配置相关工具，根据预定义目标发出成本和使用量警报，并在任何使用量超过这些目标时接收通知。定期召开会议，分析工作负载的成本效益，提高成本意识。 

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

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

 必须定期报告组织内成本和使用量的优化情况。您可以安排专门的会议来讨论成本绩效，或者将成本优化纳入工作负载的常规运营报告周期。利用服务和工具定期监控成本绩效，并抓住机会实施节约成本措施。  

 使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)，按多种筛选条件和粒度查看成本和使用量，此工具提供控制面板和报告，例如按服务或按账户统计的成本、每日成本或市场成本。通过  [AWS Budgets 报告](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/)根据配置的预算，跟踪成本和使用量情况。 

 使用 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 设置自定义预算以跟踪成本和使用情况，并在您超过阈值时快速响应从电子邮件或 Amazon Simple Notification Service（Amazon SNS）通知收到的警报。 [将首选预算](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) 期设置为每日、每月、每季度或每年，并创建具体的预算限制，以随时了解实际或预测成本和使用量相对于预算阈值的情况。您还可以将 [警报](https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html) 和 [操作](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) 设置为自动运行，或在超出预算目标时通过审批流程运行。 

 启用关于成本和使用情况的通知，以确保在成本和使用情况发生意外变化时能够迅速采取行动。 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 使您能够减少意外成本，加强控制，同时不放慢创新速度。AWS Cost Anomaly Detection 可识别异常支出并找出根本原因，这有助于降低账单意外的风险。只需简单三步，您就可以创建自己的情境化监控器，在检测到任何异常支出时接收警报。 

 您也可以结合使用 [Quick](https://aws.amazon.com/quicksight/) 与 AWS 成本和使用情况报告（CUR）数据，以提供包含更精细数据的高度定制的报告。利用 Quick，您可以安排报告，并定期收到关于历史成本和使用情况或成本节省机会的成本报告电子邮件。看看我们的 [Cost Intelligence Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/a-detailed-overview-of-the-cost-intelligence-dashboard/) （CID）解决方案，该解决方案基于 Quick 构建，为您提供高级监控能力。 

 使用 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，它可提供指导，以验证预置的资源是否符合 AWS 的成本优化最佳实践。 

 通过可视化图表，对照精细的成本和使用量数据检查Savings Plans建议。每小时图表显示按需支出和建议的Savings Plans承诺，让用户深入了解预计节省的费用、Savings Plans覆盖范围和Savings Plans使用情况。这有助于组织了解Savings Plans如何应用于每小时的支出，而不必投入时间和资源来构建分析支出的模型。 

 定期创建报告，其中包含来自 AWS Cost Explorer 的Savings Plans、预留实例和 Amazon EC2 合理调整大小建议的提要，以开始降低与稳态工作负载、闲置和未充分利用的资源相关的成本。识别并收回与已部署资源的云浪费有关的支出。当创建的资源大小不正确，或者观察到不同于预期的使用模式时，就会发生云浪费。遵循 AWS 最佳实践以减少浪费，或者请您的客户团队和合作伙伴协助您 [优化并节省](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/) 云成本。 

 定期生成报告，为您的资源提供更好的购买选项，以降低工作负载的单位成本。诸如Savings Plans、预留实例或 Amazon EC2 竞价型实例等购买选项可为具备容错能力的工作负载节省大量成本，并使利益相关者（业务负责人、财务和技术团队）能够参与有关这些承诺的讨论。 

 分享包含可能有助于降低云总拥有成本（TCO）的机会或新发布公告的报告。采用新的服务、区域、功能、解决方案或新的方式来进一步削减成本。 

### 实施步骤
<a name="implementation-steps"></a>
+  **配置 AWS Budgets：** 在所有账户中为您的工作负载配置 AWS Budgets。通过使用标签设置账户总支出预算和工作负载预算。 
  +  [Well-Architected 实验室：成本和治理使用情况](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  **报告成本优化：** 定期讨论和分析工作负载的效率。使用已确立的指标，报告实现的指标和实现成本。找出任何负面趋势，加以解决，并确定可以在整个组织中推广的正面趋势。报告的参与者应该包括应用程序团队和负责人、财务团队以及云支出方面的关键决策者的代表。 

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

 **相关文档：** 
+  [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) 
+  [AWS 成本和使用情况报告](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html) 
+  [AWS Budgets 最佳实践](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html#budgets-best-practices-setting-budgets%3Fsc_channel=ba%26sc_campaign=aws-budgets%26sc_medium=manage-and-control%26sc_content=web_pdp%26sc_detail=how-do-I%26sc_outcome=aw%26trk=how-do-I_web_pdp_aws-budgets) 
+  [Amazon S3 分析](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 

 **相关示例：** 
+  [Well-Architected 实验室：成本和治理使用情况](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [开始优化 AWS 云成本的关键方法](https://aws.amazon.com/blogs/aws-cloud-financial-management/key-ways-to-start-optimizing-your-aws-cloud-costs/) 

# COST01-BP06 主动监控成本
<a name="cost_cloud_financial_management_proactive_process"></a>

利用工具和控制面板主动监控工作负载的成本。定期用已配置的工具或开箱即用的工具审核成本，不要只在收到通知时才查看成本和类别。主动监控和分析成本有助于识别积极趋势，使您能够在整个组织中推广这些趋势。

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

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

建议在组织内部主动监控成本和使用量，而不仅仅是在出现异常或意外时。在整个办公室或工作环境中，一目了然的仪表板能确保关键人员可以访问所需信息，并凸显组织对成本优化的重视程度。通过可见的控制面板，您可以积极推动成功的结果，并在整个组织中加以实施。

创建一个每日或经常性的例程，以使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或任何其他控制面板（如 [Amazon Quick](https://aws.amazon.com/quicksight/) ）来查看成本并主动分析。通过分组和筛选，在 AWS 账户级、工作负载级或特定 AWS 服务级分析 AWS 服务的使用情况和成本，并验证它们是否符合预期。使用小时级和资源级粒度和标签来筛选和识别主要资源所产生的成本。您还可以使用 [Cost Intelligence Dashboard](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)（一种 [Amazon Quick](https://aws.amazon.com/quicksight/) 解决方案，由 AWS 解决方案架构师构建）构建自己的报告，并将预算与实际成本和使用情况进行比较。

**实施步骤**
+  **报告成本优化：** 定期讨论和分析工作负载的效率。使用已确立的指标，报告实现的指标和实现成本。找出任何负面趋势，加以解决，并确定积极趋势，以便在整个组织中推广。报告应该包括应用程序团队和负责人、财务团队和管理团队的代表。
+ **为成本和使用情况创建并启用每日粒度的 [AWS Budgets](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) ，以便及时采取措施防止任何潜在的成本超支情况： ** 您可以使用 AWS Budgets 配置警报通知，以便在任何预算类型超出预配置阈值时，都会得到通知。利用 AWS Budgets 的最佳方式是将预期成本和使用量设置为您的限值，这样一来，任何超出预算的情况均视为超支。
+ **为成本监控器创建 AWS Cost Anomaly Detection： ** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 使用先进的机器学习技术来识别异常支出和根本原因，以便您快速采取行动。您可以利用它来配置成本监控器，以定义您想要评估的支出部分（例如，各项 AWS 服务、成员账户、成本分配标签和成本类别），并设置何时、何地以及如何接收警报通知。对于每个监控器，为业务负责人和技术团队附加多个警报订阅，包括每个订阅的名称、成本影响阈值和警报频率（单个警报、每日总结、每周总结）。
+ **使用 AWS Cost Explorer 或将您的 AWS 成本和使用情况报告（CUR）数据与 Amazon Quick 控制面板集成，使贵组织的成本可视化：** AWS Cost Explorer 有一个易于使用的界面，使您能够可视化、理解和管理随时间变化的 AWS 成本和使用情况。使用 [Cost Intelligence Dashboard](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) ，这是一个可定制且可访问的控制面板，可帮助创建您自己的成本管理和优化工具的基础。

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

 **相关文档：** 
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [每日成本和使用情况预算](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)

 **相关示例：** 
+  [Well-Architected 实验室：可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Well-Architected 实验室：高级可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+ [Well-Architected 实验室：云智能控制面板](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)
+ [Well-Architected 实验室：成本可视化](https://wellarchitectedlabs.com/cost/200_labs/200_5_cost_visualization/)
+ [AWS Cost Anomaly Detection 警报与 Slack 集成](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)

# COST01-BP07 及时了解新发布的服务
<a name="cost_cloud_financial_management_scheduled"></a>

 定期咨询专家或 AWS 合作伙伴，以便确定哪些服务和功能的成本更低。查看 AWS 博客和其他信息源。

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

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

AWS 不断地添加新的功能，以便您可以利用前沿技术来更快地进行试验和创新。您或许可以实施新的 AWS 服务和功能，以提高工作负载的成本效率。定期查看 [AWS 成本管理](https://aws.amazon.com/aws-cost-management/)、 [AWS 新闻博客](https://aws.amazon.com/blogs/aws/)、 [AWS 成本管理博客](https://aws.amazon.com/blogs/aws-cloud-financial-management/)和 [AWS 新增功能](https://aws.amazon.com/new/) 以了解有关新服务和功能发布的信息。新增功能博客文章简要概述了 AWS 发布的所有服务、功能和区域扩展公告。

**实施步骤**
+  **订阅博客：** 转到 AWS 博客页面，订阅新增功能博客和其他相关博客。您可以在 [通信偏好](https://pages.awscloud.com/communication-preferences?languages=english) 页面上用您的电子邮件地址进行注册。
+ **订阅 AWS 新闻： **定期查看 [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 和 [AWS 新增功能](https://aws.amazon.com/new/) 以了解有关新服务和功能发布的信息。订阅 RSS 源，或通过电子邮件关注公告和发布的信息。
+ **关注 AWS 降价：** 我们会定期对各项服务进行降价，这是 AWS 将我们的规模所带来的经济效益传递给客户的一种标准方式。截至 2022 年 4 月，AWS 自 2006 年推出以来已经降价 115 次。如果您有任何因价格问题而悬而未决的业务决策，可在降价和新服务整合后再次考虑这些决策。您可以了解以前的降价情况，包括 Amazon Elastic Compute Cloud（Amazon EC2）实例 [（在 AWS 新闻博客的降价类别中了解这些情况）](https://aws.amazon.com/blogs/aws/category/price-reduction/)。
+ ** AWS 活动和交流会： **参加当地的 AWS 峰会，以及与当地其他组织的任何当地交流会。如果您不能亲自参加，请尝试参加虚拟活动，从 AWS 专家和其他客户的业务案例中了解更多信息。
+ ** 与客户团队交流： **定期与您的客户团队交流，讨论行业发展趋势和 AWS 服务。与您的客户经理、解决方案架构师和支持团队沟通。

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

 **相关文档：** 
+  [AWS 成本管理](https://aws.amazon.com/aws-cost-management/) 
+ [AWS 新增功能](https://aws.amazon.com/new/)
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 

 **相关示例：** 
+  [Amazon EC2 – 15 年来为您优化和节省 IT 成本](https://aws.amazon.com/blogs/aws-cost-management/amazon-ec2-15th-years-of-optimizing-and-saving-your-it-costs/) 
+ [AWS 新闻博客 - 降价](https://aws.amazon.com/blogs/aws/category/price-reduction/)

# COST01-BP08 建立对成本敏感的文化
<a name="cost_cloud_financial_management_culture"></a>

 在整个组织中实施更改或计划，以建立对成本敏感的文化。建议先从小范围着手，然后随着能力的增强和组织对云的使用的增加，在更广泛的范围实施更大型的计划。 

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

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

在对成本敏感的文化中，您可以在整个组织中以有机和分散的方式执行最佳实践，从而扩展成本优化和云财务管理（财务运营、云卓越中心、云运营团队等）。与严格的自上而下的集中式方法相比，只需要很少的工作，成本意识就能让您在整个组织中培养起较高的能力水平。

建立云计算成本意识（尤其对于云计算中的主要成本驱动因素）可以让团队了解成本角度的任何更改的预期结果。访问云环境的团队应了解定价模式，以及传统的本地数据中心与云计算之间的区别。

对成本敏感的文化的主要好处是，技术团队会主动且持续地优化成本（例如，在设计新工作负载或更改现有工作负载时，优化成本会被视为一项非功能性需求），而不是根据需要被动地进行成本优化。

文化上的细微改变可对您当前和将来的工作负载的效率产生重大影响。这种情况的示例包括：
+ 在工程团队中提供能见度并提高意识，以了解他们所做的事情，以及他们在成本方面的影响。
+ 以游戏方式展示整个组织的成本和使用量。这可以通过一个公开可见的仪表板或比较各个团队的规范化成本和使用量的报告（例如，每个工作负载的成本和每笔交易的成本）来完成。
+ 认可成本效率。公开或私下奖励自愿或主动实现的成本优化成果，并从错误中吸取教训，以免日后重蹈覆辙。
+ 创建自上而下的组织要求，确保工作负载按预定义的预算运行。
+ 询问变更的业务要求，以及所请求的架构基础设施或工作负载配置变更的成本影响，以确保您只需为所需的内容付费。
+ 确保变更规划者了解对成本有影响的预期变更，并确保这些变更得到利益相关者的确认，以经济高效的方式实现业务成果。

**实施步骤**
+ **向技术团队报告云成本：** 提高成本意识，为财务和业务利益相关者建立效率 KPI。
+ **将计划变更告知利益相关者或团队成员：** 创建一个议程项目，在每周变更会议期间讨论计划变更及其对工作负载的成本效益影响。
+ ** 与客户团队交流： **与您的客户团队建立定期沟通机制，讨论行业发展趋势和 AWS 服务。与您的客户经理、架构师和支持团队沟通。
+ **分享成功案例：** 分享关于任何工作负载、AWS 账户或组织的成本降低的成功案例，以便围绕成本优化树立积极的态度并给予鼓励。
+ **培训： **确保技术团队或团队成员接受了关于 AWS 云 资源成本意识方面的培训。
+ ** AWS 活动和交流会： **参加当地的 AWS 峰会，以及与当地其他组织的任何当地交流会。
+  **订阅博客：** 转到 AWS 博客页面，订阅 [新增功能博客](https://aws.amazon.com/new/) 和其他相关博客，以关注 AWS 分享的新发布、实施、示例和更改。 

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

 **相关文档：** 
+  [AWS 博客](https://aws.amazon.com/blogs/) 
+  [AWS 成本管理](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 

 **相关示例：** 
+  [AWS 云财务管理](https://aws.amazon.com/blogs/aws-cloud-financial-management/) 
+  [AWS Well-Architected 实验室：云财务管理](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/1_cloud_financial_management/) 

# COST01-BP09 量化通过成本优化实现的业务价值
<a name="cost_cloud_financial_management_quantify_value"></a>

 通过量化成本优化带来的业务价值，您可以了解组织取得的全部效益。由于成本优化是一项必要的投资，因此量化业务价值之后，您就可以向利益相关者说明投资回报。如果能够量化业务价值，在未来的成本优化投资中，就可以从利益相关者那里得到更多支持，并获得一个框架来衡量组织成本优化活动的成果。 

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

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

 量化业务价值是指衡量企业从他们所采取的行动和作出的决策中获得的收益。业务价值可以是有形的（例如减少支出或增加利润），也可以是无形的（例如改善品牌声誉或提高客户满意度）。 

 量化成本优化带来的业务价值，意味着要确定您从提高支出效率的努力中获得了多少价值或收益。例如，如果一家公司花费 10 万 USD 在 AWS 上部署工作负载，然后对其进行优化，则在不牺牲质量或产出的情况下，新成本仅为 8 万 USD。在这种情况下，成本优化带来的量化业务价值是节省 2 万 USD。但是，除了节约成本外，企业还可以从缩短交付时间、提高客户满意度或成本优化工作带来的其他指标等方面量化价值。利益相关者需要就成本优化的潜在价值、优化工作负载的成本和回报价值作出决定。 

 除了报告通过成本优化节省的费用外，建议量化其创造的附加价值。成本优化的效益通常以每项业务成果降低的成本来量化。例如，当您购买 Savings Plans 时，可以量化 Amazon Elastic Compute Cloud（Amazon EC2）节省的成本，这可以降低成本并维持工作负载输出水平。当闲置的 Amazon EC2 实例删除，或者未连接的 Amazon Elastic Block Store（Amazon EBS）卷删除时，可以量化削减的 AWS 支出成本。 

 然而，成本优化带来的好处绝不仅仅在于降低或规避成本。考虑捕获其他数据来衡量效率提升值和业务价值。 

### 实施步骤
<a name="implementation-steps"></a>
+  **评估业务效益：**这是分析和调整 AWS 云 成本的过程，使每一美元的花费都能产生最大的效益。与其专注于降低成本而忽略业务价值，不如考虑业务效益和成本优化的投资回报，这样可能会让您所花的钱产生更大价值。这就是要明智地花钱，在能产生最大回报的领域进行投资和支出。 
+  **分析预测 AWS 成本：**预测使得财务利益相关者可以与其他内部和外部组织的利益相关者一同设定期望，并有助于提高组织的财务可预测性。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 可用于预测成本和使用量。 

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

 **相关文档：** 
+ [AWS 云 经济性](https://aws.amazon.com/economics/)
+  [AWS 博客](https://aws.amazon.com/blogs/) 
+  [AWS 成本管理](https://aws.amazon.com/blogs/aws-cost-management/) 
+  [AWS News Blog](https://aws.amazon.com/blogs/aws/) 
+  [Well-Architected 可靠性支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 

 **相关视频：** 
+ [在 AWS 上使用 Windows 挖掘业务价值](https://aws.amazon.com/windows/tco/)

 **相关示例：** 
+ [客户 360 的商业价值衡量及最大化](https://pages.awscloud.com/measuring-and-maximizing-the-business-value-of-customer-360-062022.html)
+ [采用 Amazon Web Services 托管数据库的业务价值](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Adopting Amazon Web Services Managed Databases.pdf)
+ [Amazon Web Services 为独立软件供应商带来的业务价值](https://pages.awscloud.com/rs/112-TZM-766/images/The Business Value of Amazon Web Services %28AWS%29 for Independent Software Vendors %28ISVs%29.pdf)
+ [云现代化的业务价值](https://pages.awscloud.com/aws-cfm-known-business-value-of-cloud-modernization-2022.html)
+ [迁移到 Amazon Web Services 的业务价值](https://pages.awscloud.com/global-in-gc-500-business-value-of-migration-whitepaper-learn.html)

# 支出和使用情况意识
<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.  根据工作负载的环境和业务需求（开发、用户验收测试、预生产或生产），选择美国东部区域 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) 

 **相关示例：** 
+  [VMware – 什么是云策略？](https://blogs.vmware.com/cloudhealth/what-are-cloud-policies/) 

# 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%。

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

 您需要能够近乎实时地监控 KPI 及相关的成本节省机会，并不断跟踪进度，这非常重要。要着手定义和跟踪 KPI 方向性目标，我们建议使用 [Cloud Intelligence 控制面板（CID）框架中提供的 KPI 控制面板](https://aws.amazon.com/blogs/mt/visualize-and-gain-insights-into-your-aws-cost-and-usage-with-cloud-intelligence-dashboards-using-amazon-quicksight/)。根据来自 AWS 成本和使用情况报告 的数据，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 Control Tower 登录区的 AWS 多账户策略](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) 
+  [使用 IAM 策略控制对 AWS 区域的访问](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/) 
+ [ SMART 方向性目标 ](https://en.wikipedia.org/wiki/SMART_criteria)

 **相关视频：** 
+ [ Well-Architected 实验室：方向性目标和执行性目标（第 100 级） ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/)

 **相关示例：** 
+ [ Well-Architected 实验室：停用资源（方向性目标和执行性目标） ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/)
+ [ Well-Architected 实验室：资源类型、大小和数量（方向性目标和执行性目标） ](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/6_resource_type_size_number/)

# 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 账户的付款整合至一个管理账户下，同时仍可查看每个关联账户的活动。由于成本和使用量在管理账户中汇总，因此，您可以最大限度地提高服务量折扣，并最大限度地利用承诺折扣（Savings Plans 和预留实例）来获得最高折扣。 

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

![\[Tree diagram showing how to group multiple accounts under organizational units.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/aws-organizations-ou-grouping.png)


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

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

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

 **相关文档：** 
+  [使用成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 
+  [针对工作职能的 AWS 托管策略](https://docs.aws.amazon.com//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) 
+  [启用共享预留实例和 Savings Plans 折扣](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 组织（级别 100）](https://www.wellarchitectedlabs.com/cost/100_labs/100_1_aws_account_setup/2_account_structure/)
+ [ 拆分 AWS 成本和使用情况报告 和共享访问 ](https://wellarchitectedlabs.com/cost/300_labs/300_splitting_sharing_cur_access/)
+  [为电信公司定义 AWS 多账户策略](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/) 
+  [优化 AWS 账户的最佳实践](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/) 
+  [使用 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)

 **相关示例：** 
+  [Well-Architected 实验室：基本身份和访问权限](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html) 
+  [使用 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 成本、使用量和承诺折扣（Savings Plans 和预留实例）设置通知并定义每月预算。可以在总成本级别（如所有成本）创建预算，也可以在更细粒度的级别创建预算，其中只包含特定的维度，如关联的账户、服务、标记或可用区。

 使用 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 中创建成本监视器，然后通过设置美元阈值来选择提醒首选项（例如，对影响大于 1,000 美元的异常情况发出提醒）。收到提醒后，可以分析造成异常情况的根本原因，以及对成本的影响。您还可以在 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 配置为默认情况下拒绝或允许对成员账户执行操作。有关实施访问管理的更多详细信息，请参阅[《架构完善的安全性支柱》白皮书](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 预算操作，以强制实施特定 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//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 预算操作](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 身份对特定 Amazon EC2 资源的访问](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/) 
+  [创建 IAM 策略以按系列限制 Amazon EC2 使用](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/3_ec2_restrict_family/) 
+  [架构完善的实验室：成本和使用情况治理（级别 100）](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [架构完善的实验室：成本和使用情况治理（级别 200）](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html) 
+  [使用 Amazon Q Developer in chat applications 的 Cost Anomaly Detection Slack 集成](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 提供了许多可用于实体生命周期跟踪的管理和治理服务。可以使用 [AWS Config](https://aws.amazon.com/config/) 或 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 提供一份详尽的 AWS 资源和配置清单。建议集成现有项目或资产管理系统来跟踪组织内的活动项目和产品。将当前系统与 AWS 提供的丰富事件集和指标结合起来，您就可以构建大量生命周期事件的视图并主动管理资源，以减少不必要的成本。 

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

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

 有关实施实体生命周期跟踪的更多详细信息，请参阅 [AWS Well-Architected 卓越运营支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。 

### 实施步骤
<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>

 **相关文档：** 
+ [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//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/)

# 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 成本和使用情况报告 提供所有收费 AWS 服务的每日或每小时使用粒度、费率、成本和使用属性。CUR 中的所有可能维度包括：标记、位置、资源属性和账户 ID。 

 使用以下自定义项配置 CUR： 
+  包括资源 ID 
+  自动刷新 CUR 
+  每小时粒度 
+  **版本控制：** 覆盖现有报告 
+  **数据集成：** Athena（Parquet 格式和压缩） 

 使用 [AWS Glue](https://aws.amazon.com/glue/) 准备分析数据、使用 [Amazon Athena](https://aws.amazon.com/athena/) 执行数据分析、使用 SQL 查询数据。您也可以使用 [Quick](https://aws.amazon.com/quicksight/) 构建复杂的自定义视图，并在整个组织内分发。 

### 实施步骤
<a name="implementation-steps"></a>
+  **配置成本和使用情况报告：** 使用账单控制台，至少配置一个成本和使用情况报告。配置以每小时为粒度的报告，以便包括所有标识符和资源 ID。还可以创建采用不同粒度的其他报告，以提供概括性摘要信息。 
+  **在 Cost Explorer 中配置每小时粒度：** 启用 **每小时** 和 **资源级别数据** ，以按照每小时粒度访问过去 14 天的成本和使用情况数据，并按资源级别粒度访问这些数据。
+  **配置应用程序日志记录：** 确认应用程序记录所交付的每项业务成果，以便进行跟踪和衡量。确保该数据的粒度至少为每小时一次，以便与成本和使用情况数据匹配。有关日志记录和监控的更多详细信息，请参阅 [Well-Architected 卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。 

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

 **相关文档：** 
+  [AWS 成本和使用情况报告](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) 
+  [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) 
+  [使用 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) 
+  [Well-Architected 卓越运营支柱](https://wa.aws.amazon.com/wat.pillar.operationalExcellence.en.html) 

 **相关示例：** 
+  [AWS Account Setup](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html) 
+  [AWS Cost Explorer’s New Look and Common Use Cases](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：**您可以创建 [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 函数[自动标记](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)，或使用微服务定期扫描工作负载并删除任何未标记的资源，这是测试和开发环境的理想选择。
+ ** 监控和报告标记：**要验证您是否在整个组织中保持高水平的标记，请监控并报告工作负载中的标记。可以使用 [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)

 **相关示例：** 
+ [ 根据标识或角色自动对新的 AWS 资源进行标记](https://aws.amazon.com/blogs/mt/auto-tag-aws-resources/)

# 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 账户、成本分配标记、服务或费用类型）。通过成本类别，您可以使用基于规则的引擎整理成本。您配置的规则可将成本分类。在这些规则中，您可以使用每个类别的多个维度进行筛选，例如特定 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/2023-10-03/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)。可以将多个类别分配给一个资源，并且一个资源可以位于多个不同的类别中，因此可以根据需要定义任意数量的类别，以便您在分类的结构中 [管理成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) （使用 AWS Cost Categories）。 

## 资源
<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/) 
+  [Well-Architected 实验室：成本和使用量可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected 实验室：成本类别](https://wellarchitectedlabs.com/cost/200_labs/200_cost_category/) 

# 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 Cost Categories 对应起来，以为特定业务单位就其成本中心进行账户分组，这样业务单位负责人就可以在一个位置查看多个账户的使用量。 
+  **访问：** 在 [整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) 中跟踪组织范围内的计费信息，并确认相应的利益相关者和业务负责人是否拥有访问权限。 
+  **控制：** 使用服务控制策略（SCP，Service Control Policy）、标签策略和预算警报时，使用适当的防护机制建立有效的治理机制，以防止出现意外情况。例如，您可以通过使用有效的控制机制，只允许团队在首选区域创建资源。 
+  **当前状态：** 配置显示当前成本和使用量水平的控制面板。控制面板应位于工作环境中的显眼位置，类似于操作控制面板。您可以使用 [Cloud Intelligence 控制面板（CID）](https://github.com/aws-samples/aws-cudos-framework-deployment) 或任何其他支持的产品来实现这种方便查看的效果。 
+  **通知：** 当成本或使用量超出定义的限值时，以及在 AWS Budgets 和 AWS Cost Anomaly Detection 中出现异常时，触发通知。 
+  **报告：** 汇总所有成本和使用量信息，并通过详细的、可归因的成本数据提高对云支出的认识和加强问责制。报告应与使用报告的团队相关，理想情况下应包含建议。 
+  **跟踪：** 对照配置的方向性目标或执行性目标显示当前的成本和使用量。 
+  **分析：** 让团队成员可按照所有可能的维度，执行详尽至每小时粒度的自定义和深入分析。 
+  **检查：** 及时了解资源部署和成本优化机会。获取有关组织级别资源部署的通知（使用 Amazon CloudWatch、Amazon SNS 或 Amazon SES），以及查看成本优化建议（例如，AWS Compute Optimizer 或 AWS Trusted Advisor）。 
+  **趋势分析：** 以所需的粒度显示所需时间段内成本和使用量的变化。 
+  **预测：** 使用您创建的预测控制面板，显示估计的未来成本、估计资源使用量和支出。 

 您可以使用 AWS 工具（例如 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、 [AWS 账单与成本管理](https://aws.amazon.com/aws-cost-management/aws-billing/)或 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) ）来获取基本功能，您也可以将 CUR 数据与 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) 和 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) 集成来提供此功能，以获取更详细的视图。如果贵组织不具备必备技能或带宽，则可以与 [AWS ProServ](https://aws.amazon.com/professional-services/)、 [AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)或 [AWS Partner](https://aws.amazon.com/partners/) 合作，并使用他们的工具。您也可以使用第三方工具，但首先要验证成本是否为贵组织提供了价值。 

### 实施步骤
<a name="implementation-steps"></a>
+  **允许对工具进行团队性质的访问：** 配置您的账户并创建组，这些组可以访问所需的成本和使用量报告来了解其使用情况，并使用 [AWS Identity and Access Management](https://aws.amazon.com/iam/) 来 [控制](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html) 对 AWS Cost Explorer 等工具的访问。这些组必须包括负责或管理应用程序的所有团队的代表。这证明每个团队都可以访问他们的成本和使用量信息，以跟踪他们的使用情况。 
+  **配置 AWS Budgets：** [在所有账户中为您的工作负载配置 AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) 。通过使用标记设置账户总支出预算和工作负载预算。在 AWS Budgets 中配置通知，以便在您超出预算金额或估计成本超出预算时收到警报。 
+  **配置 AWS Cost Explorer：** 为您的工作负载和账户配置 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) ，从而实现您的成本数据可视化，以便进一步分析。为工作负载创建一个控制面板，用于跟踪总体支出、工作负载的关键使用指标，以及基于历史成本数据的未来成本预测。 
+  **配置 AWS Cost Anomaly Detection：** 将 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) 用于您创建的账户、核心服务或成本类别，以监控您的成本和使用量，并检测异常支出。您可以在汇总的报告中单独收到警报，以及在电子邮件或 Amazon SNS 主题中收到警报，以便您分析和确定异常的根本原因，并确定导致成本增加的原因。 
+  **配置高级工具：** 您可以选择为组织创建自定义工具，以便提供额外详细信息和所需的粒度。您可以使用 [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)实施高级分析功能，使用 [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway)实施控制面板。考虑使用 [CID 解决方案](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) ，它具有预配置的高级控制面板。您还可以与 [AWS Partner](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) 合作并采用其云管理解决方案，以便在一个方便的位置激活云账单监控和优化功能。 

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

 **相关文档：** 
+  [AWS 成本管理](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html) 
+  [标记](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) AWS 资源 
+  [使用 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://aws.amazon.com/aws-cost-management/aws-cost-categories/) 
+  [使用 AWS 管理云财务](https://aws.amazon.com/aws-cost-management/) 
+  [服务控制策略示例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) 
+  [AWS APN 合作伙伴 – 成本管理](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management) 

 **相关视频：** 
+  [部署 Cloud Intelligence 控制面板](https://www.youtube.com/watch?v=FhGZwfNJTnc) 
+  [获取任何 FinOps 或成本优化指标或 KPI 的警报](https://www.youtube.com/watch?v=dzRKDSXCtAs) 

 **相关示例：** 
+  [Well-Architected 实验室 – AWS 账户设置](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/) 
+  [Well-Architected 实验室：账单可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) 
+  [Well-Architected 实验室：成本和治理使用情况](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) 
+  [Well-Architected 实验室：成本和使用量分析](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html) 
+  [Well-Architected 实验室：成本和使用量可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected 实验室：Cloud Intelligence 控制面板](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) 
+  [如何使用 SCP 跨账户设置权限防护机制](https://aws.amazon.com/blogs/security/how-to-use-service-control-policies-to-set-permission-guardrails-across-accounts-in-your-aws-organization/) 

# 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 中启用拆分成本分配数据。通过拆分成本分配数据，您可以了解并优化容器化应用程序的成本和使用量，并根据共享计算和内存资源的使用情况，将应用程序成本分配给各个业务实体。如果您有共享的 API Gateway 和 AWS Lambda 函数使用量，那么您可以使用 [AWS Application Cost Profiler](https://docs.aws.amazon.com/application-cost-profiler/latest/userguide/introduction.html) ，根据函数的 `租户 ID` 或 `客户 ID`对使用情况分类。 

### 实施步骤
<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 标记最佳实践](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。
+ **实施工作负载吞吐量或输出监控：**实施工作负载吞吐量监控或警报，在输入请求或输出完成时触发。将其配置为在工作负载请求或输出下降到零时发出通知，指示不再使用工作负载资源。如果在正常情况下，工作负载周期性地下降到零，则加入时间因素。有关未使用或未充分利用的资源的更多详细信息，请参阅 [AWS Trusted Advisor 成本优化检查](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 成本优化检查](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/Amazon/latest/monitoring/publishingMetrics.html) 

 **相关视频：** 
+  [如何使用 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 最短存储持续时间取决于所使用的存储类。有关每个存储类的最短存储持续时间的摘要，请参阅[跨 Amazon 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/)。 

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

![\[Flow chart depicting the steps of decommissioning a resource.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/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) 
+  [了解哪个用户启动了 Amazon EC2 实例](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/) 

 **相关示例：** 
+  [架构完善的实验室：停用资源（级别 100）](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

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

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

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

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

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

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

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

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

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

 **相关示例：** 
+  [计划自动删除 AWS CloudFormation 堆栈](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/) 
+  [架构完善的实验室 – 自动停用资源（级别 100）](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 
+  [Servian AWS 自动清理](https://github.com/servian/aws-auto-cleanup) 

# 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 的 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) 

 **相关视频：** 
+  [使用 Amazon Data Lifecycle Manager 实现 Amazon EBS 快照自动化](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/) 
+  [Well-Architected 实验室：自动停用资源（级别 100）](https://www.wellarchitectedlabs.com/cost/100_labs/100_goals_and_targets/4_decommission_resources/) 

# 具有成本效益的资源
<a name="a-cost-effective-resources"></a>

**Topics**
+ [COST 5.您在选择服务时如何评估成本？](cost-05.md)
+ [COST 6.在选择资源类型、规模和数量时，如何实现成本目标？](cost-06.md)
+ [COST 7.您如何使用定价模式来降低成本？](cost-07.md)
+ [COST 8.您如何规划数据传输费用？](cost-08.md)

# COST 5.您在选择服务时如何评估成本？
<a name="cost-05"></a>

Amazon EC2、Amazon EBS 和 Amazon S3 属于构建块 AWS 服务。托管服务（如 Amazon RDS 和 Amazon DynamoDB）属于更高级别或应用程序级别的 AWS 服务。通过选择适当的基础服务和托管服务，您可以优化工作负载，从而降低成本。例如，使用托管服务，您可以节省或消除大部分管理和运营开销，从而使您有精力从事应用程序和业务相关活动。

**Topics**
+ [COST05-BP01 确定组织对成本的要求](cost_select_service_requirements.md)
+ [COST05-BP02 分析此工作负载的所有组件](cost_select_service_analyze_all.md)
+ [COST05-BP03 对每个组件进行彻底分析](cost_select_service_thorough_analysis.md)
+ [COST05-BP04 选择具有成本效益许可的软件](cost_select_service_licensing.md)
+ [COST05-BP05 选择此工作负载的组件，以便根据组织的优先事项优化成本](cost_select_service_select_for_cost.md)
+ [COST05-BP06 对不同时间的不同使用情况执行成本分析](cost_select_service_analyze_over_time.md)

# COST05-BP01 确定组织对成本的要求
<a name="cost_select_service_requirements"></a>

 与团队成员合作，为此工作负载确定成本优化与其他支柱（例如性能和可靠性）之间的平衡。 

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

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

 在大多数组织中，信息技术（IT）部门由多个小型团队组成，每个小团队都有自己的议程和重点领域，这反映了其团队成员的专长和技能。您需要了解组织的总体目标、优先事项、具体目标以及每个部门或项目如何为这些总体目标做出贡献。对所有基本资源（包括人员、设备、技术、材料和外部服务）进行分类，是实现组织目标和全面预算规划的重要一环。采用这种系统化的方法来确定和了解成本，对于组织制定切合实际且稳健的成本计划至关重要。 

 在为工作负载选择服务时，了解组织的优先要务至关重要。在成本优化和 AWS Well-Architected Framework 的其他支柱（例如性能和可靠性）之间取得平衡。这一过程应系统性地定期进行，以反映组织目标、市场条件和运营动态的变化。完全成本优化的工作负载是最符合组织需求的解决方案，但不一定是成本最低的。与组织内的所有团队（例如产品、业务、技术和财务）会面以收集信息。在有冲突的利益或替代方法之间做出权衡并评估其影响，以便在确定工作重心或选择行动方案时作出明智的决策。 

 例如，加快新功能上市的速度可能会比成本优化更重要，或者您可以为非关系数据选择关系数据库，以简化迁移系统的工作，而不是迁移到针对您的数据类型优化的数据库和更新您的应用程序。 

### 实施步骤
<a name="implementation-steps"></a>
+ **确定组织对成本的要求：**与组织中的团队成员会面，这些成员包括产品管理、应用程序负责人、开发和运营团队、管理和财务角色。对此工作负载及其组件的 Well-Architected 支柱进行优先级排序，输出应该是一个按顺序排列的支柱列表。您还可以为每个支柱添加一个权重，以指示该支柱体现的额外关注程度，或者两个支柱之间的关注点的相似程度。
+  **解决技术债务并将其记录在案：**在工作负载审查期间，解决技术债务。记录待办事项以便将来重新审视工作负载，目标是重构或重新构造以进一步优化工作负载。必须向其他利益相关者明确说明所做的权衡取舍。 

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

 **相关最佳实践：** 
+ [REL11-BP07 构造您的产品以满足可用性目标和正常运行时间服务等级协议（SLA）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [OPS01-BP06 评估权衡](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)

 **相关文档：** 
+  [AWS 总拥有成本（TCO）计算器](https://aws.amazon.com/tco-calculator/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [云产品](https://aws.amazon.com/products/) 

# COST05-BP02 分析此工作负载的所有组件
<a name="cost_select_service_analyze_all"></a>

 确认已分析工作负载的每个组件，无论当前大小或当前成本如何。审核工作应该体现出可能带来的好处，例如当前成本和预期成本。 

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

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

 旨在为组织提供业务价值的工作负载组件可能包含各种服务。对于每个组件，组织可以选择特定的 AWS 云 服务来满足业务需求。对这些服务的熟悉程度或以往的使用经验等因素可能会影响这种选择。 

 确定组织的需求（如 [COST05-BP01 确定组织对成本的要求](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)中提到的）后，对工作负载中的所有组件进行全面分析。根据当前和预计的成本和规模，分析每个组件。结合工作负载在其生命周期内可能实现的节省来考虑分析成本。分析该工作负载的所有组件所花费的精力应与优化该特定组件预期能产生的潜在节省或改进相匹配。例如，如果拟议资源的成本为每月 10 USD，在预测的负载下不会超过每月 15 USD，则花一天的时间将成本降低 50％（每月 5 USD）可能会超过系统使用寿命内的潜在收益。使用更快、更有效的基于数据的预估可为该组件带来最佳的总体结果。 

 工作负载可能会随时间变化，如果工作负载架构或使用量发生变化，原本合适的服务集可能不再是最优之选。为甄选服务进行分析时，必须考虑工作负载当前和未来的状态以及使用量水平。为将来的工作负载状态或使用量实施服务可以减少或消除未来进行更改所需的工作量，从而降低总体成本。例如，最初使用 Amazon EMR Serverless 可能是合适的选择。但是，随着该服务使用量的增加，过渡到 Amazon EC2 上的 Amazon EMR 可以降低该工作负载组件的成本。 

 对所有工作负载组件进行战略审查，无论其目前的属性如何，都有可能随着时间的推移带来显著的改进和财务节约。应仔细考量审查过程中投入的精力，同时仔细考虑可能实现的潜在优势。 

 [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/)（CUR）可以分析概念验证（PoC）或运行环境的成本。还可以使用 [AWS 定价计算器](https://calculator.aws/#/) 来估算工作负载成本。 

### 实施步骤
<a name="implementation-steps"></a>
+  **列出工作负载组件：**生成工作负载组件的列表。这用于验证是否分析了每个组件。投入的工作量应体现出组织优先事项所规定的工作负载的关键性。如果有多个数据库，按功能（例如生产数据库存储）将资源分组可以提高效率。
+  **对组件列表进行优先级排序：**获取组件列表，按工作顺序进行优先级排序。通常按照组件的成本从最昂贵到最便宜的顺序排列，或者按照组织优先事项规定的关键性排列。
+ **执行分析：**对于列表中的每个组件，检查可用的选项和服务，然后选择最符合组织优先事项的选项。

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

 **相关文档：** 
+  [AWS 定价计算器](https://calculator.aws/#/) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [云产品](https://aws.amazon.com/products/) 

# COST05-BP03 对每个组件进行彻底分析
<a name="cost_select_service_thorough_analysis"></a>

 分析组织为每个组件付出的总体成本。通过考虑运营和管理成本（尤其是在使用云提供商提供的托管服务时）来计算总拥有成本。审核工作量应该体现可能带来的好处（例如分析时间与组件成本成正比）。 

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

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

 利用节省下来的时间，您的团队将能够专注于解决技术债务、创新和增值功能，并打造企业的竞争优势。例如，您可能需要尽快将数据库从本地环境直接迁移（也称为更换主机）到云，然后再进行优化。值得探索的是，通过使用 AWS 上可消除或减少许可证成本的托管服务，您可以节省多少成本。AWS 上的托管服务消除了维护服务的运营和管理负担（例如修补或更新 OS），让您可以专注于创新和业务。 

 由于托管服务在云级运行，它们可以提供更低的单位事务或服务成本。您可以在不改变应用程序核心架构的情况下进行潜在优化，以获得一些切实的优势。例如，您可能希望通过迁移到数据库即服务平台 [如 [Amazon Relational Database Service（Amazon RDS）](https://aws.amazon.com/rds/)]，或将您的应用程序迁移到完全托管式平台（如 [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)），来减少管理数据库实例所花的时间。 

通常，可以设置托管服务的部分属性，以确保容量足够。您必须设置和监控这些属性，以便最大限度地减少多余容量，并最大限度地提高性能。您可以使用 AWS 管理控制台或 AWS API 和 SDK 来修改 AWS Managed Services 的属性，以使资源需求匹配不断变化的要求。例如，您可以增加或减少 Amazon EMR 集群（或 Amazon Redshift 集群）上的节点数量，以扩展或缩减集群。

您还可以在 AWS 资源上打包多个实例，以实现更高密度的使用量。例如，您可以在单个 Amazon Relational Database Service（Amazon RDS）数据库实例上预置多个小型数据库。随着使用量的增长，您可以使用快照和还原过程将其中一个数据库迁移到专用 Amazon RDS 数据库实例。

在托管服务上预置工作负载时，您必须了解调整服务容量的要求。这些要求通常是时间、工作量和对正常工作负载运营的任何影响。预置的资源必须留出时间来进行任何更改，并预置必要的开销以允许这样做。通过使用与系统和监控工具（如 Amazon CloudWatch）集成的 API 和开发工具包，可以将修改服务所需的持续工作量减少至接近零。

[Amazon RDS](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/) 和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 提供托管数据库服务。[Amazon Athena](https://aws.amazon.com/athena/)、[Amazon EMR](https://aws.amazon.com/emr/) 和 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) 提供托管分析服务。

[AMS](https://aws.amazon.com/managed-services/) 是代表企业客户和合作伙伴运营 AWS 基础设施的服务。该服务提供了一个安全且合规的环境，您可以将工作负载部署到其中。AMS 使用具有自动化功能的企业云运营模型，可以满足组织要求，更快地迁移到云中并降低持续管理的成本。

**实施步骤**
+ **执行彻底分析：**使用组件列表，从最高优先级到最低优先级遍历每个组件。对于优先级较高且成本较高的组件，执行额外分析并评估所有可用选项及其长期影响。对于优先级较低的组件，评估使用情况的变化是否会更改组件的优先级，然后以适当的工作量进行分析。
+  **比较托管和未托管资源：**考虑您所管理的资源的运营成本，并将其与 AWS 托管的资源进行比较。例如，审查您在 Amazon EC2 实例上运行的数据库，并与 Amazon RDS 选项（AWS 托管的服务）进行比较，或将 Amazon EMR 与在 Amazon EC2 上运行 Apache Spark 进行比较。当从自我管理的工作负载迁移到 AWS 完全托管的工作负载时，请仔细研究您的选择。需要考虑的三个最重要的因素是您想使用的[托管服务类型](https://aws.amazon.com/products/?&aws-products-all.q=managed)、您将用于[迁移数据](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/)的过程，以及了解 [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)。 

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

 **相关文档：** 
+  [AWS 总拥有成本（TCO）计算器](https://aws.amazon.com/tco-calculator/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [AWS 云 产品](https://aws.amazon.com/products/) 
+ [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)

 **相关视频：** 
+ [为何要迁移到托管数据库？](https://www.youtube.com/watch?v=VRFdc-MVa4I)
+ [什么是 Amazon EMR，如何才能使用它来处理数据？](https://www.youtube.com/watch?v=jylp2atrZjc)

 **相关示例：** 
+ [为何要迁移到托管数据库？](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/)
+ [使用 AWS DMS 将相同 SQL Server 数据库中的数据整合到单个 Amazon RDS for SQL Server 数据库中](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/)
+ [将数据大规模交付到 Amazon Managed Streaming for Apache Kafka（Amazon MSK）](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson)
+ [将 ASP.NET Web 应用程序迁移到 AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson)

# COST05-BP04 选择具有成本效益许可的软件
<a name="cost_select_service_licensing"></a>

 开源软件无需软件许可成本，从而大大节省了工作负载的成本。如果需要许可软件，应避免使用绑定到任意属性（如 CPU）的许可证，而应使用绑定到输出或结果的许可证。这些许可证的成本与所提供的效益更为相当。 

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

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

 开源起源于软件开发，表示软件符合某些自由发布的标准。任何人都可以检查、修改和增强开源软件的源代码。根据业务要求、工程师技能、预测的使用情况或其他技术依赖关系，组织可以考虑在 AWS 上使用开源软件来最大限度地降低许可成本。换句话说，使用[开源软件](https://aws.amazon.com/what-is/open-source/)可以降低软件许可成本。随着工作负载规模的扩展，这可能对工作负载成本产生重大影响。 

 将许可软件能够带来的好处与总成本进行比较，以优化工作负载。对许可中的任何更改及其对工作负载成本的影响建模。如果供应商更改了数据库许可证的成本，请调查这会如何影响工作负载的整体效率。考虑供应商的历史定价公告，了解其产品中的许可更改趋势。许可成本也可以独立于吞吐量或使用量进行扩缩，例如按硬件扩缩的许可证（CPU 绑定许可证）。应避免使用这些许可证，因为成本会迅速增加，而且无法取得相应的结果。 

 例如，与在 Windows 上运行 Amazon EC2 实例相比，使用 Linux 操作系统在 us-east-1 中运行另一个 Amazon EC2 实例可以将成本降低大约 45%。 

 [AWS 定价计算器](https://calculator.aws/) 提供了一种全面的方法，可以比较具有不同许可选项的各种资源（例如 Amazon RDS 实例和不同的数据库引擎）的成本。此外，AWS Cost Explorer 为现有工作负载（尤其是附带不同许可证的工作负载）的成本提供了宝贵的视角。对于许可证管理，[AWS License Manager](https://aws.amazon.com/license-manager) 提供了一种监督和处理软件许可证的简化方法。客户可以在 AWS 云 中部署和运行他们首选的开源软件。 

### 实施步骤
<a name="implementation-steps"></a>
+ **分析许可选项：**查看可用软件的许可条款。查看具有所需功能的开源版本，以及许可软件提供的效益是否大于成本。优惠条款可确保软件成本与所提供的效益相符。
+ **分析软件提供商：**查看供应商的任何历史定价或许可变更。了解与成果不符的任何变化，例如在特定供应商硬件或平台上运行的惩罚性条款。此外，还要了解他们如何执行审计和处罚。

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

 **相关文档：** 
+ [AWS 开源](https://aws.amazon.com/opensource/)
+  [AWS 总拥有成本（TCO）计算器](https://aws.amazon.com/tco-calculator/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [云产品](https://aws.amazon.com/products/) 

 **相关示例：** 
+ [开源博客](https://aws.amazon.com/blogs/opensource/)
+ [AWS 开源博客](https://aws.github.io/)
+ [优化与许可评测](https://aws.amazon.com/optimization-and-licensing-assessment/)

# COST05-BP05 选择此工作负载的组件，以便根据组织的优先事项优化成本
<a name="cost_select_service_select_for_cost"></a>

 为工作负载选择所有组件时考虑成本因素。这包括使用应用程序级别的托管服务或无服务器服务、容器或事件驱动型架构，以降低整体成本。使用开源软件、没有许可证费用的软件或替代方案来尽可能减少许可证成本，从而减少开支。 

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

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

 在选择所有组件时考虑服务和选项的成本。这包括使用应用程序级别的托管服务，例如 [Amazon Relational Database Service](https://aws.amazon.com/rds/) （Amazon RDS）、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、 [Amazon Simple Notification Service](https://aws.amazon.com/sns/) （Amazon SNS）和 [Amazon Simple Email Service](https://aws.amazon.com/ses/) （Amazon SES），来降低组织的总体成本。 

 使用无服务器服务和容器进行计算，例如用于静态网站的 [AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Simple Storage Service](https://aws.amazon.com/s3/) （Amazon S3）。尽可能将您的应用程序容器化，并使用 AWS 托管的容器服务，例如 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) （Amazon ECS）或 [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) （Amazon EKS）。 

 使用开源软件或没有许可证费用的软件，尽可能减少许可证成本，例如，对计算工作负载使用 Amazon Linux 或将数据库迁移到 Amazon Aurora。 

 您可以使用无服务器或应用程序级服务，如 [Lambda](https://aws.amazon.com/lambda/)、 [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/)、 [Amazon SNS](https://aws.amazon.com/sqs/)和 [Amazon SES](https://aws.amazon.com/ses/)。这些服务剔除了管理资源的需要，并提供代码执行、排队服务和消息传递功能。另一个好处是，这些服务可以根据使用量扩展性能和成本，从而实现有效的成本分配和归属。 

 还可以通过无服务器服务来使用 [事件驱动型架构](https://aws.amazon.com/what-is/eda/) 。事件驱动型架构是推送式的，所以当事件在路由器中出现时，一切都按需发生。这样，您就不会为检查事件的连续轮询而付费。这意味着更少的网络带宽消耗、更低的 CPU 使用率、更少的闲置实例集容量，以及更少的 SSL/TLS 握手次数。 

 有关无服务器的更多信息，请参阅 [架构完善的无服务器应用程序剖析白皮书。](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) 

### 实施步骤
<a name="implementation-steps"></a>
+  **选择每个服务以优化成本：** 使用经过优先级排序的列表和分析，选择最符合组织优先事项的每个选项。与其增加容量来满足需求，不如考虑其他可以提供更高性价比的选项。例如，您需要审查您的数据库在 AWS 上的预期流量，并考虑增加实例大小或使用 Amazon ElastiCache 服务（Redis 或 Memcached），来为您的数据库提供缓存机制。 
+  **评估事件驱动型架构：** 通过使用无服务器架构，您还可以为基于微服务的分布式应用程序构建事件驱动型架构，这有助于您构建可扩展、有弹性、敏捷且具有成本效益的解决方案。 

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

 **相关文档：** 
+  [AWS 总拥有成本（TCO）计算器](https://aws.amazon.com/tco-calculator/) 
+  [AWS 无服务器](https://aws.amazon.com/serverless/) 
+  [什么是事件驱动型架构？](https://aws.amazon.com/what-is/eda/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [云产品](https://aws.amazon.com/products/) 
+  [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis) 

 **相关示例：** 
+  [Getting started with event-driven architecture](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/) 
+  [事件驱动型架构](https://aws.amazon.com/event-driven-architecture/) 
+  [How Statsig runs 100x more cost-effectively using Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/) 
+  [Best practices for working with AWS Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) 

# COST05-BP06 对不同时间的不同使用情况执行成本分析
<a name="cost_select_service_analyze_over_time"></a>

 工作负载可能会随时间而变化。某些服务或功能在不同的使用水平下更具成本效益。通过根据每个组件在一段时间内的预期使用情况执行分析，工作负载可在其生命周期内保持成本效益。 

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

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

随着 AWS 发布新的服务和功能，适用于您的工作负载的最佳服务可能会发生变化。所需的工作量应反映出可能带来的好处。工作负载审核频率取决于您的组织要求。如果工作负载的成本很高，则尽早实施新服务可最大限度地节省成本，因此提高审核频率可能是有利的。审核的另一个触发因素是使用模式发生变化。使用量发生重大变化可能表明备用服务更加理想。

 如果您需要将数据移入 AWS 云，可以选择 AWS 提供的任何种类的服务和合作伙伴工具，来帮助您迁移数据集，无论它们是文件、数据库、机器镜像、数据块卷，还是磁带备份。例如，要将大量数据移入和移出 AWS，或者要在边缘处理数据，您可以使用 AWS 专用设备之一，经济高效地离线移动 PB 级数据。再例如，对于更高的数据传输率，直接连接服务可能比 VPN 更便宜，而 VPN 可以为您的业务提供所需的稳定一致的连接。 

 根据一段时间内针对不同使用情况的成本分析，审查您的扩缩活动。分析结果，看看是否可以调整扩缩策略，以增加具有多种实例类型和购买选项的实例。审查您的设置，看看是否可以减小最小值，用较小的实例集大小满足用户请求，并增加更多资源来满足预期的高需求。 

 通过与组织中的利益相关者讨论，针对一段时间内的不同使用情况进行成本分析，并使用 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) 的预测功能来预测服务变化的潜在影响。使用 AWS Budgets、CloudWatch 计费警报和 AWS Cost Anomaly Detection 监视使用水平触发因素，以尽早确定和实施最具成本效益的服务。 

**实施步骤**
+ **定义预计使用模式：**与组织中的相关人员（例如市场营销部门和产品负责人）合作，记录哪些预期和预计使用模式适用于工作负载。与业务利益相关者讨论历史和预测的成本及使用量的增加，并确保增加幅度与业务需求一致。确定预计会有更多用户使用您的 AWS 资源的日历日、周或月，这表明您应该增加现有资源的容量，或采用额外的服务来降低成本和提高性能。
+ **对预测的使用情况执行成本分析：**使用定义的使用模式，对每个点执行分析。分析工作量应该体现潜在的成果，例如，如果使用情况变化很大，应执行彻底分析，以验证任何成本和变化。换句话说，当成本增加时，企业的使用量也应该增加。

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

 **相关文档：** 
+  [AWS 总拥有成本（TCO）计算器](https://aws.amazon.com/tco-calculator/) 
+  [Amazon S3 存储类](https://aws.amazon.com/s3/storage-classes/) 
+  [云产品](https://aws.amazon.com/products/) 
+ [ Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [云数据迁移](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)

 **相关视频：** 
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)

# COST 6.在选择资源类型、规模和数量时，如何实现成本目标？
<a name="cost-06"></a>

确保选择适合当前任务的资源规模和资源数量。选择最经济实惠的资源类型、规模和数量可以尽可能减少浪费。

**Topics**
+ [COST06-BP01 执行成本建模](cost_type_size_number_resources_cost_modeling.md)
+ [COST06-BP02 根据数据选择资源类型、规模和数量](cost_type_size_number_resources_data.md)
+ [COST06-BP03 根据指标自动选择资源类型、规模和数量](cost_type_size_number_resources_metrics.md)

# COST06-BP01 执行成本建模
<a name="cost_type_size_number_resources_cost_modeling"></a>

确定组织要求（如业务需求和现有承诺），并对工作负载及其每个组件进行成本建模（总体成本）。对不同预计负载下的工作负载执行基准测试活动，并比较成本。建模工作量应该体现可能带来的好处，例如花费的时间与组件成本成正比。

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

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

 对工作负载及其每个组件执行成本建模，以了解资源之间的平衡，并在给定的具体性能水平下，确定工作负载中各项资源的适当规模。在评估计划的工作负载部署的价值实现结果时，了解成本考虑因素可为您组织的业务案例和决策过程提供依据。 

 对不同预计负载下的工作负载执行基准测试活动，并比较成本。建模工作量应该体现可能带来的好处，例如花费的时间与组件成本或预计可节省的成本成正比。有关最佳实践，请参阅[《AWS Well-Architected Framework – 性能效率支柱》白皮书的“审核”部分](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)。 

 例如，要为由计算资源组成的工作负载创建成本模型，[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 可以协助对所运行的工作负载进行成本建模。它根据历史使用量为计算资源提供合理调整大小的建议。确保将 CloudWatch 代理部署到 Amazon EC2 实例，以收集内存指标，这会通过 AWS Compute Optimizer 内更准确的建议为您提供帮助。这是计算资源的理想数据源，因为它是一项免费的服务，并且使用机器学习根据风险等级提出多个建议。 

 有[多个服务](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)可以与自定义日志一起用作数据源，针对其他服务和工作负载组件合理调整规模，例如 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)。AWS Trusted Advisor 会检查资源并标记出利用率低的资源，这可以帮助您合理调整资源规模，并建立成本模型。 

 以下是成本建模数据和指标的建议： 
+  监控必须准确反映用户体验。为时间段选择正确的粒度，并仔细选择最大值或第 99 个百分位值而不是平均值。 
+  为覆盖任何工作负载周期所需的分析时间段选择正确的粒度。例如，如果执行为期两周的分析，您可能会忽略高利用率的月度周期，这可能导致预置不足。 
+  通过考虑您现有的承诺、为其他工作负载选择的定价模式，以及更快地创新和专注于核心商业价值的能力，为您计划的工作负载选择合适的 AWS 服务。 

**实施步骤**
+ **对资源执行成本建模：**将工作负载或概念验证部署到具有特定资源类型和规模的单独账户，然后执行测试。使用测试数据运行工作负载，并记录输出结果以及运行测试时段的成本数据。然后，重新部署工作负载或更改资源类型和规模，并再次运行测试。在创建成本模型时，考虑您可能与这些资源一起使用的任何产品的许可证费用，以及用于部署和管理这些资源的估计运营（劳动力或工程师）成本。考虑对一个时间段（每小时、每天、每月、每年或三年）进行成本建模。

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

 **相关文档：** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+ [确定合理调整规模的机会](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+  [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/) 
+  [成本优化：合理调整 Amazon EC2 的规模](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+ [AWS 定价计算器](https://calculator.aws/#/)

 **相关示例：** 
+ [执行数据驱动的成本建模](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [估算计划的 AWS 资源配置的成本](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [选择合适的 AWS 工具](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)

# COST06-BP02 根据数据选择资源类型、规模和数量
<a name="cost_type_size_number_resources_data"></a>

根据工作负载和资源特征的相关数据选择资源规模或类型，例如计算、内存、吞吐量或写入密集型资源。选择的依据通常是使用工作负载的上一个版本（本地版本）、文档或关于工作负载的其他信息源。

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

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

 Amazon EC2 提供许多实例类型，它们具有不同的 CPU、内存、存储和联网容量级别，适合不同的使用案例。这些实例类型具有不同的 CPU、内存、存储和联网容量组合，让您在为项目选择正确的资源组合时有更多的备选方案。每种实例类型都有多种大小，因此您可以根据工作负载的需求调整资源。要确定您需要哪种实例类型，请根据您计划在实例上运行的应用程序或软件，收集相关的系统要求详细信息。这些详细信息应包括以下各项： 
+  操作系统 
+  CPU 内核数量 
+  GPU 内核数 
+  系统内存 (RAM) 容量 
+  存储类型和空间 
+  网络带宽要求 

 确定计算要求的目的以及需要哪个实例，然后探索各种 Amazon EC2 实例系列。Amazon 提供以下实例类型系列： 
+  通用型 
+  计算优化型 
+  内存优化型 
+  存储优化型 
+  加速计算型 
+  HPC 优化型 

 要更深入地了解特定 Amazon EC2 实例系列适用的特定目的和使用案例，请参阅 [AWS 实例类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。 

 想要选择最能满足您需求的特定实例系列和实例类型，系统要求的收集至关重要。实例类型名称由系列名称和实例大小组成。例如，t2.micro 实例属于 T2 系列，而且是微型实例。 

 根据工作负载和资源特征（例如计算、内存、吞吐量或写入密集型）选择资源规模或类型。选择的依据通常是使用成本建模、工作负载的上一个版本（例如本地版本）、文档或关于工作负载的其他信息源（白皮书或发布的解决方案）。使用 AWS 定价计算器或成本管理工具有助于就实例类型、规模和配置作出明智的决策。 

### 实施步骤
<a name="implementation-steps"></a>
+ **根据数据选择资源：**使用您的成本建模数据来选择预期的工作负载使用水平，然后选择指定的资源类型和规模。根据成本建模数据，确定虚拟 CPU 的数量、总内存 (GiB)、本地实例存储容量 (GB)、Amazon EBS 卷和网络性能级别，同时考虑实例所需的数据传输速率。务必根据详细的分析和准确的数据做出选择，这样不仅能够优化性能，还能有效管理成本。

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

 **相关文档：** 
+ [AWS 实例类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/) 
+  [成本优化：合理调整 EC2 的大小](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) 

 **相关视频：** 
+ [为您的工作负载选择正确的 Amazon EC2 实例 ](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [合理调整服务规模](https://youtu.be/wcp1inFS78A)

 **相关示例：** 
+ [让发现和比较 Amazon EC2 实例类型变得更容易](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)

# COST06-BP03 根据指标自动选择资源类型、规模和数量
<a name="cost_type_size_number_resources_metrics"></a>

使用当前运行的工作负载的指标选择正确的规模和类型，从而优化成本。为计算、存储、数据和网络服务适当地预置吞吐量、规模和存储。这可以通过自动扩展等反馈环路进行，也可以在工作负载中使用自定义代码来实现。

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

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

在工作负载中创建一个反馈循环，此循环使用正在运行的工作负载中的活动指标来对该工作负载进行更改。您可以使用托管服务（例如 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)），您可以配置该服务来执行正确的规模调整操作。AWS 还提供了 [API、软件开发工具包](https://aws.amazon.com/developer/tools/)和功能，能够以最小的工作量修改资源。您可以对工作负载进行编程以停止和启动 Amazon EC2 实例，从而允许更改实例大小或实例类型。这带来双重好处：既合理调整了大小，又几乎消除了进行更改所需的全部运营成本。

某些 AWS 服务内置了自动类型或大小选择功能，例如 [Amazon Simple Storage Service 智能分层](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)。Amazon S3 智能分层会根据您的使用情况模式，自动在两个访问层之间移动数据：频繁访问和不频繁访问。

**实施步骤**
+ **通过配置工作负载指标来提高可观测性**：捕获工作负载的关键指标。这些指标指明了客户体验（例如工作负载输出），并适应资源类型和规模之间的差异（例如 CPU 和内存使用情况）。对于计算资源，请分析性能数据以适当调整 Amazon EC2 实例大小。识别空闲实例和未充分利用的实例。要查找的关键指标是 CPU 使用率和内存利用率（例如，按照[在启用 AWS Compute Optimizer 和内存利用率的情况下调整大小](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)中的说明，在 90% 的时间内 40% 的 CPU 利用率）。确定四周内最大 CPU 使用率和内存利用率低于 40% 的实例。这些是大小适当能够降低成本的实例。对于存储资源（例如 Amazon S3），您可以使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)，它允许您在存储桶级别查看各个类别的 28 个指标，默认情况下可在控制面板中查看 14 天的历史数据。您可以按摘要和成本优化或事件筛选 Amazon S3 Storage Lens 控制面板，以分析特定指标。 
+ **查看合理调整大小建议：**使用成本管理控制台中的 AWS Compute Optimizer 和 Amazon EC2 合理调整大小工具中的合理调整大小建议，或查看 AWS Trusted Advisor 如何合理调整资源大小，以对工作负载进行调整。在合理调整不同资源的大小时，请务必使用[正确的工具](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)，并遵循[合理调整大小准则](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)，无论是 Amazon EC2 实例、AWS 存储类，还是 Amazon RDS 实例类型。对于存储资源，您可以使用 Amazon S3 Storage Lens，它可以让您了解对象存储使用情况、活动趋势，并提出可行的建议，以优化成本并应用数据保护最佳实践。使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 从整个组织的指标分析中得出的上下文建议，您可以立即采取措施来优化存储。 
+ **根据指标自动选择资源类型和规模：**使用工作负载指标，手动或自动选择工作负载资源。对于计算资源，配置 AWS Auto Scaling 或在应用程序中实施代码可以减少频繁更改所需的工作量，而且实现更改的速度可能比手动操作更快。您可以在单个 Auto Scaling 组中启动并自动扩展按需型实例和竞价型实例的实例集。除了获得使用竞价型实例的折扣外，您还可以使用预留实例或 Savings Plans 来享受常规按需型实例定价的折扣率。将所有这些因素相结合，可帮助您优化 Amazon EC2 实例的成本节约，并确定应用程序所需的规模和性能。您还可以在 [Auto Scaling 组（ASG）](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)中使用[基于属性的实例类型选择（ABS）](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)策略，该策略允许您将实例要求表示为一组属性，例如 vCPU、内存和存储。您可以在发布新一代实例类型时自动使用它们，并通过 Amazon EC2 竞价型实例访问更广泛的容量。Amazon EC2 实例集和 Amazon EC2 Auto Scaling 会选择并启动符合指定属性的实例，无需手动选择实例类型。对于存储资源，您可以使用 [Amazon S3 Intelligent Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) 和 [Amazon EFS 不频繁访问](https://aws.amazon.com/efs/features/infrequent-access/)功能，这些功能允许您自动选择存储类，以便在数据访问模式更改时自动节省存储成本，而不会影响性能或增加运营开销。 

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

 **相关文档：** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS 合理调整大小](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/) 
+  [设置 CloudWatch](https://docs.aws.amazon.com/Amazon/latest/monitoring/GettingSetup.html) 
+  [CloudWatch 发布自定义指标](https://docs.aws.amazon.com/Amazon/latest/monitoring/publishingMetrics.html) 
+  [开始使用 Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [Amazon S3 智能分层](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) 
+  [Amazon EFS 不频繁访问](https://aws.amazon.com/efs/features/infrequent-access/) 
+  [使用 SDK 启动 Amazon EC2 实例](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html) 

 **相关视频：** 
+  [适当调整服务大小](https://www.youtube.com/watch?v=wcp1inFS78A) 

 **相关示例：** 
+  [基于属性为 Amazon EC2 实例集的 Auto Scaling 选择实例类型](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/) 
+  [使用计划的扩缩优化 Amazon Elastic Container Service 成本](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/) 
+  [使用 Amazon EC2 Auto Scaling 的预测性扩缩](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [使用 Amazon S3 Storage Lens 优化成本并提高可见性](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 
+  [架构完善的实验室：合理调整大小建议（级别 100）](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [架构完善的实验室：在启用 AWS Compute Optimizer 和内存利用率的情况下合理调整大小（级别 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 

# COST 7.您如何使用定价模式来降低成本？
<a name="cost-07"></a>

使用最适合的资源定价模式可以尽可能减少支出。

**Topics**
+ [COST07-BP01 执行定价模式分析](cost_pricing_model_analysis.md)
+ [COST07-BP02 根据成本选择区域](cost_pricing_model_region_cost.md)
+ [COST07-BP03 选择具有经济实惠条款的第三方协议](cost_pricing_model_third_party.md)
+ [COST07-BP04 针对此工作负载的所有组件实施定价模型](cost_pricing_model_implement_models.md)
+ [COST07-BP05 在管理账户级别执行定价模式分析](cost_pricing_model_master_analysis.md)

# COST07-BP01 执行定价模式分析
<a name="cost_pricing_model_analysis"></a>

分析工作负载的每个组件。确定组件和资源是长时间运行（享受承诺折扣），还是短时间动态运行（采用 Spot 或按需定价）。使用成本管理工具中的建议对工作负载执行分析，并对这些建议应用业务规则以实现高回报。

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

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

AWS 有多种[定价模式](https://aws.amazon.com/pricing/)，让您可以通过符合组织需求、最具成本效益的方式支付资源费用，具体取决于产品。与您的团队一起确定最适合的定价模式。您的定价模式通常包含多种选项的组合，根据供应情况来决定 

 使用**按需型实例**时，您按小时或按秒（最少 60 秒）支付计算或数据库容量的费用，具体取决于您运行哪些实例，而无需长期承诺或预付款。 

 **Savings Plans** 是一种灵活的定价模式，以低廉的价格使用 Amazon EC2、Lambda 和 AWS Fargate，而无需承诺在一年或三年内保持一致的使用量（以每小时美元金额计算）。 

 **竞价型实例**是一种 Amazon EC2 定价机制，允许您以折扣的小时费率（与按需型实例价格相比，最多可减少 90%）申请备用计算容量，无需前期投入。 

 使用**预留实例**时，通过预付容量费用，您可以享受高达 75% 的折扣。有关更多详细信息，请参阅[使用预留优化成本](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)。 

 您可以选择为与生产、质量和开发环境相关的资源包括 Savings Plans。或者，因为沙盒资源仅在需要时才会启用，所以您可以为该环境中的资源选择按需模式。使用亚马逊[竞价型实例](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances)降低 Amazon EC2 成本，或使用[计算 Savings Plans](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) 降低 Amazon EC2、Fargate 和 Lambda 成本。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建议工具通过 Saving Plans 提供承诺折扣的机会。 

 如果您过去一直为 Amazon EC2 购买[预留实例](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop)，或者在组织内确立了成本分配做法，则目前可以继续使用 Amazon EC2 预留实例。但是，我们建议制定一项战略，以便在未来使用 Savings Plans，它是一种更灵活的成本节省机制。您可以在 AWS Cost Management 中刷新 Savings Plans（SP）建议，以便随时生成新的 Savings Plans 建议。使用预留实例（RI）来降低 Amazon RDS、Amazon Redshift、Amazon ElastiCache 和 Amazon OpenSearch Service 成本。Saving Plans 和预留实例提供三个选项：全额预付、部分预付和无预付款。使用 AWS Cost Explorer RI 和 SP 购买建议中提供的建议。 

 要为 Spot 工作负载寻找机会，请查看总体使用量的小时视图，并确定使用量或弹性的定期变化周期。您可以为各种容错和灵活应用程序使用竞价型实例。示例包括无状态 Web 服务器、API 端点、大数据和分析应用程序、容器化工作负载、CI/CD 及其他灵活工作负载。 

 分析您的 Amazon EC2 和 Amazon RDS 实例，确定在您不使用时（下班后和周末）是否可以将其关闭。与 24/7 全天候使用这些实例相比，您可以使用这种方法将成本降低 70% 或更多。如果您的 Amazon Redshift 集群只需要在特定时间内可用，则可以暂停集群并在稍后恢复它。停止 Amazon Redshift 集群或 Amazon EC2 和 Amazon RDS 实例时，计算计费会停止，仅收取存储费用。 

 请注意，[按需容量预留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html)（ODCR）不是一项价格折扣。不管您是否在预留容量中运行实例，容量预留均按照与按需费率同等的费率来收费。当您需要为计划运行的资源提供足够的容量时，应该考虑使用这种模式。ODCR 不需要做出长期承诺，因为当您不再需要时可以取消它们，但它们也可以享受 Savings Plans 或预留实例提供的折扣。 

**实施步骤**
+  **分析工作负载弹性：**在 Cost Explorer 或自定义控制面板中使用每小时粒度，分析您的工作负载的弹性。确定正在运行的实例数量的规律性变化。短期实例比较适合采用竞价型实例或竞价型实例集。
  +  [Well-Architected 实验室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
  +  [Well-Architected 实验室：成本可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  **查看现有定价合同：**查看当前合同或对长期需求的承诺。分析您目前拥有的承诺以及这些承诺中有多少正在使用。利用已有的合同折扣或企业协议。[企业协议](https://aws.amazon.com/pricing/enterprise/)让客户可以选择定制最适合其需求的协议。对于长期承诺，请考虑预留定价折扣、特定实例类型的预留实例或 Savings Plans、实例系列、AWS 区域 和可用区。 
+ **执行承诺折扣分析：**在账户中使用 Cost Explorer 查看 Savings Plans 和预留实例建议。要验证您是否实施了具有所需折扣和风险的正确建议，请按照 [Well-Architected 实验室](https://wellarchitectedlabs.com/cost/costeffectiveresources/)操作。

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

 **相关文档：** 
+  [获取预留实例建议](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [实例购买选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+ [AWS Enterprise](https://aws.amazon.com/pricing/enterprise/)

 **相关视频：** 
+  [节省高达 90% 并在竞价型实例上运行生产工作负载](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **相关示例：** 
+  [Well-Architected 实验室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) 
+  [Well-Architected 实验室：成本可视化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) 
+  [Well-Architected 实验室：定价模式](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html) 

# COST07-BP02 根据成本选择区域
<a name="cost_pricing_model_region_cost"></a>

资源定价在每个区域中可能各不相同。确定区域成本差异，仅当需要满足延迟、数据驻留和数据主权要求时，才在成本较高的区域部署。考虑区域成本有助于您为此工作负载支付最低的总体费用。

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

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

此 [AWS 云 基础设施](https://aws.amazon.com/about-aws/global-infrastructure/) 是全球性的，托管在 [世界范围内的多个位置](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)，并围绕 AWS 区域、可用区、Local Zone、AWS Outposts 和 Wavelength Zone 构建。区域是世界上的一个物理位置，每个区域都是一个独立的地理位置，而 AWS 有多个可用区。可用区是每个区域内多个相互隔离的位置，由一个或多个独立的数据中心组成，每个数据中心都拥有冗余的电力、联网和连接。

每个 AWS 区域都在当地市场条件下运作，由于土地、光纤、电力和税收等成本的不同，每个区域的资源定价也不同。选择特定区域来运行解决方案组件或整个解决方案，以便您可以在全球范围内以尽可能低的价格运行。使用 [AWS 计算器](https://calculator.aws/#/) ，按位置类型（区域、Wavelength Zone 和 Local Zone）和区域搜索服务，估算您的工作负载在不同区域的成本。

在架构解决方案时，最佳实践是设法将计算资源放在更接近用户的位置，以提供更低的延迟和强大的数据主权。根据您的业务、数据隐私、性能和安全要求来选择地理位置。对于具有全球终端用户的应用程序，请使用多个位置。

 如果您不存在数据隐私、安全和业务要求方面的义务，请使用 AWS 服务价格较低的区域来部署您的工作负载。例如，如果您的默认区域是 ap-southeasth-2（悉尼），并且不存在使用其他区域的限制（例如数据隐私、安全），则在 north-east-1（弗吉尼亚州北部）区域部署非关键（开发和测试）Amazon EC2 实例成本更少。 

![\[图表显示不同区域的合规性、延迟、成本以及服务和功能。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/region-feature-matrix.png)


 

 前面的矩阵表显示，区域 4 是这种给定场景的最佳选择，因为与其他区域相比，其延迟较低，可以使用相应服务，而且是最便宜的区域。 

## 实施步骤
<a name="implementation-steps"></a>
+ ** 查看 AWS 区域定价： **分析当前区域的工作负载成本。首先使用按服务和使用类型划分的最高成本，计算其他可用区域的成本。如果预测的节省超过迁移组件或工作负载的成本，则迁移到新区域。
+  **审查多区域部署的要求：** 分析您的业务要求和义务（数据隐私、安全或性能），以确认是否存在任何会阻止您使用多个区域的限制。如果不存在要求您只能使用单个区域的限制，那么就使用多个区域。 
+  **分析所需的数据传输：** 在选择区域时要考虑数据传输成本。让您的数据靠近您的客户和资源。在数据流动和数据传输非常少时，选择成本较低的 AWS 区域。根据您对数据传输的业务要求，可以使用 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[AWS PrivateLink](https://aws.amazon.com/privatelink/)、 [AWS Direct Connect](https://aws.amazon.com/directconnect/)和 [AWS Virtual Private Network](https://aws.amazon.com/vpn/) 来降低您的联网成本，提高性能，并增强安全性。 

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

 **相关文档：** 
+  [获取预留实例建议](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [Amazon EC2 定价](https://aws.amazon.com/ec2/pricing/) 
+  [实例购买选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [区域表](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) 

 **相关视频：** 
+  [节省高达 90% 并在竞价型实例上运行生产工作负载](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **相关示例：** 
+ [ 常见架构的数据传输成本概述 ](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [ 全球部署的成本考虑因素 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [ 为工作负载选择区域时应考虑的事项 ](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
+ [ Well-Architected 实验室：按区域限制服务使用（级别 200） ](https://www.wellarchitectedlabs.com/cost/200_labs/200_2_cost_and_usage_governance/2_ec2_restrict_region/)

# COST07-BP03 选择具有经济实惠条款的第三方协议
<a name="cost_pricing_model_third_party"></a>

 经济实惠的协议和条款可确保这些服务的成本与所提供的效益相称。选择与可为组织带来额外效益相称的协议和定价。 

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

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

 市场上有多种产品可用于管理云环境中的成本。根据客户需求，它们在功能方面可能有一些差异，例如有些侧重于成本治理或成本可见性，而有些则侧重于成本优化。想要得到有效的成本优化和治理，一个关键因素是使用具有必要功能的正确工具和正确的定价模型。这些产品有不同的定价模型。有些产品按每月账单的一定比例收费，有些则按所实现节省额的一定比例收费。理想情况下，您应该只为您需要的资源付费。 

 当您在云中使用第三方解决方案或服务时，确保定价结构契合期望结果非常重要。定价应与其带来的结果和价值成比例。例如，可带来一定百分比节省额的软件中，节省额（结果）越高，其价格也就越高。许可协议规定，随着开支的增加，您需要支付更多的费用，这可能并不总是有利于您优化成本。但是，如果供应商为您的账单的所有部分都提供明显的优惠，那么这种按比例收费可能是合理的。 

 例如，如果您使用的其他服务没有带来任何好处，提供 Amazon EC2 相关建议并按整体账单一定比例收取费用的解决方案将会变得更加昂贵。另一个示例是根据托管资源的成本，按一定百分比收费的托管服务。实例越大并不一定意味着需要更多的管理工作，但会收取更多费用。验证这些服务定价安排是否在其服务中包含了成本优化计划或功能，以提高效率。 

 客户可能会发现市场上的这些产品更先进或更易于使用。您需要考虑这些产品的成本，并考虑长期潜在的成本优化结果。 

### 实施步骤
<a name="implementation-steps"></a>
+  **分析第三方协议和条款：**查看第三方协议中的定价。基于不同的使用情况水平执行建模，并将新成本（例如使用新服务，或当前服务由于工作负载增长导致使用量增加）纳入考量。确定额外成本能否为业务提供所需效益。 

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

 **相关文档：** 
+  [获取预留实例建议](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [实例购买选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 

 **相关视频：** 
+  [节省高达 90% 并在竞价型实例上运行生产工作负载](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

# COST07-BP04 针对此工作负载的所有组件实施定价模型
<a name="cost_pricing_model_implement_models"></a>

 永久运行的资源应利用预留容量，如Savings Plans或预留实例。短期容量配置为使用竞价型实例或竞价型实例集。按需型实例仅用于无法中断并且运行时长不足以使用预留容量的短期工作负载（根据具体的资源类型，时长介于 25% 到 75% 之间）。 

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

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

 为了提高成本效率，AWS 根据您过去的使用情况提供多项承诺建议。您可以使用这些建议，了解可以节省的金额以及如何使用承诺。您使用这些服务的方式可以是按需型实例、竞价型实例，或在一定时间内承诺使用量，通过预留实例（RI）和Savings Plans（SP）降低按需成本。您不仅需要了解每个工作负载组件和多项 AWS 服务，还需要了解这些服务的承诺折扣、购买选项和竞价型实例，以优化您的工作负载。 

 考虑您的工作负载组件的要求，并了解这些服务的不同定价模型。定义这些组件的可用性要求。确定工作负载中是否存在执行功能的多个独立资源，以及工作负载随着时间推移的需求情况。使用默认的按需定价模型和其他适用模型比较资源成本。考虑资源或工作负载组件的任何潜在更改。 

 例如，让我们看一下 AWS 上的这个 Web 应用程序架构。此示例工作负载由多个 AWS 服务组成，例如 Amazon Route 53、AWS WAF、Amazon CloudFront、Amazon EC2 实例、Amazon RDS 实例、负载均衡器、Amazon S3 存储和 Amazon Elastic File System（Amazon EFS）。您需要审查每项服务，并确定使用不同定价模型带来的潜在成本节省机会。其中一些服务可能有资格使用 RI 或 SP，而另一些可能只能使用按需方案。如下图所示，一些 AWS 服务可以使用 RI 或 SP 承诺。 

![\[Chart of AWS services committed using Reserved Instances and Savings Plans\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/ri-sp-services.png)


### 实施步骤
<a name="implementation-steps"></a>
+  **实施定价模型：**根据分析结果，购买Savings Plans、预留实例或实施竞价型实例。如果是首次承诺购买，请选择列表中的前 5 个或 10 个建议，然后在接下来的一到两个月内监控并分析结果。AWS Cost Management Console会指导您完成整个过程。查看控制台中的 RI 或 SP 建议，自定义建议（类型、付款和期限），查看每小时承诺（例如每小时 20 USD），然后添加到购物车。折扣将自动应用于符合条件的使用量。定期购买少量承诺折扣（例如每 2 周或每月一次）。对可以中断或者无状态的工作负载实施竞价型实例。最后，选择按需型 Amazon EC2 实例并为其余需求分配资源。
+  **工作负载审核周期：**实施工作负载审核周期，用于专门分析定价模型覆盖范围。工作负载达到所需覆盖范围后，可部分（每隔几个月）购买额外的承诺折扣，或者随着组织的使用情况变化进行购买。

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

 **相关文档：** 
+ [了解您的 Savings Plans 建议](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+  [访问预留实例建议](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [如何购买预留实例](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/) 
+  [实例购买选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [竞价型实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 
+ [其他 AWS 服务的预留模式](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [Savings Plans支持的服务](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)

 **相关视频：** 
+  [节省高达 90% 并在竞价型实例上运行生产工作负载](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **相关示例：** 
+ [在购买Savings Plans之前我应该考虑什么？](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [如何使用 Cost Explorer 来分析我的支出和使用情况？](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)

# COST07-BP05 在管理账户级别执行定价模式分析
<a name="cost_pricing_model_master_analysis"></a>

 检查账单和成本管理工具，并查看承诺和预留的建议折扣，以便在管理账户级别执行定期分析。 

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

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

 定期执行成本建模帮助您跨多个工作负载进行优化。例如，如果总体上多个工作负载使用按需型实例，则变更的风险较低，并且实施基于承诺的折扣可降低总体成本。建议每两周到一个月定期执行一次分析。这样您可以进行少量调整性采购，因此定价模型的覆盖范围会随着工作负载及其组件的变化而不断变化。 

 使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建议工具，寻找在您的管理账户中享受承诺折扣的机会。在计算管理账户级别的建议时，考虑 AWS 组织中启用了预留实例（RI）或 Savings Plans（SP）的所有账户的使用情况。它们也是在启用折扣共享的情况下计算的，以便推荐可在不同账户中最大限度实现节省的承诺。 

 虽然在许多情况下，在管理账户级别购买可以优化以最大限度地节省开支，但在某些情况下，您可能会考虑在关联账户级别购买 SP，例如当您希望首先对该特定关联账户中的资源使用量应用折扣时。在个人账户级别计算成员账户建议，以便为每个独立账户实现最大限度的节省。如果您的账户同时拥有 RI 和 SP 承诺，则它们将按以下顺序应用： 

1.  区域 RI 

1.  标准 RI 

1.  可转换 RI 

1.  实例 Savings Plan 

1.  计算 Savings Plan 

 如果您在管理账户级别购买 SP，则将根据从最高到最低的折扣百分比来应用实惠。管理账户级别的 SP 会查看所有关联账户，并在任何可以实现最高折扣的地方应用实惠。如果您希望限制应用实惠的位置，则可以在关联账户级别购买 Savings Plan，而只要该账户在运行符合条件的计算服务，就会首先在其上应用折扣。当账户未运行符合条件的计算服务时，将在同一管理账户下的其他关联账户之间共享折扣。默认情况下，折扣共享处于启用状态，不过您可以根据需要关闭。 

 在整合账单系列中，Savings Plans首先应用于拥有者账户的使用量，然后应用于其他账户的使用量。只有当您启用了共享时才会出现这种情况。您的Savings Plans将首先应用到能够实现最高节省百分比的地方。如果多个使用量具有相同的节省百分比，则Savings Plans将应用于Savings Plans比率最低的第一个使用量。Savings Plans将继续应用，直到没有剩余的使用量或您的承诺用量用完为止。剩余的所有使用量均按照按需费率收取费用。您可以在 AWS Cost Management 中刷新Savings Plans建议，以便随时生成新的Savings Plans建议。 

 分析实例的灵活性之后，您可以按照建议进行承诺。创建成本模型，使用可能的不同资源选项分析工作负载的短期成本、分析 AWS 定价模式并使其与您的业务需求保持一致，发现总拥有成本和 [成本优化](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html) 机会。 

### 实施步骤
<a name="implementation-steps"></a>

 **执行承诺折扣分析**：在账户中使用 Cost Explorer 查看Savings Plans和预留实例建议。确保了解实惠配套建议，估算每月支出以及每月节省。查看管理账户级别的建议，这些建议根据 AWS 组织中启用了 RI 或Savings Plans折扣共享的所有成员账户的使用情况计算得出，以便各账户实现最大限度的节省。您可以按照 Well-Architected 实验室操作，确认您实施了具有所需折扣和风险的正确建议。 

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

 **相关文档：** 
+  [AWS 定价如何运作？](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln) 
+  [实例购买选项](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) 
+  [实惠配套概览](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html) 
+  [实惠配套建议](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [获取预留实例建议](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) 
+  [了解您的 Saving Plans 建议](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html) 
+  [Savings Plans如何应用于您的 AWS 使用](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html) 
+  [实惠配套与整合账单](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/) 
+  [启用共享预留实例和Savings Plans折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html) 

 **相关视频：** 
+  [节省高达 90% 并在竞价型实例上运行生产工作负载](https://www.youtube.com/watch?v=BlNPZQh2wXs) 

 **相关示例：** 
+  [AWS Well-Architected 实验室：定价模式（级别 200）](https://wellarchitectedlabs.com/cost/200_labs/200_3_pricing_models/) 
+  [AWS Well-Architected 实验室：定价模式分析（级别 200）](https://www.wellarchitectedlabs.com/cost/200_labs/200_pricing_model_analysis/) 
+  [在购买 Savings Plan 之前我应该考虑什么？](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/) 
+  [如何使用滚动Savings Plans来降低承诺风险？](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/) 
+  [何时使用竞价型实例](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.html) 

# COST 8.您如何规划数据传输费用？
<a name="cost-08"></a>

确保规划并监护您的数据传输费用，以便制定架构决策，尽可能降低成本。持续以小步迭代的方式进行架构优化可以实现运营成本的大幅降低。

**Topics**
+ [COST08-BP01 执行数据传输建模](cost_data_transfer_modeling.md)
+ [COST08-BP02 选择组件以便优化数据传输成本](cost_data_transfer_optimized_components.md)
+ [COST08-BP03 实施服务以便降低数据传输成本](cost_data_transfer_implement_services.md)

# COST08-BP01 执行数据传输建模
<a name="cost_data_transfer_modeling"></a>

 收集组织要求，并对工作负载及其每个组件执行数据传输建模。这样可以确定满足当前数据传输要求的最低成本点。 

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

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

 在云端设计解决方案时，由于习惯于设计使用本地数据中心的架构或者缺乏相应的知识，数据传输费用常常会被忽视。AWS 中的数据传输费用由流量的来源、目的地和数量决定。在设计阶段将这些费用考虑在内可以节省成本。了解工作负载中的哪些环节需要进行数据传输、传输成本及其相关好处，对于准确估算总拥有成本（TCO）非常重要。因此，您可以作出明智的决定来修改或接受架构决策。例如，您可能有一个多可用区配置，可以在可用区之间复制数据。 

 您可以对在工作负载中传输数据的服务组件进行建模，并确定这是可接受的成本（类似于在两个可用区中支付计算和存储费用），以实现所需的可靠性和韧性。对不同使用级别的成本进行建模。工作负载的使用量可能随时间而变化，不同的服务可能在不同的级别上更具有成本效益。 

 在对数据传输进行建模时，须考虑接收了多少数据以及这些数据来自哪里。此外，还须考虑处理了多少数据以及需要多少存储或计算容量。在建模期间，应遵循工作负载架构的联网最佳实践，以优化潜在的数据传输成本。 

 可利用 AWS 定价计算器 查看特定 AWS 服务和预期数据传输的估计成本。如果您的工作负载已经在运行（用于测试目的或在预生产环境中），请使用 [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/)（CUR）来了解您的数据传输成本并对其进行建模。配置概念证明 (PoC) 或测试您的工作负载，并在实际的模拟负载下运行测试。您可以根据不同的工作负载需求对成本进行建模。 

### 实施步骤
<a name="implementation-steps"></a>
+  **确定需求：**计划在来源和目的地之间传输数据的主要目标和业务需求是什么？ 最后预期的业务成果是什么？ 收集业务需求并定义预期结果。 
+  **确定来源和目的地：**数据传输的数据来源和目的地是什么，例如是在 AWS 区域内传输、传入 AWS 服务还是传出到互联网？ 
  + [AWS 区域内的数据传输](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
  + [AWS 区域之间的数据传输](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
  + [将数据传输到互联网](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+  **识别数据分类：**此数据传输的数据分类是什么？ 这是什么样的数据？ 数据量有多大？ 必须多久传输一次数据？ 数据是否敏感？ 
+  **确定要使用的 AWS 服务或工具：**此数据传输使用哪些 AWS 服务？ 是否可以将已经预置的服务用于其他工作负载？ 
+  **计算数据传输成本：**结合使用 [AWS 定价](https://aws.amazon.com/pricing/)和您之前创建的数据传输建模，计算工作负载的数据传输成本。计算不同使用情况水平的数据传输成本，包括工作负载使用量的增加和减少这两种情况。如果工作负载架构有多个传输选项，则计算每个选项的成本以便进行比较。 
+  **将成本与成果相关联：**对于产生的每项数据传输成本，明确要实现的工作负载成果。如果在组件之间传输，可能是为了实现解耦；如果在可用区之间传输，则可能是为了实现冗余。 
+  **创建数据传输建模：**收集所有信息后，为多个使用案例和不同工作负载创建概念性基础数据传输建模。 

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

 **相关文档：** 
+  [AWS 缓存解决方案](https://aws.amazon.com/caching/aws-caching/) 
+  [AWS 定价](https://aws.amazon.com/pricing/) 
+  [Amazon EC2 定价](https://aws.amazon.com/ec2/pricing/on-demand/) 
+  [Amazon VPC 定价](https://aws.amazon.com/vpc/pricing/) 
+ [了解数据传输费用](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)

 **相关视频：** 
+ [监控和优化数据传输成本](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [ S3 Transfer Acceleration](https://youtu.be/J2CVnmUWSi4)

 **相关示例：** 
+ [常见架构的数据传输成本概述](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS 规范性指南 - 联网](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)

# COST08-BP02 选择组件以便优化数据传输成本
<a name="cost_data_transfer_optimized_components"></a>

 选择所有组件然后设计架构，以便降低数据传输成本。其中包括使用广域网（WAN）优化和多可用区（AZ）配置等组件 

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

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

 针对数据传输进行构造，可最大限度地降低数据传输成本。这可能涉及使用内容分发网络来定位更靠近用户的数据，或者使用从您的本地设施到 AWS 的专用网络链接。您还可以使用 WAN 优化和应用程序优化来减少组件之间传输的数据量。 

 向 AWS 云 传输数据或在其中传输数据时，必须根据不同的使用案例、数据的性质和可用的网络资源来了解目的地，以便选择正确的 AWS 服务来优化数据传输。AWS 提供一系列针对不同数据迁移要求量身定制的数据传输服务。根据组织内部的业务需求，选择正确的[数据存储](https://aws.amazon.com/products/storage/)和[数据传输](https://aws.amazon.com/cloud-data-migration/)选项。 

 在规划或审查您的工作负载架构时，请考虑以下几点： 
+  **在 AWS 内使用 VPC 端点：**VPC 端点允许在您的 VPC 和支持的 AWS 服务之间建立私有连接。这使您可以避免使用公共互联网，而使用公共互联网会产生数据传输成本。 
+  **使用 NAT 网关：**使用 [NAT 网关](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)，以便私有子网中的实例可以连接到互联网或 VPC 外部的服务。检查发送流量最多的 NAT 网关后面的资源是否与 NAT 网关位于同一可用区。如果未在同一可用区，则在与资源相同的可用区中创建新的 NAT 网关，从而降低跨可用区传输数据的费用。 
+  **使用 AWS Direct Connect** Direct Connect 会绕过公共互联网，在您的本地网络和 AWS 之间直接建立私有连接。与通过互联网传输大量数据相比，这可能更具成本效益且更加一致。 
+  **避免跨区域边界传输数据：**在 AWS 区域 之间（从一个区域到另一个区域）传输数据通常会产生费用。采用多区域方法应是一项深思熟虑的决定。有关更多详细信息，请参阅[多区域场景](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html)。 
+  **监控数据传输：**使用 Amazon CloudWatch 和 [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)来捕获有关您的数据传输和网络使用情况的详细信息。分析 VPC 中捕获的网络流量信息，例如进出网络接口的 IP 地址或范围。 
+  **分析您的网络使用情况：**使用计量和报告工具（例如 AWS Cost Explorer、CUDOS 控制面板，或 CloudWatch）了解工作负载的数据传输成本。 

### 实施步骤
<a name="implementation-steps"></a>
+  **选择数据传输组件：**使用[COST08-BP01 执行数据传输建模](cost_data_transfer_modeling.md)中所述的数据传输建模，关注产生最多数据传输成本之处，或者工作负载使用情况发生变化时产生最多数据传输成本之处。寻找替代架构或其他组件，以消除或减少数据传输的需要（或降低其成本）。 

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

 **相关最佳实践：** 
+  [COST08-BP01 执行数据传输建模](cost_data_transfer_modeling.md) 
+  [COST08-BP03 实施服务以便降低数据传输成本](cost_data_transfer_implement_services.md) 

 **相关文档：** 
+ [云数据迁移](https://aws.amazon.com/cloud-data-migration/)
+  [AWS 缓存解决方案](https://aws.amazon.com/caching/aws-caching/) 
+  [使用 Amazon CloudFront 更快地交付内容](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) 

 **相关示例：** 
+ [常见架构的数据传输成本概述](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS 网络优化技巧](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [使用 Apache Parquet 格式的 VPC 流日志优化性能并降低网络分析成本](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)

# COST08-BP03 实施服务以便降低数据传输成本
<a name="cost_data_transfer_implement_services"></a>

 实施服务以减少数据传输。例如，使用边缘站点或内容分发网络（CDN）向最终用户交付内容，在应用程序服务器或数据库前构建缓存层，并使用专用网络连接而不是 VPN 连接到云端。 

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

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

 您可以利用多种 AWS 服务来优化网络数据传输使用情况。根据工作负载组件、类型和云架构，这些服务有助于您在云端压缩、缓存、共享和分发流量。 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 是一个全球内容分发网络，可提供低延迟、高传输速度的数据。它在世界各地的边缘站点缓存数据，从而减少资源负担。通过使用 CloudFront，您可以减少向全球大量用户分发内容的管理工作，同时将延迟降到最低。此 [安全实惠服务包](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch) 有助于您节省高达 30% 的 CloudFront 使用量 - 如果您计划随着时间的推移增加使用量。 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) 允许您建立到 AWS 的专用网络连接。与基于互联网的连接相比，这可以降低网络成本、增加带宽并提供更一致的网络体验。 
+  [Site-to-Site VPN](https://aws.amazon.com/vpn/) 可让您在专用网络和 AWS 全球网络之间建立安全的专用连接。此网络是小型办公室或业务合作伙伴的理想之选，因其提供简化的连接，并且是完全托管的弹性服务。 
+  [VPC 端点](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) 允许通过专用网络在 AWS 服务之间建立连接，可用于减少公共数据传输和 [NAT 网关](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 成本。 [网关 VPC 端点](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html) 不按小时收费，支持 Amazon S3 和 Amazon DynamoDB。 [接口 VPC 端点](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) 由 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 提供，有小时费和每 GB 使用成本。 
+  [NAT 网关](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 与独立的 NAT 实例相比，提供内置的扩展和管理功能，可降低成本。将 NAT 网关放置在与高流量实例所在的同一可用区中，并考虑对需要访问 Amazon DynamoDB 或 Amazon S3 的实例使用 VPC 端点，以降低数据传输和处理成本。 
+  使用具有计算资源的 [AWS Snow Family](https://aws.amazon.com/snow/) 设备在边缘收集和处理数据。AWS Snow Family 设备（[Snowball Edge](https://aws.amazon.com/snowcone/)、 [Snowball Edge](https://aws.amazon.com/snowball/) 和 [Snowmobile](https://aws.amazon.com/snowmobile/)）让您可以经济高效地将 PB 级数据离线迁移到 AWS 云。 

### 实施步骤
<a name="implementation-steps"></a>
+  **实施服务：** 使用数据传输建模并查看 VPC 流日志，根据服务和工作负载类型选择适用的 AWS 网络服务。了解产生最多成本和最多数据流之处。了解 AWS 服务并评测是否存在一种服务，可以减少或消除传输，特别是联网和内容交付。如有需要重复访问数据或存在大量数据的情况，则应了解缓存服务。 

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

 **相关文档：** 
+  [AWS Direct Connect](https://aws.amazon.com/directconnect/) 
+  [AWS 探索我们的产品](https://aws.amazon.com/) 
+  [AWS 缓存解决方案](https://aws.amazon.com/caching/aws-caching/) 
+  [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 
+  [AWS Snow Family](https://aws.amazon.com/snow/) 
+  [Amazon CloudFront 安全实惠服务包](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/) 

 **相关视频：** 
+  [监控和优化数据传输成本](https://www.youtube.com/watch?v=UjliYz25_qo) 
+  [AWS Cost Optimization Series: CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k) 
+  [如何降低我的 NAT 网关的数据传输费用？](https://www.youtube.com/watch?v=hq4KtPRezus) 

 **相关示例：** 
+  [How-to chargeback shared services: An AWS Transit Gateway example](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/) 
+  [Understand AWS data transfer details in depth from cost and usage report using Athena query and QuickSight](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/) 
+  [Overview of Data Transfer Costs for Common Architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/) 
+  [Using AWS Cost Explorer to analyze data transfer costs](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/) 
+  [Cost-Optimizing your AWS architectures by utilizing Amazon CloudFront features](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/) 
+  [如何降低我的 NAT 网关的数据传输费用？](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/) 

# 管理需求和供应资源
<a name="a-manage-demand-and-supply-resources"></a>

**Topics**
+ [COST 9.如何管理需求和供应资源？](cost-09.md)

# COST 9.如何管理需求和供应资源？
<a name="cost-09"></a>

为了工作负载的性能与支出实现平衡，请确保您支付过费用的所有资源都得到利用，并避免出现资源利用率过低的情况。无论是从运营成本（由于过度使用导致性能下降）还是从浪费 AWS 支出（由于超额配置）的角度衡量，利用率指标过高或过低都会对您的组织产生负面影响。

**Topics**
+ [COST09-BP01 对工作负载需求执行分析](cost_manage_demand_resources_cost_analysis.md)
+ [COST09-BP02 实施缓冲区或节流来管理需求](cost_manage_demand_resources_buffer_throttle.md)
+ [COST09-BP03 动态供应资源](cost_manage_demand_resources_dynamic.md)

# COST09-BP01 对工作负载需求执行分析
<a name="cost_manage_demand_resources_cost_analysis"></a>

 分析工作负载需求随时间的变化。确认分析涵盖季节性趋势，并准确反映整个工作负载生命周期内的运行条件。分析工作应该体现出可能带来的好处，例如花费的时间与工作负载成本成正比。 

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

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

 分析云计算的工作负载需求涉及了解在云环境中启动的计算任务的模式和特征。这种分析有助于用户优化资源分配、管理成本并验证性能是否达到要求的水平。 

 了解工作负载的要求。组织需求应指出工作负载对于请求的响应时间。响应时间可用于确定需求是否得到了管理，或者是否应改变资源供应以满足需求。 

 分析应包括需求的可预测性和可重复性、需求的变化速率以及需求的变化量。对足够长的时间执行分析，以纳入任何季节性变化，例如月末处理或假期高峰。 

 分析工作应反映实施扩展的潜在好处。查看组件的预期总成本，以及在工作负载生命周期内使用量和成本的任何增加和减少。 

 以下是执行云计算的工作负载需求分析时，需要考虑的一些关键方面： 

1.  **资源利用率和性能指标**：分析一段时间内 AWS 资源的使用情况。确定高峰和非高峰期使用模式，以优化资源分配和扩展策略。监控性能指标，如响应时间、延迟、吞吐量和错误率。这些指标有助于评测云基础设施的整体运行状况和效率。 

1.  **用户和应用程序扩展行为**：了解用户行为及其对工作负载需求的影响。检查用户流量模式有助于增强内容的交付和应用程序的响应能力。分析工作负载如何随着需求的增长而扩展。确定弹性伸缩参数的配置是否正确有效，以处理负载波动。 

1.  **工作负载类型**识别云中运行的不同类型的工作负载，如批处理、实时数据处理、Web 应用程序、数据库或机器学习。每种类型的工作负载都可能有不同的资源需求和性能特征。 

1.  **服务水平协议（SLA）**：将实际绩效与 SLA 进行比较，以确保合规性并确定需要改进的领域。 

 您可以使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 来收集和跟踪指标，监控日志文件，设置警报，并自动应对 AWS 资源变化。您还可以使用 Amazon CloudWatch 了解系统范围内的资源使用率、应用程序性能和运行状况。 

 利用 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)，您可以按照最佳实践预置资源，以提高系统性能和可靠性，增强安全性，并寻找节省资金的机会。您也可以关闭非生产实例，并使用 Amazon CloudWatch 和 Auto Scaling 来匹配需求的增加或减少。 

 最后，您可以将 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或 [Quick](https://aws.amazon.com/quicksight/) 与 AWS 成本和使用情况报告（CUR）文件或应用程序日志一起使用，对工作负载需求执行高级分析。 

 总之，通过全面的工作负载需求分析，组织可以就资源预置、扩展和优化做出明智的决策，从而提高性能、成本效益和用户满意度。 

### 实施步骤
<a name="implementation-steps"></a>
+  **分析现有工作负载数据：** 分析现有工作负载中的数据、以前工作负载版本中的数据或预测使用模式中的数据。使用 Amazon CloudWatch、日志文件和监控数据来深入了解工作负载的使用情况。分析整个工作负载周期，并收集任何季节性变化数据，如月末或年末活动。分析中反映的工作应该体现出工作负载特征。应将最多的精力放在需求变化最大的高价值工作负载上。应将最少的精力放在需求变化最小的低价值工作负载上。 
+  **预测外部影响：** 与组织中会影响或更改工作负载需求需求的团队成员会面。通常涉及的团队包括销售、营销或业务拓展团队。与他们合作，了解其运作周期，以及是否有改变工作负载需求的任何活动。使用这些数据预测工作负载需求。 

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

 **相关文档：** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 
+  [AWS X-Ray](https://aws.amazon.com/xray/) 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [开始使用 Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 
+  [Quick](https://aws.amazon.com/quicksight/) 

 **相关视频：** 

 **相关示例：** 
+  [监控、跟踪和分析以实现成本优化](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/) 
+  [Searching and analyzing logs in CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html) 

# COST09-BP02 实施缓冲区或节流来管理需求
<a name="cost_manage_demand_resources_buffer_throttle"></a>

 缓冲区和节流可修改工作负载需求，从而避免出现任何峰值情形。在客户端执行重试时实施节流。实施缓冲以存储请求并将处理任务往后推迟一段时间。确认设计节流和缓冲区时客户端能够在所需的时间内收到响应。 

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

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

 在云计算领域，实施缓冲区或节流对于管理需求和减少工作负载所需的预置容量至关重要。为了获得最佳性能，必须衡量总需求，包括峰值、请求变化的速度和必需的响应时间。当客户端能够重新发送请求时，应用节流比较切实可行。相反，对于缺乏重试功能的客户端，理想的方法是实施缓冲区解决方案。此类缓冲区可舒缓请求的涌入，并优化具有不同操作速度的应用程序之间的交互。 

![\[Demand curve with two distinct peaks that require high provisioned capacity\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)


 假设工作负载的需求曲线如上图所示。此工作负载有两个峰值，为了处理这些峰值，如橙色线所示预置资源容量。因为需要预置容量来处理这两个峰值，所以此工作负载所使用的资源和能源不是由需求曲线下的区域表示，而是由预置容量线下面的区域表示。展平工作负载需求曲线有助于降低工作负载的预置容量和减少对环境的影响。为了平滑峰值，可以考虑实施节流或缓冲解决方案。 

 为了更好地理解它们，让我们探讨一下节流和缓冲。 

 **节流：**如果需求源具有重试功能，可以实施节流。节流会告诉需求源，如果当前无法处理请求，则应稍后再试。源将等待一段时间，然后重试请求。实施节流的优势是可限制最大资源量和工作负载成本。在 AWS 中，您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 来实施节流。 

 **基于缓冲区：**基于缓冲区的方法使用*产生器*（向队列发送消息的组件）、*使用器*（从队列接收消息的组件）和*队列*（保存消息）来存储消息。然后消息将由使用器读取并处理，这样消息就能够以满足使用器业务需求的速率运行。通过使用以缓冲区为中心的方法，产生器发出的消息被存储在队列或流中，随时可供使用器以符合其运营需求的速度进行访问。 

在 AWS 中，您可以从多个服务中进行选择来实施缓冲方法。[Amazon Simple Queue Service（Amazon SQS）](https://aws.amazon.com/sqs/)是一项托管服务，它提供队列，允许单个使用器读取单个消息。[Amazon Kinesis](https://aws.amazon.com/kinesis/) 提供了一个允许许多使用器读取相同消息的流。

 缓冲和节流可以通过修改工作负载需求来平滑任何峰值。在客户端重试操作时使用节流，并使用缓冲来保存请求以供以后处理。使用基于缓冲区的方法时，请构造工作负载以在所需时间内处理请求，并验证您是否能够处理重复的工作请求。分析总体需求、变化率和所需的响应时间，以使所需节流或缓冲的大小适宜。 

### 实施步骤
<a name="implementation-steps"></a>
+ **分析客户端需求：**分析客户端请求以确定它们是否能够重试。对于无法执行重试的客户端，需要实施缓冲区。分析总体需求、变化率和所需的响应时间，以确定所需的节流或缓冲区大小。
+ **实施缓冲区或节流：**在工作负载中实施缓冲区或节流。Amazon Simple Queue Service（Amazon SQS）之类的队列可以为工作负载组件提供缓冲区。Amazon API Gateway 可以为工作负载组件提供节流。

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

 **相关最佳实践：** 
+ [SUS02-BP06 实施缓冲区和节流以展平需求曲线](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [REL05-BP02 限制请求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)

 **相关文档：** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS 实例调度器](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 
+  [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) 
+  [开始使用 Amazon SQS](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Amazon Kinesis](https://aws.amazon.com/kinesis/) 

 **相关视频：** 
+ [为分布式应用程序选择适合的消息传递服务](https://www.youtube.com/watch?v=4-JmX6MIDDI)

 **相关示例：** 
+ [管理和监控工作负载中的 API 节流](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [使用 API Gateway 大规模节流分层的多租户 REST API](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [使用 Amazon API Gateway 在多租户 Amazon EKS SaaS 解决方案中启用分层和节流](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [使用队列和消息的应用程序集成](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

# COST09-BP03 动态供应资源
<a name="cost_manage_demand_resources_dynamic"></a>

资源按计划预置。这种预置可以基于需求（例如通过自动扩缩来实现），也可以基于时间（需求可以预测，基于时间提供资源）。这些方法可以尽可能减少过度预置或预置不足的情况。

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

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

 AWS 客户可以通过多种方式增加可供应用程序使用的资源，并提供资源以满足需求。其中一个选项是使用 AWS Instance Scheduler，其可以自动启动和停止 Amazon Elastic Compute Cloud（Amazon EC2）以及 Amazon Relational Database Service（Amazon RDS）实例。另一个选项是使用 AWS Auto Scaling，该服务让您可以根据应用程序或服务的需求，自动扩展计算资源。根据需求提供资源，这样您就只需要为使用的资源付费，并且仅在有需要时启动资源，在不需要时终止资源，从而降低成本。 

 [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) 让您可以将 Amazon EC2 和 Amazon RDS 实例配置为在指定的时间停止和启动，这样您就可以通过一致的时间模式满足对相同资源的需求，例如用户在每天早上八点访问 Amazon EC2 实例，晚上六点后就不再需要访问。该解决方案可停止不使用的资源，并在需要时启动它们，来实现运营成本的降低。 

![\[显示使用 AWS Instance Scheduler 优化成本的图。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/instance-scheduler-diagram.png)


 

您还可以通过简单的用户界面（UI）使用 AWS Systems Manager 快速设置，轻松地跨账户和区域来为您的 Amazon EC2 实例配置计划。您可以使用 AWS Instance Scheduler 来调度 Amazon EC2 或 Amazon RDS 实例，也可以停止和启动现有实例。然而，您不能停止和启动属于Auto Scaling组（ASG）或管理 Amazon Redshift 或 Amazon OpenSearch Service 等服务的实例。Auto Scaling组对组内创建的实例有自己的计划。

[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 有助于您调整容量以维持稳定、可预测的性能，并确保成本最低，来满足不断变化的需求。这是一项用来扩展应用程序容量的完全托管式免费服务，与 Amazon EC2 实例和竞价型实例集、Amazon ECS、Amazon DynamoDB 和 Amazon Aurora 集成。Auto Scaling提供自动资源发现功能，以便您在工作负载中找到可以配置的资源，其具有内置的扩展策略来优化性能、成本或者在两者之间取得平衡，并提供预测性扩展来协助应对定期出现的峰值。

 您可以通过多种扩展选项来扩展Auto Scaling组： 
+  始终保持当前的实例水平 
+  手动扩展 
+  根据计划扩展 
+  根据需求扩展 
+  使用预测性扩缩 

 Auto Scaling策略各不相同，可以分为动态扩缩策略和计划扩缩策略。动态策略为手动扩缩或动态扩缩，这可以是计划扩缩或者预测性扩缩。您可以针对动态、计划和预测性扩缩使用扩缩策略。您还可以使用来自 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 的指标和警报触发工作负载的扩缩事件。我们建议您使用 [启动模板](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)，这可让您访问最新的功能和改进。使用启动配置时，并非所有Auto Scaling功能均可用。例如，您不能创建一个Auto Scaling组，然后在其中同时启动竞价型实例和按需型实例，也不能指定多种实例类型。这些功能必须使用启动模板来配置。使用启动模板时，建议您对每个模板进行版本控制。通过启动模板的版本控制，您可以创建完整参数集的子集。然后，您可以重复使用参数子集来创建相同启动模板的其他版本。 

 您可以使用 AWS Auto Scaling，也可以通过 [AWS API 或 SDK](https://aws.amazon.com/developer/tools/)在代码中纳入扩缩功能。这样省去了手动更改环境的操作成本，因而工作负载的总体成本得以降低，而且可以更快地执行更改。这还使您的工作负载资源配置随时与您的需求相匹配。为了遵循这一最佳实践，并为您的组织动态供应资源，您应该了解 AWS 云 中的横向和纵向扩展，以及 Amazon EC2 实例上运行的应用程序的性质。您的云财务管理团队最好与技术团队合作，以遵循这一最佳实践。 

 [Elastic Load Balancing（Elastic Load Balancing）](https://aws.amazon.com/elasticloadbalancing/) 通过在多种资源之间分配需求来助力您扩展规模。通过使用 ASG 和Elastic Load Balancing，您可以按照最优方式路由流量来管理传入的请求，这样就可以避免Auto Scaling组中某个实例负载过高的情况。请求将以轮询方式，在目标组的所有目标上分配，而不考虑容量或利用率。 

 典型的指标可以是标准 Amazon EC2 指标，例如 CPU 利用率、网络吞吐量以及 Elastic Load Balancing 观察到的请求和响应延迟。如果可能，应该使用指示客户体验的指标，通常是来自工作负载中的应用程序代码的自定义指标。在本文档中，为了详细说明如何动态满足需求，我们将Auto Scaling划分为两类：基于需求的供应模型和基于时间的供应模型，并分别深入探讨这两种模型。 

**基于需求的供应：** 利用云的弹性来提供资源，根据近实时的需求状态来满足不断变化的需求。对于基于需求的供应，请使用 API 或服务功能，以编程方式改变架构中云资源的数量。这使您能够在架构中扩展组件，并在需求高峰期间增加资源数量以保持性能，也可以在需求量降低时减少容量以降低成本。

![\[图中描述了基于需求的扩缩策略，例如简单/分步扩展和目标跟踪。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/demand-based-supply.png)


 
+  **简单/分步扩展：** 监控指标，按照客户定义的步骤手动添加/删除实例。 
+  **目标跟踪：** 类似恒温器的控制机制，可自动添加或删除实例，以维护客户定义的目标指标。 

当构建基于需求的方法时，请注意两个重要事项。首先，了解您必须以多快的速度预置新资源。其次，了解供应和需求之间的差额将发生变化。您必须准备好应对需求变化的速度，并准备好应对资源故障。

**基于时间的供应：** 基于时间的方法可以协调资源容量以满足可预测或时间明确定义的需求。此方法通常不依赖资源的利用水平。基于时间的方法可以确保资源在需要的特定时间可用，并且提供时不会因启动流程和系统或一致性检查而发生延迟。使用基于时间的方法，您可以在繁忙时段提供额外的资源或增加容量。

![\[图中描述了基于时间的扩缩策略，例如计划扩缩和预测性扩缩。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2023-10-03/framework/images/time-based-supply.png)


 

您可以使用计划性或预测性自动扩缩，实施基于时间的方法。工作负载可以在定义的时间按计划扩展或缩减（例如办公时间开始时），从而确保用户就位或需求增加时资源可用。预测性扩缩使用模式进行横向扩展，而计划扩展在预先定义的时间进行横向扩展。您也可以将 [基于属性的实例类型选择（ABS）策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 用于Auto Scaling组，该策略允许您将实例要求表示为一组属性，例如 vCPU、内存和存储。这还允许您在新一代实例类型发布时自动使用它们，并通过 Amazon EC2 竞价型实例访问更广泛的容量。Amazon EC2 实例集和 Amazon EC2 Auto Scaling 会选择并启动符合指定属性的实例，无需手动选择实例类型。 

您还可以利用 [AWS API 与 SDK](https://aws.amazon.com/developer/tools/) 和 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 在需要时自动预置和停用整个环境。此方法非常适合仅在定义的办公时间或时间段运行的开发或测试环境。您可以使用 API 来扩展环境中的资源大小（纵向扩展）。例如，可以通过更改实例大小或分类纵向扩展生产工作负载。这可以通过停止和启动实例，以及选择不同的实例大小或分类来实现。这种技巧也可以应用于其他资源，如 Amazon EBS 弹性卷，您可以在使用时对其进行修改以增加大小、调整性能（IOPS）或更改卷类型。

当采用基于时间的方法进行架构设计时，请注意两个重要事项。首先，使用模式的一致性如何？ 其次，如果模式发生更改会产生什么影响？ 您可以通过两种方式提高预测的准确性：监控工作负载和使用商业智能。如果您发现使用模式发生重大更改，可以调整时间，以确保提供覆盖范围。

## 实施步骤
<a name="implementation-steps"></a>
+ ** 配置计划扩缩： **对于可预测的需求变化，基于时间的扩缩可以及时提供正确的资源量。如果资源创建和配置的速度不够快，无法响应需求变化，也可使用这种方法。根据工作负载分析，使用 AWS Auto Scaling 配置计划扩缩。要配置基于时间的计划，您可以使用预测性扩缩而不是计划扩缩，根据预期或可预测的负载变化，提前增加Auto Scaling组中的 Amazon EC2 实例数量。
+  **配置预测性扩缩：** 通过预测性扩缩，您可以根据流量的每日和每周模式，提前增加Auto Scaling组中的 Amazon EC2 实例数量。如果您有定期的流量高峰和需要很长时间才能启动的应用程序，则应该考虑使用预测性扩缩。与本质上属于被动应对的单纯动态扩缩相比，预测性扩缩可帮助您在预测的负载到来之前初始化容量，从而更快地扩展。例如，如果用户在开始上班时开始使用工作负载，而在下班后不再使用，那么预测性扩缩可以在上班之前增加容量，这就消除了动态扩缩对流量变化作出反应的延迟。 
+ ** 配置动态自动扩缩： **要根据活动的工作负载指标配置扩缩，请使用Auto Scaling。使用分析并配置Auto Scaling以在正确的资源级别上启动，并确认工作负载在所需的时间内扩展。您可以在单个Auto Scaling组中启动并自动扩展按需型实例和竞价型实例的实例集。除了获得使用竞价型实例的折扣外，您还可以使用预留实例或实惠配套来享受常规按需型实例定价的折扣率。将所有这些因素相结合，有助于您优化 Amazon EC2 实例的成本节约，并帮助您获得应用程序所需的规模和性能。

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

 **相关文档：** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  扩缩Auto Scaling组的大小 
+  [开始使用 Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [开始使用 Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) 
+  [Amazon EC2 Auto Scaling 的计划扩缩](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+ [ Amazon EC2 Auto Scaling 的预测性扩缩 ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)

 **相关视频：** 
+ [ Auto Scaling的目标跟踪扩缩策略 ](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS Instance Scheduler ](https://www.youtube.com/watch?v=nTLEyo2NzUs)

 **相关示例：** 
+ [ 基于属性为 Amazon EC2 实例集的Auto Scaling选择实例类型 ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ 使用计划扩缩优化 Amazon Elastic Container Service 成本 ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [ Amazon EC2 Auto Scaling 预测性扩缩 ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [ 如何通过将 Instance Scheduler 和 CloudFormation 结合使用来调度 Amazon EC2 实例？ ](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)

# 持续优化
<a name="a-optimize-over-time"></a>

**Topics**
+ [COST 10.如何评估新服务?](cost-10.md)
+ [COST 11.如何评估工作量成本？](cost-11.md)

# COST 10.如何评估新服务?
<a name="cost-10"></a>

AWS 不断发布新服务和功能，因此您最好不断审视现有架构决策，以便确保其始终最具成本效益。

**Topics**
+ [COST10-BP01 制定工作负载审核流程](cost_evaluate_new_services_review_process.md)
+ [COST10-BP02 定期审核和分析此工作负载](cost_evaluate_new_services_review_workload.md)

# COST10-BP01 制定工作负载审核流程
<a name="cost_evaluate_new_services_review_process"></a>

 制定流程，定义工作负载的审核标准和流程。审核工作量应该体现可能带来的好处，例如，核心工作负载或费用占比超过 10% 的工作负载每季度或每六个月审核一次，而费用占比低于 10% 的工作负载每年审核一次。 

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

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

为了让工作负载始终最具成本效益，您必须定期对其进行审核，以了解是否有机会实施新的服务、功能和组件。为了降低整体成本，审核工作量必须与潜在的节省额成比例。例如，与占总支出 5% 的工作负载相比，应更经常、更彻底地审核占总支出 50% 的工作负载。考虑任何外部因素或波动。如果工作负载服务于特定的地理位置或市场领域，并且您已预测出该领域会出现的变化，则提高审核频率可能会节省成本。审核时要考虑的另一个因素是实施更改的工作量。如果测试和验证变更的成本很高，则审核的频率应该降低。

考虑维护过时和旧式组件及资源的长期成本，以及无法在其中实施新功能的事实。当前的测试和验证成本可能会超过预计的收益。但是，随着时间的推移，工作负载和当前技术之间的差距会增大，进行更改的成本可能会大幅增加，导致成本升高。例如，迁移到新的编程语言的成本当前可能不具成本效益。然而，五年之后，熟练使用该语言的人员的成本可能会增加，并且由于工作负载的扩展，迁移到新语言的系统规模更大，这其中涉及的工作量甚至高于以前。

将工作负载分解成多个组件，分配组件的成本（估算即可），然后在每个组件旁边列出因素（例如工作量和外部市场）。使用这些指示信息来确定每个工作负载的审核频率。例如，您可能觉得 Web 服务器的成本高、变更的工作量小、外部因素多，因而审核频率很高。而中央数据库的成本可能中等、变更的工作量很大、外部因素较少，因而审核频率也为中等。 

 制定相应流程，在新的服务、设计模式、资源类型和配置推出后，对它们进行评估，以优化您的工作负载成本。与[性能支柱审核](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-06.html)和[可靠性支柱审核](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_review_monitoring.html)过程类似，识别、验证和优先考虑优化和改进活动以及问题补救，并将其纳入您的待办事项列表。 

**实施步骤**
+  **定义审核频率：**定义工作负载及其组件的审核频率。分配时间和资源，以持续改进并保持审核频率，来优化工作负载并提高工作负载的效率。应考虑多种因素，且这些因素可能会因组织中的工作负载以及工作负载中的组件而异。常见的因素包括：从收入或品牌角度来讲对组织的重要性、运行工作负载的总成本（包括运营和资源成本）、工作负载的复杂性、实施变革的难易程度、任何软件许可协议以及变革是否会因惩罚性的许可而显著增加许可成本。可以在功能上或技术上定义组件，例如 Web 服务器和数据库，或者计算和存储资源。相应地权衡这些因素，并为工作负载及其组件制定一个周期。您可能决定每 18 个月审核一次完整的工作负载，每 6 个月审核一次 Web 服务器，每 12 个月审核一次数据库，每 6 个月审核一次计算资源和短期存储，每 12 个月审核一次长期存储。
+ **定义审核的彻底性：**定义在工作负载或工作负载组件的审核上投入的工作量。与审核频率类似，这也需要权衡多种因素。评估各种改进机会并确定其优先顺序，以便将精力集中在可以实现最大收益的工作上，同时估计这些活动所需的工作量。如果预期成果不符合目标，并且所需工作会花费更多成本，则寻求其他行动方案。审核流程中应该分配专用的时间和资源，以便实现持续增量改进。例如，您可能决定投入一周的时间对数据库组件进行分析，投入一周的时间对计算资源进行分析，投入四小时的时间进行存储审核。

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

 **相关文档：** 
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 
+  [云计算类型](https://aws.amazon.com/types-of-cloud-computing/) 
+  [AWS 新增功能](https://aws.amazon.com/new/) 

 **相关示例：** 
+ [AWS 支持主动式服务](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)
+ [定期审核 SAP 工作负载](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/best-practice-4-4.html)

# COST10-BP02 定期审核和分析此工作负载
<a name="cost_evaluate_new_services_review_workload"></a>

根据每个明确的流程定期审核现有工作负载，以便确定是采用新服务、替换现有服务还是重新构建工作负载。

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

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

AWS 在不断地增加新功能，以便您可以使用最新技术更快地进行实验和创新。[AWS 新增功能](https://aws.amazon.com/new/)详细介绍了 AWS 如何实现这一点，并在 AWS 服务、功能和区域扩展公告发布时进行简要概述。您可以深入了解已经宣布的产品发布，并使用它们来审核和分析您现有的工作负载。为了享受新 AWS 服务和功能带来的好处，请对工作负载进行审核，并根据需要实施新服务和功能。这意味着您可能需要替换用于工作负载的现有服务，或对工作负载进行现代化改造，以便采用这些新的 AWS 服务。例如，您可以审核工作负载，并使用 Amazon Simple Email Service 替换消息收发组件。这省去了运行和维护实例集的成本，同时能以更低的成本提供所有功能。

 为了分析您的工作负载并突显潜在机会，您不仅应考虑新服务，而且还要考虑构建解决方案的新方法。观看 AWS 上的[这是我的架构](https://aws.amazon.com/architecture/this-is-my-architecture)视频，了解其他客户的架构设计、面临的挑战及其解决方案。查看[全包系列](https://aws.amazon.com/architecture/all-in-series/)，了解 AWS 服务的现实世界应用和客户案例。您还可以观看[回归基础](https://aws.amazon.com/architecture/back-to-basics/)视频系列。该系列说明、检查和分解基本的云架构模式最佳实践。另一个资料源是[如何构建](https://aws.amazon.com/architecture/how-to-build-this/)视频。这些视频旨在帮助有好想法的人使用 AWS 服务将他们的最小可行产品（MVP）变为现实。来自世界各地有着坚定想法的构建者可以利用这种方式从经验丰富的 AWS 解决方案架构师那里获得架构指导。最后，您可以查看[使用入门](https://aws.amazon.com/getting-started/)资源材料，其中包含循序渐进的教程。 

 在执行审核流程之前，请遵照您的企业对工作负载的要求、安全性和数据隐私要求，以便在遵循商定的审核流程时，运用特定的服务或区域和性能要求。 

**实施步骤**
+ **定期审核工作负载：**使用明确的流程，按照指定的频率执行审核。确认在每个组件上投入适当的工作量。此流程类似于您选择服务进行成本优化的初始设计流程。分析服务及其带来的优势，这一次需考虑实施更改所产生的成本，而不仅仅是长期优势。
+ **实施新服务：**如果分析结果表明可以实施更改，请先执行工作负载基线，以了解每项产出的当前成本。实施更改，然后执行分析以确认每项产出的新成本。

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

 **相关文档：** 
+  [AWS 新闻博客](https://aws.amazon.com/blogs/aws/) 
+  [AWS 新增功能](https://aws.amazon.com/new/) 
+ [AWS 文档](https://docs.aws.amazon.com/)
+ [AWS 入门](https://aws.amazon.com/getting-started/)
+ [AWS 一般资源](https://docs.aws.amazon.com/#general_resources)

 **相关视频：** 
+  [AWS - 这是我的架构](https://aws.amazon.com/architecture/this-is-my-architecture) 
+  [AWS - 回归基础](https://aws.amazon.com/architecture/back-to-basics/) 
+  [AWS - 全包系列](https://aws.amazon.com/architecture/all-in-series/) 
+  [如何构建](https://aws.amazon.com/architecture/how-to-build-this/) 

# COST 11.如何评估工作量成本？
<a name="cost-11"></a>

**Topics**
+ [COST11-BP01 执行运营自动化](cost_evaluate_cost_effort_automations_operations.md)

# COST11-BP01 执行运营自动化
<a name="cost_evaluate_cost_effort_automations_operations"></a>

 评估云上运营工作量的成本。量化使用自动化之后管理任务、部署和其他运营工作减少的时间和工作量。评估运营工作所需的时间和成本，并自动执行管理任务，以尽可能减少人工工作量。 

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

 自动执行运营可解放人力资源和改善指标，从而提高一致性和可扩展性、实现更高的可见性、可靠性和灵活性、降低成本以及加快创新。还可以在部署、管理或运营工作负载时提供一致且可靠的体验，从而降低手动任务的频率、提高效率以及使企业受益。您可以将基础设施资源从手动操作任务中解放出来，并将它们用于更高价值的任务和创新，从而改善业务成果。企业需要行之有效、经过测试的方法来管理他们在云中的工作负载。该解决方案必须安全、快速和经济高效，风险最小且可靠性最高。 

 首先着眼于云中的总体运营成本，根据所需的工作量确定运营优先级。例如，在云中部署新资源、对现有资源进行优化更改或实施必要的配置需要多长时间？ 考虑运营和管理成本，看看人工行为的总成本。优先考虑管理任务的自动化，以减少人工工作量。审核工作应该体现可能带来的好处。例如，与自动执行任务相比，手动执行任务所花费的时间。优先考虑自动执行重复、高价值的活动。从那些人为错误风险更高的活动开始实现自动化通常会更好，因为风险通常会带来不必要的额外运营成本（例如，运营团队加班产生的成本）。 

 使用 AWS 服务、工具或第三方产品，您可以选择要实施哪些 AWS 自动化，并根据您的特定需求进行定制。下表显示了您为了自动执行管理和运营而可以通过 AWS 服务实现的一些核心运营职能和能力： 
+  [AWS Audit Manager](https://aws.amazon.com/audit-manager/)：持续审计您的 AWS 使用情况，以便简化风险和合规性评测 
+  [AWS Backup](https://aws.amazon.com/backup/)：集中管理和自动执行数据保护。 
+  [AWS Config](https://aws.amazon.com/config/)：配置计算资源、评测、审计和评估配置与资源清单。 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/)：使用基础设施即代码启动高可用性资源。 
+  [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)：IT 变更管理、合规性和控制。 
+  [Amazon EventBridge](https://aws.amazon.com/eventbridge/)：安排事件并触发 AWS Lambda 以采取行动。 
+  [AWS Lambda](https://aws.amazon.com/lambda/)：通过事件触发流程或使用 Amazon EventBridge 按固定时间表运行流程，使重复流程实现自动化。 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/)：启动和停止工作负载、修补操作系统、自动配置和持续管理。 
+  [AWS Step Functions](https://aws.amazon.com/step-functions/)：安排作业和自动执行工作流。 
+  [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)：具有合规性和控制的模板使用和基础设施即代码。 

 利用节省下来的时间，您的团队将能够专注于解决技术债务、创新和增值功能。例如，您可能需要尽快将本地环境直接迁移到云，然后再进行优化。值得探索的是，通过使用可消除或减少许可证成本的完全托管式 AWS 服务（例如，[Amazon Relational Database Service](https://aws.amazon.com/rds/)、[Amazon EMR](https://aws.amazon.com/emr/)、[Amazon WorkSpaces](https://aws.amazon.com/workspaces/) 和 [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)），您可以节省多少成本。托管服务消除了维护服务的运营和管理负担，让您可以专注于创新。此外，由于托管服务在云级别运行，因此可以提供更低的单位事务或服务成本。 

 如果您希望使用 AWS 产品和服务立即采用自动化，而您的组织中没有相应的技能，请联系 [AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)、[AWS Professional Services](https://aws.amazon.com/professional-services/) 或 [AWS 合作伙伴](https://aws.amazon.com/partners/work-with-partners/)，以便提高自动化的采用率，以及改进云中的卓越运营。 

 [AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)是代表企业客户和合作伙伴运营 AWS 基础设施的服务。该服务提供了一个安全且合规的环境，您可以将工作负载部署到其中。AMS 使用具有自动化功能的企业云运营模型，可以满足组织要求，更快地迁移到云中并降低持续管理的成本。 

 [AWS Professional Services](https://aws.amazon.com/professional-services/) 还可以帮助您实现期望的业务成果并通过 AWS 实现运营自动化。AWS Professional Services 提供全球专业实践服务，以支持您在企业云计算重点领域的工作。这些专业实践服务通过解决方案、技术和行业主题领域的最佳实践、框架、工具和服务提供有针对性的指导。它们帮助客户部署自动、稳健、敏捷的 IT 运营，还提供针对云中心进行优化的治理能力。 

 **实施步骤** 
+  **一次构建，多次部署：**使用基础设施即代码 [例如 AWS CloudFormation、AWS SDK 或 AWS Command Line Interface（AWS CLI）]，对于同一环境或灾难恢复场景，只部署一次，多次使用。在部署时进行标记，以便按照其他最佳实践中的规定跟踪您的使用情况。使用 [AWS Launch Wizard](https://aws.amazon.com/launchwizard/) 以缩短部署许多常用企业工作负载的时间。AWS Launch Wizard 会指导您按照 AWS 最佳实践完成企业工作负载的大小调整、配置和部署。您还可以使用 [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) 帮助创建和管理经批准的基础设施即代码模板，在 AWS 上使用，以便任何人都可以发现经批准的自助式云资源。 
+  **自动操作：**自动运行日常操作，无需人工干预。使用 AWS 服务和工具，您可以选择要实施哪些 AWS 自动化，并根据您的特定需求进行定制。例如，使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/) 来构建、测试和部署虚拟机和容器映像，以在 AWS 或在本地使用。如果无法使用 AWS 服务完成您的期望操作或您需要使用筛选资源的更复杂操作，则使用 [AWS CLI](https://aws.amazon.com/cli/index.html) 或 AWS SDK 工具自动执行操作。AWS CLI 可以通过脚本自动完成控制和管理 AWS 服务的整个过程，而无需使用 AWS 控制台。选择您首选的 AWS SDK 与 AWS 服务交互。有关其他代码示例，请参阅 [AWS SDK 代码示例库](https://github.com/awsdocs/aws-doc-sdk-examples)。 

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

 **相关文档：** 
+ [在 AWS 云 中实现运营现代化](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/welcome.html)
+ [AWS 服务自动化](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/aws-services-for-automation.html)
+ [AWS Systems Manager 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [SAP 管理和运营的 AWS 自动化](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [AWS Managed Services](https://aws.amazon.com/managedservices/index.html)
+ [AWS Professional Services](https://aws.amazon.com/professional-services/)
+ [基础设施和自动化](https://aws.amazon.com/blogs/infrastructure-and-automation/)

 **相关示例：** 
+ [重塑自动化运营（第 I 部分）](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-i/)
+ [重塑自动化运营（第 II 部分）](https://aws.amazon.com/blogs/mt/reinventing-automated-operations-part-ii/)
+ [SAP 管理和运营的 AWS 自动化](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-automation/automations.html)
+ [使用 AWS Lambda 实现 IT 自动化](https://aws.amazon.com/lambda/it-automation/)
+ [AWS 代码示例库](https://github.com/awsdocs/aws-doc-sdk-examples)
+ [AWS 示例](https://github.com/aws-samples)