← #802

Ask HN：有人遇到 AWS 账单问题吗？亚马逊预测我要花 30 亿美元

文章摘要

这是 2026 年 7 月 16 日至 17 日 AWS 一次账单显示故障在 HN 上留下的记录。发帖人收到了一封 AWS Budgets 预算告警邮件，提示预算超过了告警阈值——阈值是 5 美元，而预测金额显示为 $3,005,575,870.47，也就是三十亿美元。他过去一年根本没有活跃使用 AWS，但控制台上就是这个数字。AWS 人工支持还没回应，支持 AI 聊天机器人用德语回了一句：「自 7 月 1 日起每日成本完美均匀，这强烈暗示是一个计费或计量错误。」机器人说它建了一张支持工单（至少它这么声称）。发帖人已经禁用了所有 IAM 角色、删掉了自己知道的所有 AWS 资源，也确认登录没有被入侵，但「欠亚马逊三十亿美元还是有点让人担心」。

这个帖子本身的评论被 HN 管理员 dang 合并到了同期一个更大的主帖（「AWS: Inaccurate Estimated Billing Data – $1.7 billion」，1317 分、753 条评论），下面的精华来自那里。整个事件的规模在评论区呈现得非常清楚：几百位用户报出了从几万到几十万亿美元不等的估算账单，而他们的正常月账单通常在 0.03 到 100 美元之间。

AWS 官方状态页面的时间线是：7 月 16 日 19:38 PDT 开始，Billing and Cost Management 控制台开始显示错误的估算账单数据；7 月 17 日 03:03 PDT，AWS 确认根因是「估算账单计算子系统内的单位定价问题」，正在做缓解，并明确说明「显示的账单估算不反映实际使用和费用」，客户无需采取任何行动。评论区里流传的技术猜测是：原本表示「消耗的存储 GB 数」的字段被当成了「消耗的存储字节数」，导致 2^30 倍（约十亿倍）的偏差——这个数量级和大家看到的账单倍数吻合。

事件本身很快被修正（有人在两小时内看到账单从 368 亿美元回到 0.17 美元），但这个帖子真正有价值的部分是它暴露的两个结构性问题：一是 AWS 至今不提供硬性支出上限（hard spend cap），让「账单恐惧」成为爱好者和小型账户长期悬着的心事；二是这类明显荒谬的错误竟然能一路进到生产环境，说明计费系统缺少任何形式的方差熔断或异常检测。

HN 评论精华

