亚马逊云科技服务中断暴露了关键云基础设施的脆弱性
来源: InfoQ - AI＆大模型
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实例启动来恢复稳定性，这凸显了建立预定义流程以应对级联故障的重要性。
原文链接：