AWS 故障报告：DNS 机制失灵「信号灯」灭了

DynamoDB 系统故障波及众多 AWS 服务，导致各大网站瘫痪数小时。

亚马逊发布了一份详细的事后分析报告，解释了 DynamoDB DNS 管理系统的一个严重故障如何导致持续一天的宕机，进而导致各大网站和众多品牌的服务中断，损失估计可能高达数千亿美元。

这起事件始于太平洋夏令时间 10 月 19 日晚上 11 点 48 分（UTC 时间 10 月 20 日 7 点 48 分），当时客户报告北弗吉尼亚 US-EAST-1 区域的 DynamoDB API 错误率上升。

根本原因是 DynamoDB 的自动化 DNS 管理系统中的一个竞态条件导致该服务区域端点的 DNS 记录为空。

DNS 管理系统由两个独立组件组成（出于确保可用性的考虑）：监控负载均衡器运行状况并创建 DNS 计划的 DNS Planner，以及通过 Amazon Route 53 确保更改生效的 DNS Enactor。

亚马逊的事后分析报告称，错误率是由该服务的自动化 DNS 管理系统中的“潜在缺陷”触发的。

当一个 DNS Enactor 遇到“异常高的延迟”，而 DNS Planner 仍在继续生成新计划时，竞态条件就发生了。第二个 DNS Enactor 开始让较新的计划生效，并在第一个 Enactor 完成延迟运行后执行了清理过程。此番清理删除了较旧的计划（视为过时的计划），立即清除了区域端点的所有 IP 地址，使系统处于不一致状态，从而阻止任何 DNS Enactor 实施的进一步自动更新。

在手动干预之前，连接到 DynamoDB 的系统出现了 DNS 故障，包括客户流量和内部 AWS 服务。事后分析报告称，这影响了 EC2 实例启动和网络配置。

DropletWorkflow Manager（DWFM）负责维护托管 EC2 实例的物理服务器的租约，它依赖 DynamoDB。当 DNS 故障导致 DWFM 状态检查失败时，EC2 服务器（droplet）无法为实例状态更改建立新的租约。

DynamoDB 于太平洋夏令时间凌晨 2 点 25 分（UTC 时间上午 9 点 25 分）恢复后，DWFM 尝试为整个 EC2 集群重新建立租约。由于规模庞大，整个过程耗时很长，租约在完成之前就开始超时，导致 DWFM 进入“拥塞崩溃”状态，需要手动干预，直到太平洋夏令时间凌晨 5 点 28 分（UTC 时间下午 12 点 28 分）。

接下来，Network Manager 开始传播大量积压的延迟网络配置，导致新启动的 EC2 实例出现网络配置延迟。

这些网络传播延迟影响了网络负载均衡器（NLB）服务。 NLB 的健康检查子系统移除了因网络延迟而未通过健康检查的新 EC2 实例，结果却在后续检查成功后恢复了这些实例。

由于 EC2 实例启动受阻，包括Lambda、Elastic Container Service（ECS）、Elastic Kubernetes Service（EKS）和 Fargate 在内的相关服务均出现问题。

AWS 已在全球范围内禁用了 DynamoDB DNS Planner 和 DNS Enactor 自动化功能，直至安全措施到位，以防竞态条件再次发生。

亚马逊在道歉声明中表示：“我们正在继续研究影响这此事件的细节，寻找其他方法来避免未来类似事件的影响以及如何进一步缩短恢复时间。”

这次长时间中断在一天内影响了众多网站和服务，政府服务也受到影响。有人估计，由此造成的混乱和损失可能高达数千亿美元。

我们使用一个比喻描述下发生了什么。大型城市交通系统陷入“信号灯全暗、出入口阻塞”的混乱。

有一座繁忙的大都市 —— 我们叫它「云城」。这座城市里有几条关键的交通干道、几十条支路，还有数百条公交、出租、货运线路，它们每天为数百万居民和企业提供流转服务。

在这座城市中心，有一个“城市导航系统”（类似城市的“主干交通总指挥中心”），负责给所有车辆、巴士、货车指明路线、开放道路、切换信号灯、分配交通资源。这套系统运行多年、十分自动化。

某天晚上，这个导航系统中的一个「自动信号调度模块」出现了一个“竞态（race-condition）”错误。

