摘要
2026年7月16日，AWS 美东（us-east-1，弗吉尼亚北部）区域因 DynamoDB 内部 DNS 自动化系统的一处罕见竞态条件，意外删除了该区域 DynamoDB API 端点的主 DNS 记录，导致区域内所有 DynamoDB 连接瞬间失败，并沿依赖链级联击穿 EC2 启动、EC2 网络、网络负载均衡器（NLB）等基础系统，70+ 个 AWS 服务（EC2、API Gateway、Redshift、Lambda、EKS、控制台等）出现错误率升高，外部依赖方（Reddit、Snapchat、Roblox、Coinbase、Amazon.com、Prime Video、Alexa 等）大面积中断。AWS 全球停用 DynamoDB DNS 自动化模块并手动恢复，分阶段复原。
时间线
2026-07-16（具体逐分钟时间戳 AWS 未公开明细）DynamoDB DNS 自动化（Planner/Enactor）出现潜藏竞态，us-east-1 主 DNS 记录被误删、产生空 regional record 且未自愈
随即该区域所有 DynamoDB 连接瞬间失败，依赖 DynamoDB 的控制面与下游服务（含 EC2 启动管理 DWFM、AWS 控制台）失联
DNS 恢复后DWFM 同时重建数十万笔租约，请求洪峰使其壅塞，新 EC2 实例无法启动、网络配置延迟
继之EC2 网络管理器（IP 分配/路由表）被新实例配置风暴淹没，大量实例「存在但无连接」
末段NLB 健康检查因数千实例同时异常而过载，形成「缺失网络配置→健康检查失败→NLB 过载→丢弃健康实例」反馈环，局部 DNS 故障放大为区域级中断
AWS 处置手动恢复被删 DNS 记录、对 EC2 启动节流、清理网络配置积压、禁用不稳定健康检查，分阶段恢复；全球停用 DynamoDB DNS Planner 与 Enactor 自动化模块
根因
DynamoDB 内部 DNS 自动化系统（管理所有 DynamoDB 端点路由记录）存在一处罕见竞态条件：在 us-east-1 区域，自动化意外删除了 DynamoDB API 端点的主 DNS 记录，产生一条空的 regional record 且系统未能自动修复；该区域所有 DynamoDB 连接瞬间失败。依赖 DynamoDB 的众多核心服务（含控制面系统）随之失去访问。
放大因素
- DynamoDB 是 AWS 内外最关键的 NoSQL 依赖之一（Amazon.com、Alexa、Netflix 等），单点 DNS 失效即触发大规模链式反应
- 恢复阶段「租约重建风暴」：DNS 恢复后数十万笔租约同时重建，反过来压垮 EC2 启动子系统——修复第一个问题引发了第二个
- EC2 网络配置风暴叠加 NLB 健康检查反馈环，将局部 DNS 故障放大为区域级中断
- us-east-1 核心地位放大灾情：大量全球控制平台与管理后端集中于此
缓解措施
- 手动恢复被删 DNS 记录并校验端点可达
- 对 EC2 启动施加节流、重启租约管理器以吸收恢复洪峰
- 清理网络配置积压、临时扩容
- 禁用不稳定健康检查、重建路由稳定
- AWS 全球停用 DynamoDB DNS Planner 与 Enactor 自动化模块，待补竞态修正与安全控制后重新启用
经验教训
- 一处 Virginia 的数据库 DNS 自动化缺陷即可拖垮上千家公司，单区域单依赖的集中度风险极高
- 自动化恢复本身可能是二次故障源（租约/连接重建风暴），需节流与分批
- 基础服务（DynamoDB / DNS）故障会沿依赖链级联击穿控制面与下游
- 多区域韧性、依赖多样性、对云集中的监管审视愈发重要
检查清单
- 评估关键路径对单区域单依赖（如 DynamoDB / DNS）的强耦合
- 为自动化 DNS / 配置变更加安全校验、竞态保护、分批节流
- 恢复流程设计「节流重建」，避免租约/连接风暴
- 关键系统准备多区域 / 多供应商兜底，降低云集中风险