AWS崩了，官方复盘来了！

背景

2025年10月20日，亚马逊云服务（AWS）发生大规模宕机事故，影响范围广泛，涉及多个领域和地区的数百万用户及企业。

互联网平台与应用

• 社交媒体：Snapchat、Reddit等平台出现服务中断，用户无法发送消息、浏览内容或登录账号。
• 金融科技：Robinhood、Coinbase、Venmo等金融交易平台无法进行交易、转账或登录，影响用户资金操作。
• 在线游戏：《堡垒之夜》《罗布乐思》等游戏服务器瘫痪，玩家无法登录或游戏中断。
• 工具与服务：Canva设计工具、Zoom会议系统、多邻国学习平台等出现故障，影响用户正常使用。

企业与商业服务

• 电商与物流：亚马逊平台的卖家中心功能瘫痪，卖家无法处理订单、编辑商品信息或结算。
• 企业办公：依赖AWS的企业级应用（如企业内部系统、客户关系管理工具）出现故障，影响工作效率。
• 教育领域：Canvas等在线教育平台无法访问，学生无法上课、提交作业。

智能家居与物联网

亚马逊Alexa语音助手、Ring智能门铃、智能车库门等设备无法正常工作，用户无法通过语音控制家电或查看监控。
政府与公共服务

苏格兰银行、英国税务海关等政府机构的在线服务受影响，用户无法进行网上银行操作、查询税务信息等。

全球范围影响

故障主要集中在AWS的美国东部1区（US-East-1），但因该区域是AWS的核心节点，影响波及全球多个地区，包括美国、英国、荷兰、澳大利亚等国家的用户。

• DynamoDB是亚马逊云服务（AWS）提供的一种完全托管的NoSQL数据库服务，主要用于存储和管理大规模、高并发的应用程序数据。
• Route 53是亚马逊云服务（AWS）提供的一种高可用、高扩展性的云DNS服务。

原因分析

技术层面原因

• DNS解析故障
  根本原因是AWS的DynamoDB服务的DNS管理系统中存在竞态条件（race condition）。两个DNS执行器在更新DNS记录时出现时间上的巧合，导致DynamoDB的区域端点DNS记录被错误地清空，使得客户端无法将域名解析为正确的IP地址，进而引发服务中断。

• 服务依赖链级联故障
  DynamoDB是AWS内部多个服务（如EC2、IAM、NLB等）的基础依赖。DNS解析失败后，依赖DynamoDB的服务无法正常工作，触发了级联故障。例如，EC2实例启动依赖DynamoDB存储的元数据，DynamoDB故障导致EC2实例启动失败；NLB的健康检查依赖DynamoDB记录状态，故障后健康检查失败，进一步影响服务可用性。

• 网络配置与重试风暴
  新实例启动后，网络配置传播延迟导致NLB健康检查异常，引发可用区级别的自动DNS故障切换。同时，DNS查询失败后，大量客户端（如Lambda函数、其他AWS服务）因UDP协议的无状态特性，在超时后重试，形成“重试风暴”，二次冲击DNS服务器和缓存，延缓了恢复进程。

管理层面原因：

• 人才流失与经验缺失
  AWS近年大量资深工程师离职，带走多年积累的系统运行知识。人才流失导致团队应对复杂故障的预防和处理能力下降，对系统整体性的认知和快速响应能力减弱。

• 架构设计与冗余不足
  AWS核心区域（如us-east-1）过度集中部署关键服务，缺乏足够的冗余和故障转移机制。单一服务故障易通过复杂的服务依赖链迅速放大，影响整个区域甚至全球服务。

• AI工具过度依赖与决策延迟
  过度强调AI工具加速开发，可能弱化了对系统整体性的认知。在故障处理时，团队因缺乏现成应急方案，决策和响应速度较慢，如重启关键组件的决策延迟了100分钟。

以下是官方发布的原文，作者做了简单翻译和汇总：

AWS 北弗吉尼亚 (us-east-1) 区域服务中断事件（2025 年 10 月 19-20 日）

事件时间线

• 10 月 19 日 23:48（PDT）：DynamoDB DNS 系统故障引发区域服务中断。
• 10 月 20 日 02:25（PDT）：DynamoDB 恢复，但 EC2 实例启动和网络配置问题持续。
• 10 月 20 日 13:50（PDT）：EC2 全面恢复，NLB 健康检查问题持续至 14:09。
• 10 月 21 日 04:05（PDT）：Redshift 集群替换实例完成，事件完全结束。

核心问题与影响服务

1. DynamoDB DNS 故障（11:48 PDT - 02:40 PDT）
   原因：DNS 管理系统的竞争条件导致区域终端节点（dynamodb.us-east-1.amazonaws.com）解析失败。
   影响：客户及内部服务无法连接 DynamoDB，全局表出现复制延迟。
   解决：手动干预恢复 DNS 记录，凌晨 2:25 完全修复。

2. EC2 实例启动与网络配置延迟（11:48 PDT - 13:50 PDT）
   原因：
   DynamoDB 故障导致 EC2 的 Droplet 租约超时。
   恢复后因租约重建过载引发拥塞崩溃。
   网络管理器积压导致新实例网络配置延迟。
   影响：实例启动失败（“容量不足”或“超出请求限制”），部分实例无法连接。
   解决：重启 DWFM 主机、限流请求，10:36 网络配置恢复，13:50 全面恢复。

3. NLB 健康检查失败（05:30 PDT - 14:09 PDT）
   原因：新 EC2 实例网络状态延迟传播，健康检查误判节点异常。
   影响：部分负载均衡器节点被移除，导致连接错误。
   解决：禁用自动故障转移，09:36 恢复健康节点，14:09 重新启用健康检查。

4. 其他服务受影响
   Lambda：DynamoDB 故障导致函数调用错误，NLB 问题加剧延迟，14:20 完全恢复。
   ECS/EKS/Fargate：容器启动失败，14:20 恢复。
   Amazon Connect：13:20 恢复，但受 Lambda 和 NLB 影响出现间歇性故障。
   Redshift：DynamoDB 依赖导致查询失败，部分集群需替换实例，10 月 21 日 04:05 修复。
   STS/IAM：身份验证和 API 调用错误，09:59 恢复。

根本原因与改进措施

DynamoDB DNS 系统：
竞争条件导致旧 DNS 规划覆盖新规划，触发手动干预。
改进：禁用自动化系统，修复竞争条件，新增 DNS 规划保护机制。
EC2 子系统：
租约重建拥塞和网络传播延迟暴露恢复流程缺陷。
改进：增强 DWFM 测试套件，优化限流机制，根据队列大小动态控制请求。
NLB 健康检查：
无速率限制的故障转移导致容量中断。
改进：添加健康检查速率控制，限制单个 NLB 的容量移除速度。

客户影响与后续承诺

直接影响：客户应用程序在 DynamoDB 连接、EC2 启动、NLB 负载均衡等方面遭遇中断，部分服务（如 Redshift、Connect）因依赖关系出现延迟恢复。
后续行动：
全面审查依赖 DynamoDB、EC2、NLB 的 AWS 服务弹性设计。
优化自动化系统容错能力，缩短故障恢复时间。
加强跨服务故障隔离，减少级联效应。

致歉与承诺

AWS 对事件造成的不便深表歉意，并承诺通过技术改进和流程优化提升服务可用性，确保未来类似事件影响最小化。

参考链接：https://aws.amazon.com/cn/message/101925/

本文作者：运维技术团队：辣个男人Devin
发布日期：2025年10月24日