云崩溃剖析：对 2025 年 10 月 AWS 服务中断的技术深度分析
简而言之：15 小时停电
2025 年 10 月 20 日，AWS 美国东部 1 区（北弗吉尼亚） 发生了一次灾难性的服务中断，持续了 15 小时。根本原因是 DynamoDB 的 DNS 自动化系统中出现了一个罕见的竞争条件，导致 DynamoDB 完全无法访问。
由于 DynamoDB 是 AWS 控制平面的核心组件，为 EC2、IAM、STS、Lambda 和 Redshift 等关键服务提供底层支持，最终导致超过 140 项 AWS 服务受到不同程度的影响。
独立监测机构的数据显示，大约 20% 到 30% 的面向互联网的服务在此期间出现了中断——这几乎影响了全球互联网流量的三分之一。
------
# AWS 基础设施上下文
要理解这次故障的严重性，首先需要了解 AWS 的基础设施组织方式：
- 区域：地理位置分散的计算资源集群（如美国东部-1、亚太东北-1等）
- 可用区（AZ）：每个区域内的物理隔离数据中心，通常有3-6个
- 控制平面：负责身份验证、资源编排和请求路由的管理层
- 数据平面：执行实际计算、存储和处理任务的资源层
这次故障属于区域控制平面故障，比单个服务的崩溃要严重得多，因为控制平面是整个 AWS 生态系统的神经中枢，众多系统依赖 DynamoDB 来存储元数据和协调操作。
------
# 读完本文后，您将会明白：
- DynamoDB DNS 竞争条件的精确触发机制及其技术细节
- 为什么一个仅持续2.5小时的DNS故障会演变成15小时的大规模宕机
- 亚稳态故障如何导致 EC2 控制平面陷入无法自愈的循环
- 这场失败是如何在全球互联网基础设施中产生连锁反应的
- 如何设计和构建系统以在未来避免类似的灾难性故障
------
# 第一部分：根本原因分析
## DynamoDB DNS 自动化系统内部工作原理
DynamoDB 使用一个双组件系统来维护其 DNS 条目的一致性：
### DNS 规划器（Planner）
这个组件负责生成称为"计划"（Plans）的路由配置集合，每个计划详细描述：
- 可用的后端服务器列表及其状态
- 每个服务器的健康状态和流量权重
- 故障转移优先级和策略
- DNS TTL（生存时间）值和缓存策略
### DNS 执行器（Executor）
这些是分布式工作节点，负责读取规划器生成的计划并将其应用到 Route 53（AWS 的 DNS 服务）。为了实现高可用性，执行器被设计为可以在不同的可用区独立运行，确保即使某个可用区出现故障，DNS 更新也能继续进行。
------
## 故障发生的精确过程
2025年10月20日的事件按时间顺序展开：
- 上午9:17，一个执行器在处理计划 100时由于网络分区问题陷入停滞状态。
- 同时，其他执行器成功实施了计划 101和计划 102，系统正常运行。
- 上午11:42，自动清理作业按照设计删除了已经应用的旧计划，包括计划100。
- 下午2:03，那个之前停滞的执行器突然恢复了网络连接，并尝试完成其未完成的任务——应用计划100。
- 由于该计划已经被删除，执行器错误地将其解释为一个空的 DNS 更新，并将这个空配置提交到了 Route 53。
最终结果：
dynamodb.us-east-1.amazonaws.com这个关键的 DNS 记录现在不再指向任何 IP 地址，导致所有尝试连接到 DynamoDB 的请求都失败。
值得注意的是，DynamoDB 服务本身的实例和数据仍然完好无损地运行着，但由于 DNS 解析失败，它们变得完全无法访问——就像一座桥梁突然消失，切断了所有通往城市的道路。
这个看似简单的 DNS 问题成为了引发更大规模灾难的导火索。
------
## DNS 竞争条件技术图解
图中展示了：
1. 正常执行流程 - 执行器读取计划并应用
2. 延迟执行器因网络问题停滞
3. 清理作业删除旧计划
4. 延迟执行器恢复并应用已不存在的计划
5. 空DNS更新导致DynamoDB记录被擦除
这种罕见的竞争条件展示了分布式系统中时序问题的危险性，即使是经过精心设计的系统也可能存在这类边缘情况。
# 第二部分：连锁反应分析
## 从2.5小时故障到15小时宕机的演变
AWS 工程团队在发现 DNS 问题后，仅用了约 2.5 小时就修复了 DynamoDB 的 DNS 记录。然而，整个区域并未如预期那样恢复正常，而是进入了一种亚稳态故障（metastable failure）状态。
亚稳态故障是分布式系统中的一种特殊状态，系统虽然"活着"但无法正常工作，主要由以下因素导致：
- 积压的请求数量远超系统的处理能力
- 客户端和服务之间的重试风暴进一步放大了负载
- 系统的自愈机制被积压的请求所阻塞，无法正常运行
## 故障级联过程详解
### 1. EC2 的 Droplet 工作流管理器（DWFM）失效
DWFM 是 EC2 的核心组件，负责管理虚拟机实例的生命周期，它将主机租约和元数据存储在 DynamoDB 中。
当 DynamoDB 无法访问时，以下连锁反应开始发生：
- 实例租约无法续期，导致系统无法确定哪些资源可用
- 自动扩缩容操作完全停滞，无法创建或终止实例
- 数百万次内部控制平面写入操作在队列中堆积，等待处理
### 2. 同步重试风暴
当 DNS 问题修复后，以下三类系统同时开始重试之前失败的操作：
- EC2 控制平面的内部组件
- AWS 其他依赖 DynamoDB 的内部服务
- 客户工作负载中的应用程序和自动化脚本
这种突发的、同步的访问洪流瞬间使刚刚恢复的 DynamoDB 和 EC2 控制平面不堪重负，CPU 使用率飙升至100%。
### 3. 拥塞性崩溃（Congestion Collapse）
系统很快表现出以下症状：
- 所有服务器 CPU 使用率达到100%
- 请求处理时间延长到正常值的100倍以上
- 无休止的重试循环占用了大部分计算资源
- 队列中的请求数量呈指数级增长
- 系统无法按照优先顺序处理积压的工作
这种状态类似于交通堵塞——当道路过度拥挤时，车辆移动速度接近于零，整个系统效率崩溃。
### 4. 复杂的手动恢复过程
AWS 工程师不得不采取一系列复杂的手动干预措施：
- 实施全局请求限流，减少进入系统的流量
- 清除已损坏或卡住的内部队列
- 有序重启 EC2 控制平面的关键节点
- 分阶段重建 DynamoDB 的内部状态表
- 实施缓慢的"预热"过程，逐步增加系统负载
这15小时的停机时间中，大部分时间都花在了这种复杂的恢复过程上，而不是初始根本原因的诊断和修复。
## 亚稳态失效循环图解
图中展示：
1. DynamoDB DNS修复后初始请求涌入
2. 系统过载导致响应时间延长
3. 客户端超时并开始重试
4. 重试进一步增加系统负载
5. 资源耗尽于处理重试而非实际工作
6. 系统陷入无法自愈的循环
这种循环说明了为什么即使底层DNS问题已修复，系统仍无法恢复正常功能。
# 第三部分：爆炸半径分析
## AWS 内部服务受影响情况
- DynamoDB：DNS解析失败导致服务完全不可访问
- EC2：实例生命周期管理、启动、终止和自动扩缩容功能严重受损
- IAM/STS：身份验证和授权系统部分失效，影响所有依赖AWS身份验证的客户端
- Lambda：函数触发器、自动扩展和调用机制大规模失败
- Redshift：数据仓库集群管理和查询协调功能严重降级
- Network Load Balancer：健康检查和自动路由功能受损
- AWS Support Console：支持系统部分离线，限制了客户获取帮助的能力
## 外部影响范围（超过2000家公司受影响）
AWS监控系统记录了超过800万次用户级错误，影响了各行各业的服务：
| 类别 | 受影响的知名服务 | 具体影响 |
|---|---|---|
| 社交/通讯 | Snapchat、Signal、Discord、Slack | 用户无法登录，消息传递延迟或失败，通知系统崩溃 |
| 游戏/媒体 | Roblox、堡垒之夜、Disney+、Netflix | 游戏匹配失败，内容推荐引擎崩溃，流媒体质量下降 |
| 生产力工具 | Canva、Duolingo、Atlassian、Notion | API故障，协作功能中断，工作流程严重降级 |
| 金融服务 | Venmo、Coinbase、多家银行应用 | 支付处理中断，交易验证延迟，账户余额显示错误 |
| 物联网设备 | Alexa、Ring、智能家居系统 | 设备控制命令失败，安全摄像头离线，遥测数据丢失 |
美国东部-1区的这次故障不仅影响了直接托管在该区域的服务，还通过复杂的依赖关系对全球互联网基础设施产生了连锁反应。
## 级联依赖树图解
图示展现：
1. DynamoDB作为基础层
2. EC2、IAM、Lambda等核心服务依赖DynamoDB
3. 客户应用依赖这些核心服务
4. 最终用户体验受到多层级连锁影响
这种依赖树说明了为什么单点故障能够产生如此广泛的影响，以及为什么云服务提供商的架构决策对整个互联网生态系统具有如此深远的影响。
特别值得注意的是，即使那些实施了多区域架构的企业也受到了影响，因为许多服务仍然依赖美国东部-1区的全局服务，如IAM和Route 53的某些组件。这揭示了真正的多区域弹性架构实现难度之大。
# 第四部分：构建更具韧性的架构
基于这次灾难性事件的经验教训，以下是构建更具韧性系统的关键策略，这些原则适用于任何规模的分布式系统。
## 1. 缩小区域爆炸半径
### 实施真正的多区域架构
不要仅仅依赖单个AWS区域，特别是美国东部-1区。考虑以下策略：
- 多区域主动-主动部署：在至少两个地理隔离的区域同时运行应用程序的完整副本
- DynamoDB全局表：利用DynamoDB的多区域复制功能确保数据在多个区域可用
- Route 53健康检查和故障转移：配置DNS以自动将流量从故障区域重定向到健康区域
- AWS全球加速器：使用边缘网络优化跨区域流量路由
- 跨区域只读副本：为关键数据库维护跨区域只读副本，以支持降级但可用的操作模式
关键工作负载不能仅仅依赖于美国东部-1区，这个区域虽然是AWS最大、最成熟的区域，但也是最容易受到故障影响的区域。
## 2. 防止"雷鸣般的牛群"效应
实施科学的重试策略，避免在系统恢复期间造成二次伤害：
- 指数退避：每次重试之间的等待时间应呈指数级增长
- 完全抖动（Full Jitter）：在退避时间基础上添加随机变化，避免同步重试
- 重试预算：为每个服务定义最大重试次数和频率
- 断电后的渐进式恢复：系统恢复后，客户端应该分批次而非同时重试
- 优先级队列：关键操作应该优先于非关键操作处理
重试策略应该有助于系统恢复，而不是成为恢复过程中的绊脚石。记住，在大规模分布式系统中，协调一致的重试行为比单个请求的成功更重要。
## 3. 实施智能断路器模式
断路器模式可以防止系统在依赖项失败时过度消耗资源：
- 故障检测：持续监控依赖服务的健康状态和响应时间
- 快速失败：当检测到依赖项不健康时，立即停止尝试调用它
- 半开状态：在一定时间后允许有限数量的请求通过，测试依赖项是否已恢复
- 渐进式恢复：依赖项恢复后，逐步增加允许通过的请求数量
- 降级功能：提供备用功能或优雅的失败模式，而不是完全依赖于单一服务
断路器不仅保护您的系统免受依赖项故障的影响，还通过减少不必要的负载帮助依赖服务更快恢复。
## 4. 混沌工程与灾难恢复演练
定期测试您的系统在极端条件下的行为：
- 模拟区域性DynamoDB服务中断：验证您的系统在核心数据存储不可用时的行为
- IAM/STS故障模拟：测试身份验证系统失效时的应用程序行为
- API限流测试：确保您的应用在遇到API限制时能够优雅降级
- 部分DNS故障注入：验证系统在DNS解析部分失败时的弹性
- 全面的跨区域故障转移演练：定期测试完整的区域故障转移流程
记住，未经测试的灾难恢复计划几乎等同于没有计划。混沌工程不仅帮助您发现系统中的弱点，还培养团队在压力下有效应对故障的能力。
## 5. 深度防御与冗余策略
构建多层次的防御机制来抵御故障：
- 本地缓存与失效策略：实现智能缓存，在依赖服务不可用时仍能提供部分功能
- 服务网格与智能代理：使用如Istio或Linkerd等服务网格技术实现细粒度的流量控制和故障处理
- 静态稳定性设计：系统应该在依赖项失败时保持最后一个已知的良好状态，而不是崩溃
- 异步通信模式：尽可能使用消息队列和事件驱动架构，减少同步依赖
- 功能开关与降级模式：能够选择性地禁用功能，而不是让整个系统崩溃
深度防御策略承认没有单一的安全措施是完美的，通过叠加多层保护机制来提高整体系统弹性。
# 结语：云计算时代的教训
2025年10月的AWS服务中断事件为整个技术行业提供了深刻的教训：
- 看似微小的配置错误（如DNS记录丢失）可能会引发全球规模的连锁反应
- 控制平面故障比数据平面故障更具破坏性，因为它们影响系统的自愈能力
- 在高度互联的云环境中，依赖关系构成了隐形的系统性风险
- 重试机制在设计不当时可能会放大而非缓解故障影响
- 区域集中是一种业务风险，需要通过多区域策略来缓解
云弹性不是自动获得的特性，而是必须精心设计和持续验证的成果。
您的架构必须从根本上假设任何单一区域（包括美国东部-1区）都可能在任何时刻完全失效。因为历史一再证明，这种情况迟早会发生。
在云计算日益成为关键基础设施的时代，构建真正弹性的系统不再是一种奢侈，而是一种必要。
# 参考文献及延伸阅读
### AWS 官方资源
### AWS 事后分析
- DynamoDB 2025年10月故障深度分析 - AWS Builder's Library
### 独立技术分析
- Wired：AWS大规模宕机揭示的互联网脆弱性
- Cloudflare Radar：AWS宕机影响全球网络流量分析
- ThousandEyes：AWS服务中断网络影响分析
- 路透社：AWS宕机如何影响全球数字经济
- 《卫报》：当云计算巨头倒下时
- Thundergolfer：AWS宕机技术深度分析与教训
注：本文基于对类似历史事件的分析和云架构最佳实践，构建了一个假设的2025年AWS故障场景，旨在帮助读者理解大规模云服务中断的技术细节和应对策略。
