AWS 成本报告里虚假的 +687%：为什么任何跨越 1 号的那一周都在撒谎

不是告警的告警

一个按周对比的自动成本报告触发了两个红色告警：Route53 +687%、EC2 +34%。本能反应是去追查什么暴涨了。但 AWS 成本的按周对比有一个结构性偏差：每当窗口跨越当月第一天，就会产生误报。

机制一：月度费用落在 1 号

AWS 的多项费用在 1 号一次性入账：No-Upfront 预留实例、Route53 托管区域、月费。如果你的"一周"包含 1 号，它就把整整一个月的费用与一个不含 1 号的周相比——对比自然爆表。

证据：看真实的月度成本而非周切片，Route53 实际下降了 -8.9%（18.00 → 16.40 美元），EC2 下降了 -19%（218.01 → 176.54 美元，一个 c5a.large 的 RI 到期了）。真实 BoxUsage 变化 < 0.5%。"+687%"是窗口造成的假象。

# 不要按周对比，改为按服务比较月度成本：
aws ce get-cost-and-usage \
  --time-period Start=2026-01-01,End=2026-03-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE --output table

# 并把 HeavyUsage（RI）与 BoxUsage（按需）分开——只有 BoxUsage 反映真实用量：
aws ce get-cost-and-usage --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE --output table

经验法则：只有当两周都不跨越 1 号时，AWS 成本的按周对比才可信。否则，看月度。

机制二：日历效应（31 天的月份）

第二个误报来源更微妙：每月有 28 到 31 天。一台 24×7 运行的按需实例，在三月（31 天）按比例比二月（28 天）花得更多。证明是算术：

c5.4xlarge 按需, 24x7:
  二月（28 天）: 456.91 美元
  三月预测（31 天）: 456.91 × 31/28 = 505.86 美元
  三月实际: 505.85 美元   ✓  （“涨”只是日历）

额外：把 Tax 归类成"Cost Explorer"的工具

同一份报告里，一项"Cost Explorer +1865%"很吓人——其实是税费（Tax）本身，被计费工具错误地标成了 Cost Explorer 服务用量。永远怀疑一个便宜服务"暴涨"：往往是归类错误，而非新增成本。顺便揪出真正的浪费——闲置的 Elastic IP：

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table

经验教训

1. 跨越 1 号的一周总会"上涨"。RI 和托管区域在 1 号一次性入账。拉响警报前先比月度。

2. 31 天的月份让按需成本虚增约 10%。在喊"涨了"之前按天数归一化。

3. 便宜服务"暴涨" = 归类错误。Tax 被标成 Cost Explorer（+1865%）是工具假象，不是成本。

结论

自动成本报告很有用，直到它变成恐慌制造机。两个机制——1 号入账与日历效应——几乎能解释所有虚假的周峰值。在叫醒团队之前，两条按月粒度的 Cost Explorer 命令就能显示真实方向。在这里，报告尖叫 +687% 的同时，账单其实在下降。