AWS 计费惊现 17 亿美元乌龙，单位错误引发巨额账单

事件概述

近日，多位 AWS 用户在 Hacker News 上报告称，其 AWS 管理控制台中显示的月度账单估算金额高达 17 亿美元，而他们的正常使用量通常不到 5 美元。这一异常情况迅速引发了广泛关注，用户纷纷创建紧急支持工单寻求解决。有用户指出，类似问题此前已在 Reddit 上被讨论过。

前员工揭秘：单位错误是根源

一位前 AWS 员工在评论中详细解释了此类错误的常见原因。他表示，这通常是一个单位错误（unit error）。在他亲身经历的一个案例中，团队本意是按每 GB 收费 5 美分，但在配置计费系统时遗漏了单位（GB），导致系统默认以字节为单位计费。这样一来，每字节 5 美分的价格使得数据传输费用在数小时内飙升到数百万美元。该员工回忆，他在凌晨 2 点被支持团队呼叫，经过紧急修复和修正账单，到凌晨 3-4 点问题才得以解决，随后发送了道歉邮件。

他进一步说明，AWS 的服务会发出计量值，这些值并不直接与价格挂钩。每个 SKU/计费项目都在一个“定价计划”中定义，包含单位类型、区域和每单位价格。计量记录会根据账户 ID、区域、SKU 等信息与定价计划进行关联。如果定价计划中的单位类型配置错误，计量数据转换就会失效，从而产生离谱的账单。

测试流程的缺失

评论中，多位用户对 AWS 的测试流程提出了质疑。有用户问道：“没有测试吗？就搞错了一个微不足道的细节，结果导致数十万管理员被惊醒和心脏病发作？”

另一位用户分析认为，AWS 很可能存在测试，但缺乏端到端测试。例如，团队 A 会测试新系统是否按预期发出计费条目（如“我们做了 100 字节操作，看到计费系统记录了 100 字节”），团队 B 会测试计费系统是否正确计算费用（如“我们为 SKU#12345 提供 100 GB 单位的账单，看到费用为 17 美元”）。然而，这两个测试很少被组合在一起进行，因为跨团队协作难度大，且管理链条不同。该用户还指出，曾有人提议“测试应该实际产生费用”，但被以“法律/会计问题，甚至可能是犯罪”为由否决，之后也无人追问替代方案。

有用户建议，如果系统支持多币种计费，可以使用 ISO 4217 代码中的测试货币（XTS）来进行测试。

异常检测的缺失

除了测试问题，评论还批评 AWS 缺乏基本的异常检测机制。有用户表示：“甚至不需要测试，只要有一些基本的异常检测就行。比如，如果账单金额增加了 1000 万倍，应该有人去调查一下。”

对此，有前员工回应称，在亚马逊这样的大公司，当一切以“棍棒”而非“胡萝卜”驱动时，工作文化并不鼓励员工主动关心产品质量。与其提前预防问题，不如让问题发生，然后在凌晨 3 点成为“救火英雄”，这反而更有利于个人绩效和职业发展，尤其是对于持有 H1B 签证的员工而言。

内部流程与激励机制

然而，另一位前亚马逊员工反驳了这种观点。他表示，任何导致客户影响的事件都会触发 COE（错误纠正）报告，这需要团队投入大量人力进行整改，并且会在高层会议上被随机抽查，对管理者而言是巨大的麻烦。因此，COE 机制实际上创造了强烈的预防动机。

但更多评论指出，亚马逊内部不同组织之间存在巨大差异。一位前经理透露，COE 报告通常只能解决单个团队能力范围内的问题，如果问题涉及跨团队的战略优先级调整，就会触及总监和副总裁的“面子”，从而被掩盖。

一位前 IC（个人贡献者）则详细描述了亚马逊绩效评估中的“强制分布”问题：无论团队整体表现如何，每年都必须有一定比例的人被评定为“LE”（低绩效）。在这种激励结构下，员工没有动力去默默修复潜在的 bug，因为“预防火灾”看起来不像“工作”。相反，让 bug 先暴露，然后在 SEV（严重事件）中跳出来修复，才能获得管理层的认可。这种“幸存者游戏”式的竞争文化，从根本上阻碍了团队协作和问题预防。

总结

此次 AWS 计费乌龙事件，表面上是单位配置错误导致的技术故障，但深层次反映了大型云服务商在测试流程、异常检测和内部激励机制方面的系统性缺陷。尽管 AWS 拥有 COE 等事后复盘机制，但跨团队协作的壁垒、绩效评估的强制分布以及“救火英雄”文化，都可能成为预防类似问题的障碍。对于用户而言，定期检查账单并设置预算警报，仍是避免被巨额账单惊吓的必要措施。

原标题：AWS: Inaccurate Estimated Billing Data – $1.7 billion。 HN 原始发布时间：2026年7月17日星期五。当前记录为 1094 分、660 条评论。

阅读原文 · 查看 HN 讨论