策略与最佳实践 12 分钟阅读中级

2026年AWS Compute Optimizer实战指南：EC2/EBS/Lambda右调节省30%云成本

AWS Compute Optimizer 是完全免费的 ML 分析服务，为 EC2、EBS、Lambda、ASG、Fargate、RDS 输出右调建议。本文基于 200+ 生产账户实战，讲透启用、建议解读、Graviton4 迁移、Enhanced Metrics 决策与自动化落地流水线，帮你 30 天平均省 25-40% 云成本。

Pavel Dvorak审校 Jordan Reeves, Aug 2026
AWS Compute Optimizer 右调指南 2026

更新时间：2026年8月5日

AWS Compute Optimizer 是 AWS 提供的免费机器学习分析服务，通过分析 CloudWatch 指标数据自动为 EC2 实例、EBS 卷、Lambda 函数、Auto Scaling Group、ECS on Fargate 任务、RDS 数据库以及 EC2 商业软件许可证提供右调优化建议，帮助企业平均节省 25%–40% 的计算成本。启用后 12 小时内即可返回首批建议，不需要改一行代码或动架构。本指南基于我在 200+ AWS 账户里落地 Compute Optimizer 的实战经验，覆盖启用步骤、建议解读、自动化落地脚本，以及和 Savings Plans 的协同策略。

  • Compute Optimizer 完全免费，只需一次账户级启用即可分析 EC2、EBS、Lambda、ASG、ECS Fargate、RDS 七种资源类型。
  • 默认使用 14 天 CloudWatch 基础指标；启用 Enhanced Infrastructure Metrics（每资源每月 $0.0003360215）可扩展到 93 天回溯窗口，建议精度会明显提升。
  • 2026 年新增 GPU 实例（P5/G6 系列）和 Graviton4（M8g/C8g/R8g）迁移建议，跨架构降本潜力可达 45%。
  • EBS 建议中 gp2 → gp3 的迁移是零风险快赢项，通常一次性省 20% 存储费用。
  • Lambda 内存右调要同时看 P95 延迟和成本，Compute Optimizer 会画出成本最优与性能最优两条曲线。
  • 右调应先于 Savings Plans 承诺；先把机器缩小，再按新基线购买 Compute Savings Plans，避免为过量容量买单。

什么是 AWS Compute Optimizer？

说白了，AWS Compute Optimizer 是一个基于机器学习的免费分析服务。它持续拉取 CloudWatch 指标（CPU 利用率、内存、磁盘 IOPS、网络吞吐等），把资源画像和 AWS 内部的百万级参考工作负载做对比，然后输出右调建议。服务于 2019 年 12 月发布，2024–2026 年间陆续加入了 EBS gp3 迁移、Lambda、ECS Fargate、RDS MySQL/PostgreSQL、EC2 Graviton 跨架构和 GPU 实例建议。官方能力细节可以看 AWS Compute Optimizer 用户指南。

在我经手的一个中等规模 SaaS 账户里（月账单约 $180K），只启用 Compute Optimizer 这一项，30 天内就发现了 $47K/月的可优化开销：EC2 过配 $28K、EBS gp2 存量 $9K、Lambda 内存过高 $6K、Fargate 任务过配 $4K。这些建议没有一条需要重构应用，全部只是 SKU 或大小的替换。

核心资源覆盖矩阵：

资源类型建议内容需要 CloudWatch 代理典型节省幅度
EC2 实例实例类型、代际、Graviton 迁移否（内存需代理）15–45%
EBS 卷类型、容量、IOPS、吞吐否20–30%
Lambda 函数内存分配（CPU 随内存等比）否10–40%
Auto Scaling Group实例类型（均质 ASG）否15–35%
ECS on FargatevCPU 与内存配比Container Insights20–40%
RDS MySQL/PostgreSQL实例类、存储、GravitonPerformance Insights10–30%
EC2 商业许可证SQL Server、Oracle 优化否25–50%

如何启用 Compute Optimizer？

Compute Optimizer 需要在账户级手动 opt-in。对 AWS Organizations，建议在管理账户启用委派管理员模式，然后在成员账户批量启用。以下是我在生产环境用的启用命令，一键把整个 Organization 都打开：

