利用 AWS Compute Optimizer 实现持续优化和成本降低
掌握使用 AWS Compute Optimizer (ACO) 实现 AWS 成本效益和性能优化的方法。本综合指南解释了 ACO 如何利用机器学习生成可操作的、数据驱动的建议，用于调整 EC2 实例、EBS 卷和 Lambda 函数的大小。了解实施这些更改的具体步骤和 CLI 示例，确保持续优化以降低云支出并保持应用程序可靠性。
利用 AWS Compute Optimizer 实现持续优化和成本降低
AWS 的优化听起来像是一项财务工作，直到第一次错误的更改导致生产工作负载宕机。更实用的版本则更为谨慎：找到明显过大、明显过小或在笨拙的基础设施代上运行的资源，然后以尊重流量模式、状态、回滚和应用程序行为的方式进行更改。
AWS Compute Optimizer 通过分析资源配置和利用率指标来帮助完成这项工作，并为 EC2 实例、Auto Scaling 组、EBS 卷、Fargate 上的 ECS 服务和 Lambda 函数等服务生成建议。这些建议很有用，但应将其视为决策支持，而非自动真理。Compute Optimizer 可以看到指标。但它并不总能看到发布日历、客户承诺、许可问题或仅在月底运行的奇怪批处理作业。
了解 AWS Compute Optimizer
AWS Compute Optimizer 通过分析受支持资源的历史利用率指标来提供建议。默认回顾期通常基于近期历史记录，增强的基础设施指标可以延长某些资源类型的分析窗口。确切的可用性和保留时间可能因资源类型、区域、账户设置和 AWS 功能更改而异，因此在围绕某个数字构建严格流程之前，请查看当前的服务页面。
ACO 评估多个因素，包括 CPU 利用率、内存使用情况（如果安装了适当的 CloudWatch 代理）、网络吞吐量和磁盘 I/O，生成优先考虑成本效益和性能的建议。
ACO 提供的关键指标
- 优化发现： 资源分类（例如，过度配置、配置不足、已优化）。
- 估计每月节省： 如果实施建议，预计可减少的成本。
- 性能风险： 低、中或高评估，表明实施建议对工作负载性能产生负面影响的可能性。
- 推荐选项： 特定的替代资源配置（例如，实例类型、内存设置、EBS 卷规格）。
注意： 在许多常见用途中，Compute Optimizer 建议本身无需单独服务费用即可获得，但可选增强指标和正在分析的资源仍可能影响您的账单。在广泛启用可选功能之前，请验证您账户中的定价。
调整 Amazon EC2 实例的大小
EC2 实例通常是云计算成本的最大单一驱动因素。ACO 为独立实例和 Auto Scaling 组 (ASG) 中的实例提供量身定制的建议。
识别过度配置和配置不足的实例
ACO 根据其分析对 EC2 实例进行分类：
- 过度配置： 对于 Compute Optimizer 可以看到的指标，表现出持续低利用率的实例。它可能建议迁移到更小或不同类型的实例。
- 配置不足： 显示高利用率或资源压力的实例。它可能建议使用更大的实例、不同的系列或具有更好 CPU、内存、网络或存储特性的配置。
实施 EC2 优化建议
实施更改需要仔细规划，尤其是对于生产工作负载。更改实例类型的过程通常涉及停止、修改和重新启动实例。
示例：通过 CLI 修改过度配置的实例
如果 Compute Optimizer 建议将实例从 m5.large 更改为 t3.large，则对于 EBS 支持的实例，机械步骤如下：
- 停止实例：
aws ec2 stop-instances --instance-ids i-1234567890abcdef0 - 修改实例类型：
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}" - 启动实例：
aws ec2 start-instances --instance-ids i-1234567890abcdef0
最佳实践： 始终在低流量时段执行这些更改，并在实施后密切监控实例指标（CPU、延迟、应用程序日志）24-48 小时，以确保新大小能够处理峰值负载而不会出现性能下降。
在更改类型之前，请检查实例是否是 Auto Scaling 组的一部分、是否使用实例存储卷、是否有放置组要求、是否使用 ENA 或 NVMe 命名假设，或者是否绑定到许可模型。对于生产服务，将新大小烘焙到启动模板中、逐步替换实例并让负载均衡器耗尽连接通常更安全。
优化 Amazon EBS 卷
Compute Optimizer 将其建议扩展到附加到 EC2 实例的 Elastic Block Store (EBS) 卷。此处的优化侧重于通过建议现代卷类型和调整 IOPS/吞吐量设置来最大化每美元的性能。
迁移建议
一种常见的优化是将较旧的通用卷（尤其是 gp2）迁移到适合工作负载的 gp3。
| 卷类型 | 优势 |
|---|---|
gp2 |
性能随卷大小和突发积分而扩展。 |
gp3 |
性能可以在服务限制内与大小分开配置。 |
Compute Optimizer 可能会根据观察到的使用模式推荐特定的 IOPS 和吞吐量值。将这些建议视为起点。最近写入量较低的数据库卷可能仍需要为维护窗口、压缩、索引构建、备份或故障转移追赶预留空间。
可操作步骤：修改卷
EBS 卷修改通常可以在卷使用中执行（与更改 EC2 实例类型不同），但应考虑性能影响。
# 示例：将卷迁移到 gp3 并设置特定的 IOPS/吞吐量
aws ec2 modify-volume \
--volume-id vol-fedcba9876543210 \
--volume-type gp3 \
--iops 3000 \
--throughput 125
命令后监视修改状态：
aws ec2 describe-volumes-modifications \
--volume-ids vol-fedcba9876543210
对于关键数据库，首先在副本或暂存副本上测试更改。卷类型更改可能是在线的，但如果新的 IOPS 或吞吐量设置过低，工作负载仍然可能感受到 I/O 行为的变化。
调整 AWS Lambda 函数的大小
对于无服务器工作负载，Compute Optimizer 为 AWS Lambda 函数提供了关键见解。在 Lambda 中，内存设置决定了分配给函数的 vCPU 数量。优化 Lambda 主要是找到满足性能目标的最低内存配置。
内存/CPU 权衡
Compute Optimizer 分析 Lambda 利用率和持续时间模式以推荐内存设置。一个函数可能分配了 1024 MB，但在 512 MB 下也能接受。另一个函数在增加内存时可能会变得更便宜，因为增加的 CPU 减少了持续时间，足以抵消更大的内存分配。
第二种情况令人惊讶。Lambda 成本与分配的内存和持续时间相关，因此最便宜的设置并不总是最小的内存值。在广泛应用建议之前，测试代表性事件。
实施 Lambda 函数优化
Lambda 优化很简单，通常只需要对函数配置进行简单更新。
示例：更新 Lambda 内存配置
如果 ACO 建议将函数从 2048MB 迁移到 1024MB：
aws lambda update-function-configuration \
--function-name MyOptimizedFunction \
--memory-size 1024
将持续优化集成到您的工作流程中
优化不应是一次性审计，而应是一项持续的工作。Compute Optimizer 通过其 API 和与 AWS Organizations 的集成促进了这一点。
1. 集中管理
如果使用 AWS Organizations，请为 Compute Optimizer 指定一个委派管理员账户。这允许 ACO 跨所有账户提供整合建议，提供企业范围内潜在节省的整体视图。
2. 自动化和通知
使用 Compute Optimizer API 并将其与 AWS CloudWatch Events 或 Lambda 集成以创建自动化工作流程：
- 定期报告： 设置每日或每周触发器，提取最新的高优先级建议（例如，估计节省最多的建议）。
- 警报： 当 ACO 识别出具有特定发现的资源（例如，配置不足且性能风险高的实例）时，通过 SNS 触发警报。
- 半自动化实施： 对于低风险、高节省的建议（如 EBS gp3 迁移），使用 Lambda 函数自动生成更改请求，甚至在通过必要的治理阈值后直接应用更改。
# 使用 boto3 检索建议的概念性 Python 代码片段
import boto3
aco_client = boto3.client('compute-optimizer')
response = aco_client.get_ec2_instance_recommendations(
filters=[
{'name': 'finding', 'values': ['Overprovisioned']}
]
)
# 处理并执行推荐选项...
保持实施与建议收集分离。每周报告可以安全地列出候选者。一个在没有工作负载上下文的情况下停止实例或更改 Lambda 内存的机器人可能会造成事故。一个好的中间立场是使用建议、当前指标、提议的更改、估计节省和回滚计划来开具工单或拉取请求。
如何在采取行动前审查建议
对于每个建议，提出一些实际问题：
- 资源是否仍在使用中，或者删除是否比调整大小更好？
- 回顾期是否包括正常峰值流量、批处理窗口和最近的发布？
- EC2 是否有内存数据可用，或者建议主要基于 CPU 和网络？
- 实例是有状态的、已许可的、绑定到硬件的还是手动配置的？
- 更改能否在 Auto Scaling 组、蓝/绿部署或副本后面推出？
- 什么指标可以证明更改成功或失败？
例如，运行夜间报告的 EC2 实例在工作时间可能看起来空闲，但在午夜后 40 分钟内非常繁忙。基于广泛平均值的建议可能会建议缩小规模，但真正的问题是报告是否仍在业务截止日期前完成。破坏批处理窗口的成本节省不是节省。
降低风险的推出模式
最安全的实施路径取决于资源。
对于负载均衡器后面的无状态 EC2 服务，最好通过 Auto Scaling 组或部署管道替换实例，而不是手动停止实时实例。更新启动模板，添加一个具有新类型的实例，观察健康检查和应用程序指标，然后逐步推出其余部分。这为您提供了自然的回滚：放回旧的启动模板版本并替换新实例。
对于有状态 EC2 主机，采取较慢的路径。确认备份，了解附加卷，检查维护窗口，并确保应用程序能够容忍停止/启动周期。一些较旧的实例系列和较新的系列以不同方式暴露磁盘或网络设备，因此假设设备名称的启动脚本在类型更改后可能会中断。
对于 EBS，在更改卷类型或配置性能后，同时监视成本和性能指标。较低的月度估计是不够的。检查队列长度、延迟、吞吐量和应用程序级症状。如果卷支持数据库，应用程序延迟可能比单独的卷图告诉您更多信息。
对于 Lambda，当函数很重要时，发布新版本或基于别名的推出。将一小部分流量发送到新的内存设置，比较持续时间、错误、冷启动和下游压力，然后转移更多流量。随着内存增加而变快的函数可能会对其调用的数据库或 API 施加更大压力，因此请监视整个路径。
清晰报告建议
有用的优化报告不应是充满实例 ID 且没有上下文的电子表格。包括当前配置、推荐配置、观察到的利用率窗口、估计每月节省、性能风险、所有者、提议的推出方法和回滚计划。添加简短说明，解释为什么接受、推迟或拒绝建议。
被拒绝的建议仍然有用。数据库服务器可能看起来配置过度，因为它的大小是为了故障转移，而不是平均流量。许可服务器可能需要固定的实例系列。低使用率主机可能正在等待计划中的迁移。记录这些原因可以防止每月再次争论相同的建议。
使用 Compute Optimizer 的最佳实践
| 领域 | 最佳实践 |
|---|---|
| 监控周期 | 确保资源在典型负载下运行至少 14 天，然后再信任建议。 |
| 性能测试 | 实施缩小建议后，始终运行负载测试以确保应用程序维持所需的 SLO（服务级别目标）。 |
| 专业化工作负载 | 对有状态应用程序、数据库或第三方许可服务器保持谨慎，这些可能需要特定的实例类型或最小资源，即使 ACO 建议更小的尺寸。 |
| 内存指标 | 对于 EC2，安装 CloudWatch 代理以收集详细的内存使用数据。如果没有此数据，ACO 的优化建议主要依赖于 CPU 和网络，这可能不完整。 |
| 持续审查 | 将 ACO 仪表板视为动态文档。工作负载不断变化，需要定期重新评估资源大小。 |
最终检查
当 AWS Compute Optimizer 成为审查习惯的一部分时，它最有价值。使用它来发现浪费、发现配置不足的资源并挑战旧假设。然后引入 AWS 无法推断的上下文：发布时机、峰值事件、客户承诺、故障域和回滚路径。最好的优化计划不是接受最多建议的计划。而是在不使生产更脆弱的情况下节省资金的计划。