摘要
2026-08-03（约 11:48 PM PDT 起），AWS us-east-1 区域 DynamoDB 的 DNS 管理系统出现潜在 race condition，生成了 `dynamodb.us-east-1.amazonaws.com` 的错误空 DNS 记录且自动化未能自愈，导致所有经公网端点连接该区域 DynamoDB 的流量（含 IAM/EC2/Lambda/控制台等内部服务）立即 DNS 失败并级联。AWS 已发布官方 post-mortem，全球禁用涉事 DNS 自动化。
时间线
2026-08-03 ~23:48 PDTDynamoDB DNS 管理系统生成空 DNS 记录，自动化修复失败
2026-08-03 夜间客户与内部依赖 DynamoDB 的 AWS 服务开始出现 DNS 失败、连接超时、控制面错误
2026-08-04（周四）AWS 发布官方 post-mortem，说明根因为 DNS 管理系统 race condition
事后AWS 全球禁用 DynamoDB DNS Planner/Enactor 自动化，加保护校验、限流、测试套件
根因
官方确认：DynamoDB 自动化 DNS 管理系统存在潜在缺陷（latent race condition），在特定操作序列下错误地将该区域端点所有 IP 从 DNS 记录中移除，生成空记录且自动化未能修复。DynamoDB 通过区域服务端点对外暴露，客户端须先正确解析该端点；DNS 层返回失败/空记录后，大量客户端（含 AWS 内部强依赖 DynamoDB 的 IAM、EC2 控制面、Lambda、API Gateway、Console 等）无法定位 DynamoDB，即便数据库存储层本身仍在运行。
放大因素
- DynamoDB 是 AWS 众多控制面与应用工作流的隐藏基础依赖（dogfooding）：IAM 鉴权、EC2 实例元数据查询、Lambda 状态/限流、控制台后端调用均依赖它，单点失效沿依赖链放大至全平台控制面。
- 恢复分阶段：DNS 记录恢复后，依赖服务仍需重连、清缓存失败、退避重试、排空积压队列，客户可见恢复滞后于 DNS 层稳定。
- us-east-1 是最老、最重、承载全局控制面（IAM/Route 53）的区域，全球「global」栈常在 Virginia 锚定身份/状态/元数据，区域失效外溢至全球。
缓解措施
- 手动运营商介入修复空 DNS 记录，恢复正确解析路径并全网监控。
- 全球禁用 DynamoDB DNS Planner 与 DNS Enactor 自动化，待加保护校验、限流控制、扩展测试套件后重启。
- AWS 承诺强化隔离、更安全的 DNS 自动化、改进恢复行为、降低共享依赖。
经验教训
- 隐藏的负载承载层（DNS/服务发现）常被当「基础管道」轻视；一旦它服务于被广泛依赖的基础服务（如 DynamoDB），爆炸半径远超显性使用者。
- 自动化修复（自愈）必须覆盖自身失败模式：当自动化生成错误状态且无法自愈时，需人工兜底与外部校验，不能假设「自动化总会修好」。
- 多区域设计仅在应用真正能干净 failover、且身份/配置/DNS/部署工具链不仍锚定故障区域时有效；否则只是名义多活。
检查清单
- 关键基础服务的 DNS/服务发现是否具备「空记录/坏记录」检测与自动告警？
- 自动化 DNS 变更是否有保护校验与「生成空/错误记录即中止」的熔断？
- 强依赖基础服务（如 DynamoDB）的内部服务是否列出依赖清单与降级路径？
- 多区域架构是否验证身份/配置/DNS 不锚定单一区域？
- 恢复 SLO 是否覆盖「DNS 恢复 → 重连 → 缓存失效 → 队列排空」全链路，而非仅看链路恢复？