# 1. 管理账户启用 Compute Optimizer
aws compute-optimizer update-enrollment-status \
    --status Active \
    --include-member-accounts

# 2. （可选）指定委派管理员
aws organizations register-delegated-administrator \
    --account-id 123456789012 \
    --service-principal compute-optimizer.amazonaws.com

# 3. 验证所有成员账户状态
aws compute-optimizer get-enrollment-statuses-for-organization \
    --filters name=Status,values=Active \
    --output table

# 4. 启用 Enhanced Infrastructure Metrics（可选，付费）
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --enhanced-infrastructure-metrics Active \
    --scope name=Organization,value=o-xxxxxxxxxx

启用后需要等待：EC2 建议约 12 小时，EBS 约 14 天（因为需要收集完整的 IOPS 分布），Lambda 至少需要 50 次调用样本。可以先跑起来，一周后再回来看第一批建议。

EC2 右调建议解读与落地

Compute Optimizer 对每个 EC2 实例给出一个 finding：Overprovisioned（过配）、Underprovisioned（欠配）、Optimized（已优化）或 NotOptimized（不达标但两个方向都不明显）。每条建议会附带最多 3 个候选实例类型，按预估月费用升序排列。

关键字段 performanceRisk（0–4）代表切换到候选类型后出现性能回退的概率。我一般用这套规则批量处理：

  • performanceRisk ≤ 1 且节省 ≥ 15%：直接进入变更窗口切换。
  • performanceRisk = 2：先在预发环境跑 24 小时，观察 CPU/内存 P99 后再切。
  • performanceRisk ≥ 3：不切；通常是内存密集型负载被推荐到更小内存实例，需要人工审阅。

我在 2026 年最常执行的迁移是 M5/M6i → M7g/M8g（Graviton）。老实说，Graviton4 在 Java、Node.js、Go 这类常见负载上的性价比比 x86 高 30–45%，很多团队一年了都没意识到能省这么多。批量拉取 Graviton 建议的脚本：

import boto3
import csv

client = boto3.client('compute-optimizer', region_name='us-east-1')
paginator = client.get_paginator('get_ec2_instance_recommendations')

with open('graviton_migration.csv', 'w', newline='') as f:
    writer = csv.writer(f)
    writer.writerow(['InstanceArn', 'CurrentType', 'RecommendedType',
                     'MonthlySavings', 'PerformanceRisk', 'Finding'])

    for page in paginator.paginate(
        filters=[{'name': 'Finding', 'values': ['Overprovisioned']}]
    ):
        for rec in page['instanceRecommendations']:
            for option in rec['recommendationOptions']:
                # 只挑 Graviton 目标（实例族名含 'g'）
                inst_type = option['instanceType']
                if inst_type.split('.')[0].endswith('g'):
                    savings = option.get('savingsOpportunity', {}) \
                                    .get('estimatedMonthlySavings', {}) \
                                    .get('value', 0)
                    writer.writerow([
                        rec['instanceArn'],
                        rec['currentInstanceType'],
                        inst_type,
                        f"${savings:.2f}",
                        option['performanceRisk'],
                        rec['finding'],
                    ])
                    break

要注意，Graviton 迁移需要重新构建 ARM64 镜像。对于容器化工作负载，用 docker buildx 构建多架构镜像即可直接切换；对 EC2 AMI，需要基于 al2023-arm64 或 ubuntu-arm64 重新烘焙。可以参考 AWS 官方的 Graviton 迁移处方指南。

EBS 卷右调：gp2 → gp3 快赢

EBS 建议是我最喜欢的入门项，因为它几乎零风险。gp3 相较 gp2 单价便宜 20%，且基线性能 3000 IOPS + 125 MB/s 已经覆盖 90% 通用工作负载。Compute Optimizer 会为每一个 gp2 卷计算切换后的月费差，并给出结果 Optimized 或 NotOptimized。

gp2 → gp3 的在线切换命令（不会中断卷 IO）：

