当未经检查的自动扩缩造成 12 万美元的云支出时

作者 | Daniel Dominguez

译者 | 刘雅梦

策划 | 丁晓昀

最近的一个关于云成本恐怖故事的 Reddit 帖子，在 LinkedIn 上引发了广泛的讨论，讨论的内容是一个真实世界的事件，其中一个集群在遭受 DDoS 攻击时自动扩展到 2000 个实例，仅在短短 72 小时内就产生了高达 12 万美元的惊人账单。

这起事件是所谓的“钱包拒绝”攻击（Denial of Wallet，DoW）的一个例子，它鲜明地提醒人们，不受监控的自动化会带来财务风险。受访者 amylamky 在帖子中发布了这样一个例子：

一家初创公司在 72 小时内烧掉了 12 万美元，因为自动扩展没有上限；DDoS 攻击出现后，集群启动了 2000 个 m5.24xlarge 实例，当有人解析 Slack 上的噪音时，账单看起来像一个电话号码。

基于这条评论，Zero Cloud Waste 的创始人 Mikael Almstedt 在 LinkedIn 上的一个帖子引发了一场围绕云财务管理教训的广泛讨论。此外，他还提供了一个关键的教训：“自动扩缩是一个强大的工具，但如果没有适当的护栏，它就是一张‘空白支票’”，并提供了一份基本的预防措施清单：

• 为每个自动扩缩组设置上限，以设定资源消耗的硬性限制。
• 将预算报警与账户级别的关闭绑定，以便在超过阈值时自动停止消费。
• 使用基础设施漂移检测来发现配置中的意外变化。
• 将消费报警连接到以人为中心的报警上，而不是依赖未读的 Slack 频道。

LinkedIn 上的帖子充满了来自开发人员、架构师和工程师的评论，很快就为这一核心问题添加了一层细微差别。AWS 的企业解决方案架构师 Tal Klinger 指出，虽然消费上限是一种有用的纠正措施，但它并不能解决根本问题。他认为主要问题是 DDoS 攻击本身，而解决方案架构师 Uros Zizek 建议的预防措施是应该有一个 Web 应用防火墙（Web Application Firewall，WAF）。Klinger 做了以下评论：“根本原因是 DDoS，症状是不断扩展。”

Klinger 的评论得到了其他人的呼应，他们认为这次事件是安全问题，而不是配置问题；它强调 AWS 在 共享责任模型 上运行，其中客户负责保护其应用程序。

讨论还揭示了实施硬限制的权衡。DevOps 工程师 Ben Shtark 评论了成本控制和系统可用性之间的“棘手权衡”。他写道：“在云消费上设置硬性货币限制，实际上会破坏你的生产系统。”他暗示，预算上限可能会阻止合法用户流量的激增，导致业务中断。从这个角度来看，共识是平衡软报警和自动审批与动态护栏。

此外，一些评论者指出，这个问题的根源在于云提供商的商业模式。软件 CI/CD 工程师 Niklas R. 将其与电话费进行了比较，指出如果没有预付费卡，就没有固有的限制。他和其他人建议云提供商应该提供严格的每日或每周成本上限。这与一个在 Azure 中有类似体验的用户的情况形成了对比，他能够与供应商和微软合作，以“折中差异”。

这一事件突出表明，FinOps 工具和服务的市场正在不断增长，旨在为现代云环境提供必要的护栏和可见性。从 AWS Cost Explorer 这样的云提供商原生工具，到 Apptio Cloudability 和 CloudZero 这样的第三方平台，这些产品通过以下方式帮助组织避免了 DoW 攻击：

• 成本可见性和异常检测，以快速识别和意外报警的消费激增。
• 通过预算上限和政策执行实现自动化治理。
• 优化建议，以正确调整资源并消除浪费。

最终，DevOps 社区的共识很明确：虽然自动扩缩是现代云架构的关键推手，但它必须与强大的 FinOps 战略相配合，以防止它成为财务负担。

原文链接：

https://www.infoq.com/news/2025/08/denial-of-wallet-attack-cloud/

声明：本文为 InfoQ 翻译，未经许可禁止转载。