换言之：本该“先关闭旧信号→再启用新信号”这一顺序被打乱了，导致在一个区域的所有入口信号灯 突然全部熄灭 —— 车辆此时“找不到通行路线”，只能停在原地。

这个“入口信号灯全暗”就像 Amazon DynamoDB 的地区端点 (dynamodb.us-east-1.amazonaws.com) 的 DNS 记录“突然变成空白”，外部服务无法再“拨号／定位”到数据库。 

当城市里的主干道封锁后，公交无法出发、地铁换乘站停摆、货运卡车进出港口受阻 —— 整个城市交通体系开始连锁崩溃。

在这个比喻中：

• 公交 /出租 ≈ AWS 的 EC2 实例／Lambda／容器服务等。

• 货运卡车／港口 ≈ AWS 的 NLB（网络负载均衡）／实例网络配置／健康检查机制。

• 所有这些都依赖“导航系统”的正常运行。

然后，当导航系统恢复信号灯时（DNS 记录被修复），并不意味着城市立刻回到正常。

因为：车辆排起长龙等待通行、交通阻塞带来积压、一些路口被关闭导致绕行、系统还要重新校准。

于是交通恢复过程分阶段：先恢复公交路线，再恢复货运，再恢复重型卡车通道。

在 AWS 事件中：DNS 记录的恢复只是第一步，紧接着是 EC2 实例启动流程积压（比喻：货运堆在港口）、网络配置延迟（比喻：绕行路线／信号同步慢）、NLB 健康检查误判（比喻：交叉路口仍被误关闭）等。

整个恢复过程持续了数小时。 

最终，当所有车辆、卡车、货运、公交都恢复了路线，城市交通才算真正重启。

但此刻人们已经感受到：这座城市虽恢复运行，但原有的“设计”暴露了某些潜在脆弱性 —— 如果导航系统再出故障，波及范围可能更大。

比喻里：就像城市管理者决定“对信号系统做大修，增设人工备份、加快路口切换”等改进措施。AWS 也在事后宣布将禁用出问题的自动化模块、加强限流、改进恢复机制。 

为什么“延迟”导致无法判断新旧方案 ？

在本次事件中，AWS 在其北弗吉尼亚（US‑EAST‑1）区域的 Amazon DynamoDB API 端点出现 DNS 解析问题。 

其 DNS 管理系统设计为：一个“规划器（planner）”预先生成变更计划，再由多个“执行器（enactor）”在不同可用区内将这些计划写入 DNS（即把旧的 DNS 指向替换为新的指向／记录版本）。在正常状态下，这能确保平滑迁移／切换。

但在这次事件中，一个执行器落后、另一个执行器先做了新方案、再旧方案被错误地覆盖回去，从而造成 DNS 记录“先被删”“再被旧记录意外恢复”或“新旧混淆”的状态。

关键原因：

1、分布式更新延迟（Execution Lag）

当多个执行器在不同可用区并行执行 DNS 更新时，如果一个执行器速度慢、落后于其他执行器，就可能在其他执行器已经完成“切换”后，仍然以旧方案为基础去执行。这样，在系统整体看来，某些节点／用户看到的是新方案，而其他节点却还在旧方案。

由于各可用区的传播时间、缓存刷新时间、节点健康状态判定不同，难以同步清晰判断“现在生效的是哪一个方案”。

2、竞争条件（Race Condition）

如果控制逻辑中没有正确地序列化“删除旧计划 → 启用新计划”这一过程，而是多个执行器几乎同时或冲突地操作，就会发生“执行器 A 先删除旧方案，再启用新方案；执行器 B 滞后后又错误地启用了旧方案”这种情形。因为其间的延迟，系统状态会在一段时间内处于“旧方案与新方案并存”的模糊地带。

换言之：系统无法准确判断“哪一条 DNS 记录是最新的／哪一条是有效的”——因为几乎同时有多个版本在传播。

3、缓存与解析延迟（DNS Cache & Propagation Delay）

即便DNS记录在控制平面更新完毕，客户端与中间网络（例如ISP、本地DNS解析器、操作系统缓存）可能仍然缓存旧记录。这样，某些用户会继续访问“旧方案”中的IP 或服务地址，其他用户则已跳转到“新方案”中的IP。

