7 月 17 日，全球不少 AWS 用户登录控制台后发现，当月预估账单突然飙升至数百万、数十亿，甚至数万亿美元。一个平时每月费用不足 5 美元的账户，预估账单竟显示为 17 亿美元；一位 Reddit 用户晒出的截图显示金额高达 225,579,210,164.83 美元；还有用户的控制台甚至显示当月费用达到 7.1 万亿美元，这一数字已超过亚马逊市值的两倍。这些数字最终被证实全部属于错误数据，实际账单并未受到影响。不过，这起事故持续了超过 24 小时，而真正值得关注的并不是那些夸张的金额，而是事件暴露出的云成本管理问题。
根据 AWS Health Dashboard 公布的信息，事故始于 7 月 16 日 19:46（PDT）。当时，计费计算系统进行了一次配置变更，导致预估账单计算流水线出现了单价错误。真正值得关注的是 AWS 随后公布的一段说明：
7 月 16 日 19:46（PDT），我们的告警系统检测到了成本异常，但未能阻止预估账单生成流程，也没有通知工程团队。我们直到 7 月 17 日 00:19（PDT）收到客户升级反馈后，才意识到这一问题，并立即展开调查。
也就是说，告警已经触发，但预估账单仍在持续生成，值班工程师也没有收到任何通知。
直到四个半小时后凌晨 12：19，大量客户主动反馈异常，AWS 才意识到自己的计费系统出了问题。对于很多 AWS 用户而言，他们通常也是通过异常账单才发现自己的云成本失控。只是这一次，角色发生了互换——变成了 AWS 自己依靠客户发现了系统故障。
关于这次事故的根本原因，一位曾在 AWS 工作、处理过类似问题的 Hacker News 用户给出了自己的解释。他表示，这属于一种典型的计费单位（Unit）错误。
我以前就在 AWS 遇到过这种问题。当时原本应该按 5 美分/GB 收费，但由于漏掉了 GB 这个单位，计费系统默认按 字节（Byte） 计费。结果就变成了 每传输一个字节收费 5 美分，几个小时内就有客户收到账单金额达到数百万美元。当时凌晨两点左右客服通知了我，我在三四点前修复了问题，随后补发更正账单并发送了致歉邮件。
他进一步解释，AWS 的各项服务只会上报资源使用量（Metering Data），其中并不包含价格信息。真正决定收费的是计费系统中的 Pricing Plan，每一项计费规则都会指定对应的单位类型（Unit Type）。一旦单位配置错误，整个价格换算都会失效。相比之下，这次事故最大的不同在于响应时间。他当年遇到的问题，从收到告警到修复仅用了约两小时；而此次事故直到四个半小时后客户反馈，AWS 工程师才真正介入处理。
另一位 Hacker News 用户则从系统架构角度解释了，为何这类问题很容易逃过测试：
测试肯定做过，但缺少端到端测试。一套测试会验证新的计量系统是否正确生成计费记录；另一套测试则验证计费系统本身是否正常。但很少有人会把两个系统真正串起来测试，因为实现难度更高，而且通常属于不同团队负责。我已经在好几家公司见过这种情况。
随后，AWS 的应急处理方式又带来了新的讽刺意味。在尝试回滚配置变更未能解决问题后，AWS 于 8:24（PDT） 暂停了预估账单生成，因此控制台中的异常金额被直接“冻结”。与此同时，AWS 还关闭了 Budget 告警和 成本异常检测功能，以防止错误数据继续触发告警。这意味着，在事故持续期间，AWS 官方一直建议用户依赖的两项成本防护机制实际上都被平台关闭了。对于那些已经将成本告警接入 Slack、自动绑定 SCP，甚至自动关闭工作负载的企业而言，要么此前已经被错误数据触发自动化流程，要么之后完全失去了成本监控能力。
Hacker News 最初发帖的收到 17 亿美元账单的用户写道：
我平时每月费用不到 5 美元。我已经提交了紧急 AWS 支持工单。还有其他人遇到类似情况吗？
The Duckbill Group 首席云经济学家 Corey Quinn 在领英上调侃道：
我谈过价值数百亿美元的 AWS 合同，但从来没有帮任何客户把账单做到一万亿美元。Cost Explorer 团队却在一个晚上就帮成千上万个账户做到了。
Quinn 同时指出，这次事故也让 FinOps 团队陷入了两难境地。
请为昨天晚上收到“较基线增长 55,000,000,000%”异常告警的每一位 FinOps 从业者默哀。他们必须判断，这到底只是系统 Bug，还是 us-east-1 又发生了什么新的事情。
对于部分用户来说，这起事故的影响并不仅仅是虚惊一场。OpenValue 软件架构顾问 Piet van Dongen 表示，这些数字存在的时间已经足够让人行动起来了：
我收到预算超支的邮件通知，Cost Explorer 显示我的个人项目在 S3 上花了 369,188,086.24 美元。我真的相信了，大约十分钟都觉得是真的，还提交了支持工单。后来我把所有工作负载都删掉了，短期内应该不会再用了。
软件工程负责人 Daniel Blumenthal 则认为，他八百四十三万美元的预估账单事故再次暴露了 AWS 多年来一直存在的问题。
我第一反应是账号被盗了，感觉心脏病都快犯了。最可怕的是，你可以配置告警，却无法给账户设置真正的消费上限。
不过，许多人真正担心的，并不是这次几万亿美元这样一眼就能看出的错误。正如一位评论者所说：“如果 AWS 能因为 Bug 生成这么离谱的账单，那为什么不能因为另一个 Bug，多收一点点费用，而绝大多数用户根本不会注意到，最后直接付款？”荒谬的错误很容易暴露，而看起来合理的小额错误，却未必如此。
这起事件发生的时间也颇具讽刺意味。就在事故发生前几天，InfoQ 刚刚报道过云成本管理领域的另一个长期问题：AWS 的计费数据通常比真实资源消耗滞后约 24 小时；Budget 自动操作依赖的也是这些延迟数据；很多真实事故最终都是信用卡扣款通知先发现，而不是 AWS 自己的告警系统。
而这次事故恰好相反——数据更新得足够快，却完全错误；之前的问题则是数据准确，却来得太晚。但两者反映的是同一个问题：计费遥测本身也是一项基础依赖，而任何基于它构建的自动化成本控制机制，都不可避免地会继承它的所有故障模式。
AWS 最终修复了这一问题，并确认控制台显示的预估金额从未影响实际计费。截至目前，AWS 除了在 Health Dashboard 上公布事件时间线外，尚未发布更详细的事故复盘，也没有说明是否会针对此次暴露出的几个问题——包括告警未触发人工响应、配置回滚失败，以及平台级关闭预算告警——调整计费系统自身的安全保护机制。对于一个负责提醒全球用户“成本异常”的系统来说，一个仍未回答的问题是：当它自己出现异常时，又该由谁来提醒它？
原文链接：AWS Billing Bug Shows Customers Trillion-Dollar Estimates While Its Own Cost Alarms Fail to Act
