

# 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-BP04 考虑使用共享资源
](cost_type_size_number_resources_shared.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) 

 **相关视频：**
+ [Selecting the right Amazon EC2 instance for your workloads](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [Right size your service](https://youtu.be/wcp1inFS78A)

 **相关示例：**
+ [It just got easier to discover and compare Amazon EC2 instance types](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、SDK](https://aws.amazon.com/developer/tools/) 以及各类功能，让您可以毫不费力地修改资源。您可以对工作负载进行编程以停止和启动 Amazon EC2 实例，从而允许更改实例大小或实例类型。这带来双重好处：既合理调整了大小，又几乎消除了进行更改所需的全部运营成本。

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

**实施步骤**
+ **通过配置工作负载指标来提高可观测性：**捕获工作负载的关键指标。这些指标指明了客户体验（例如工作负载输出），并适应资源类型和规模之间的差异（例如 CPU 和内存使用情况）。对于计算资源，请分析性能数据以合理调整 Amazon EC2 实例大小。确定空闲实例和未充分利用的实例。要查找的关键指标是 CPU 利用率和内存利用率（例如，在 90% 的时间内为 40% 的 CPU 利用率，如 [Rightsizing with AWS Compute Optimizer and Memory Utilization Enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 中所述）。确定四周内最大 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 如何合理调整资源大小以调整工作负载。无论是 Amazon EC2 实例、AWS 存储类还是 Amazon RDS 实例类型，都必须使用[正确的工具](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 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 Plan 获得常规按需实例定价的折扣费率。将所有这些因素相结合，可帮助您优化 Amazon EC2 实例的成本节约，并确定应用程序所需的规模和性能。还可以在[自动扩缩组（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 Fleet 和 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 Getting Set Up](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingSetup.html) 
+  [CloudWatch Publishing Custom Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Getting Started with 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 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) 
+  [Amazon EFS 不频繁访问](https://aws.amazon.com/efs/features/infrequent-access/) 
+  [Launch an Amazon EC2 Instance Using the SDK](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html) 

 **相关视频：**
+  [Right Size Your Services](https://www.youtube.com/watch?v=wcp1inFS78A) 

 **相关示例：**
+  [基于属性选择实例类型用于 Amazon EC2 Fleet 的自动扩缩](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/) 
+  [Optimizing Amazon Elastic Container Service for cost using scheduled scaling](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/) 
+  [Predictive scaling with 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/) 

# COST06-BP04 考虑使用共享资源
<a name="cost_type_size_number_resources_shared"></a>

 对于已经在组织级别为多个业务部门部署的服务，可以考虑使用共享资源来提高利用率，并降低总拥有成本（TCO）。使用共享资源是一种经济实惠的选择，可以通过使用现有解决方案和/或共享组件，实现集中管理和成本优化。在账户边界内或专用账户中管理监控、备份和连接等常见功能。还可以通过实施标准化、减少重复和降低复杂性来降低成本。

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

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

 如果多个工作负载产生相同的功能，则使用现有解决方案和共享组件，改善管理和优化成本。考虑使用现有资源（尤其是共享资源），例如非生产数据库服务器或目录服务，通过遵循安全最佳实践和组织法规来降低云成本。为了更好地实现价值和提高效率，将成本分配（使用对账和扣款）给产生使用情况的相关业务领域至关重要。

 *对账*是指将云成本分为可归属类别的报告，例如消费者、业务部门、总分类账账户或其他责任实体。对账的目标是向团队、业务部门或个人展示其使用的云资源的成本。

 *扣款*是指根据适合特定财务管理流程的策略，将中央服务支出分配给成本单位。对于客户而言，扣款会将一个共享服务账户产生的成本，分别计入适用于客户报告流程的不同财务成本类别。通过建立扣款机制，您可以报告不同业务部门、产品和团队产生的成本。

 工作负载可以分类为关键和非关键工作负载。根据此分类，使用常规配置的共享资源来处理不太关键的工作负载。为了进一步优化成本，请仅为关键工作负载预留专用服务器。跨多个账户共享或预置资源，对资源进行高效管理。即使在不同的开发、测试和生产环境中，安全共享也是可行的，不会破坏组织结构。

 为了加强您的了解，并优化容器化应用程序的成本和使用情况，请使用拆分成本分配数据，采用这种做法，有助于您根据应用程序对共享计算和内存资源的使用情况，将成本分配给各个业务实体。拆分成本分配数据可帮助您在容器工作负载中实现任务级对账和扣款，这些工作负载在 Amazon Elastic Container Service（Amazon ECS）或 Amazon Elastic Kubernetes Service（Amazon EKS）上运行。

 对于分布式架构，请构建共享服务 VPC，集中访问每个 VPC 中的工作负载所需的共享服务。这些共享服务可以包括目录服务或 VPC 端点等资源。为了减少管理开销和成本，请从中心位置共享资源，而不是在每个 VPC 中构建资源。

 使用共享资源时，可以节省运营成本、大幅提高资源利用率并提高一致性。在多账户设计中，可以集中托管一些 AWS 服务，并在中心使用多个应用程序和账户访问这些服务，此举有助于节省成本。可以使用 [AWS Resource Access Manager（AWS RAM）](https://aws.amazon.com/ram/)共享其它公用资源，如 [VPC subnets and AWS Transit Gateway attachments](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) 或 [Amazon SageMaker AI pipelines](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)。在多账户环境中，使用 AWS RAM 一次性创建资源并与其他账户共享。

 组织应有效地标记共享成本，并确认其没有大量成本未标记或未分配。如果您未有效地分配共享成本，也没有人对共享成本管理负责，则共享云成本可能会急剧增加。您应当知道自己在资源、工作负载、团队或组织层面产生了哪些成本，因为这些信息有助于您进一步了解相较于实现的业务成果，在适当层面所实现的价值。最终，通过共享云基础设施，组织将实现成本节省。建议对共享云资源进行成本分配，以优化云支出。

### 实施步骤
<a name="implementation-steps"></a>
+  **评估现有资源：**审核对您的工作负载使用类似服务的现有工作负载。根据工作负载的组件，如果业务逻辑或技术要求允许，考虑现有平台。
+  **在 AWS RAM 中使用资源共享并进行相应的限制：**使用 AWS RAM 与组织内的其他 AWS 账户共享资源。共享资源时，无需在多个账户中重复构建资源，这样可以大幅减少资源维护的运营负担。此过程还有助于您与账户中的角色和用户，以及与其他 AWS 账户 安全地共享已创建的资源。
+  **标记资源：**标记比较适合成本报告的资源，并将其在成本类别中归类。激活这些与成本相关的资源标签来进行成本分配，以实现 AWS 资源使用情况的可见性。专注于在成本和使用情况可见性方面创建适当的粒度级别，并通过成本分配报告和 KPI 跟踪来影响云使用行为。

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

 **相关最佳实践：**
+ [SEC03-BP08 在组织内安全地共享资源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)

 **相关文档：**
+ [什么是 AWS Resource Access Manager？](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)
+ [AWS services that you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [Shareable AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html)
+ [AWS Cost and Usage (CUR) Queries](https://catalog.workshops.aws/cur-query-library/en-US)

 **相关视频：**
+ [AWS Resource Access Manager - granular access control with managed permissions ](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [How to design your AWS cost allocation strategy](https://pages.awscloud.com/aws-cfm-talks-how-to-design-your-AWS-cost-allocation-strategy-01122022.html)
+ [AWS Cost Categories](https://www.youtube.com/watch?v=84GYnBBM0Cg)

 **相关示例：**
+ [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/)
+ [How to build a chargeback/showback model for Savings Plans using the CUR](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-build-a-chargeback-showback-model-for-savings-plans-using-the-cur/)
+ [Using VPC Sharing for a Cost-Effective Multi-Account Microservice Architecture](https://aws.amazon.com/blogs/architecture/using-vpc-sharing-for-a-cost-effective-multi-account-microservice-architecture/)
+ [Improve cost visibility of Amazon EKS with AWS Split Cost Allocation Data](https://aws.amazon.com/blogs/aws-cloud-financial-management/improve-cost-visibility-of-amazon-eks-with-aws-split-cost-allocation-data/)
+ [利用 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/)