在这种“多版本并存”的状态下，系统、监控、自动化判断流程就难以区分“哪些解析请求用了新记录”“哪些还在旧记录”，从而造成判断延迟。

4、健康检查／负载均衡状态反馈延迟

在更新方案切换之后，系统通常会通过健康检查机制判定“新方案是否稳定”“旧方案是否可关闭”。但如果健康检查本身因为网络或服务延迟出现延迟或误判，就可能导致控制逻辑无法立即确认“新方案是否完全生效”。这进一步放大了“旧／新方案状态不一致”的窗口。

简化比喻说明：

想象你在一个城市里把所有车辆的红绿灯系统从「旧方式」切换为「新方式」。

各个路口由不同施工队同时执行：队 A 先完成更新、队 B 落后。

在队 A 更新后，一些路口已经使用「新方式」的信号灯，但队 B 仍在「旧方式」运行。

行驶的车辆／司机就会看到一部分路口是新信号、一部分还是旧信号。这时你 无法立刻判断“全城现在到底是哪种方案在跑”。

加上有些司机还在「旧信号」的习惯中，或者路口还缓存旧灯状态，切换过程中延迟导致混乱。

健康检查（检测新信号灯是否可靠）也可能因为交通拥堵／检测延迟而无法立即确定「新方案可以全面开启、旧方案可以关闭」。

同理，在AWS 这次事件中：更新了 DNS 指向（“新方案”）但执行器之间／缓存之间／健康检查之间都存在延迟，导致“旧记录”“新记录”在不同节点并存，从而系统一时间无法确认“哪一种才是最新版、哪一种应被淘汰”。

AWS 故障报告

我们希望向您提供有关 2025 年 10 月 19–20 日在北弗吉尼亚（N. Virginia，us-east-1）区域发生的服务中断的更多信息。虽然此次事件起于 10 月 19 日晚 11:48（PDT），止于 10 月 20 日下午 2:20（PDT），但对客户应用的影响可分为三个明确阶段。

第一阶段：10 月 19 日 11:48 PM 至 10 月 20 日 2:40 AM，Amazon DynamoDB 在北弗吉尼亚（us-east-1）区域出现 API 错误率上升。

第二阶段：10 月 20 日 5:30 AM 至 2:09 PM，Network Load Balancer（NLB）在该区域的部分负载均衡器上出现连接错误增多，起因是 NLB 机群的健康检查失败，导致部分 NLB 的连接错误升高。

第三阶段：10 月 20 日 2:25 AM 至 10:36 AM，新的 EC2 实例启动失败；虽自 10:37 AM 起实例启动开始成功，但部分新启动的实例出现连通性问题，至 1:50 PM 才得以解决。

DynamoDB

在 10 月 19 日 11:48 PM（PDT）至 10 月 20 日 2:40 AM（PDT） 期间，北弗吉尼亚（us-east-1）区域的客户遇到 Amazon DynamoDB API 错误率上升。在此期间，客户以及依赖 DynamoDB 的其他 AWS 服务都无法与该服务建立新的连接。该事故由服务自动化 DNS 管理系统中的一个潜在缺陷触发，导致 DynamoDB 端点解析失败。