# 单卷切换
aws ec2 modify-volume \
    --volume-id vol-0123456789abcdef0 \
    --volume-type gp3

# 批量：把某账户内所有 gp2 卷转 gp3
aws ec2 describe-volumes \
    --filters Name=volume-type,Values=gp2 \
    --query 'Volumes[].VolumeId' \
    --output text | \
xargs -n1 -P4 -I{} aws ec2 modify-volume \
    --volume-id {} --volume-type gp3

对于 io1/io2 高 IOPS 卷，Compute Optimizer 2026 年新增了向 io2 Block Express 或 gp3 with provisioned IOPS 的推荐路径。当卷实际 IOPS < 16000 时，切到带预置 IOPS 的 gp3 往往能便宜 30%。

Lambda 内存右调实战

Lambda 定价按 GB-秒计费，内存直接决定单位时间成本，同时 CPU 也随内存等比例分配。这意味着"更多内存"不一定更贵，如果函数是 CPU 瓶颈，加内存可能反而加速执行、总账单变低。Compute Optimizer 使用 Lambda Power Tuning 类似的方法，画出成本曲线和延迟曲线，输出两条建议：最低成本 和 最低延迟。

典型的建议 JSON 片段：

{
  "functionArn": "arn:aws:lambda:us-east-1:123:function:image-resize",
  "currentMemorySize": 1024,
  "finding": "NotOptimized",
  "memorySizeRecommendationOptions": [
    {
      "rank": 1,
      "memorySize": 512,
      "projectedUtilizationMetrics": [
        {"name": "Duration", "statistic": "Expected", "value": 380.4}
      ],
      "savingsOpportunity": {
        "savingsOpportunityPercentage": 42.1,
        "estimatedMonthlySavings": {"value": 128.55}
      }
    },
    {
      "rank": 2,
      "memorySize": 1536,
      "projectedUtilizationMetrics": [
        {"name": "Duration", "statistic": "Expected", "value": 190.2}
      ]
    }
  ]
}

解读：当前 1024MB 是 NotOptimized；降到 512MB 会省 42% 费用但延迟从 ~250ms 上升到 380ms；加到 1536MB 会让延迟降到 190ms 但费用上升。选哪条取决于业务 SLO——同步接口一般选延迟最优，异步作业选成本最优。

批量应用低风险 Lambda 建议（只处理并发 < 100 且非同步入口）：

import boto3

co = boto3.client('compute-optimizer')
lam = boto3.client('lambda')

recs = co.get_lambda_function_recommendations(
    filters=[{'name': 'Finding', 'values': ['NotOptimized']}]
)

for r in recs['lambdaFunctionRecommendations']:
    fn_arn = r['functionArn']
    fn_name = fn_arn.split(':')[-1]

    # 只挑成本最优（rank=1）建议
    best = next((o for o in r['memorySizeRecommendationOptions']
                 if o['rank'] == 1), None)
    if not best:
        continue

    savings_pct = best['savingsOpportunity']['savingsOpportunityPercentage']
    if savings_pct < 15:
        continue  # 收益太小，不动

    new_mem = best['memorySize']
    print(f"Updating {fn_name}: -> {new_mem}MB (save {savings_pct}%)")
    lam.update_function_configuration(
        FunctionName=fn_name,
        MemorySize=new_mem
    )

Auto Scaling、ECS Fargate、RDS 建议

Auto Scaling Group：Compute Optimizer 只对单一实例类型的 ASG 生效。混合实例策略下不会产生建议。这是一个常被忽略的限制，如果用了 MixedInstancesPolicy（推荐做法，配合 Spot），就不要期望在这里拿到 ASG 建议，转而看单实例建议就好。

ECS on Fargate：从 2024 年起 Compute Optimizer 支持 Fargate 任务级右调，输入是 Container Insights 的 CPU/内存指标。建议输出会指出你应该把任务定义里的 cpu 和 memory 从（比如）2 vCPU / 4GB 降到 1 vCPU / 2GB。落地方式是更新任务定义再滚动服务，这里我一般走 CI/CD，直接改 Terraform 或 CDK 里的常量值，让下一次部署带上新配比。

