AWS 成本管理与优化之六：计算篇

案例分析

客户背景

有一个出海客户 A，在迁移上云之后将其全部的工作负载运行在 AWS 之上。除了使用大量的计算资源（EC2）之外，该客户还使用了多种 AWS 托管服务（MSK, RDS, EMR, Elasticache, S3 以及 OpenSearch 等）。本文提到的具体用量和成本数字均经过脱敏处理。

客户需求

在业务平稳运行三个月之后，该客户的 TAM 对其云上用量和成本分析之后，发现在成本上有比较大的优化空间，于是主动联系客户，提出对其成本进行优化的建议。与此同时，客户也意识到了成本管理和优化的重要性，为了更高效经济的使用 AWS 云资源，客户在进行成本管理和优化的同时也提出了一些要求：

• 成本优化的同时保持云环境的稳定（客户刚刚迁移完毕并处在业务拓展的关键期，稳定是第一要务）。
• 成本优化方案应尽可能保持灵活性，避免因为云上服务的使用变化或者业务变化带来不确定影响。
• 成本优化方案应简易，可执行，并尽可能减少带来的运维负担。

成本分析

在初步分析了客户的账单之后，发现客户的总成本大概是每个月 290 万美元，其中 EC2 实例服务的成本占据了总成本的 50%， 达到了 140 多万美元。在本章节，我们也会聚焦客户使用的这部分计算资源，提出可行性方案和建议，有针对性的进行成本优化。

Right sizing：为工作负载选择最合适的资源类型和大小

在开始陈述具体的优化方案之前，我们先来探讨一下在成本优化过程中至关重要的一个概念 Right sizing，中文意思就是为工作负载选择最合适的资源类型和大小。

如何理解 Right sizing ?

基于 TAM 对大量上云客户的实践经验，客户在上云初期经常会有过度预置计算资源的问题。客户对于速度和性能的需求往往会优先于成本，导致了资源配置过高进而造成资源浪费和不必要的成本支出。比如创建了过高配置的机型，而实际的资源利用率却很低，这种情况下会造成不必要的资源浪费和成本支出。Right sizing 的关键是准确的理解云上资源的使用需求和模式，并知道如何利用云的弹性特征来满足这些需求。为客户量体裁衣，合理调整资源的大小（Right sizing）是所有成本优化措施中首先应该被设计并执行的。

Right sizing 是一个以尽可能低的成本将实例类型和大小与客户的工作负载性能和容量要求相匹配的过程。它同时也是一个重新审视已部署资源并在不影响容量或其他要求的情况下降低配置的过程。TAM 需要去帮助客户了解云上资源的真正性能和容量需求，进而调整资源的大小以最大限度的提高成本效益。其核心观点包括：

• 选择最便宜的实例，同时满足业务和性能需求
• 查看 CPU、RAM、存储和网络使用情况，找出可缩减的实例
• 清楚未充分利用或完全没有使用的资源
• 调度资源在适当的时候启动和停止

要实现成本优化，需将 Right sizing 看做一个持续的过程，不仅仅在上云初期，在上云以后业务持续运行的整个过程中，Right sizing 也是实现成本优化的重要手段。因为即使在最初合理调整了工作负载的大小，性能和容量要求依旧会随时间改变，这可能会产生未被充分利用或闲置的资源。更不用说，还会有新的项目和工作负载不断的被放在云上，如果没有一个完善的 Right sizing 流程和规范，同样也会造成资源浪费和成本升高。AWS 最佳实践 Right sizing 至少每个月都需要执行一次：

• 每个部门都应该设置一个定期 Right sizing 的计划并将结果报告给管理部门
• 借助 AWS 提供的成本和报告工具，密切的监控成本的变化
• 强制使用成本标签（Cost Tag）去细粒度的管理各个部门的成本消耗，快速定位每个资源的所有者、类型和环境（开发/测试/生产）等
• 理解如何进行 Right sizing

Right sizing 的基本原则

通过监控性能指标进行 Right sizing

