2026年7月17日，一个AWS用户像往常一样打开账单页面，想确认一下这个月的云服务花了多少钱——正常情况下，他每个月付给AWS的钱不到5美元。但屏幕上跳出来的数字是：$1,700,000,000——十七亿美元。
这个用户名叫nprateem，他在Hacker News上发帖说：“这个月的预估账单是17亿美元。正常月费不到5块钱。已经在紧急工单里联系AWS了。还有人也这样吗？”
他不是一个人。同一时间，全球各地数百个AWS用户看到了类似的天文数字。有人在Reddit上晒出截图，说自己上月账单只有0.19美元，现在预估变成了将近25亿美元。还有人在X（前身Twitter）上写道：“我刚在AWS账单上看到1.5万亿美元，我的灵魂离开了我的身体。”
AWS的健康面板上，一条橘黄色的”运营问题”公告赫然在列：“预估账单数据不准确。“这家全球最大的云计算公司用了90分钟确认了根因，又花了将近一整天修复。而根因，用一位前AWS工程师的话来说，是一个”单位错误”。
漏掉两个字母，账单膨胀十亿倍
前AWS工程师donavanm在Hacker News评论区详细解释了内情。他在AWS工作时，亲身经历过完全一样的故障。
他的解释翻译过来是这样的：AWS内部有一个叫”定价计划”的东西。每个服务项——比如数据传输、存储、计算——都定义在这个计划里，包含单价、地区、以及一个关键字段：计费单位。
打个比方，就像你在超市买大米。标签上写着”5元”，但漏写了是”5元/斤”还是”5元/粒”。如果是5元一斤，你买20斤花100块。但如果是5元一粒，你买20斤大米可能要花掉几百万。
AWS这次的情况就是：系统里某处本该写”$0.05/GB”（每GB收费5美分），但”GB”这个单位被漏掉了，计费系统默认按”byte”来算——5美分每byte。1个GB等于大约10亿个byte，所以同样的数据传输量，账单暴涨了10亿倍。
donavanm说，他在AWS时遇到过一模一样的事：“凌晨两点被支持团队紧急叫醒，三点到四点修好，然后赶紧发道歉邮件。“看来这个错误在AWS内部至少发生过不止一次。
图：手机上的AWS健康面板应用界面。来源：Yahoo/TechRadar
一个没人能完全理解的计费系统
到这里，一般读者可能会问：这么明显的错误，难道没有测试？没有审核？没有任何人检查吗？
donavanm的解释值得细读。他写道，AWS的计费系统是一个多层级的匹配引擎，远比一张价格表复杂。服务产生的是”计量数据”（比如你传了多少数据），这些原始数据本身不带价格。系统需要用账户ID、区域、服务代码等多维信息去匹配”定价计划”，找到对应的单价和单位，然后计算账单。
“搞错定价计划里的单位类型，计量数据转换就失效了，然后你就看到了疯狂的账单。”
这意味着什么？这意味着一个在AWS工作过的人也在说：这个系统复杂到出错的方式本身就很隐蔽。一个漏掉的单位字段，不会让系统报错，不会触发任何告警。它只是默默地、无声地把所有用户的账单乘以十亿倍。等到用户发现，已经是第二天早上了。
一些HN用户把这个故障比作金融交易里的”胖手指”——交易员不小心多按了一个零，导致市场瞬间暴跌。但AWS这次的事不是一个人按错了键。这是系统设计层面的脆弱性：一个全球基础设施的计费引擎，对一个缺失的单位字段完全没有防御能力。
二十年前，你把一张CD放进电脑，它要么能读要么不能读——不存在”算错价格”这回事。但今天的云服务已经变成了一个账单维度多到你无法穷举的东西。不仅AWS如此，Google Cloud、微软Azure同样有复杂的定价结构。一笔月度账单里可能包含几十种不同的计费项，每一种都有不同的单位、不同的阶梯价格、不同的折扣规则。
这就是笔者的核心判断：云的计费系统复杂到了没有人能完全理解的地步，包括构建它的人。
图：AWS数据中心内的技术人员。来源：Crypto Briefing
实际扣款没事——但信任少了点什么
AWS在公告中强调，受影响的只是”预估账单”——就是账单页面显示的预测数字，不是实际扣款。用户的真实用量记录和实际收费没有出错。AWS暂停了预估账单的更新，重新计算了所有数据，预计在周六中午（太平洋时间）完成修正。
从工程角度看，这算是一个”还好只是显示错误”的事故。但如果我们跳出工程视角来看这件事，问题就不一样了。
当一个普通用户——开小公司、做个人项目的用户——在早晨的账单页面上看到17亿美元时，他脑子里想的是什么？他可能根本分不清”预估”和”实际”的区别。他看到的是”你要付17亿”，然后疯狂删服务器、关服务、毁数据。Reddit上确实有用户写道：“不用说，我慌了，把这个账户上的一切都毁掉了。”
而且，云账单恐惧症不是一个新问题。在Reddit的AWS板块上，关于”莫名其妙被扣款”的帖子几乎每天都有。有些确实是用户的配置错误，有些是免费试用期结束后的自动扣费，还有些——像这次——是AWS自己出的问题。但对于一个非技术用户来说，他怎么知道是哪一种？
笔者不是在指责AWS。“预估不等于实际扣款”这个信息在健康面板上写了，AWS也承诺会修正。但这就引出了一个更深层的问题：云的信任模型建立在”账单正确”这个基本前提上，而当这个前提动摇时，用户感受到的除了惊吓，还有一种更深的无力感。
在Hacker News那条帖子的六百多条评论里，有一个高频出现的词：“trust”（信任）。人们讨论的不是AWS的技术能力——没有人质疑亚马逊的工程实力。人们讨论的是：当你的基础设施账单可以因为一个单位字段的缺失而从5块跳到170亿时，晚上怎么睡得着？
这不是第一次，也不会是最后一次
如果把视野拉远一点，这件事其实是一类系统性问题的缩影。
AWS是全球最大的云服务商，市场份额超过30%，年收入超过900亿美元。它上运行着无数你每天使用的服务——Netflix的剧集、Uber的打车、甚至很多政府系统。它的定价模型之复杂，已经催生了专门的”云成本优化”行业——有一整个生态的公司，唯一的业务就是帮助其他公司搞清楚自己的AWS账单。
但这件事说明，连AWS自己都无法完全掌控自己的计费系统。donavanm在AWS工作时就遇到了同样的故障，说明这个漏洞存在了至少数年而没有被系统性地堵上。
这不是”亚马逊不行”的问题——把任何一家公司扔到同样的规模、同样的复杂度下，结果也未必更好。但这个事实本身就是一个值得思考的判断：我们正在把越来越多的关键基础设施交给一些复杂到连构建者都无法完全理解的系统。
图：AWS云服务计费系统故障概念图。来源：The Next Web
最后
用户nprateem的帖子里有一句话值得注意。他在描述了自己的17亿账单之后说：“Obviously have created an urgent AWS support ticket.”——“当然，我已经建了紧急工单。”
这句”当然”很有意思。一个用户看到17亿账单，第一反应是默默地去建工单——他甚至不去怀疑这个数字。因为他知道，在云的世界里，这种离谱的事有时候是真的——有时候你真的会因为一个配置失误而欠下天价账单。
而这次，虽然不是用户的错，但也并没有让他更安心。这个系统太复杂了，复杂到每个人都在猜测：下一次离谱的数字背后，到底是系统bug，还是我真的欠了这么多钱？
参考链接：
- AWS Health Dashboard 事件报告
- HN 讨论 (item?id=48945241)
- 前AWS工程师 donavanm 的技术分析
- The Next Web 报道
- Yahoo/TechRadar 报道
- Crypto Briefing 报道
配图说明：本文配图来自The Next Web、Crypto Briefing和Yahoo/TechRadar的新闻报道。HN讨论页及AWS Health Dashboard均为纯文本页面，无可用的尺寸≥200px的内容配图。HN页面仅含1×1像素的s.gif占位图和18×18的SVG logo；AWS Health Dashboard页面为纯文本状态列表。
