摘要
2026年5月7日（太平洋时间下午）至5月8日，AWS 美东（弗吉尼亚北部）区域 use1-az4 单个数据机房的多台制冷机组（冷水机组）同时失效，机房温度超出安全阈值，主机固件为保护硬件主动断电关机，部分机架彻底掉电、个别硬件物理受损。受影响的 EC2 实例与 EBS 卷不可达，依赖它们的 150+ 云服务与 Coinbase、FanDuel、CME Group 等头部客户数小时中断。制冷在 5月8日 13:50 PT 才恢复至事件前水平，距首次告警约 20 小时 25 分。这是物理设施故障，无软件层补救手段，只能先物理恢复制冷再安全上电。AWS 定级 SEV-1。
时间线
17:25 PDT 5/7AWS Health Dashboard 首次告警：use1-az4 的 EC2 实例与 EBS 卷因「热事件期间的断电」受损
18:47 PDT 5/7AWS 提示依赖受影响 EC2/EBS 的其他 AWS 服务也可能出现功能降级
20:06 PDT 5/7AWS 称正努力恢复温度至正常水平，但进展慢于预期
22:11 PDT 5/7AWS 称冷却系统恢复取得增量进展（外部客户不可见，但为服务恢复所必需）
01:32 PDT 5/8缓解仍在进行；IoT Core、ELB、NAT Gateway、Redshift 等工作流显著改善，但部分客户 EC2/EBS 仍处受损状态，无完全恢复 ETA
13:50 PDT 5/8制冷稳定在事件前水平（距首次告警约 20h25m），多数受影响实例与卷恢复
~20:00 EDT 5/7Coinbase 系统标记多服务高错误率，后追溯至 use1-az4 故障，核心交易服务中断约 7 小时
根因
单一数据机房内的多台制冷机组在同一时间窗口内同时失效，冗余制冷未能兜底，机房温度迅速越过安全运行阈值。主机固件/电源为保护硬件主动关机，部分机架直接掉电，个别硬件被物理损坏——AWS 原话为「loss of power during the thermal event」。EBS 卷位于受影响硬件上变得不可达。该故障属性是「一栋楼太热了」，与软件 Bug、配置错误无关，因此无法靠编排自动绕开，只能先把制冷恢复、再安全上电。
放大因素
- use1-az4 是美东最重度使用的可用区，互联网大量服务默认依赖它，爆炸半径天然巨大
- EBS 单 AZ 设计：卷无自动跨 AZ 故障转移，受损硬件上的卷只能从快照恢复，不能「等 AZ 回来」
- 「多 AZ」仅承诺数据面冗余：控制面、选主、单例组件若落在 use1-az4，则端到端并不多 AZ，照样硬宕
- Coinbase 撮合引擎与 Kafka 管线为压低延迟而固定在单 AZ，其备份 DR「未按预期工作」，被迫人工执行灾难恢复，延长中断
- 默认部署到 us-east-1 的惯性：距 2017 年 S3 事件九年，us-east-1 仍承载过多互联网默认流量
缓解措施
- 将大多数服务流量从受影响的 AZ 切走，引导用户在未受影响 AZ 重新部署资源
- 启用额外冷却系统容量，分阶段、安全地将受影响机架重新上电
- 对受损 EBS 卷执行按卷从快照恢复（而非等待 AZ 自愈）
- 建议需要立即恢复的客户从 EBS 快照还原或在其他 AZ 启动资源
经验教训
- 可用区不是抽象逻辑标签，它是一个物理场所；机房过热时内部机架可被物理损坏
- 「多 AZ」是数据面冗余声明，AZ 中断的爆炸半径由控制面决定，而非数据面
- EBS 受损硬件上的卷 = 从快照恢复，不是等待——若 runbook 写「等 AZ 回来」便无法应对本类事故
- 为延迟而单 AZ 的取舍需配套「可在 5 分钟内无脑提升的热备 + 季度级 AZ 失效演练」（AWS Fault Injection Simulator）
- AI/HPC 机柜功率密度（30–100kW）远超传统机房设计（5–10kW），散热缺口随 GPU 代际持续拉大，属系统性风险
检查清单
- 复核关键工作负载的控制面是否端到端多 AZ，而非仅数据面多 AZ
- 对单 AZ 延迟敏感组件，维护可 <5 分钟提升、且经演练验证的热备
- 季度级主动 AZ 失效演练（FIS），验证「杀掉一个 AZ 后一切仍在线」
- 跨 AZ EBS 快照为强制项；runbook 明确写「从快照恢复」而非「等待 AZ 恢复」
- 评估各 AZ 的物理隔离：电力、网络、冷却、物理安全是否独立设施