通过分析性能数据来对 EC2 实例进行 Right sizing，从而识别出空闲和未被充分利用的实例。关键性能指标是 CPU 利用率和内存利用率。比如：在过去四周的时间里，CPU 和内存利用率低于 40% 的实例就是潜在的可以进行 Right sizing 的对象。

当合理调整实例大小的时候，我们既可以在同一实例系列里选择不同的大小，也可以在不同的实例系列之间进行切换。对于前面的 CPU 和内存利用率低于 40% 的例子，如果选择同一实例系列进行 Right sizing，那我们就可以选择比当前实例小一半的实例来运行负载。比如将一台 c5.8xlarge EC2 换成 c5.4xlarge EC2。如果选择不同的实例系列进行 Right sizing，就需要确保新的实例系列和当前实例系列在虚拟类型、网络和平台上是兼容的。

基于使用需求进行 Right sizing

除了参考性能指标，在进行 Right sizing 的时候也要结合具体的使用需求和模式：

• 稳定状态 – 工作负债已经稳定运行了很长时间，并且对于未来的资源需求也可以进行很准确的预测。这种模式建议购买 Savings Plans 或者 Reserved Instances 来节省成本。
• 不断变化，但是可预测 – Amazon Auto Scaling 非常适合具有稳定需求并且使用量每小时、每天或每周都会有变化的工作负载。当遇到流量高峰或可预测的流量大幅波动时，Auto Scaling 可以自动进行扩缩容来增加或者减少资源使用量。
• 开发/测试/生产环境 – 不同的业务环境对于资源的使用模式也是不同的，对于开发/测试环境来说，对于资源的使用一般都集中在工作日的白天，而在晚上、周末和节假日这些资源都是可以被关掉以节省成本的（使用 Amazon Tag 可以识别出开发/测试/生产环境的资源，使用 Amazon Instance Scheduler 可以制定自动的开关机计划）。
• 临时需求 – 对于一些临时的工作负载，没有特殊的启动时间要求，也可以随时被中断的，可以考虑使用 EC2 Spot 实例节省成本。

通过关闭空闲资源进行 Right sizing

最简单有效的降低成本的方法就是关闭不再使用的资源。如果发现某些资源在在超过 2 周的时间里都是空闲状态，那就应该考虑关闭这些资源。在关闭之前应该确认以下几个问题：

• 谁拥有这些资源？
• 关闭这些资源会造成哪些潜在的影响？
• 如果需要，在删除之后是否可以很容易的重建这些资源？

另外一个简单的节省成本的方法就是利用上文提到的 Amazon Instance Scheduler 对一些不需要长期运行的资源配置定时的开关机计划，这种方式也可以大幅度的降低成本。

成本优化方案

TAM 基于客户的需求和成本优化的最佳实践，并结合大量客户实践经验的总结，给出了分阶段的优化方案。在实际操作过程中，每种成本方法背后都有多个方案可选，TAM 会根据不同客户的具体需求，为客户量身定做，选择最适合的方案。

第一阶段：量体裁衣，合理调整资源类型和大小

AWS 提供最具广度和深度的服务器类型选择，来全方位满足客户对服务性价比的追求。截止到 2022 年，AWS 提供了超过 500 种计算实例类型，几乎满足所有的工作负载和业务需求。在上云初期，解决方案架构师会结合您的具体业务，推荐不同类型的计算实例。这些计算类型包括：通用型、计算密集型、内存密集型、存储优化型、GPU 计算型、量子计算型、训练/推理加速型等等。在客户确定其使用的主要机型以后，为了保证平稳迁移，一般会选择创建比实际需求偏大的计算资源类型。造成这种选择的原因是因为在迁移阶段，系统的稳定性是第一位的，而成本在这个阶段则是其次的。

在迁移完成，系统平稳运行一段时间以后，成本逐渐会是一个比较重要的话题。针对我们这个案例的客户，为了系统的完成成本优化，我们需要做的第一件事就是为其量体裁衣，合理调整资源类型和大小。AWS 和第三方合作伙伴都分别提供了丰富的工具来帮组客户去合理调整资源类型和大小，在本章节主要介绍如下三个工具：

• 大小优化建议
• Amazon Compute Optimizer
• Trusted Advisor