许多规模最大的 AWS 服务都高度依赖 DNS，以实现无缝扩展、故障隔离与恢复、低延迟和就近性。像 DynamoDB 这样的服务在每个区域都维护着数十万条 DNS 记录，以运营一个非常庞大、异构的负载均衡器机群。自动化对确保这些 DNS 记录得到高频更新至关重要：当新增容量可用时及时纳入、在硬件故障时正确处置、并高效分配流量以优化客户体验。这套自动化已按高弹性设计，使服务能够从多种运营问题中恢复。除公共区域端点外，该自动化还为多个动态的 DynamoDB 变体维护额外的 DNS 端点，包括符合 FIPS 的端点、IPv6 端点以及账户专属端点。此次问题的根本原因，是 DynamoDB DNS 管理系统中的潜在竞态条件（race condition），它导致该服务的区域端点（dynamodb.us-east-1.amazonaws.com）被错误地置为空的 DNS 记录，且自动化未能修复。为解释此次事件，我们需要介绍 DynamoDB DNS 管理架构的一些细节。出于可用性考虑，系统被拆分为两个独立组件。第一组件 DNS Planner（规划器） 负责监控负载均衡器的健康与容量，并定期为服务的每个端点创建新的 DNS 计划（由一组负载均衡器及其权重构成）。我们只生成单一区域 DNS 计划，因为当多个端点共享容量（如新推出的 IPv6 端点与公共区域端点）时，这能极大简化容量管理与故障处置。第二组件 DNS Enactor（执行器） 以最小依赖设计，以便在任何场景下都可恢复系统；它通过在 Amazon Route 53 中应用必要变更来执行 DNS 计划。为增强韧性，DNS Enactor 在三个不同的可用区（AZ）冗余且完全独立地运行。每个独立的 DNS Enactor 实例都会寻找新计划，并尝试通过一次 Route 53 事务将当前计划替换为新计划，从而保证即使多个 DNS Enactor 并发尝试更新，也能让每个端点以一致的计划被更新。此次竞态条件涉及两个 DNS Enactor 之间一次小概率的交互。在正常情况下，DNS Enactor 会获取最新计划并开始依次对服务端点应用该计划。此过程通常很快，且能有效保持 DNS 状态的实时更新。在应用新计划之前，DNS Enactor 会进行一次性检查，确认其计划较之前应用的计划更新。当 DNS Enactor 沿着端点列表推进时，如果在尝试事务时被另一台正在更新同一端点的 DNS Enactor 阻塞，就可能出现延迟。在这种情况下，该 DNS Enactor 会对每个端点进行重试，直到计划成功应用到所有端点。就在事件开始前，有一台 DNS Enactor 在多个 DNS 端点的更新上出现异常高的延迟，需要多次重试。当它缓慢推进端点时，几件事同时发生：其一，DNS Planner 持续运行并产生了更多新一代的计划；其二，另一台 DNS Enactor 随后开始应用这些更新的计划，并快速完成所有端点的更新。这些事件的时序触发了潜伏的竞态条件：当第二台（应用最新计划的）Enactor 完成端点更新后，启动了计划清理流程，识别并删除相较其刚应用计划陈旧许多代的旧计划。就在清理流程启动的同时，第一台（此前异常延迟的）Enactor 把自己更早一代的旧计划应用到区域 DDB 端点上，覆盖了较新的计划。由于 Enactor 处理延迟异常之久，最初那次“新旧比对”检查此时已过期（stale），因此无法阻止旧计划覆盖新计划。紧接着，第二台 Enactor 的清理流程因为该旧计划相对其最新计划已陈旧许多代而将其删除。随着该计划被删除，区域端点的所有 IP 地址被立刻移除。此外，由于活跃计划被删除，系统陷入不一致状态，任何 DNS Enactor 随后都无法再对其应用更新。此情形最终需要人工运维介入纠正。

当问题在 11:48 PM（PDT） 发生时，所有需要通过公共端点连接北弗吉尼亚（us-east-1）区域的 DynamoDB 服务的系统，立刻出现 DNS 解析失败，无法连接到 DynamoDB。这既包括客户流量，也包括依赖 DynamoDB 的 AWS 内部服务流量。拥有 DynamoDB 全球表的客户能够成功连接并向其他区域的副本表发起请求，但与北弗吉尼亚（us-east-1）区域的副本表之间出现长时间复制延迟。受影响 AWS 服务的工程团队立即介入并开始排查。到 10 月 20 日 12:38 AM，我们的工程师已将故障根源定位为 DynamoDB 的 DNS 状态。1:15 AM 起，所采取的临时缓解措施使部分内部服务能够连接 DynamoDB，并修复了关键的内部工具，为后续恢复扫清障碍。2:25 AM，所有 DNS 信息恢复；2:32 AM，所有全球表副本已完全追平。随着缓存的 DNS 记录在 2:25–2:40 AM 之间陆续过期，客户能够解析到 DynamoDB 端点并建立成功连接。至此，本次主要服务中断事件的恢复完成。

Amazon EC2

在 10 月 19 日 11:48 PM（PDT）至 10 月 20 日 1:50 PM（PDT） 期间，北弗吉尼亚（us-east-1）区域的客户遇到 EC2 API 错误率上升、时延增大，以及实例启动失败。在事件开始之前已启动的 EC2 实例保持健康，整个事件期间未受影响。2:25 AM（PDT） 解决 DynamoDB DNS 问题后，客户在新实例启动上仍看到更多错误。12:01 PM（PDT） 开始恢复，1:50 PM（PDT） EC2 完全恢复。在此期间，新实例启动失败时返回的错误为 “request limit exceeded（请求限额超出）”或“insufficient capacity（容量不足）”。

