摘要
2026年7月24日 UTC 10:55 起，AWS us-west-2（俄勒冈）区域与西雅图城域（Seattle Metro）之间的网络路由链路中断，最直接的故障点是承载该区域与西雅图互联枢纽之间路由的网络硬件失效。区域内双向流量基本正常，但任何需要跨越区域边界的流量（含部分私有网络与 Direct Connect 专线）出现超时与错误。11:15 UTC 初步恢复，11:59 UTC 路由完全恢复；但 11:47–11:59 的路由重收敛（reconvergence）又造成部分客户间歇连接抖动。公开影响窗口核心约 20 分钟，经 EqSe2（西雅图 Westin 大楼交换中心）Direct Connect 的客户最长约 1 小时 17 分钟。下游级联波及 Apple Pay、Reddit、Hulu、DoorDash、PlayStation Network 等，约 80 分钟。AWS 在 13:01 UTC 发布关闭摘要并点名根因；官方称将在 2–4 周内发布正式详细事后报告。
时间线
根因
AWS 将故障归因于承载 us-west-2 区域与西雅图城域之间路由的网络硬件失效。该故障位于「区域与公网之间的边界」而非计算/存储层——多可用区（multi-AZ）冗余对此无能为力，因为冗余保护的是区域内故障（硬件、电力、制冷），而不是区域网络出口本身。初步修复生效后，路由器重新就网络路径达成一致（路由重收敛）的过程中产生了第二波更小的间歇影响窗口。受影响 10 项服务几乎全是入站/出站层：Direct Connect、Global Accelerator、Internet Connectivity、IoT Core、Site-to-Site VPN、API Gateway、EC2、ECS、ELB、VPC；区域内计算持续正常运行。
放大因素
- 故障点位于区域网络出口边界，zone 级冗余完全失效，跨边界流量成片失败
- 路由重收敛期（11:47–11:59）新路径尚未稳定即产生二次抖动
- 下游队列放大：邮件投递（SendGrid 7h32m、SparkPost 6h45m 才清空积压）、远程监控代理（NinjaOne 9h29m 才恢复）的级联尾巴远超上游 20 分钟窗口——20 分钟的连接中断排出了远超 20 分钟处理能力的消息量
- 多数下游团队比 AWS 首次公开更新（11:40）更早自建事件：12 起被追踪事件中 11 起在 11:40 前已开启
缓解措施
- AWS 并行推进多条缓解路径，首条于 11:15 UTC 恢复连接
- 拥有经其他 Direct Connect 位置的冗余路径的客户未受延长窗口影响
- 官方承诺增加防护以避免类似路由失效
经验教训
- 「AWS 挂了」几乎从不是正确心智模型：云中断通常是特定服务/区域/可用区/网络路径，而非全有全无；关键是快速判断「哪一片受影响、我的关键路径是否触碰它」
- 区域网络层的地理冗余（而非仅 zone 层）才是对抗边界故障的真正防线
- 不要把供应商状态页当首要真相源：成熟团队把状态页当确认信号与沟通辅助，而非自己响应的触发条件
- 恢复预期应按「级联尾巴」而非供应商关闭时间戳来规划
检查清单
- 确认关键流量路径不会全部跨越单一网络边界
- 为 Direct Connect 准备替代接入位置（避免绑定 EqSe2 单点）
- 建立独立于供应商状态页的自己的遥测与告警
- 按级联尾巴时长（而非上游恢复时刻）规划业务恢复 SLA 与 backlog 清理