大小优化建议

大小优化建议并不是一个独立的服务，而是被集成在 AWS 成本管理控制台的一个免费工具。该工具可以分析客户 EC2 的历史使用情况，识别出空闲和未充分利用的实例，以确定节省成本和提高使用效率的机会。

大小优化建议主要是通过 CloudWatch 去获取实例过去 14 天的 CPU 使用数据、内存使用数据（需要安装代理）、网络进出数据、本地磁盘的 I/O 数据和 EBS 卷的性能数据，以此来产生总体的优化建议。在优化建议里有如下两个条目是客户最关心的，

• 每月节省估算值：综合所有优化建议以后每月可节省的成本预估值
• 节省估算值 (%)：可节省成本的百分比估算值

从以上两个条目的建议值中，您可以很直观的看到在采纳了优化建议以后可达到的节省比例。大小优化建议使用机器学习来确定特定工作负载的最佳 EC2 实例类型。推荐引擎分析工作负载的配置和资源使用情况，以确定数十个定义特征。例如：它可以确定工作负载是否是 CPU 密集型的，或者它是否表现出每天的重复模式。推荐引擎分析这些特征并确定工作负载所需的硬件资源。最后，它会模拟工作负载在各种 EC2 实例上的执行情况，以便提出最佳 AWS 计算资源使用建议。在最终的输出结果里，所有具有潜在优化机会的实例会被归类到以下两个类别：

• 未充分利用的实例：对于在过去 14 天内 CPU 利用率大于 1% 的实例，推荐引擎会继续寻找更加便宜的并且能处理其工作负载的实例类型，一旦找到合适的备选机型，就会将其归类的为充分利用的实例。您可以在建议详情里查看建议修改的实例以及每月节省估算值。推荐引擎同时还会计算出修改后实例的预期 CPU 利用率。根据具体场景，推荐引擎会给出不止一个优化建议，点击建议的其他选项查看更多优化方案。

• 空闲实例：如果该实例的 CPU 利用率 <= 1%，那一个终止该实例的建议就会显示在结果列表里。对于此类实例，一般的建议就是直接关闭该空闲实例，在实际的操作中，我们还需要在执行删除动作之前，进行必要的备份工作，以防万一。

Amazon Compute Optimizer

Amazon Compute Optimizer 可以提供实例类型和 Auto Scaling 组建议，使您能够更轻松的为特定工作负载选择合适的计算资源。它通过机器学习分析工作负载的配置和资源利用率以确定数十种定义特征，然后分析工作负载在各种硬件平台上的运行情况，并提供最佳的资源使用建议来降低成本。

Compute Optimizer 为分析的每个 AWS 资源提供多达三个建议选项，以合理调整工作负载的大小和提供工作负载的性能。它可在各种 EC2 实例类型上生成工作负载的预计 CPU 和内存利用率。这可以帮助您在实施建议之前了解工作负载在建议选项上的运行情况。

除了支持对 EC2 实例和 Auto Scaling 组的优化，还支持对 EBS 卷和 Lambda 函数提供优化建议，这也是和上文提到的大小优化建议的区别所在。在实际执行成本优化的过程中，TAM 一般会结合使用这两个工具，遵循最合适的优化建议。

对于 EC2 实例来说，Compute Optimizer 会将具有潜在优化机会的实例进行如下分组：

• 预置过度：当至少一个利用率指标（CPU、内存、网络）可以在仍满足工作负载的性能要求的情况下降低配置，EC2 实例被视为过度配置。
• 预置不足：当至少一个利用率指标（CPU、内存、网络）不能满足工作负载的性能要求的情况下，EC2 实例被视为预置不足。
• 已优化：当实例的所有规格（如 CPU、内存和网络）满足工作负载的性能要求且实例未处于过度预配置状态时，将 EC2 实例视为已优化。对于已优化的实例，Compute Optimizer 有时可能会建议新一代实例类型

Trusted Advisor

