CPU ≥ 5%：把 EC2 账单抬高 14 倍的自动伸缩阈值

症状：有成本峰值，却没有使用峰值

一个 AWS 上交易型应用的成本报告显示 EC2 波动得离谱：11 美元/天与 160+ 美元/天交替出现，且与真实流量增长毫无关联。99% 的 EC2 成本来自单个由 c6g.2xlarge 实例组成的 Auto Scaling Group。

最夸张的一例：2 月 1–2 日花了 271.56 美元，而预期约为 22.92 美元——两天多花 248.64 美元。日峰值 162.34 美元，对比 11.46 美元的基线：是正常账单的 14 倍。

根因：一个荒唐的扩容阈值

ASG 的扩容告警被设为 CPU ≥ 5%、3 个 60 秒数据点。百分之五。任何负载的微小波动——尤其是每次部署带来的瞬时 CPU 抬升——都越过触发点，ASG 便启动新实例。由于缩容很保守，膨胀的实例群迟迟不回落，而每多一台 c6g.2xlarge 都按小时计费。

自动伸缩不是"越有弹性越好"。过于敏感的触发器把噪声变成账单——把部署变成成本事故。

如何度量：按 USAGE_TYPE 看 Cost Explorer

动手之前，先证明成本来自哪里。通过 CLI 调用 Cost Explorer，按使用类型分组，隔离出 ASG 的 BoxUsage：

aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[].Groups[?contains(Keys[0], `BoxUsage`)]' --output table

正是这条命令揭示了日峰值集中在部署日——而非高流量日。

修复：抬高阈值，把部署和伸缩分开

主要修复是把扩容触发器从 5% 提到一个现实的区间（40–50%），并拉长评估周期，使得只有持续负载——而非噪声或部署——才驱动伸缩。预计仅此 ASG 就节省约 150 美元/月，消灭了"幽灵实例群"。

# 之前（荒唐的触发器）
ScaleUpThreshold: 5      # CPU%，3x60s  → 任何部署都扩容

# 之后（真正的持续负载）
ScaleUpThreshold: 45     # CPU%，5x60s
ScaleDownThreshold: 25   # 扩容与缩容之间健康的死区

一个补充注意点：扩容与缩容之间的死区必须够宽以避免抖动，但又不能宽到让实例群卡住（另文再述）。

经验教训

1. 低扩容阈值是成本，不是韧性。5% CPU 是噪声。从 40–50% 的持续负载起步，用数据调优。

2. 触发器敏感时，部署会拉起实例群。成本峰值集中在部署日，正是该问题的特征。

3. 动手前按 USAGE_TYPE 度量。按 BoxUsage 分组的 Cost Explorer 能证明是哪个 ASG/实例在产生成本，而不是靠猜。

结论

当弹性响应真实需求时，它很棒。5% 的触发器响应的是幽灵：指标噪声和部署流水线本身。实例群膨胀，没人看告警，账单悄悄涨了 14 倍。一行配置——正确的阈值——让成本回到与使用量相称的大小。