摘要
2026年7月16日，全球大量 AWS 用户登录控制台后发现当月预估账单异常飙升至数百万、数十亿乃至数万亿美元。AWS Health Dashboard 随后确认，事故源于计费计算系统的一次配置变更导致预估账单流水线出现单价错误。错误数据持续超 24 小时，但**实际账单未受影响**。事件暴露了云成本告警与计费流程的脱节。
时间线
2026-07-17 10:46 (UTC+8)计费计算系统配置变更，预估账单计算流水线出现单价错误（AWS 口径：7/16 19:46 PDT）
2026-07-17 15:19 (UTC+8)告警系统检测到成本异常，但未能阻止预估账单生成流程，也未通知工程团队（7/17 00:19 PDT 收到客户升级反馈后才意识到问题并展开调查）
2026-07-17 全天大量用户控制台显示预估账单飙升至数百万~数万亿美元，社交媒体广泛传播截图
2026-07-18AWS 修复流水线，预估账单恢复正常；官方重申实际账单不受影响
根因
计费计算系统的一次配置变更引入了**单价（Unit）错误**：本应按"5 美分/GB"计费，因漏掉 GB 单位，系统默认按"每字节（Byte）5 美分"计费，单价被放大约 9 个数量级。典型案例如月费不足 5 美元的账户预估显示 17 亿美元、Reddit 用户截图 225,579,210,164.83 美元、有用户显示 7.1 万亿美元（超亚马逊市值两倍）。
放大因素
- 成本告警已触发，却**未接入阻断逻辑**，预估账单生成流程继续运行
- 告警**未通知值班工程师**，直到 4.5 小时后客户主动反馈才被发现
- 错误账单通过控制台直接呈现给全球用户，引发大规模恐慌与舆情
- 单位（Unit）缺失类缺陷静默生效，缺乏计费结果的合理性校验/上限保护
缓解措施
- AWS 修复单价计算，恢复正常预估账单，并明确实际账单不受影响
- 事后需将成本告警接入"暂停/限流"动作，并补齐计费结果合理性校验（如金额上限、量级异常拦截）
经验教训
- 配置变更须覆盖下游消费者（计费流水线），不只是"改完即上线"
- 告警必须带动作闭环：能阻断、能通知，不能只产生一条无人看的记录
- 面向用户的数值（账单/额度）应设合理性边界与异常拦截，防止单位级错误放大为万亿美元级展示
- 参考来源：AWS Health Dashboard 事故说明；InfoQ 中文 https://www.infoq.cn/article/ogvAbgp1eFp6ddoommVh ；Reddit / r/aws 用户截图
检查清单
- 配置变更是否评估过对计费/展示链路的级联影响？
- 成本告警是否接入阻断或限流动作、是否通知到人？
- 面向用户的金额是否设上限/量级校验？
- 是否做过"单位缺失"类的故障注入与边界测试？