Amazon Trusted Advisor (TA) 是一款在线工具，它可以分析 AWS 环境，并为您提供实时指导，以帮助您基于 AWS 架构完善的框架，进而更加经济高效地预置自己的资源。TA 不仅仅可以用来提供成本优化建议，还支持对 AWS 环境的安全性、容错能力、性能和服务配额进行审查和评估，并给出改进和修改意见。

小结

经过第一阶段的优化，在本案例中，成功的将客户的 EC2 的成本降低了 20% 左右。

注：本案例的客户同时也重度的使用了 EMR 服务，EMR 在运行大数据任务的时候会使用到大量的 EC2 计算资源，在本文最开始提到客户的 EC2 用量达到了 140 万美元，其中有 45% 的用量来自于 EMR 服务，针对 EMR 的优化，我们会在后续部分讲解。在优化的第一阶段，我们针对的是剩下的 55% 的 EC2 资源，整体平均以后，客户的 EC2 总成本降低了 10% 左右。

第二阶段：有张有弛，方能进退自如

资源的弹性伸缩弹性是在云上运行工作负载绕不开的一个话题，从本质上来说，云上资源的按需使用就是弹性的基本出发点。当工作负载上升的时候，动态增加资源，保证业务的正常运行，当工作负载下降的时候，及时回收不再被使用的资源，减少浪费和不必要的成本支出。弹性不仅关乎成本，同样也关乎业务的稳定运行。AWS 为了帮助您在云上实现资源的弹性伸缩，引入了一个名为 EC2 Auto Scaling 的服务来处理和 EC2 相关的弹性伸缩需求。EC2 Auto Scaling 是一个完全托管的服务，它根据某些定义的条件，通过自动添加或删除 EC2 实例来处理应用程序负载，帮助维护应用程序的可用性。其主要功能包括：

• 增强容错能力
• 提高可用性
• 减低成本

EC2 Auto Scaling 的核心概念是 Auto Scaling Group (ASG)，它是包含多个 EC2 实例的集合，这些实例被视为逻辑分组，用于自动扩展和管理。同时，单个 ASG 还支持多种购买选项 (Savings Plan/Reserved Instances/Spot)、多种实例类型以及多种 CPU 架构。这样的多元化支持属性，可以使 ASG 在成本优化方面做到极致，帮助您兼顾资源利用和成本节省。

扩缩容策略

要实现弹性伸缩，就需要制定科学的扩缩容策略，扩缩容策略来源于扩缩容准则，其表达的是增加或者减少应用程序计算资源的能力，通用的扩缩容准则的形式及适用场景包括：

基于以上扩缩容准则，AWS 提供了如下扩缩容策略供用户来使用：

• 动态扩缩容
  • 简单/步进扩展：根据客户自定义的步骤，监控相关指标并添加/删除计算实例
  • 目标跟踪扩展：类似于恒温器的控制机制，可自动添加或删除实例以将指标控制在客户定义的目标范围
• 计划扩展（Scheduled）：按照客户的时间计划来启动/终止计算实例
• 预测性扩展：借助机器学习算法，根据历史趋势主动执行扩展或者缩容

扩缩容方案

针对本案例中提到的客户，TAM 详细分析了客户的应用场景和业务需求，有针对性的引入了弹性扩缩容方案：

• 针对 EC2 计算实例，主要采用 EC2 Auto Scaling 服务来实现扩缩容
• 针对大数据业务所用的计算实例，TAM 直接在 Amazon EMR 服务里启动了 Auto Scaling 功能，并不断的进行测试和验证，最终帮助客户找到了最适合的扩缩容策略和参数调整。

需要注意的是弹性扩缩容策略并没有固定的模式，这是因为 AWS 客户的工作负载各不相同，业务需求也有差异，在引入弹性伸缩的过程中，需要不断的测试和试错，最终找到最适合的扩缩容策略，并在以后很长的时间内根据负载和业务的变化对其进行调整，实现高效运维和成本节省。

Instance Scheduler