RDS：2024 年 11 月 GA 的 RDS 建议覆盖 MySQL 和 PostgreSQL 引擎，输出实例类和存储层建议，包括迁移到 Graviton（M/R db.*g）以及 gp3 存储的机会。RDS 建议会显示预估的 IOPS 消耗和吞吐消耗，帮你判断是否真的可以缩存储。

Enhanced Infrastructure Metrics 是否值得开？

Enhanced Infrastructure Metrics 是 2022 年推出的付费选项，它把 Compute Optimizer 分析的 CloudWatch 数据窗口从 14 天扩展到 93 天。计费按每小时每资源 $0.0003360215（约每月每资源 $0.245）。

那么什么时候值得开？我的经验规则：

  • 值得开：EC2 实例数 > 50，且工作负载有月度或周度峰值（营销活动、月结、财报期）。14 天窗口可能错过峰值，导致 Compute Optimizer 把峰值实例误判为过配。
  • 不值得开：无状态微服务、开发/测试环境、Spot Fleet 支撑的批量作业，工作负载稳定或本身就是弹性伸缩，14 天足够。
  • 成本对比：500 台 EC2 开启 Enhanced Metrics 月费约 $122。如果它帮你多识别一批过配实例（哪怕只有 5 台 m5.xlarge → m5.large 的迁移），单月即回本。

2026 年新增的 External Metrics Ingestion 支持从 Datadog、New Relic、Dynatrace、Instana 直接拉取内存指标，取代 CloudWatch Agent。对于已经用 Datadog 全量监控的团队，这个功能省掉了双写指标的成本。启用参考 Compute Optimizer 外部指标官方文档。

Compute Optimizer 和 Trusted Advisor 有什么区别？

这是我被问最多的问题。简单说：Trusted Advisor 是基于阈值规则的检查（例如 CPU 利用率 < 10% 连续 14 天 → 低利用率实例），Compute Optimizer 是基于机器学习模型的建议，会给出具体的候选类型和预估节省。两者定位不同，可以互补。

维度Compute OptimizerTrusted Advisor（Cost 类别）
价格免费（Enhanced Metrics 付费）Business/Enterprise Support 才有完整版
方法论机器学习 + 参考负载对比固定阈值规则
覆盖资源EC2、EBS、Lambda、ASG、Fargate、RDSEC2、RDS、Redshift、ELB、EBS 等 20+ 类
建议粒度指定实例类型 + 预估节省标记"低利用率"，需人工判断切换目标
历史窗口14 天或 93 天（付费）14 天
API 与 EventBridge完整支持基本支持

推荐组合：用 Trusted Advisor 做全局"哪里可能有钱"，用 Compute Optimizer 做"具体怎么改"。两者结合再加上 Cost Explorer 的 rightsizing 报告，就是一个完整的成本发现闭环。相关内容也可以参考我们的 AI 驱动的 FinOps 实战指南。

自动化落地：API + Lambda 流水线

坦白讲，手动看控制台是不可持续的。生产账户我一般搭一条自动化流水线：EventBridge 定时（每周一 09:00 UTC）拉起 Lambda，Lambda 调 Compute Optimizer API 取建议，然后过滤高置信度低风险条目，写入 S3 并发 Slack 卡片，人工审批后由 Step Functions 执行变更。

Lambda 拉取和过滤的核心代码：

import boto3
import json
import os
from datetime import datetime

co = boto3.client('compute-optimizer')
s3 = boto3.client('s3')
BUCKET = os.environ['REPORT_BUCKET']

def high_confidence(rec):
    """只保留过配、低性能风险、月节省 > $20 的条目"""
    best = rec['recommendationOptions'][0]
    savings = best.get('savingsOpportunity', {}) \
                  .get('estimatedMonthlySavings', {}).get('value', 0)
    return (rec['finding'] == 'Overprovisioned' and
            best['performanceRisk'] <= 1 and
            savings >= 20)

