亚马逊云科技服务中断暴露了关键云基础设施的脆弱性

2025 年 10 月 20 日，亚马逊云科技的服务（AWS）遭遇重大故障，导致其全球互联网服务中断，影响了 60 多个国家的数百万用户和数千家公司。该事件源于美国东部 1 区（US-EAST-1），经追溯发现，这是因为一个 DNS 解析失败影响了DynamoDB端点，进而导致多个依赖服务中断。

根据亚马逊云科技官方事件报告，故障源于 DNS 子系统在受影响区域内未能正确更新域名解析记录。客户无法解析服务端点，即使数据存储本身仍在运行，操作也被迫停止。本次事件影响范围广泛：根据Ookla和监控服务 Downdetector 的数据，在中断窗口内，全球有超过 1700 万用户报告该问题的记录。

事件源于 DynamoDB 自动化 DNS 管理系统中的一个潜在竞争条件。亚马逊云科技的云服务使用两个子网组件来管理其 DNS 记录：一个 DNS Planner，负责跟踪负载均衡器的健康状况并提出更改建议；一个 DNS Enactor，通过Route 53应用这些更改。因为一个 Enactor 滞后，一个清理作业错误地删除了活动的 DNS 记录，导致 dynamodb.us-east-1.amazonaws.com 端点指向了没有 IP 的地址。

由于损坏的 DNS 记录没有及时得到纠正，无论是亚马逊云科技的服务还是客户应用程序，都无法解析 DynamoDB 端点。尽管 DynamoDB 本身仍然健康，但 DNS 可达性的丧失使其无法访问。

中断并未就此止步。亚马逊云科技内部依赖 DynamoDB 的子系统，包括EC2和Lambda的控制平面，开始出现故障。随着客户 SDK 重试失败的请求，出现了一次重试风暴，进一步压垮了亚马逊云科技的内部解析器基础设施。网络负载均衡器（NLB）健康检查服务也开始出现故障，拒绝新启动的 EC2 实例，这减慢了恢复速度。

最终，这演变成了一个连锁反应：DNS 漏洞导致终端不可见，触发重试机制，引发控制平面压力级联效应，并造成区域性大规模不稳定。

连锁效应远远超出了亚马逊云科技的云平台：包括社交媒体、游戏、金融和电子商务在内的主要消费者、企业和政府应用程序，要么经历了性能下降，要么完全离线。专家指出，该事件再次警示人们过度依赖单一云区域或提供商所带来的风险。

作为回应，亚马逊云科技已经采取措施，在受影响的区域内禁用并重新评估负责 DNS 更新和负载均衡的自动化系统，并建议客户采用多区域架构并多样化依赖链，以减轻未来遇到类似风险的可能。此次故障不仅引发了人们对亚马逊云科技服务弹性的质疑，更凸显了当今互联网架构的根本性缺陷——单点基础设施故障便可能引发全球范围的服务中断连锁反应。

为了让企业最好地采用亚马逊云科技建议的多区域架构方案，推荐采用以下做法。

亚马逊云科技的客户应该设计多区域故障转移，而不仅仅是多 AZ 高可用性。当 DNS 或控制平面发生故障时，仅依赖美国东部 1 区（或任何单一区域）可能会有风险。

系统设计应该充分考虑弹性，采用异步复制、本地或分布式缓存、持久化队列等备用方案，确保单一服务的中断不会引发整个应用程序的连锁故障。这些模式能保证系统持续运行，即使上游组件出现不可用或响应迟缓也能维持服务的连续性。

客户端弹性也很重要。从这次事件可以看出，大量未经协调的重试会压垮已经降级的服务，将局部故障变成广泛事件。实现指数退避和抖动、断路器和请求丢弃，允许系统优雅地回退，而不是在服务部分中断期间加重过载。

事实证明，DNS 是另一个关键的薄弱环节。组织应考虑采用更具弹性的 DNS 策略，例如使用自定义解析器、降低 TTL 值以提升故障转移响应速度，并引入内部回退机制以降低对单一托管 DNS 提供商的依赖。这些措施有助于在控制平面组件出现故障时控制影响范围。

最后，需要对弹性进行持续验证。运行混沌工程实验，故意增加压力或禁用控制平面依赖项，如 DNS、负载均衡器健康检查或内部元数据服务，这样可以在问题显现之前揭示潜在的脆弱性。结合明确的事件响应计划——涵盖 DNS 重建、内部操作限流以及压力之下的可控扩展——企业能够确保自身更充分地做好准备。正如我们在此次服务中断中所看到的那样，就连亚马逊云科技也需要通过限制 EC2 实例启动来恢复稳定性，这凸显了建立预定义流程以应对级联故障的重要性。

原文链接：

https://www.infoq.com/news/2025/11/aws-disruption-cloud/