一、事件概况
- 时间：2025 年10 月19日 23:48 PDT（太平洋夏令时）起至 10 月20日 14:20 PDT 结束。 ’
- 地点：北弗吉尼亚区，即 us-east-1 区域。 ’
- 影响范围：主要是 Amazon DynamoDB（DynamoDB），然后波及到 Amazon EC2（EC2）、 AWS Lambda（Lambda）、 Amazon Redshift（Redshift）等多个服务。 ’
二、分阶段影响（按时间顺序）
下面用一个简单图表展现“何时出问题／何时恢复”的关键阶段。
| 阶段 | 服务 | 时间段（PDT） | 问题内容 |
|---|---|---|---|
| 阶段 1 | DynamoDB | 10/19 23:48 → 10/20 02:40 | API错误率上升，客户及依赖服务无法连接。 |
| 阶段 2 | EC2 新实例启动 | 10/19 23:48 → 10/20 13:50 | 原有实例正常，但新实例启动失败或网络连接问题频发。 ’ |
| 阶段 3 | 网络负载均衡器 NLB | 10/20 05:30 → 10/20 14:09 | 健康检查失败、连接错误增加。 ’ |
（注：以上为重点时间段，事件中还有对 Lambda、Redshift 等服务的连锁影响。）
三、根本原因解析
1. DynamoDB 的 DNS 管理系统出错
- DynamoDB 使用自动化系统管理其海量 DNS 记录：为了大量负载均衡器、FIPS 端点、IPv6 端点、账号专用端点。
- 出了“赛跑条件”（race condition）：两个负责更新 DNS 的组件（叫 DNS Planner 和 DNS Enactor）在极不寻常的延迟／竞争状况下出错。
- 结果：一个较旧的 DNS 计划覆盖了更新的计划——导致区域端点（
dynamodb.us-east-1.amazonaws.com）指向“空”DNS记录（IP 被移除）且自动恢复机制失效。
2. 连锁反应：EC2 + NLB +其他服务
- EC2 新实例的启动流程依赖 DynamoDB：其内部管理子系统（DWFM：DropletWorkflow Manager）无法完成“租约”续签，因为 DynamoDB 不可用。
- 网络状态传播（Network Manager）也受影响，导致即便实例启动，也可能没有网络连接。
- NLB 健康检查失败：由于网络状态尚未传播且部分实例被错误标记为“不可用”，NLB 的自动故障转移反而降低了可用容量。
- 更多服务（Lambda、Redshift、IAM 认证等）因为上述基础服务的异常，也出现错误或延迟。
四、恢复过程与变更措施
恢复过程
- 在 DynamoDB DNS 问题被定位后（约 10/20 00:38 PDT）工程师采取临时措施，于约 02:25 PDT 恢复 DNS 信息。
- EC2 的 lease 重建 +网络传播延迟被逐步清理，直到 13:50 PDT 恢复正常。
- NLB 的健康检查自动转移功能曾被暂停以缓解问题，并于约 14:09 PDT 重新启用。
变更措施
- DynamoDB：禁用其 DNS Planner 和 DNS Enactor 的自动化流程，直到修复 race condition 并增加保护措施。
- NLB：将增加“速率控制机制”（velocity control）来限制健康检查失败时单个 NLB 移除的容量。
- EC2：扩充其规模测试（scale testing）覆盖 DWFM 恢复流程，改进网络状态传播系统的节流机制（throttling）以防高负荷下系统崩溃。