要理解发生了什么，我们需要介绍几个用于管理 EC2 实例启动以及为新启动实例配置网络连通性的子系统。第一是 Droplet Workflow Manager（DWFM），负责管理用于承载 EC2 实例的所有底层物理服务器——我们称这些服务器为 “droplets”。第二是 Network Manager，负责管理并向所有 EC2 实例及网络设备传播网络状态。每个 DWFM 在各可用区管理一组 droplets，并为当前托管的每台 droplet 维护一个租约（lease）。该租约使 DWFM 能跟踪 droplet 的状态，确保 EC2 API 的所有动作或来自实例自身的操作（如由操作系统发起的关机或重启）都能在更广泛的 EC2 系统中体现出正确的状态变更。作为维持租约的一部分，每台 DWFM 主机必须每隔几分钟与其管理的每台 droplet 进行一次签到并完成状态检查。

从 10 月 19 日 11:48 PM（PDT） 开始，这些 DWFM 的状态检查因其依赖 DynamoDB而无法完成，遂开始失败。虽然这未影响任何正在运行的 EC2 实例，但它导致 droplet 在对其所承载的 EC2 实例进行进一步状态变更前，必须先与某个 DWFM 重新建立租约。在 10 月 19 日 11:48 PM 至 10 月 20 日 2:24 AM 之间，EC2 机群中 DWFM 与 droplets 的租约开始逐步超时。

2:25 AM（PDT），随着 DynamoDB API 恢复，DWFM 开始在 EC2 机群中与 droplets 重新建立租约。由于任何没有有效租约的 droplet 都不能作为新 EC2 启动的候选，EC2 API 对新进入的启动请求返回了“容量不足”错误。DWFM 着手在整个 EC2 机群内重建 droplet 租约；然而，由于 droplets 数量极大，建立新租约所需时间过长，以至在完成前就再次超时。系统把更多工作排队，准备再次尝试建立租约。此时，DWFM 陷入一种拥塞性崩溃（congestive collapse）状态，无法在恢复 droplet 租约方面取得前进。鉴于该情形没有既定的运维恢复流程，工程师在尝试修复 DWFM 时十分谨慎，以避免引入更多问题。经过多轮缓解手段后，4:14 AM 工程师对进入的工作实施限流，并开始选择性重启 DWFM 主机以摆脱困境。重启 DWFM 主机清空了其队列、降低了处理时间，使得能够成功建立 droplet 租约。到 5:28 AM，DWFM 已与北弗吉尼亚（us-east-1）区域内所有 droplets 建立起租约，新实例启动开始再度成功；不过，因此前为降低整体请求负载而引入了请求限流，许多请求仍会遇到 “request limit exceeded” 错误。

当新 EC2 实例启动后，一套名为 Network Manager 的系统会传播网络配置，使实例能与同一 VPC 内的其他实例、其他 VPC 的网络设备以及互联网通信。5:28 AM（PDT），在 DWFM 恢复不久后，Network Manager 开始向新启动的实例，以及在事件期间被终止的实例传播更新的网络配置。由于这些网络传播事件此前被 DWFM 问题所延迟，北弗吉尼亚（us-east-1）区域内需要由 Network Manager 处理的网络状态传播积压显著。因此，6:21 AM 起，Network Manager 在处理这批积压的网络状态变更时，网络传播时延开始升高。虽然新的 EC2 实例可以成功启动，但由于网络状态传播的延迟，它们尚无必要的网络连通性。工程师通过降低 Network Manager 负载并采取行动加速恢复。到 10:36 AM，网络配置传播时间恢复正常，新 EC2 实例的启动也再次恢复到正常状态。

迈向 EC2 恢复的最后一步，是完全移除此前为降低各 EC2 子系统负载而设置的请求限流。随着 API 调用与新实例启动请求趋稳，11:23 AM（PDT） 我们的工程师开始放宽请求限流，向全面恢复推进。1:50 PM，所有 EC2 API 与新实例启动均恢复正常。

