
10 月 19 日和 20 日,亚马逊云科技公司(AWS)经历了一次长时间的中断,原因是亚马逊 DynamoDB 故障,影响了其最受欢迎的北弗吉尼亚地区的大部分服务。这家云提供商发布了一份对该事件的分析报告,引发了社区对 AWS 冗余、退出公有云以及多区域方法的讨论。
根据事后分析报告,该报告提供了 DynamoDB DNS 管理架构的详细信息,事件是由服务的自动 DNS 管理系统中的潜在缺陷触发的,导致 DynamoDB 的端点解析失败。其他依赖 DynamoDB 的流行服务,包括新的 EC2 实例启动、Lambda 调用和 Fargate 任务启动,也在中断期间受到影响。在对美国东部 1 区 Amazon DynamoDB 服务中断的总结中,团队承认可靠性问题严重影响了许多客户。他们写道:
这个问题的根本原因是 DynamoDB DNS 管理系统中存在的潜在竞态条件,导致服务区域端点(dynamodb.us-east-1.amazonaws.com)的错误空 DNS 记录,自动化无法修复。
虽然事件报告关注特定的 2 或 3 小时的时间段和服务,但对许多客户的影响持续时间要长得多,一些客户报告问题持续了长达 15 小时。虽然在许多在线讨论中开发者开玩笑说“总是 DNS”,但 AWS 英雄和无服务器专家Yan Cui在他的简报中强调:
DNS 故障是最近 AWS 宕机的第一个症状,而不是根本原因。根本原因是 DynamoDB 内部微服务中的竞态条件,该微服务为 DynamoDB 的区域单元自动化 DNS 记录管理。
在中断期间,新的 EC2 实例在虚拟化层面被创建,但它们的网络配置从未完成。此外,新启动的 EC2 实例的网络状态传播延迟也对网络负载均衡器服务和所有依赖它的服务产生了连锁影响。CloudZero 研究主管 Jeremy Daly写道:
好消息是什么?一切都恢复正常了。坏消息呢?人们对此失去了理智,认为通往车库的 T1 线路会更有弹性。
AWS 还没有解决竞争条件的问题,但是由于这次宕机,AWS 正在计划进行一些短期和长期的更改。该团队写道:
我们已经在全球范围内禁用了 DynamoDB DNS Planner 和 DNS Enactor 自动化。在重新启用此自动化之前,我们将修复竞态条件场景,并增加额外的保护措施,以防止应用错误的 DNS 计划。对于 NLB,我们正在添加一个速度控制机制,以限制单个 NLB 在健康检查失败导致 AZ 故障转移时可以移除的容量。
此外,云服务提供商计划改进 EC2 数据传播系统中的节流机制,根据等待队列的大小对传入工作进行速率限制,以在高负载期间保护服务。
在一篇广受欢迎的LinkedIn帖子中,ERGO Technology 的 DevOps 顾问 Roman Siewko 认为,尽管中断影响了众多大型提供商并受到了广泛关注,但实践者在做出改变之前也应该了解历史和实际数字。Siewko 评论道:
2025 年 10 月 20 日发生的大约 15 小时 AWS 中断给人留下了深刻印象。相比之下,很难将其与前几年近乎无声的可靠性进行比较。(...)大多数时候,它更接近四个九。截至 2025 年 10 月 25 日,滚动数字是 99.84%(1 年)和 99.95%(5 年)。
Rebase 的联合创始人兼首席执行官 Mudassir Mustafa补充道:
在可靠性工程中,记忆偏差往往大于数据偏差。团队对罕见事件反应过度,但对保持年复一年正常运行时间稳定的缓慢、无形的工作投入不足。
AWS事件历史记录跟踪所有受影响的服务及其时间线。
原文链接:
https://www.infoq.com/news/2025/11/aws-dynamodb-outage-postmortem/








评论