摘要
2026年7月16日，AWS CloudFront 发生全球性 5xx 错误，持续约 3 小时 33 分（07:45–11:18 UTC）。故障范围限定在使用 VPC Origins 功能的 distribution，根因为管理私有 VPC origins 连接的机群出现"内部约束"，路由配置分发到网络处理器时未能正确加载，导致相关请求大面积返回 5xx。AWS 官方发布 resolution summary 并给出临时切换 origin 类型的 workaround。事件通过全球 CDN 边缘层放大，引发大量下游服务级联中断。
时间线
2026-07-16 07:45 (UTC)VPC Origins 客户开始报告 5xx 错误升高（真实影响起点）
2026-07-16 08:44 (UTC)AWS 首次公开：调查 VPC Origins 连接 5xx
2026-07-16 09:21 (UTC)确认起始 07:45，其他 origin 类型不受影响，建议临时切换 origin 类型作为 workaround
2026-07-16 09:57 (UTC)内部定位根因：连接管理机群触及内部约束，配置分发到网络处理器未能正确加载
2026-07-16 11:18 (UTC)全面恢复（12:21 UTC 发布 resolution summary）
2026-07-16 12:21 (UTC)复盘确认影响窗口 07:45–11:18 UTC（3h33m），workaround 可回退
根因
CloudFront 的 VPC Origins 功能（2024 年末推出，允许从客户私有 VPC 子网拉取内容）所依赖的连接管理机群触及一个"内部约束"，导致路由配置分发到网络处理器时未能正确加载。使用 VPC Origins 的 distribution 全部返回 5xx，使用其他 origin 类型（如 S3/公有 ALB）的distribution 正常。AWS 在 resolution summary 中确认了上述机制，但未披露该"约束"的具体技术细节。
放大因素
- 全局 CDN 边缘层把单一功能/单区域的故障放大到全球：欧洲、北美、亚洲、澳洲用户均报错
- 下游级联广泛：Frontegg、Hugging Face、TigerData、Coda、Instructure（Canvas）、Ubiquiti、Doxy、Blackboard 等先后受影响
- 区域/多可用区冗余对"全局控制面/配置面"故障无效——控制面不分区域边界，区域 failover 救不了
- AWS 早期给出 workaround（临时切换 origin 类型），但需事先演练才能在事故中临场生效
缓解措施
- AWS 采取多项缓解动作并分阶段修复，11:18 UTC 全面恢复
- 客户侧 workaround：将受影响 distribution 从 VPC Origin 切回 public origin
- 事后建议客户监控 AWS Health Dashboard 而非仅依赖下游状态页
经验教训
- 全局控制面/配置面故障不尊重区域边界，仅靠多区域 failover 不足以应对，需跨 provider 或降级模式
- 依赖图谱必须画到二阶：身份提供商、CDN 等关键共享层一旦故障会连锁拖垮业务
- 上游 provider 故障时，应预先演练过的降级/origin 回退路径；监控体系不能与 provider 同生共死
- 参考来源：AWS Health Dashboard / IncidentHub 复盘 https://blog.incidenthub.cloud/aws-cloudfront-outage-jul-16-2026 ；The Register；Pagerly
检查清单
- 关键依赖（CDN/IdP）是否识别到二阶？
- 是否对全局控制面故障准备了跨 provider/降级预案？
- origin 回退路径是否事前演练？
- 监控是否独立于云 provider（provider 宕机时仍能告警）？