Instance Scheduler 是一种基于时间的计算资源优化方案。其目标是合理的安排资源的启动和停止时间，是资源容量与可预测或由时间明确定义的需求保持一致，能够最高帮助节省成本。Instance Scheduler 是一个由 AWS 开发和维护的解决方案，使用 Amazon CloudFormation 进行部署，最适合的场景是应用在开发/测试环境。对于开发/测试环境，很多情况下没必要使计算资源一直处于运行状态，只需要在工程上班时间保持运行就可以。对比计算资源 24*7 的运行时间，如果使用 Instance Scheduler 可以很方便的实现只在工作日的白天运行计算资源 (10*5 的运行时间)，这样就能实现高达 70% 的成本节省。

小结

通过以上弹性方案，TAM 成功的将客户的成本降低了 10% 左右。（考虑到客户业务和工作负载的差异，应用本方案以后不同的客户最终的成本节省会有很大不同。）

第三阶段：承诺用量，调整付费方式

在 AWS 上承诺一定的用量即可享受相应的折扣，购买折扣计划可以在不改变当前云环境，保持服务稳定的前提下立竿见影的节省成本。对于计算资源，目前 AWS 支持的折扣计划是 Savings Plans（SP）和预留实例（Reserved Instances, RI）。SP 与 RI 相比，为客户提供了更多的灵活性和更少的管理成本，客户通过承诺固定的每小时计算资源使用量（以 USD/小时为单位衡量）来节省最多 72% 的计算资源成本，该计划包含 1 年期和 3 年期两种选择。

Savings Plans 的类型

• Compute Savings Plans：可提供最高的灵活性，最高可帮您降低 66% 的成本。这些计划会自动应用于 EC2 实例使用量、Amazon Fargate 和 Amazon Lambda 服务使用量，而不受实例系列、大小、可用区、区域、操作系统或租期的限制。
• EC2 Instance Savings Plans：可提供超低价格，最多可为您节省 72% 的成本，而您需在一个区域内按稳定使用量承诺使用某个实例系列(例如，在弗吉尼亚北部使用 M5)。这可以自动降低您在该区域花费在所选实例系列上的成本，而不受可用区、大小、操作系统或租期的限制。
• SageMaker Savings Plans：可帮助您将 SageMaker 成本降低高达 64％。无论实例系列、大小、组件或 AWS 区域如何，这些计划都会自动应用于 SageMaker 的使用情况。

正如在本节开头提到的，SP 是一种更灵活的定价模式，特别是对比 RI，这些灵活性可以使客户在保持业务敏捷性的同时最大程度的节省成本，如下是 SP 和 RI 的详细对比：

Savings Plans vs. Reserved Instances

说明：

* 可转换 RIs 可以应用于不同的实例系列、大小、OS 和租赁方式，但是需要手工去执行变更操作。

** 区域性可转换 RIs 和区域性标准 RIs 支持相同实例系列的大小转换。

回到本案例，客户的工作负载多种多样，有长期稳定类型的，也有波峰波谷类型的，还有突发型的。如何选择合适的折扣计划才能获得最大的节省呢？TAM 首先会对您的工作负载类型进行归类，然后会映射到下图的工作负载中，帮助您来选择最适合的折扣计划。

对于本案例的客户，在当前阶段的成本优化方案里，TAM 提出了混合购买 Compute Savings Plans 和 EC2 Instance Savings Plans 的方案（一年期/无预付）。

• 购买 EC2 Instance Savings Plans 用来覆盖工作负载里的最稳定的那部分业务，这部分业务使用的计算实例类型也是固定的（m5 系列），通过这笔 SP，帮助客户节省了大约 100k 的 m5 计算资源的费用，对于 m5 来说，节省比例高达 35%。
• 购买 Compute Savings Plans 覆盖剩下的所有 EC2 资源，通过这笔 SP 帮助客户再节省大约 80k 的 EC2 费用。

通过这两笔 SP，客户的 SP 覆盖率大概维持在 85% – 90%。对于本案例的客户是一个相对健康的比例。因为此客户目前还处在业务的上升期，预期今后的业务还会不断扩展，工作负载也会持续增加。

小结

通过本阶段的优化，TAM 帮助客户在第一和第二阶段优化的基础上，又降低了客户大约 30% 的 EC2 计算资源成本。到此为止，通过以上三个阶段的优化措施，客户的 EC2 成本已经从每月 140 万美元降到了 72 万美元左右，成本节省比例达到了 48%，符合客户当前的预期。