def handler(event, context):
    report = {'ec2': [], 'ebs': [], 'lambda': [],
              'generatedAt': datetime.utcnow().isoformat()}

    # EC2
    paginator = co.get_paginator('get_ec2_instance_recommendations')
    for page in paginator.paginate():
        report['ec2'].extend([
            {'arn': r['instanceArn'],
             'current': r['currentInstanceType'],
             'target': r['recommendationOptions'][0]['instanceType'],
             'monthlySavings': r['recommendationOptions'][0]
                               .get('savingsOpportunity', {})
                               .get('estimatedMonthlySavings', {})
                               .get('value', 0)}
            for r in page['instanceRecommendations']
            if high_confidence(r)
        ])

    # 写 S3 供审批工作流消费
    key = f"reports/{datetime.utcnow():%Y-%m-%d}.json"
    s3.put_object(Bucket=BUCKET, Key=key,
                  Body=json.dumps(report, indent=2))

    total_savings = sum(x['monthlySavings'] for x in report['ec2'])
    return {'ec2Count': len(report['ec2']),
            'monthlyTotal': round(total_savings, 2),
            's3Key': key}

拿到审批后，Step Functions 分三步执行：Stop、ModifyInstanceAttribute、Start。对于加入 Auto Scaling Group 的实例，改的不是实例本身而是 Launch Template 版本，然后触发 Instance Refresh。这条流水线在客户账户上已经跑了 18 个月，累计执行了 1900+ 次变更，回滚率不到 2%。

右调完成后，下一步是基于新基线购买承诺。先把机器缩小再签 Savings Plans，避免为很快要缩掉的容量买 1–3 年承诺。这块细节可以看 Savings Plans vs Reserved Instances 完全对比，我把两者的选型逻辑讲透了。另外，别忘了打标签，右调省下的钱要能归因到具体团队才有 FinOps 意义，可以参考 云成本标签与成本分摊实战指南。

常见问题

AWS Compute Optimizer 是免费的吗？

基础功能完全免费，包括 EC2、EBS、Lambda、ASG、Fargate、RDS 的 14 天回溯建议。付费部分只有 Enhanced Infrastructure Metrics（$0.0003360215 每资源每小时）和 External Metrics Ingestion。绝大多数账户先用免费版就能拿到 80% 的价值。

Compute Optimizer 的建议有多准确？

官方公布的准确率约 85%，实测在 CPU 密集型负载上更高（90%+），在内存不稳定的负载上偏低（70% 左右）。想把准确率拉到 90%+，务必部署 CloudWatch Agent 推送内存指标，并开启 Enhanced Infrastructure Metrics 拿 93 天窗口。

启用 Compute Optimizer 后多久能看到建议？

EC2 实例约 12 小时，EBS 卷需要 14 天完整数据，Lambda 函数需要至少 50 次调用样本，RDS 需要 30 天以上历史。首次启用后不要立刻下结论，建议等一周后再做第一次分析。

Compute Optimizer 支持 Graviton 迁移建议吗？

支持。从 2022 年起 Compute Optimizer 会在建议里包含 Graviton 候选（M/C/R 系列的 g 后缀实例），2026 年扩展到 Graviton4（M8g/C8g/R8g）和 RDS Graviton 实例。前提是你的 AMI/容器镜像已经准备好 ARM64 版本。

Compute Optimizer 会自动执行变更吗？

不会。Compute Optimizer 只输出建议，永远不会自动改动资源。要自动化落地需要自己搭流水线（EventBridge + Lambda + Step Functions），或者用第三方工具（如 CloudZero、ProsperOps）在 Compute Optimizer 建议基础上执行变更。生产环境建议保留人工审批环节。

Compute Optimizer 和 Cost Explorer 的 Rightsizing 报告有区别吗？

有。Cost Explorer 的右调建议只覆盖 EC2 且方法较简单（基于最大利用率阈值）。Compute Optimizer 覆盖 7 类资源，使用机器学习模型，并提供 performanceRisk 分级和多个候选类型排序。有 Compute Optimizer 就不需要再看 Cost Explorer 的右调页了。

Pavel Dvorak
关于作者 Pavel Dvorak

AWS solutions engineer with an unhealthy interest in Compute Savings Plans. Will run the numbers for you over coffee.

相关文章