7月17日，一些AWS客户打开控制台，发现账单预估突然多出几百万甚至二十多亿美元。这不是月底扣款通知，是控制台上实时刷新的预估数字，有人直接在Reddit贴出截图。
亚马逊很快确认，问题出在计费计算子系统，预估数字不代表实际用量和费用。真正该盯的不是这笔钱要不要还，是账单显示和预算告警这套机制，这次明显失真了。
AWS计费计算子系统故障：预估最高冲到25亿美元
故障从2026年7月16日夜里开始。亚马逊在AWS状态页公告，问题出在billing computation subsystem——计费计算子系统，负责把用量换算成金额，再推送给控制台和预算告警。
工程团队先回滚了最近一次变更，这是常规操作。到7月17日早上，亚马逊确认回滚没能解决问题。具体原因官方没有细说，状态页给出的预计是还要再持续数小时。
各账户看到的预估数字差异极大：
| 案例类型 | 预估账单规模 | 说明 |
|---|---|---|
| 最高公开案例 | 接近25亿美元 | Reddit流传截图，单一账户本月预估 |
| 其他多个账户 | 数百万至数亿美元 | 区间跨度大，无统一规律 |
| 正常水平 | 通常几美分至几十美元/小时 | 按实际资源用量计费 |
亚马逊明确表态：这些数字不代表实际用量和费用，不是已经出账，更不是已经扣款。受影响客户目前不用为这些数字掏一分钱。
官方没有公布受影响账户数量，也没说清楚Cost Explorer里的实际用量记录是否被同一条计费链路连带影响。这一点，接下来值得继续盯。
为什么重要：受伤的是账单和预算告警的可信度
这次故障和常见的“云账单爆炸”不是一回事。企业上云最常见的账单异常，是资源被误配置、脚本失控或者账号被盗刷，本质是用量真的涨了。
这次不一样。用量没变，底层资源该怎么跑还怎么跑，出问题的是把用量换算成金额、再推给控制台的那套计算逻辑。
FinOps团队平时靠预算告警自动止损，费用超过阈值就报警，严重时甚至自动停服。这套机制的前提是账单数字可信。计费计算子系统本身出错，说明这个前提不是永远成立的。
谁受影响，该怎么做
对负责成本控制的云运维和FinOps团队，眼下能做的是交叉核验，不是恐慌：
- 打开Cost Explorer核对实际用量记录，和控制台预估账单做对比
- 检查资源本身有没有异常扩容或异常调用
- 三者对不上号，大概率是这次故障的连带反应，暂时不用触发自动停服或冻结预算
对审批云预算、处理异常账单的财务负责人，关键动作是不按异常预估付款或冻结账户，先等IT核实。收到异常告警邮件，建议截图留存，必要时联系AWS支持核验状态，留作日后对账或申诉的记录。
亚马逊目前没有公布受影响客户数量、故障最终持续了多久，也没有给出根因和后续说明。接下来最该盯的，是修复后亚马逊会不会公开一份说清楚“为什么算错”的复盘，而不是一句道歉。