Network Load Balancer（NLB）

新启动实例的网络状态传播延迟也对 NLB 服务及使用 NLB 的 AWS 服务产生了影响。10 月 20 日 5:30 AM 至 2:09 PM（PDT） 间，北弗吉尼亚（us-east-1）区域内，部分客户在其 NLB 上遇到了连接错误增加。NLB 构建在高度可扩展的多租户架构之上，向后端目标（通常是 EC2 实例）提供负载均衡端点并进行流量路由。该架构还使用了独立的健康检查子系统，定期对 NLB 架构内的所有节点执行健康检查，并将被判为不健康的节点移出服务。

事件期间，NLB 的健康检查子系统出现健康检查失败增多。原因在于：健康检查子系统将新 EC2 实例纳入服务时，这些实例的网络状态尚未完全传播到位。于是，在某些情况下，即便底层 NLB 节点和后端目标是健康的，健康检查仍会失败，导致健康检查结果在“失败/健康”之间反复。这使得 NLB 节点和后端目标被从 DNS 中移除，而在下一次健康检查成功时又被加回。

我们的监控系统在 6:52 AM 发现这一情况，工程师开始着手修复。此类交替的健康检查结果给健康检查子系统带来更高负载，致其退化，引发健康检查延迟并触发自动 AZ 级 DNS 故障切换。对于多 AZ 负载均衡器，这会使部分容量被移出服务。在这种情况下，如果剩余健康容量不足以承担应用负载，应用就会出现连接错误增加。9:36 AM，工程师为 NLB 禁用了自动健康检查故障切换，使所有可用且健康的 NLB 节点与后端目标得以回归服务，从而解决受影响负载均衡器上的连接错误问题。在 EC2 恢复后不久，我们于 2:09 PM 重新启用了自动 DNS 健康检查故障切换。

其他 AWS 服务

10 月 19 日 11:51 PM 至 10 月 20 日 2:15 PM（PDT），北弗吉尼亚（us-east-1）区域内，客户在使用 Lambda 函数时遇到 API 错误与时延。最初，DynamoDB 端点问题导致函数创建与更新受阻、SQS/Kinesis 事件源处理延迟以及调用错误。到 2:24 AM，除 SQS 队列处理外，服务操作均已恢复；SQS 仍受影响，原因是一套负责轮询 SQS 队列的内部子系统失败且未自动恢复。我们在 4:40 AM 恢复了该子系统，并于 6:00 AM 处理完所有消息积压。7:04 AM 起，NLB 健康检查失败触发了实例终止，使得一部分 Lambda 内部系统容量不足。在 EC2 启动仍受损的情况下，我们对 Lambda 事件源映射 和 异步调用 实施限流，以优先保障对时延敏感的同步调用。11:27 AM，容量恢复到充足水平，错误回落。随后我们逐步降低限流，并在 2:15 PM 前处理完所有积压，服务恢复正常运行。

10 月 19 日 11:45 PM 至 10 月 20 日 2:20 PM（PDT），客户在 Amazon ECS / EKS / Fargate 上遇到容器启动失败与集群扩缩容延迟。这些服务于 2:20 PM 恢复。

10 月 19 日 11:56 PM 至 10 月 20 日 1:20 PM（PDT），Amazon Connect 客户在处理呼叫、聊天与工单时遇到更高错误率。DynamoDB 端点恢复后，大多数 Connect 功能亦恢复，但客户在聊天方面的错误一直持续到 5:00 AM。7:04 AM 起，客户再度在新呼叫、聊天、任务、邮件与工单处理中遭遇错误，成因包括：Connect 所使用的 NLB 受影响，以及 Lambda 函数调用的错误率与时延升高。入线来电的呼叫者会听到忙音、错误信息或连接失败；坐席发起和通过 API 发起的外呼均失败；已接通的通话会出现提示播放失败、路由到坐席失败或“无声”音频；此外，坐席在处理联系时错误升高，部分坐席无法登录。客户在访问 API 与 “Contact Search” 时也遇到更高错误率。实时与历史型仪表盘、数据湖的数据更新出现延迟，所有数据将在 10 月 28 日前补齐。随着 Lambda 调用错误恢复，服务可用性在 1:20 PM 得到恢复。

