亚马逊 AWS 重大故障整整持续了 15 个小时，服务中断造成的损失可能高达数千亿美元

在全球依赖云计算的今天，亚马逊 AWS 的任何一次抖动，几乎都意味着互联网世界的一次“地震”。

而就在 10 月 20 日（美西时间），这场震动真实地发生了——持续超过 15 个小时的 AWS 服务中断，波及了全球数以千万计的企业与用户。

一、从 DNS 故障开始的“系统雪崩”

根据亚马逊官方说明，事故最早在 10 月 19 日晚 11:49（PDT）出现：美国东部 1 区（US-EAST-1）的多个 AWS 服务出现了显著的延迟与错误率上升。

起初的原因看似简单：DynamoDB 区域端点的 DNS 解析出现异常，导致相关服务无法访问。

但问题在于，AWS 内部的很多关键系统——包括 EC2 实例启动模块、网络负载均衡器（NLB）、Lambda 调度、CloudWatch 监控等——都不同程度依赖 DynamoDB。

当 DynamoDB 挂掉后，这些服务像骨牌一样接连出错。

官方在凌晨 2:24 修复了 DNS 问题，但由于 EC2 启动子系统对 DynamoDB 的反向依赖，故障迅速演变为经典的循环依赖（Circular Dependency）灾难。

最终，AWS 不得不临时限流部分操作，包括 EC2 启动、Lambda 异步执行、SQS 消息处理等，

系统直到下午 3:01（PDT）才全面恢复——这意味着宕机持续了约 15 个小时。

简单来说，就是 AWS 内部监控出错 → DNS 解析混乱 → 服务大面积瘫痪。

AWS 的影响范围之广，让这次事故几乎成为一次“互联网停摆演练”。

根据 CNN 报道，以下主要服务均出现了访问或功能异常：

在宕机期间，部分网站甚至不得不切换到备用区域或临时迁移到 Google Cloud、Azure。

有开发者戏称：“整个美国互联网在等待 us-east-1 重启。”

网络分析机构 NetBlocks 指出，这次事件造成的影响不仅是云端业务延迟，更是“供应链式中断”：物流、支付、广告、AI 模型推理、物联网设备等，都存在直接依赖 AWS 的链条。

一位行业专家在接受 CNN 采访时表示，此次服务中断造成的全球经济损失可能高达数千亿美元。尤其在金融交易、广告实时竞价、AI 推理服务等高时效领域，15 小时的停摆意味着巨大损失。

与此同时，AWS 的 SLA（服务级别协议）补偿额度极其有限。即便客户申请赔偿，也几乎不可能覆盖真实的经济损失。

这场事故再次引发了人们对 AWS 架构的质疑：为什么一个 DNS 故障，能让全球互联网服务“崩半边”？

业内人士指出，AWS 长期以来依赖于自家服务之间的深层互通——例如 EC2 的元数据服务依赖 DynamoDB、身份验证依赖 IAM、监控依赖 CloudWatch、网络层依赖 NLB。

这种“自我依赖”带来了高耦合，一旦关键节点出错，就可能引发级联故障。

这次事件正是一次典型的“内部循环依赖雪崩”，让 AWS 这个庞大系统短暂地陷入自锁状态。

这场持续 15 个小时的宕机事件，让外界再次看到——即便是全球最成熟的云平台，也可能因为一个底层环节出错而“雪崩”。

然而，与其因此质疑云计算的可靠性，不如反思另一面：除了云，我们还有更好的选择吗？

事实是，如果企业选择自建机房、独立部署，不仅难以达到 AWS 这种规模的冗余和安全性，而且成本可能会更高。

在云服务的背后，是数以百万计的服务器、跨区域的自动容灾体系、实时监控与工程响应团队——这些能力不是任何一家中小企业可以轻易复制的。

换句话说，这次事故虽然罕见，但也恰恰证明了 “中心化” 是现代互联网运行的唯一可行方式之一。

正因为世界大部分应用都托管在 AWS 这样的云基础设施上，我们才拥有了平时接近 100% 的可用性。

技术的成熟并不意味着“永不出错”，而是当出错时，系统仍能自愈、恢复、学习并优化，这正是云计算的真正价值所在。