当 us‑east‑1 打喷嚏：2025 年 10 月 19–20 日 AWS 中断实战指南
事件时间： 2025‑10‑19 → 10‑20（太平洋时间） 主要触发器： DynamoDB 区域端点的 DNS 自动化缺陷 波及范围： DynamoDB → EC2 启动 → Network Manager → NLB →（Lambda、STS、IAM 登录、Redshift、ECS/EKS/Fargate、Connect）在 us‑east‑1
要点速览（给忙碌的人）
- 起点（10‑19 11:48 PM）： DynamoDB 的自动 DNS 管理中出现 竞态条件，将区域端点
dynamodb.us-east-1.amazonaws.com置为空记录。任何尝试在 us‑east‑1 建立新连接到 DynamoDB 的请求都在 DNS 解析阶段失败。 - DynamoDB 主要恢复（10‑20 2:25–2:40 AM）： AWS 恢复了正确的 DNS 记录；随着客户端缓存条目的过期，客户开始恢复。
- 为何问题没就此结束： EC2 的内部控制平面依赖 DynamoDB来管理物理主机（“droplet”）的租约。租约在 DNS 窗口期间过期，导致 Droplet Workflow Manager（DWFM）出现拥塞性崩溃，Network Manager 出现积压。新的 EC2 实例启动报错或启动时缺乏完整的网络状态。
- 负载均衡的动荡（5:30 AM–2:09 PM）： Network Load Balancer（NLB）的健康检查因网络传播延迟而出现抖动，导致间歇性容量被移除并出现连接错误。
- 回到稳态： 大多数服务在 10‑20 午后早些时候稳定；由于 EC2 替换导致的 Redshift 残留问题在 10‑21 4:05 AM 前清理完毕。
“发生了什么”的时间线（PDT）
| 时间窗口（10‑19 → 10‑20） | 客户端观察到的现象 | 实际内部故障 |
|---|---|---|
| 11:48 PM → 2:40 AM | us‑east‑1 的 DynamoDB API 错误；任何发起新连接的请求均解析失败 | DNS Planner/Enactor 的竞态导致为 DynamoDB 区域端点生成了一个空的 Route 53 记录；人工修复在 2:25 AM 恢复记录；客户端在 2:40 AM（缓存过期后）开始恢复 |
| 2:25 AM → 1:50 PM | EC2：启动错误（“insufficient capacity” / “request limit exceeded”），API 延迟上升 | DWFM 对物理主机（“droplets”）的租约已过期；恢复过程中产生了大规模的重新租约工作，导致队列崩溃。限流 + 有选择的重启（从 4:14 AM）帮助追赶；5:28 AM 恢复租约；11:23 AM 放宽限流；1:50 PM 完全恢复 |
| 5:30 AM → 2:09 PM | NLB：部分负载均衡器出现连接错误增多 | 因为 Network Manager 尚未完全传播网络状态，新实例的健康检查出现抖动；自动可用区故障切换移除了容量；9:36 AM：禁用自动故障切换以停止容量震荡；2:09 PM：重新启用 |
| 按服务的不同回声 | Lambda（到 2:15 PM）、STS（到 9:59 AM）、控制台 IAM 登录（到 1:25 AM）、ECS/EKS/Fargate（到 2:20 PM）、Connect（到 1:20 PM）、Redshift 查询/控制平面（大部分到 2:21 AM，部分计算实例直到 10‑21 4:05 AM） | 每个服务对 DynamoDB、EC2 启动容量、NLB 健康或 IAM/STS 的依赖各不相同，因此症状在不同时间出现并消退 |
两分钟掌握核心概念（给新读者）
DNS（域名系统） 把 DNS 想象成互联网的电话簿。你按名字查询；它返回要拨打的地址（IP）。在超大规模环境下，服务提供者用 DNS 记录和健康检查将流量引导到巨量的实例和可用区。它快速且无处不在，但不是事务性数据库；一致性与变更排序是难题，需要通过工程手段来规避。
DynamoDB AWS 的托管键值/NoSQL 数据库。延迟极低、弹性强，应用广泛——包括被 AWS 自身 用于控制平面和元数据。当某个应用或 AWS 子系统需要读写控制状态而无法访问 DynamoDB 时，问题会逐层堆叠。
EC2 与控制平面 EC2 在“droplets”（物理主机）之上运行你的实例。内部服务管理这些主机的租约并传播网络状态（路由、安全组等）。启动新实例很简单——除非内部协调变得不健康或出现积压。
NLB（Network Load Balancer） 第 4 层负载均衡器。执行健康检查并跨 AZ 路由。如果健康检查抖动或基于 DNS 的故障切换过于激进，就可能在最需要容量时短暂移除过多节点。
真正失败的地方：DynamoDB 的 DNS 自动化
AWS 将 DynamoDB 的 DNS 管理拆成两个角色：
- DNS Planner： 计算每个端点（区域、FIPS、IPv6、账户特定等）所需的记录集合（哪些负载均衡器、权重等）。
- DNS Enactor： 在不同可用区运行的三个冗余 worker，将这些计划应用到 Route 53，每个 worker 执行事务性更新。
在罕见的争用情形下，一个 Enactor 进展缓慢，另一个则抢先应用了较新的计划并随后对旧的版本执行垃圾回收。缓慢的 Enactor 所持有的过期“旧”计划在快速 Enactor 清理旧计划之前覆盖了区域端点——这导致端点的所有 IP 被原子性地移除，并使系统进入一种阻止后续自动更新的状态。人工介入进行了修复。
为什么这很重要：区域端点消失了。任何需要对 DynamoDB 在 us‑east‑1 进行新 DNS 解析的请求会立即失败。已有的连接通常继续正常工作。
为何会产生级联：紧耦合与时间箭头
-
控制平面耦合（EC2 ⇄ DynamoDB）。 EC2 的 Droplet Workflow Manager（DWFM）维持物理主机的租约。这些检查依赖 DynamoDB。在 DNS 事件期间，租约超时，使 droplet 无法用于新实例的调度。DynamoDB 恢复后，DWFM 必须在庞大机群上重新建立租约，触发队列超时并出现拥塞。
-
网络传播延迟。 即便实例重新开始启动，Network Manager 在发布它们的网络状态时出现了积压。实例上线时没有完整的连通性，直到传播赶上（约到 10:36 AM）。
-
健康检查反馈回路（NLB）。 带有不完整网络状态的新容量被判定为不健康，因此 NLB 撤出这些节点或可用区的流量，导致容量暂时萎缩，使连接错误更严重。运维暂停了自动健康检查故障切换以停止振荡，然后在 EC2 稳定后恢复该机制。
-
下游服务的连锁反应。 Lambda 对某些路径进行了限流以保护同步调用；STS/IAM 登录出现波动后恢复；容器控制平面（ECS/EKS/Fargate）和 Connect 感受到了 EC2/NLB 的联合作用；Redshift 有额外复杂性：基于 IAM 的查询认证短暂在全球范围内失效，部分集群在等待 EC2 主机替换，问题拖入了 10‑21。
如果你在想“瑞士奶酪模型（Swiss cheese model）”——许多薄弱防线凑到一起——你理解得很到位。
复杂系统视角（为何“根本原因”不足以解释）
多位从业者引用了 Richard Cook 的《How Complex Systems Fail》和 Perrow 的《Normal Accidents》。这种框架在本次事件中非常贴合：
- 不是单一原因。 DNS 竞态点燃了导火索，但长尾来自 EC2 的亚稳态恢复模式与 NLB 的健康检查振荡——每个设计在局部都是合理的，但在压力下互相作用产生了灾难性后果。
- 系统通常以降级方式运行。 Planner/Enactor 的重试、租约过期、队列积压——这些是系统通常能忍受的摩擦，恰好在不利时刻叠加。
- 人为创造安全。 自动化停滞时，运维人员通过人工修复（手动恢复 DNS、DWFM 限流/重启、禁用 NLB 自动故障切换）重织了系统的运行状态。
结论：修复 bug 很重要，但更应识别亚稳态恢复陷阱和反馈回路，它们会把小故障放大成雪崩。
AWS 表示将做出的更改
- DynamoDB DNS 自动化： 在修复竞态问题期间全球禁用该自动化；增加保护措施以防止应用或删除错误的计划。
- NLB： 增加一种速度控制（velocity control），防止健康检查故障切换在短时间内移除过多容量。
- EC2： 为 DWFM 引入新的恢复测试套件；在数据传播系统中改进队列感知限流。
这些属于正确的缓解措施类别：阻止错误写入、节奏化自愈行为，并在负载下演练恢复路径。
你可以做什么（周一晨检清单）
即便你无法更改 AWS，你也能在自身架构中降低冲击。
-
偏好区域端点并移除隐式的 us‑east‑1 依赖。 如果服务提供区域化的控制平面（例如 STS），使用它们。不要习惯性地将认证或元数据集中在 us‑east‑1。
-
为关键控制状态设计多区域数据访问。 DynamoDB Global Tables 可以让你将读/写切换到第二个 Region。你的代码必须容忍复制延迟并在之后进行对账。
-
对健康检查振荡采取“关闭式”设计。 用阻尼（damping）来门控自动故障切换：多次连续失败、滞后（hysteresis）和按分钟的容量移除上限。考虑一个人工覆盖的断路器以停止抖动。
-
明确依赖图。 记录哪些服务必须可用以支持启动/扩缩（认证、队列、配置存储等）。练习“如果 X 慢/不可用 2 小时会怎样？”
-
演练亚稳态恢复。 针对控制平面进行混沌演练，而不仅仅是数据平面：
- 在机群切片上模拟租约过期。
- 压测你的网络配置传播器。
- 排练背压情形和**限流解除（throttle‑lift）**的顺序。
-
带目的地缓存（Cache with intent）。 DNS 缓存隐匿了恢复延迟（客户端依赖 TTL）。对那些倾向于打开大量新连接的 SDK，考虑连接池化和带抖动的指数退避，避免同步重试风暴。
-
制定“安全模式”运行手册。
- 错误激增时降低并发或限流。
- 偏好在重新启用自动扩缩前先清理积压。
- 使用 feature flags 在控制平面事件期间禁用昂贵的后台任务。
-
保护你自己的“planner/enactor”模式。 如果你生成期望状态并将其应用到其他地方，增加：
- 版本化的 plan 与 compare‑and‑swap 语义。
- 不允许清理掉最后一个已知良好计划的清理逻辑。
- 每个端点的单写者租约或小型序列器（向量时钟 / 单调计数器）。
这是“滥用 DNS”吗？
不完全是。 在超大规模场景中，DNS 是一种服务发现和流量引导工具，因为每个客户端、库和 VPC 解析器都支持它。此次的错误不是使用 DNS 本身；而是允许并发写者和一个清理器在没有铁定顺序保证的情况下交互，并在网络传播积压时让基于健康检查的 DNS 过快移除容量。这些都是可修复的工程选择。
术语表（60 秒速览）
- Route 53： AWS 的 DNS 与健康检查服务。支持加权/延迟/基于健康的路由和事务性记录更改。
- TTL（time to live）： 解析器可以缓存 DNS 答案的时长。短 TTL 加速故障切换，同时也会放大查询速率。
- DWFM（Droplet Workflow Manager）： 管理物理主机租约的 EC2 子系统。
- Network Manager： 将 VPC/网络配置传播到实例和网络设备的服务。
- Global Tables（DynamoDB）： 表的多区域复制，提供最终一致性和冲突解决机制。
结语
这次中断不是“单纯的 DNS 问题”。它是DNS + 控制平面恢复 + 健康检查动力学 + 人工干预的复合事件——再次提醒我们：可用性是一个系统属性，而非单个组件的特性。令人鼓舞的是，缓解措施很具体：序列化计划应用、节奏化容量移除、在负载下压力测试恢复。把这些模式复制到你自己的系统里，下次 us‑east‑1 打喷嚏时，你的应用就不需要那么多纸巾了。