正如笔者在本章开头所讲，什么才是高效的云财务管理？在这里我们延伸出如下的讨论：什么样的成本优化才算是完整并且成功的？这其实并没有一个标准答案，因为成本优化本身就是在整个云生命周期里持续演进的一个过程。但是对于阶段性的成本优化工作来说，以下几个维度是我们可以用来衡量成本优化是否成功的关键要素：

• 是否达到客户预期？是否有益于客户实现业务目标？
• 是否提高了资源利用率？
• 是否帮助客户建立起成本意识以及相应的成本管理流程？
• 是否帮组客户去理解更进一步的成本优化方案？

对于本案例的客户，经过如上三个阶段的优化，TAM 已经成功的帮助客户实现了成本优化的短期目标。为了帮助客户实现长期的成本优化和业务创新，TAM 继续为该客户制定了更多的优化方案供客户在未来某个时间去实施。

第四阶段：使用 Spot，用最低的成本实现最高的价值

Spot 是使用 AWS 上闲置的计算资源的一种服务，Spot 最高价格不会超过按需使用的价格，所以使用 Spot 实例会带来非常明显的成本下降。根据区域、实例类型、供求关系等的差异，使用 Spot 带来节省最高可以达到 90%。Spot 实例具有以下特点：

• 具有和按需实例一样的使用规则：相同的硬件、能力及同样的实例类型
• 根据历史的数据观察，其价格也是相对平滑，可预测的
• 当其他用户的按需需求不能得到满足的时候，Spot 实例会有被系统强制回收的风险，系统会提前 2 分钟发出回收实例的通知。
• 可以集成 Spot 实例到多种 AWS 服务中，比如：EKS/ECS/Fargate/Auto Scaling/EMR/SageMaker 等等。

回到本案例的客户，上文提到客户是重度的 EMR 服务用户，针对此我们提出了在 EMR 服务的使用中采用 Spot 实例的方案。客户可以按比例在任务节点组中配置按需实例和 Spot 实例去降低 EC2 的成本，通过估算，在引入 Spot 实例以后，可以进一步降低大约 20% 的 EC2 成本（用于运行 EMR 任务的 EC2）。

第五阶段：更新迭代，提高性价比

根据摩尔定律，大约每隔 18 个月，电脑硬件的性能将会提升一倍，而且价格却维持在一个相对平稳的水平。这就意味着，当 AWS 推出新一代的计算资源类型的时候，客户可以用同样的成本获取更高性能的计算资源，性价比会有很大的提升。

本案例的客户主要使用的是 AWS 的第五代的 x86 机型（英特尔处理器 ），TAM 为客户提供了如下方案可以进一步来降低计算资源的成本：

• 迁移当前的第五代 x86 机型到相对应的第六代机型，保持处理器不变（英特尔处理器），这种方案下成本不变，但是六代机型比五代机型有 15% 的性价比提升，即相同的支出会获得更高的性能。
• 迁移部分适合的业务到第六代机型，处理器从英特尔切换到 AMD，这种方案可以节省 10% 成本。
• 迁移部分合适的业务到第六代机型，处理器从英特尔切换到 AWS 自研的 Graviton 处理器，这种方案可以节省多达 50% 的成本。

总结

在本文开头，我们以案例开头，引入了一个真实客户的例子，从上云初期计算资源账单飞涨开始，到介绍如何为工作负载选择最合适的资源类型和大小，再到一共分为五个阶段的优化方案。TAM 在整个过程中，都紧密的跟客户一起合作、探讨，并最终成功的实施了方案，完成了降低成本的目标。

本文所介绍的优化方案，适用于大部分需要优化计算资源的场景，但是请注意，最终能为您带来的成本节省与工作负载和业务逻辑密切相关，并不是一个固定值。为了在保持业务稳定的情况下，实现最大限度的成本优化，AWS 企业支持团队始终和您精诚合作，在不断的演进中探索无尽的可能。

本篇作者