摘要：2025年10月19-20日，北弗吉尼亚区域发生服务中断。主要影响DynamoDB、EC2、NLB等服务。起因是DynamoDB DNS系统缺陷引发连锁反应。AWS已致歉并承诺改进系统。
2025年10月19-20日，北弗吉尼亚区域发生服务中断。主要影响DynamoDB、EC2、NLB等服务。起因是DynamoDB DNS系统缺陷引发连锁反应。AWS已致歉并承诺改进系统。
译自：Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region
作者：[no-author]
我们希望为您提供一些关于 2025 年 10 月 19 日和 20 日在北弗吉尼亚（us-east-1）区域发生的服务中断的额外信息。尽管事件始于 10 月 19 日太平洋夏令时晚上 11:48，并于 10 月 20 日太平洋夏令时下午 2:20 结束，但客户应用程序受到了三个不同阶段的影响。首先，在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:40 之间，Amazon DynamoDB 在北弗吉尼亚（us-east-1）区域经历了 API 错误率的增加。其次，在 10 月 20 日上午 5:30 到下午 2:09 之间，网络负载均衡器 (NLB) 在北弗吉尼亚（us-east-1）区域的某些负载均衡器上经历了连接错误的增加。这是由于 NLB 集群中的健康检查失败引起的，导致某些 NLB 上的连接错误增加。第三，在 10 月 20 日凌晨 2:25 到上午 10:36 之间，新的 EC2 实例启动失败；尽管实例启动从上午 10:37 开始成功，但一些新启动的实例遇到了连接问题，这些问题在下午 1:50 之前得到了解决。
DynamoDB
在 10 月 19 日太平洋夏令时晚上 11:48 到 10 月 20 日太平洋夏令时凌晨 2:40 之间，客户在北弗吉尼亚（us-east-1）区域经历了 Amazon DynamoDB API 错误率的增加。在此期间，客户和依赖 DynamoDB 的其他 AWS 服务无法与该服务建立新连接。该事件是由服务自动化 DNS 管理系统中的一个潜在缺陷触发的，该缺陷导致 DynamoDB 的端点解析失败。
许多最大的 AWS 服务广泛依赖 DNS 来提供无缝的扩展、故障隔离和恢复、低延迟以及本地性。像 DynamoDB 这样的服务在每个区域维护着数十万条 DNS 记录，以运营一个非常庞大的异构负载均衡器集群。自动化对于确保这些 DNS 记录频繁更新至关重要，以便在可用时增加容量、正确处理硬件故障以及高效分配流量以优化客户体验。这种自动化已被设计为具有弹性，允许服务从各种操作问题中恢复。除了提供公共区域端点外，这种自动化还为几种动态 DynamoDB 变体维护了额外的 DNS 端点，包括符合 FIPS 标准的端点、IPv6 端点和账户特定的端点。此问题的根本原因是 DynamoDB DNS 管理系统中的一个潜在竞争条件，导致服务的区域端点 的 DNS 记录不正确地为空，而自动化未能修复。为了解释此事件，我们需要分享一些关于 DynamoDB DNS 管理架构的细节。出于可用性原因，该系统分为两个独立的组件。第一个组件是 DNS 规划器 (DNS Planner)，它监控负载均衡器的健康状况和容量，并定期为服务的每个端点创建新的 DNS 计划，包括一组负载均衡器和权重。我们生成一个单一的区域 DNS 计划，因为当容量在多个端点之间共享时（如最近启动的 IPv6 端点和公共区域端点），这极大地简化了容量管理和故障缓解。第二个组件是 DNS 执行器 (DNS Enactor)，它被设计为具有最小依赖性，以允许在任何情况下进行系统恢复，并通过在 Amazon Route53 服务中应用所需的更改来执行 DNS 计划。为了弹性，DNS 执行器在三个不同的可用区 (AZ) 中冗余且完全独立地运行。这些 DNS 执行器的每个独立实例都会查找新计划，并尝试通过使用 Route53 事务将当前计划替换为新计划来更新 Route53，确保即使有多个 DNS 执行器同时尝试更新，每个端点也能以一致的计划进行更新。竞争条件涉及两个 DNS 执行器之间不太可能发生的交互。正常工作方式是 DNS 执行器获取最新计划，并开始遍历服务端点以应用此计划。此过程通常很快完成，并且能有效地保持 DNS 状态的最新。在开始应用新计划之前，DNS 执行器会进行一次性检查，确保其计划比之前应用的计划新。当 DNS 执行器遍历端点列表时，可能会遇到延迟，因为它尝试进行事务操作时被另一个 DNS 执行器更新同一端点所阻塞。在这些情况下，DNS 执行器将重试每个端点，直到计划成功应用于所有端点。在此事件开始之前，一个 DNS 执行器经历了异常高的延迟，需要在几个 DNS 端点上重试其更新。当它缓慢地处理这些端点时，其他几件事情也正在发生。首先，DNS 规划器继续运行并生成了许多更新一代的计划。其次，另一个 DNS 执行器随后开始应用其中一个较新的计划，并迅速完成了所有端点的更新。这些事件的时机触发了潜在的竞争条件。当第二个执行器（应用最新计划的执行器）完成其端点更新后，它随即调用了计划清理过程，该过程识别比它刚应用的计划显著旧的计划并将其删除。在调用此清理过程的同时，第一个执行器（经历了异常延迟的执行器）将其较旧的计划应用于区域 DDB 端点，覆盖了较新的计划。由于执行器处理中异常高的延迟，在计划应用过程开始时进行的检查（确保计划比之前应用的计划新）此时已过时。因此，这并没有阻止旧计划覆盖新计划。第二个执行器的清理过程随后删除了这个旧计划，因为它比它刚应用的计划旧了许多代。当此计划被删除时，区域端点的所有 IP 地址立即被移除。此外，由于活动计划被删除，系统处于不一致状态，阻止了任何 DNS 执行器应用后续的计划更新。这种情况最终需要手动操作员干预才能纠正。
当此问题在太平洋夏令时晚上 11:48 发生时，所有需要通过公共端点连接到北弗吉尼亚（us-east-1）区域 DynamoDB 服务的系统立即开始经历 DNS 失败并无法连接到 DynamoDB。这包括客户流量以及依赖 DynamoDB 的内部 AWS 服务的流量。拥有 DynamoDB 全局表的客户能够成功连接到并对其在其他区域的副本表发出请求，但在与北弗吉尼亚（us-east-1）区域的副本表之间经历了长时间的复制延迟。受影响的 AWS 服务的工程团队立即参与并开始调查。到 10 月 20 日凌晨 12:38，我们的工程师已将 DynamoDB 的 DNS 状态确定为中断的根源。到凌晨 1:15，应用的临时缓解措施使一些内部服务能够连接到 DynamoDB，并修复了关键的内部工具，从而为进一步恢复扫清了障碍。到凌晨 2:25，所有 DNS 信息已恢复，所有全局表副本在凌晨 2:32 之前完全追平。客户能够解析 DynamoDB 端点并在凌晨 2:25 到凌晨 2:40 之间缓存的 DNS 记录过期后建立成功连接。这标志着主要服务中断事件的恢复完成。
Amazon EC2
在 10 月 19 日太平洋夏令时晚上 11:48 到 10 月 20 日太平洋夏令时下午 1:50 之间，客户在北弗吉尼亚（us-east-1）区域经历了 EC2 API 错误率、延迟和实例启动失败的增加。在事件开始之前启动的现有 EC2 实例保持健康，并且在整个事件期间没有受到任何影响。在太平洋夏令时凌晨 2:25 解决 DynamoDB DNS 问题后，客户继续看到新实例启动的错误增加。恢复从太平洋夏令时下午 12:01 开始，并在太平洋夏令时下午 1:50 完全恢复 EC2。在此期间，新实例启动失败，并显示“请求超出限制”或“容量不足”错误。
为了理解发生了什么，我们需要分享一些关于用于管理 EC2 实例启动以及为新启动的 EC2 实例配置网络连接的几个子系统的信息。第一个子系统是 DropletWorkflow 管理器 (DWFM)，它负责管理 EC2 用于托管 EC2 实例的所有底层物理服务器——我们将这些服务器称为“droplets”。第二个子系统是网络管理器 (Network Manager)，它负责管理和传播网络状态到所有 EC2 实例和网络设备。每个 DWFM 管理每个可用区内的一组 droplets，并为当前管理下的每个 droplet 维护一个租约。这个租约允许 DWFM 跟踪 droplet 状态，确保来自 EC2 API 或 EC2 实例本身的所有操作，例如源自 EC2 实例操作系统的关机或重启操作，都能在更广泛的 EC2 系统中导致正确的状态更改。作为维护此租约的一部分，每个 DWFM 主机必须每隔几分钟与其管理的每个 droplet 进行签入并完成状态检查。
从 10 月 19 日太平洋夏令时晚上 11:48 开始，这些 DWFM 状态检查开始失败，因为该过程依赖于 DynamoDB 并且无法完成。虽然这没有影响任何正在运行的 EC2 实例，但确实导致 droplet 需要在托管的 EC2 实例发生进一步实例状态更改之前与 DWFM 建立新的租约。在 10 月 19 日晚上 11:48 到 10 月 20 日凌晨 2:24 之间，EC2 集群内 DWFM 与 droplets 之间的租约开始缓慢超时。
在太平洋夏令时凌晨 2:25，随着 DynamoDB API 的恢复，DWFM 开始在整个 EC2 集群中重新建立与 droplets 的租约。由于任何没有活跃租约的 droplet 不被视为新 EC2 启动的候选，EC2 API 对于新的传入 EC2 启动请求返回“容量不足错误”。DWFM 开始在整个 EC2 集群中重新建立与 droplets 的租约；然而，由于 droplet 数量庞大，建立新 droplet 租约的工作耗时过长，以至于在租约超时之前无法完成。额外的任务被排队以重新尝试建立 droplet 租约。此时，DWFM 已进入拥塞崩溃状态，无法在恢复 droplet 租约方面取得进展。由于这种情况没有既定的操作恢复程序，工程师们小心翼翼地尝试解决 DWFM 的问题，同时避免造成进一步的问题。在尝试了多个缓解步骤后，在凌晨 4:14，工程师们限制了传入的工作，并开始选择性地重启 DWFM 主机以从这种情况中恢复。重启 DWFM 主机清除了 DWFM 队列，缩短了处理时间，并允许建立 droplet 租约。到凌晨 5:28，DWFM 已与北弗吉尼亚（us-east-1）区域内的所有 droplets 建立了租约，新的启动再次开始成功，尽管由于为了减少整体请求负载而引入的请求限制，许多请求仍然看到“请求超出限制”错误。
当新的 EC2 实例启动时，一个名为网络管理器 (Network Manager) 的系统会传播网络配置，允许该实例与同一虚拟私有云 (VPC) 内的其他实例、其他 VPC 网络设备和互联网进行通信。在太平洋夏令时凌晨 5:28，DWFM 恢复后不久，网络管理器开始向新启动的实例和在事件期间终止的实例传播更新的网络配置。由于这些网络传播事件被 DWFM 的问题延迟，北弗吉尼亚（us-east-1）区域内需要网络管理器处理大量积压的网络状态传播。因此，在上午 6:21，网络管理器在处理积压的网络状态更改时开始经历网络传播时间的延迟增加。虽然新的 EC2 实例可以成功启动，但由于网络状态传播的延迟，它们将不具备必要的网络连接。工程师们努力减少网络管理器上的负载，以解决网络配置传播时间问题，并采取行动加速恢复。到上午 10:36，网络配置传播时间已恢复正常水平，新的 EC2 实例启动再次正常运行。
EC2 恢复的最后一步是完全移除为减少各种 EC2 子系统负载而设置的请求限制。随着 API 调用和新的 EC2 实例启动请求趋于稳定，在太平洋夏令时上午 11:23，我们的工程师开始放宽请求限制，努力实现全面恢复。到下午 1:50，所有 EC2 API 和新的 EC2 实例启动均正常运行。
网络负载均衡器 (NLB)
新启动的 EC2 实例网络状态传播延迟也对网络负载均衡器 (NLB) 服务和使用 NLB 的 AWS 服务造成了影响。在 10 月 20 日太平洋夏令时上午 5:30 到下午 2:09 之间，部分客户在北弗吉尼亚（us-east-1）区域的 NLB 上经历了连接错误的增加。NLB 构建在一个高度可扩展的多租户架构之上，提供负载均衡端点并将流量路由到后端目标，通常是 EC2 实例。该架构还利用了一个独立的健康检查子系统，该子系统定期对 NLB 架构内的所有节点执行健康检查，并将任何被认为不健康的节点从服务中移除。
在事件期间，NLB 健康检查子系统开始经历健康检查失败的增加。这是由于健康检查子系统在那些实例的网络状态尚未完全传播时将新的 EC2 实例投入使用造成的。这意味着在某些情况下，即使底层 NLB 节点和后端目标是健康的，健康检查也会失败。这导致健康检查在失败和健康之间交替。这导致 NLB 节点和后端目标从 DNS 中移除，仅在下一次健康检查成功时才返回服务。
我们的监控系统在上午 6:52 检测到此问题，工程师们开始着手解决。交替的健康检查结果增加了健康检查子系统的负载，导致其性能下降，从而导致健康检查延迟并触发自动 AZ DNS 故障转移。对于多可用区负载均衡器，这导致容量被从服务中移除。在这种情况下，如果剩余的健康容量不足以承载应用程序负载，应用程序就会经历连接错误的增加。在上午 9:36，工程师禁用了 NLB 的自动健康检查故障转移，允许所有可用的健康 NLB 节点和后端目标恢复服务。这解决了受影响负载均衡器的连接错误增加问题。EC2 恢复后不久，我们在下午 2:09 重新启用了自动 DNS 健康检查故障转移。
其他 AWS 服务
在 10 月 19 日太平洋夏令时晚上 11:51 到 10 月 20 日太平洋夏令时下午 2:15 之间，客户在北弗吉尼亚（us-east-1）区域经历了 Lambda 函数的 API 错误和延迟。最初，DynamoDB 端点问题阻碍了函数创建和更新，导致 SQS/Kinesis 事件源的处理延迟和调用错误。到凌晨 2:24，除 SQS 队列处理外，服务操作均已恢复，因为负责轮询 SQS 队列的内部子系统发生故障且未能自动恢复。我们在凌晨 4:40 恢复了此子系统，并在上午 6:00 之前处理了所有积压的消息。从上午 7:04 开始，NLB 健康检查失败触发了实例终止，导致一部分 Lambda 内部系统容量不足。由于 EC2 启动仍然受损，我们限制了 Lambda 事件源映射和异步调用，以优先处理对延迟敏感的同步调用。到上午 11:27，足够的容量已恢复，错误也随之减少。随后，我们逐步减少了限制，并在下午 2:15 之前处理了所有积压，服务恢复正常运行。
在 10 月 19 日太平洋夏令时晚上 11:45 到 10 月 20 日太平洋夏令时下午 2:20 之间，客户在北弗吉尼亚（us-east-1）区域的 Amazon Elastic Container Service (ECS)、Elastic Kubernetes Service (EKS) 和 Fargate 上都经历了容器启动失败和集群扩缩延迟。这些服务在下午 2:20 之前恢复。
在 10 月 19 日太平洋夏令时晚上 11:56 到 10 月 20 日太平洋夏令时下午 1:20 之间，Amazon Connect 客户在北弗吉尼亚（us-east-1）区域处理呼叫、聊天和案例时经历了错误率的升高。在 DynamoDB 端点恢复后，大多数 Connect 功能恢复，但客户在处理聊天时继续遇到高错误率，直到凌晨 5:00。从上午 7:04 开始，客户再次经历了处理新呼叫、聊天、任务、电子邮件和案例时错误率的增加，这是由于 Connect 使用的 NLB 受到了影响以及 Lambda 函数调用错误率和延迟的增加所致。入站呼叫者听到忙音、错误消息或连接失败。代理发起和 API 发起的出站呼叫均失败。已接听的呼叫经历了提示播放失败、路由到代理失败或无声。此外，代理在处理联系人时经历了错误率的升高，一些代理无法登录。客户在访问 API 和联系人搜索时也面临着高错误率。实时、历史仪表板和数据湖数据更新被延迟，所有数据将在 10 月 28 日之前回填。随着 Lambda 函数调用错误恢复，服务可用性在下午 1:20 恢复。
在 10 月 19 日晚上 11:51 到上午 9:59 太平洋夏令时之间，客户在北弗吉尼亚（us-east-1）区域经历了 AWS 安全令牌服务 (STS) API 错误和延迟。在内部 DynamoDB 端点恢复后，STS 在凌晨 1:19 恢复。在上午 8:31 到上午 9:59 之间，由于 NLB 健康检查失败，STS API 错误率和延迟再次增加。到上午 9:59，我们从 NLB 健康检查失败中恢复，服务开始正常运行。
在 10 月 19 日太平洋夏令时晚上 11:51 到 10 月 20 日太平洋夏令时凌晨 1:25 之间，尝试使用 IAM 用户登录 AWS 管理控制台的 AWS 客户由于北弗吉尼亚（us-east-1）区域底层的 DynamoDB 问题，经历了认证失败的增加。在北弗吉尼亚（us-east-1）区域配置了 IAM 身份中心的客户也无法使用身份中心登录。使用其根凭证的客户，以及配置为使用 signin.aws.amazon.com 进行身份联合的客户，在尝试登录北弗吉尼亚（us-east-1）区域以外区域的 AWS 管理控制台时遇到了错误。随着 DynamoDB 端点在凌晨 1:25 变得可访问，服务开始正常运行。
在 10 月 19 日太平洋夏令时晚上 11:47 到 10 月 20 日太平洋夏令时凌晨 2:21 之间，客户在北弗吉尼亚（us-east-1）区域创建和修改 Redshift 集群或对现有集群发出查询时经历了 API 错误。Redshift 查询处理依赖于 DynamoDB 端点来从集群读取和写入数据。随着 DynamoDB 端点恢复，Redshift 查询操作恢复，到凌晨 2:21，Redshift 客户成功查询集群以及创建和修改集群配置。然而，在 DynamoDB 端点恢复正常运行后，一些 Redshift 计算集群仍然受损且无法查询。由于集群节点的凭证在未刷新时过期，Redshift 自动化会触发工作流，将底层 EC2 主机替换为新实例。由于 EC2 启动受损，这些工作流被阻塞，使集群处于“修改中”状态，从而阻止查询处理并使集群无法用于工作负载。在上午 6:45，我们的工程师采取行动阻止工作流积压的增加，当 Redshift 集群在下午 2:46 开始启动替换实例时，工作流的积压开始减少。到 10 月 21 日太平洋夏令时凌晨 4:05，AWS 运营商完成了恢复因替换工作流而受损的集群的可用性。除了集群可用性受损外，在 10 月 19 日晚上 11:47 到 10 月 20 日凌晨 1:20 之间，所有 AWS 区域的 Amazon Redshift 客户都无法使用 IAM 用户凭证执行查询，原因是 Redshift 的一个缺陷使用了北弗吉尼亚（us-east-1）区域的 IAM API 来解析用户组。因此，在此期间 IAM 的受损导致 Redshift 无法执行这些查询。在 AWS 区域使用“本地”用户连接其 Redshift 集群的 Redshift 客户未受影响。
依赖 DynamoDB、新 EC2 实例启动、Lambda 调用和 Fargate 任务启动的其他 AWS 服务，例如适用于 Apache Airflow 的托管工作流、Outposts 生命周期操作和 AWS 支持中心，也在北弗吉尼亚（us-east-1）区域受到了影响。
作为此次操作事件的结果，我们正在进行多项更改。我们已经在全球范围内禁用了 DynamoDB DNS 规划器和 DNS 执行器自动化。在重新启用此自动化之前，我们将修复竞争条件场景，并增加额外的保护措施，以防止应用不正确的 DNS 计划。对于 NLB，我们正在增加一个速度控制机制，以限制当健康检查失败导致可用区故障转移时单个 NLB 可以移除的容量。对于 EC2，我们正在构建一个额外的测试套件来增强我们现有的规模测试，该套件将对 DWFM 恢复工作流进行测试，以识别未来的任何回归。我们将改进 EC2 数据传播系统中的限制机制，根据等待队列的大小对传入工作进行速率限制，以在高负载期间保护服务。最后，随着我们继续深入研究此事件在所有 AWS 服务中的细节，我们将寻找其他方法来避免未来发生类似事件的影响，以及如何进一步缩短恢复时间。
结束语
对于此次事件给我们的客户造成的影响，我们深表歉意。尽管我们在以最高可用性水平运营服务方面拥有良好的记录，但我们深知我们的服务对客户、他们的应用程序和最终用户以及他们的业务至关重要。我们知道此次事件以重大方式影响了许多客户。我们将竭尽所能从此次事件中吸取教训，并利用它来进一步提高我们的可用性。
来源：小张er日记
