AWS US-EAST-1 故障分析报告：一个 DNS 错误如何让全球互联网宕机
Doc Map
前言
最近在网上冲浪时，刷到一条足以让开发者头皮发麻的消息：AWS 又双叒叕“歇菜”了 😱
对于我们这些正在学习的开发者来说，虽然只是学生，但在学习过程中也会用到云服务，搭建一些自己的小项目或实验环境。所以一旦云服务挂了，我们也躲不开。这次的“老朋友”又来了 —— AWS US‑EAST‑1 区域宕机。自 2011 年以来，该区域已经发生过 11 次重大事故（这里的“重大”指的是导致大面积或长时间中断的严重事件，不包括日常维护的小问题），几乎相当于每年一次。
那么，为什么这个区域问题频发？这次宕机的原因是什么？官方又是如何解决的？作为开发者，我们又该如何应对？接下来，就让我们慢慢分析一番。
事情经过：一个 DNS 错误引发的“蝴蝶效应”
故障时间线（美国东部时间）
大概在 2025 年 10 月 20 日凌晨。一开始是小小的异样：AWS 状态页面上，“错误率”和“延迟”开始有点不对劲。
初始症状：数据库“找不到家”
很快，问题被定位到了 US-EAST-1 区域的一个核心服务：Amazon DynamoDB（AWS 的 NoSQL 数据库）。不是数据库本身坏了，而是调用这个数据库服务的 API 端点，出现了 “域名解析（DNS）” 错误。
简单来说： DynamoDB 的数据还在，但全世界突然都“找不到”它的“门牌号（IP 地址）”了。就像你给朋友打电话，手机里的“姓名”突然无法解析成“号码”。
根源深挖：控制平面“大脑”短路
随着调查深入，AWS 发现 DNS 故障的背后，是其内部网络控制子系统（比如负责网络负载均衡器健康监控的机制）出了问题。
TIP
DNS 只是表象，真正的“病灶”是管理云资源分配和网络健康的“控制平面”出了状况。这个“大脑”一短路，基础服务发现机制自然跟着崩塌。
现代互联网服务就像精心摆放的多米诺骨牌：你的应用依赖 DynamoDB 来存储数据，而 DynamoDB 的正常运行又依赖 AWS 的 内部网络控制 系统，而这个控制系统本身又需要 健康监控 来确保各个节点运行良好。结果就是，如果链条上任意一个环节出问题，整个服务就会像多米诺骨牌一样，摇晃甚至倒下，带来连锁反应。
影响范围：全球互联网“感冒”
为什么 US-EAST-1 这么可怕？因为它实在太核心了。很多全球性的 AWS 服务都依赖这个区域，甚至很多大厂的默认部署、身份验证（IAM）都把这里当成“大本营”。
结果，故障就像传染病一样迅速扩散：
- 普通人： 晚上 Alexa 闹钟没响；Ring 摄像头录像卡顿；游戏玩家发现 Fortnite、Roblox 连不上；连 Snapchat、WhatsApp 等社交应用也受影响。
- 开发者/公司： AWS 控制台登录不进去；新的服务器（EC2 实例）启动不了；依赖 DynamoDB 的服务集体“宕机”。
AWS 官方如何应对和解决？（抢救与恢复的细节）
在面对这种复杂的、涉及核心基础设施的故障时，AWS 工程师的抢救流程是高度专业和分阶段的，这次的处理尤其体现了对级联故障的应对。
阶段一：识别、隔离与初始 DNS 修复
- 快速定位 DNS 问题： 工程师在故障发生后不到一个小时内，迅速定位到 DynamoDB API 端点的 DNS 解析失败是客户可见错误的直接原因。
- 实施 DNS 缓解措施： 官方工程师团队立即着手在内部网络中修复 DNS 配置错误，并应用了初始缓解措施。
- 核心问题解决： 在故障开始后大约 3 小时，AWS 宣布核心的 DynamoDB DNS 问题已被缓解（Mitigated）。
处理次级故障与限流
尽管 DNS 问题解决了，但长达数小时的故障引发了严重的连锁反应和资源挤兑：
- EC2 启动受阻： 工程师发现 EC2 内部用于启动实例的子系统也受到了损害，因为它依赖于 DynamoDB 的某些内部组件。这导致客户无法启动新的计算实例。
- 网络负载均衡器（NLB）故障： 负责监控和分配流量的 NLB 健康检查机制也出现问题，进一步导致了 Lambda、CloudWatch 等多个服务的网络连接问题。
- 启动临时限流（Throttling）： 为了防止系统因大量重试和积压的恢复请求而崩溃，AWS 决定暂时限制某些操作（如新的 EC2 实例启动、Lambda 异步调用），这被称为“限流”。这个操作是为了牺牲部分功能，确保核心服务的稳定恢复。
阶段三：逐步恢复与最终解除
- 修复次级故障： 工程师优先修复了 NLB 健康检查机制和 EC2 启动子系统，使底层网络和计算资源恢复正常。
- 降级限流： 随着系统稳定，AWS 逐步减少对 EC2 启动和 Lambda 调用的限流，允许客户流量和操作逐渐恢复正常。
- 全面恢复： 经过长时间的努力（总耗时超过十几个小时），AWS 最终宣布所有服务都恢复正常运行。但同时警告，一些依赖队列和日志的服务（如 AWS Config, Redshift, Connect）还需要时间来处理故障期间积压的消息。
为什么是 US-EAST-1？为什么是 DNS？
这次事故，再次把云服务架构里的几个“阿喀琉斯之踵”暴露了出来。
“老大哥”的集中风险（US-EAST-1）
US-EAST-1区域，作为AWS全球基础设施中位于弗吉尼亚的“创始核心”，其特殊地位本身就构成了系统性风险的根源。
首先，由于其历史最悠久、资源最丰富，形成了强大的“历史惯性”：大量服务在此默认部署，使其积累了最完善的生态系统。然而，这种繁荣背后隐藏着关键的“架构脆弱性” —— 许多全球性服务（如IAM、Route 53等）的控制平面与关键功能都深度依赖此区域。这就导致了一个典型的“单点故障”架构：当所有关键业务都集中部署于这一个“数字篮筐”时，任何一次区域性故障都如同抽走了整个积木大厦的基石，必然引发波及全球的连锁反应。AWS历史上数次重大事故几乎都集中于此，正是这种架构缺陷最直接的证明。
关键依赖链的“脆弱”
这次故障路径很清晰：网络控制平面 → DNS 解析 → DynamoDB API → 客户端服务。一个基础组件（DNS 解析）出错，就能让作为“互联网关键记账本”的 DynamoDB 失效，进而导致整个链条上的服务全部崩溃。这种深层耦合，在云的宏大架构下，风险被几何级放大。
“总是 DNS” 的诅咒
我们技术人有句玩笑话：“不是我们代码写得烂，是 DNS 又出问题了。”
域名解析（DNS），这个看似简单的“翻译”服务，在云环境中承担着“服务发现”和“路径选择”的生命线角色。当 AWS 内部的 DNS 出现问题，服务就无法找到目标 IP，流量就无法导向正确的服务器。数据可能还在，但你的应用程序就是“摸”不着它。
技术人的反思：故障，是必修课
这次事故对所有人都是一次痛苦的提醒。
对普通用户：脆弱的“数字生活”
你可能没意识到，你早上用 Alexa 关闹钟，App 里刷个社交动态，甚至银行 App 查个余额，背后都可能依赖 US-EAST-1 的某个服务。云服务故障，让我们意识到自己日常生活的数字化基础设施比想象中要脆弱。
对开发者/项目团队：必须跨越“单区舒适圈”
如果你是技术负责人，这次事故给你敲响了警钟：
- 多区部署，不是选项，是底线： 别把所有核心服务都放在 US-EAST-1。虽然跨区域部署有成本和复杂性，但这是保证业务连续性的唯一解药。
- 解耦核心依赖： 仔细检查你的服务依赖链。如果你的应用过度依赖某个单点服务（比如单区 DynamoDB、或单区 IAM），必须考虑容错机制、降级策略。
- 恢复期的“陷阱”： 官方说“已恢复”不等于“完全正常”。事故后很长一段时间内，你可能仍会面临 API 限流、新实例启动失败、缓存延迟等问题。必须持续监控，不能松懈。
历史总是相似的
在报告开头就提到过，AWS 在 US-EAST-1 区域的重大事故，已经不是第一次了：
- 2023 年 6 月： US-EAST-1 区域的 Lambda 服务调用出现大量错误。
- 2024 年 7 月： US-EAST-1 Kinesis Data Streams 故障，引发多服务级联失败。
- 2021 年 12 月： US-EAST-1 爆发长时间多服务故障，同样影响 IAM、EC2、DynamoDB 等。
每一次都是核心区域 + 基础服务出问题 + 连锁反应的经典模板。这提醒我们，云服务商的 SLA 很高，但“绝对不挂”是不存在的。
几个给未来的自己留下的关键词
每次故障，都是一次架构升级的机会。把以下几点写进备忘录：
- 集中风险（US-EAST-1）： 核心业务远离 US-EAST-1，或至少在另一个区域（如 US-WEST-2）部署完整的热备。
- DNS 优先级： 把 DNS 和网络健康监控视为最高优先级的基础设施。
- 控制平面依赖： 了解你的服务对 AWS 控制平面（比如创建实例、更改 IAM 权限）的依赖程度，在控制平面故障时，如何让数据平面（已经运行的业务）继续工作。
- 故障演练： 定期进行 “Chaos Engineering”（混沌工程） 演练，模拟 US-EAST-1 挂了、DNS 失效了，你的系统是否还能撑住？
附录：
官方报告：报告
AWS Status：AWS Status
AWS US-EAST-1 Region Outage Analysis (Reddit Discussion)：Reddit Discussion