10 月 19 日 11:51 PM 至 9:59 AM（PDT），客户在 AWS Security Token Service（STS） 上遇到 API 错误与时延。内部 DynamoDB 端点恢复后，1:19 AM STS 恢复。8:31 AM–9:59 AM，受 NLB 健康检查失败影响，STS 的 API 错误率与时延再次升高；9:59 AM 我们从该问题中恢复，服务恢复正常。

10 月 19 日 11:51 PM 至 10 月 20 日 1:25 AM（PDT），尝试以 IAM 用户 登录 AWS 管理控制台 的客户因北弗吉尼亚（us-east-1）区域的底层 DynamoDB 问题而出现认证失败增加。在北弗吉尼亚（us-east-1）区域配置了 IAM Identity Center 的客户也无法通过该中心登录。使用根凭证以及配置为使用 signin.aws.amazon.com 的联合身份的客户，在北弗吉尼亚以外的区域尝试登录 AWS 管理控制台时也会遇到错误。随着 1:25 AM DynamoDB 端点恢复可访问，服务恢复正常。

10 月 19 日 11:47 PM 至 10 月 20 日 2:21 AM（PDT），客户在北弗吉尼亚（us-east-1）区域创建、修改 Redshift 集群或对现有集群发起查询时遇到 API 错误。Redshift 的查询处理依赖 DynamoDB 端点来读写集群数据。随着 DynamoDB 端点恢复，Redshift 查询操作恢复；2:21 AM 起，Redshift 客户可以成功查询集群并创建/修改集群配置。然而，在 DynamoDB 端点恢复到正常运行后，部分 Redshift 计算集群仍然受损，无法进行查询。由于集群节点的凭证到期未能刷新，Redshift 自动化触发了用新 EC2 实例替换底层主机的工作流；但鉴于 EC2 启动受损，这些工作流被阻塞，使集群处于“modifying”状态，既无法处理查询，也使集群对工作负载不可用。6:45 AM 我们采取行动阻止工作流积压进一步增长；2:46 PM 当 Redshift 集群开始启动替换实例后，工作流积压开始消退。到 10 月 21 日 4:05 AM（PDT），AWS 运维完成了对因替换工作流受损的集群的可用性恢复。除集群可用性受损外，10 月 19 日 11:47 PM 至 10 月 20 日 1:20 AM（PDT） 期间，由于 Redshift 存在一个使用北弗吉尼亚（us-east-1）区域的某个 IAM API 来解析用户组的缺陷，所有区域的 Amazon Redshift 客户在使用 IAM 用户凭证执行查询时都无法成功；因此，在该时段 IAM 的受损使 Redshift 无法执行这些查询。使用“本地（local）”用户连接其 Redshift 集群的其他区域客户不受影响。

其他依赖 DynamoDB、新的 EC2 实例启动、Lambda 调用和 Fargate 任务启动的 AWS 服务（例如 Managed Workflows for Apache Airflow、Outposts 生命周期操作、AWS Support Center）在北弗吉尼亚（us-east-1）区域也受到影响。

鉴于此次运维事件，我们正在采取多项变更。我们已在全球范围内禁用 DynamoDB 的 DNS Planner 与 DNS Enactor 自动化。在重新启用之前，我们将修复此次竞态情景，并增加额外防护，以防止错误的 DNS 计划被应用。对于 NLB，我们将增加速率控制机制，限制当健康检查失败导致 AZ 级故障切换时，单个 NLB 可移除的容量。对于 EC2，我们将新增一套测试，以补充现有的规模化测试，专门演练 DWFM 的恢复工作流，以识别未来可能的回归。我们还将改进 EC2 数据传播系统中的限流机制，使其能根据等待队列规模对进入的工作进行速率限制，以在高负载期间保护服务。最后，随着我们持续在所有 AWS 服务中深入复盘此次事件，我们将寻找更多方法以避免今后发生类似事件的影响，并进一步缩短恢复时间。

结语

对于此次事件给客户带来的影响，我们深表歉意。尽管我们在以极高可用性运营服务方面有着良好记录，但我们也深知我们的服务对于客户、他们的应用与终端用户以及他们的业务至关重要。我们清楚这次事件对许多客户造成了显著影响。我们将竭尽全力从这次事件中汲取教训，并用以进一步提升我们的可用性。

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。