一个DNS漏洞引发了AWS云服务的中断

针对最近发生的云服务中断，亚马逊已发布一份详细的事后分析报告，解释了其DynamoDB数据库的DNS管理系统中一个关键故障，如何引发了一场持续一整天的大规模中断，影响了旗下多个品牌的众多重要网站与服务，造成的经济损失估计可能高达数千亿美元。

此次事件始于美国太平洋时间10月19日晚上11:48（世界标准时间10月20日7:48），当时用户报告称，在美国东部弗吉尼亚（US-EAST-1）区域，DynamoDB的API错误率显著上升。根本原因在于DynamoDB的自动化DNS管理系统中存在一个“竞争条件”（race condition）漏洞，导致该服务区域端点的DNS记录被清空。

该DNS管理系统由两个独立组件构成（出于高可用性考虑）：一个DNS Planner（DNS规划器），负责监控负载均衡器的健康状况并生成DNS更新计划；另一个是DNS Enactor（DNS执行器），负责通过Amazon Route 53实施这些变更。

亚马逊在事后报告中指出，错误率上升是由其自动化DNS管理系统中的“潜在缺陷”所触发。

当其中一个DNS执行器出现“异常高延迟”时，DNS规划器仍在继续生成新的更新计划。就在此时，第二个DNS执行器开始应用较新的计划，并启动清理流程，而第一个执行器也恰好完成了延迟的运行。这次清理操作将旧的计划误判为过期并删除，导致区域端点的所有IP地址被立即移除，系统进入不一致状态，致使任何DNS执行器都无法再进行自动化更新。

在人工干预之前，所有试图连接DynamoDB的系统（包括用户流量和AWS内部服务）都遭遇了DNS解析失败。事后报告指出，这影响了EC2实例的启动和网络配置。

负责管理运行EC2实例的物理服务器租约的DropletWorkflow Manager（DWFM）依赖于DynamoDB。由于DNS故障导致DWFM的状态检查失败，这些被称为“droplets”的EC2服务器无法为实例状态变更建立新的租约。

在DynamoDB于太平洋时间10月20日凌晨2:25（世界标准时间9:25）恢复后，DWFM试图为整个EC2服务器集群重新建立租约。但由于规模巨大，该过程耗时过长，许多租约在完成前就已超时，导致DWFM陷入“拥塞崩溃”（congestive collapse）状态，需要人工干预，直到太平洋时间早上5:28（世界标准时间12:28）才得以解决。

随后，网络管理器（Network Manager）开始处理大量积压的延迟网络配置，导致新启动的EC2实例遭遇网络配置延迟。

这些网络传播延迟进一步影响了网络负载均衡器（NLB）服务。NLB的健康检查子系统因网络延迟导致新EC2实例健康检查失败而将其移除，但后续检查成功后又将其恢复，造成反复震荡。

由于EC2实例的启动受阻，依赖它的多项服务，包括Lambda、弹性容器服务（ECS）、弹性Kubernetes服务（EKS）和Fargate，均相继出现故障。

目前，亚马逊已在全球范围内禁用DynamoDB的DNS规划器和DNS执行器的自动化功能，直到部署足够的防护措施以防止此类竞争条件再次发生。

亚马逊在道歉声明中表示：“在我们继续深入分析此次事件对所有AWS服务的影响过程中，我们将寻找更多方法，避免未来发生类似事件造成的影响，并进一步缩短恢复时间。”

这场持续时间较长的中断在当天对众多网站和服务造成了广泛影响，甚至波及政府服务。一些估计认为，由此引发的混乱和经济损失最终可能高达数千亿美元。