everforward（最有分量的技术批评）：这次特别糟糕，因为偏差大到「我震惊它没有被测试、没有被计费系统的异常变动告警、甚至没有被财务发现。P&L 报表现在肯定各种不对，利润率得显示成 600 万 %、收入得用千万亿来计量。」他更惊讶的是这没有触发任何熔断：「对于像计费这种完全不需要实时的东西，我很惊讶他们没有一个自动 kill switch，在账单方差飙升时暂停计费系统并触发 page。」他给了个朴素的例子：如果本年度客户账单的标准差变化超过 50%，就暂停计费系统。以 AWS 的客户量，这些数字本该相当稳定。
TrickyRick（合理猜测）：这个 bug 大概在「显示」那一层，和「实际从客户账上扣钱」的那一层大概是分开的。可以想象「实际扣钱」那部分是有闸门的，尤其是对我们这种约 3000 亿美元的账单——「那是 AWS 2025 年全年收入的 2.5 倍。一个月内。如果我们真的累积了这个账单，付不出来的时候有麻烦的会是他们。」
dabinat：「这对亚马逊很尴尬，但我随时愿意要『错得可笑』而不是『错得微妙』。如果这个 bug 让账单高 20%，我大概根本不会去质疑它。」
fian（这次事件的真实后果）：这大概会推动他彻底关掉几个当年为了考认证而开的 AWS 账户。他现在什么都没跑、也没有计划跑。「我一直有一种轻微的恐惧，怕突然收到一张不是 0 美元的账单。如果 AWS 能以这种方式搞出明显巨额的账单（像今天这样），谁能保证他们不会以更微妙的方式搞错，开始多收一些很多人根本不会注意、直接就付了的小额费用？」
throwaway_5753：即使一旦停下来考虑数量级就知道明显是 bug，还是被吓到了。「非常不友好的一点是他们不允许设置硬性支出上限。我因此关掉了我那个基本闲置的个人账户。」
krawat3：他收到 2.33 亿美元的账单邮件、月底预测 4.33 亿。「我慌了，把整套配置全炸了（本来也没怎么用，告警阈值是 1 美元）——我真的很想知道有多少人做了同样的事。两小时过去了，我还是没完全平静下来。」
pfshort：11.7 亿美元。「吃我这一记，科威特的 GDP！但说真的，我这辈子没这么拼命想给 AWS 打通电话。找到支持页面上那条横幅之前的十分钟极其恐怖。它应该放在 dashboard 的正中央，而不是藏起来。而且应该是黄色的。」
pqvst：平时不到 1 美元，突然变成 $284,006,266,443.74。「这大概是我离心脏病发作最近的一次。不管他们那边是什么 bug，这不可原谅。」
dirkk0：「我还在震惊中。花了十分钟才在 dashboard 里找到那条『运营问题』的提示。我人生中最长的十分钟。」
rvz（本帖最尖锐的一句）：「我预计这类事故会继续发生。所以请继续 vibe coding。」这条引出了整个帖子最大的一条支线讨论。
lukaslueg：他给出了那个流传最广的技术解释（GB 被当成字节），并配了一段模仿 LLM 的自白：「你质疑我的计算是对的。我尝试查字段定义时 MCP server 连接失败了。我猜了一个，而没有去验证。这是我的错。但看看这营收！」
stefan_（接上）：「Vibe code 了计费系统，营收提升 9000%。升职材料写起来太棒了。」
raverbashing：「AI slop。或者只是一个分心的开发者。」root-parent 反问：「那也是一个分心的测试者？和一整条分心的回归测试流水线？不，真相要糟糕得多……」ethin 补刀：「你在假设他们还有测试者和回归测试流水线。」
anvuong（最具体的行业观察）：「是的，真相是当人们开始每天提交十几个附带 AI 生成代码评审的 PR 时，没有人在意。我现在的工作场所正在发生这件事：Sr/Staff 用 Claude 生成十页设计文档，Jr 用 Claude/Cursor 基于这份文档生成一个巨大的 commit 并开 PR，然后一堆自动化的 AI 代码评审启动、说这看起来不错，另一个 Sr/Staff 瞥一眼盖个橡皮章，同时盯着公司股价和/或 OpenAI/Anthropic 的招聘要求。这是一场闹剧。」
pixl97（提供平衡视角）：「过去三十年我见过的错误数量似乎表明，人类不在意造成的问题和 AI 使用一样多。把人类懒惰归咎于 AI 很容易，但我确实认为它对我们来说是自然的。」lenkite 补充：「一旦失去所有权就失去兴趣。AI 让这件事被极大加速了。现在这是个规模问题。」
27183：无论如何这都说明他们的 QA 和测试流程不合格。「对于像 AWS 这样的公共设施，『快速前进、打碎东西』是不可接受的。这应该让你质疑用他们的任何服务是否安全或明智。」他甚至认为如果他们会做出这种事，银行、医院、政府或任何关键基础设施托管在 AWS 上都不该合法。
poly2it（技术改进建议）：「这个错误可以通过更好的类型系统避免。如果你在计费系统里对 GiB 做计算，就要确保它只能被 GiB 类型修改。」
ihateolives（一个应景的小故事）：他当天给本地 agent 一个 CSV（列出一堆文件和人类可读的大小单位），让它统计每个 GB 区间的行数。听起来足够简单，但它完全算错了，因为不知为何把 MB 解析成了 GB。「事后看，用 Excel 反而更快。」dabbz 给出经验：「我发现更好的做法是让 AI 写一个确定性脚本来做这类计算——任何操作数据的东西都应该是脚本，而不是 AI。」
saghm（半开玩笑的制度设计）：「应该立法规定他们必须把超出正确账单的金额作为赔偿付给你。我打赌这之后他们会很快停止犯这种错误。」
akerl_（对集体诉讼的现实提醒）：「你的损失是什么？他们并不会真的从你的信用卡上刷走 340 亿美元。」他后来补充：「『我在一个周五早上被吓了几分钟，直到看到厂商状态页』，这和门槛之间差了好几个数量级。」但 Neikius 提出了一个不好笑的疑问：「我在想有多少人看到这个之后心脏病发作了。」
AegirLeet：「也许这是一个让人们终于去锁紧自己那些老旧闲置 AWS 账户的新策略。对我来说确实奏效了。」
ruddct：「如果你欠银行 100 美元，那是你的问题。如果你欠银行 17 亿美元，那是银行的问题。」
glenstein（一个真诚但危险的建议）：「最安全的做法大概是全额付款以保持良好信用状态，然后等他们下调之后退回差额。」
dv_dt（阴谋论视角）：「我愤世嫉俗地想，这会不会成为一次针对未来涨价的（无意或有意的）锚定练习。」
yuchen20：连收三封邮件警告预算超过 18 美元阈值。打开一看：7800 万美元。「以为是钓鱼，登录真正的账户，还是 7800 万。EMOTIONAL DAMAGE。」