Amazon DynamoDB 服务在北弗吉尼亚 (US-EAST-1) 区域的中断事件总结
我们希望向您提供有关 2025 年 10 月 19 日至 20 日在北弗吉尼亚 (us-east-1) 区域发生的服务中断事件的更多信息。该事件于 10 月 19 日太平洋夏令时 (PDT) 晚上 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) 出现连接错误增多的问题，这是由 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 以及依赖 DynamoDB 的其他 AWS 服务均无法与该服务建立新连接。此次事件是由该服务的自动域名系统 (DNS) 管理系统中一个潜在缺陷引发的，该缺陷导致 DynamoDB 的终端节点解析失败。
AWS 众多核心服务都高度依赖 DNS，以实现无缝扩展、故障隔离与恢复、低延迟以及本地化服务。像 DynamoDB 这样的服务，在每个区域都需要维护数十万条 DNS 记录，以支撑规模庞大、类型多样的负载均衡器集群运行。自动化对于确保 DNS 记录的频繁更新至关重要 — 通过更新可及时添加新增容量、妥善处理硬件故障，并高效分配流量以优化客户体验。这套自动化系统在设计时充分考虑了韧性，能够从各类运行问题中恢复。除了提供公共区域终端节点外，该自动化系统还为 DynamoDB 的多个动态变体维护额外的 DNS 终端节点，包括符合联邦信息处理标准 (FIPS) 的终端节点、互联网协议第 6 版 (IPv6) 终端节点以及特定账户的终端节点。此次问题的根本原因是 DynamoDB DNS 管理系统中存在一个潜在的竞态条件，这导致该服务的区域终端节点 (dynamodb.us-east-1.amazonaws.com) 生成了错误的空 DNS 记录，而自动化系统未能修复该记录。要解释这一事件，需要先介绍 DynamoDB DNS 管理架构的一些细节：出于可用性考虑，该系统分为两个独立的组件。第一个组件是 DNS 规划器 (DNS Planner)，它会监控负载均衡器的健康状态和容量，并定期为该服务的每个终端节点制定新的 DNS 规划，规划内容包括一组负载均衡器及其权重分配。我们采用统一的区域 DNS 规划，因为当多个终端节点（如近期推出的 IPv6 终端节点和公共区域终端节点）共享容量时，这种方式能大幅简化容量管理和故障缓解工作。第二个组件是 DNS 执行器 (DNS Enactor)，其设计初衷是尽可能减少依赖关系，以确保在任何情况下都能实现系统恢复。它通过在 Amazon Route53 服务中应用所需更改来执行 DNS 规划。为保证韧性，DNS 执行器在三个不同的可用区 (AZ) 中以冗余且完全独立的方式运行。每个独立的 DNS 执行器实例都会查找新的规划，并尝试通过 Route53 事务将当前规划替换为新规划，这样即使多个 DNS 执行器同时尝试更新同一个终端节点，也能确保每个终端节点都能以一致的规划完成更新。该竞态条件源于两个DNS执行器之间一种极少发生的交互情况。正常情况下，DNS 执行器会获取最新的规划，并开始逐一处理服务终端节点以应用该规划。这个过程通常能快速完成，有效确保 DNS 状态始终保持最新。在开始应用新规划之前，DNS 执行器会进行一个一次性的检查，确认当前规划比之前应用的规划更新。当 DNS 执行器处理终端节点列表时，在尝试执行事务过程中，可能会因其他 DNS 执行器正在更新同一个终端节点而被阻塞，此时就会出现延迟。遇到这种情况，DNS 执行器会不断重试，直到所有终端节点都成功应用该规划。在事件发生前，一个 DNS 执行器在更新多个 DNS 终端节点时遇到了异常高的延迟，需要不断重试。就在它缓慢处理这些终端节点的同时，还发生了另外两件事：一是 DNS 规划器持续运行，生成了多个更新的规划版本；二是另一个 DNS 执行器开始应用其中一个较新的规划，并快速完成了所有终端节点的更新。这一系列事件的时间巧合触发了潜在的竞态条件。当第二个执行器（应用最新规划的执行器）完成终端节点更新后，启动了规划清理流程 — 该流程会识别出比刚刚应用的规划旧很多的规划，并将其删除。与此同时，第一个执行器（之前出现异常延迟的执行器）将其持有的旧规划应用到了 DynamoDB 区域终端节点，覆盖了新规划。由于执行器处理过程中出现异常高的延迟，在规划应用流程开始时所做的“确保当前规划比之前应用的规划更新”的检查已经失效，因此未能阻止旧规划覆盖新规划。随后，第二个执行器的清理流程因该旧规划比其刚应用的规划旧很多，将其删除。旧规划被删除后，区域终端节点的所有 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 分，所有全局表副本都完成了数据同步。随着缓存的 DNS 记录在凌晨 2 点 25 分至 2 点 40 分期间过期，客户能够正常解析 DynamoDB 终端节点并建立连接，此次主要服务中断事件的恢复工作就此完成。
Amazon EC2 服务情况
10 月 19 日太平洋夏令时晚上 11 点 48 分至 10 月 20 日下午 1 点 50 分，客户在北弗吉尼亚 (us-east-1) 区域使用 EC2 服务时，遇到 API 错误率上升、延迟增加以及实例启动失败的问题。在事件开始前已启动的 EC2 实例保持正常运行，在整个事件期间未受任何影响。虽然 DynamoDB 的 DNS 问题在太平洋夏令时凌晨 2 点 25 分得到解决，但客户在新实例启动时仍持续遇到较多错误。恢复工作于太平洋夏令时中午 12 点 01 分开始，EC2 服务完全恢复正常的时间为下午 1 点 50 分。在此期间，新实例启动失败时会显示“超出请求限制 (request limit exceeded)”或“容量不足 (insufficient capacity)”错误。
要了解事件经过，需要先介绍几个用于管理 EC2 实例启动以及为新启动 EC2 实例配置网络连接的子系统。第一个子系统是 Droplet 工作流管理器（Droplet Workflow Manager，简称 DWFM），它负责管理 EC2 用于托管 EC2 实例的所有底层物理服务器（我们将这些服务器称为 “droplet”）。第二个子系统是网络管理器 (Network Manager)，它负责管理所有 EC2 实例和网络设备的网络状态，并将该状态同步到相关设备。每个 DWFM 在每个可用区内管理一组 droplet，并为当前管理的每个 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 与 droplet 之间的租约逐渐开始超时。
10 月 20 日太平洋夏令时凌晨 2 点 25 分，随着 DynamoDB API 恢复正常，DWFM 开始重新与 EC2 集群中的 droplet 建立租约。由于没有有效租约的 droplet 无法被用于新 EC2 实例的启动，因此 EC2 API 对新收到的 EC2 实例启动请求返回“容量不足”错误。DWFM 随即启动了与集群中所有 droplet 重新建立租约的流程，但由于 droplet 数量庞大，重新建立租约的工作尚未完成，租约就已超时。系统会将重新尝试建立 droplet 租约的任务加入队列。此时，DWFM 陷入了拥塞崩溃状态，无法在恢复 droplet 租约方面取得进展。由于此前没有针对这种情况的既定运维恢复流程，工程师在尝试解决 DWFM 问题时格外谨慎，以防引发更多问题。在尝试多种缓解措施后，工程师于凌晨 4 点 14 分对传入的任务进行了限流，并开始有选择地重启 DWFM 主机，以解决这一问题。重启 DWFM 主机清空了任务队列，缩短了处理时间，使得 droplet 租约得以成功建立。到凌晨 5 点 28 分，DWFM 已与北弗吉尼亚 (us-east-1) 区域内所有 droplet 建立了租约，新实例启动操作再次成功执行，但由于为降低整体请求负载而启用了请求限流，许多请求仍会收到“请求限制超出”错误。
当新的 EC2 实例启动时，名为“网络管理器 (Network Manager)”的系统会同步网络配置，使该实例能够与同一虚拟私有云 (VPC) 内的其他实例、其他 VPC 网络设备以及互联网进行通信。10 月 20 日太平洋夏令时凌晨 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 队列处理仍受影响，原因是负责轮询 SQS 队列的一个内部子系统出现故障且无法自动恢复。我们在凌晨 4 点 40 分恢复了该子系统，并在早上 6 点 00 分之前处理完所有积压的消息。从早上 7 点 04 分开始，NLB 健康检查失败引发了部分 Lambda 内部系统的实例终止，导致容量不足。由于当时 EC2 实例启动仍存在问题，我们对 Lambda 事件源映射 (Event Source Mappings) 和异步调用进行了限流，以优先保障对延迟敏感的同步调用。到上午 11 点 27 分，内部系统已恢复足够容量，错误也随之减少。之后，我们逐步降低限流强度，并在下午 2 点 15 分之前处理完所有积压任务，Lambda 服务恢复正常运行。
10 月 19 日太平洋夏令时晚上 11 点 45 分至 10 月 20 日下午 2 点 20 分期间，北弗吉尼亚 (us-east-1) 区域的客户在使用亚马逊弹性容器服务 (ECS)、弹性 Kubernetes 服务 (EKS) 和 Fargate 时，遇到了容器启动失败和集群扩展延迟的问题。这些服务于下午 2 点 20 分恢复正常。
10 月 19 日太平洋夏令时晚上 11 点 56 分至 10 月 20 日下午 1 点 20 分期间，北弗吉尼亚 (us-east-1) 区域的 Amazon Connect 客户在处理呼叫、聊天和工单时遇到错误增多的情况。DynamoDB 终端节点恢复后，Amazon Connect 的大部分功能也随之恢复，但客户在聊天功能方面仍遇到较多错误，该问题直至凌晨 5 点 00 分才得到解决。从早上 7 点 04 分开始，客户在处理新呼叫、聊天、任务、邮件和工单时再次遇到错误增多的情况，这是由 Amazon Connect 使用的 NLB 受影响以及 Lambda 函数调用错误率上升、延迟增加所致。呼入客户会听到忙音、错误提示，或遇到连接失败的情况；坐席发起和 API 发起的外呼均失败；已接通的呼叫会出现提示音播放失败、坐席路由失败或无声的情况。此外，坐席在处理联系人时遇到的错误增多，部分坐席无法登录；客户在访问 API 和联系人搜索功能时也遇到较多错误；实时仪表板、历史仪表板和数据湖的数据更新出现延迟，所有延迟数据将于 10 月 28 日前补全。随着 Lambda 函数调用错误问题的解决，Amazon Connect 服务于下午 1 点 20 分恢复正常。
10 月 19 日太平洋夏令时晚上 11 点 51 分至 10 月 20 日上午 9 点 59 分期间，北弗吉尼亚 (us-east-1) 区域的客户在使用 AWS Security Token Service (STS) 时遇到了 API 错误和延迟问题。内部 DynamoDB 终端节点恢复后，STS 服务于凌晨 1 点 19 分恢复正常。上午 8 点 31 分至 9 点 59 分期间，受 NLB 健康检查失败影响，STS API 错误率再次上升，延迟增加。上午 9 点 59 分，NLB 健康检查失败问题得到解决，STS 服务恢复正常运行。
10 月 19 日太平洋夏令时晚上 11 点 51 分至 10 月 20 日凌晨 1 点 25 分期间，由于北弗吉尼亚 (us-east-1) 区域 DynamoDB 服务出现问题，使用 IAM 用户登录 AWS 管理控制台的客户遇到了认证失败增多的情况。在该区域配置了 IAM 身份中心 (IAM Identity Center) 的客户，也无法通过身份中心登录。使用根凭证登录的客户，以及通过配置为使用signin.aws.amazon.com的身份联合登录的客户，在尝试登录北弗吉尼亚 (us-east-1) 区域以外其他区域的 AWS 管理控制台时，均遇到了错误。凌晨 1 点 25 分，DynamoDB 终端节点恢复正常访问，该登录服务也随之恢复正常运行。
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 实例启动存在问题，这些工作流被阻塞，导致集群处于“正在修改 (modifying)”状态，无法进行查询处理，也使得集群无法承载工作负载。早上 6 点 45 分，工程师采取措施阻止工作流任务积压的情况进一步恶化；下午 2 点 46 分，Redshift 集群开始启动替换实例，积压的工作流开始减少。10 月 21 日太平洋夏令时凌晨 4 点 05 分，AWS 运维人员让受替换工作流影响的 Redshift 集群恢复了可用。除集群可用性问题外，10 月 19 日晚上 11 点 47 分至 10 月 20 日凌晨 1 点 20 分期间，所有 AWS 区域的 Amazon Redshift 客户都无法使用 IAM 用户凭证执行查询操作。这是由于 Redshift 存在一个缺陷 —— 它会使用北弗吉尼亚 (us-east-1) 区域的 IAM API 来解析用户组。故而该期间 IAM 服务出现的故障导致 Redshift 无法执行这些查询。而在各 AWS 区域中，使用 “本地” 用户连接 Redshift 集群的客户未受此影响。
太平洋夏令时间 10 月 19 日晚上 11 点 48 分至 10 月 20 日凌晨 2 点 40 分期间，客户无法通过 AWS 支持控制台和 API 创建、查看和更新支持工单。虽然支持中心按照设计成功切换到另一个区域，但负责账户元数据的子系统开始返回无效响应，这些响应阻止了合法用户访问 AWS 支持中心。虽然我们在设计支持中心时已考虑在响应不成功时绕过该系统，但在此事件中，该子系统返回了无效响应，这些无效响应导致系统意外地阻止了合法用户访问支持工单功能。问题在凌晨 2 点 40 分得到缓解，我们在凌晨 2 点 58 分采取了额外措施防止问题再次发生。
其他依赖 DynamoDB、新 EC2 实例启动、Lambda 调用以及 Fargate 任务启动的 AWS 服务，如 Apache Airflow 托管工作流 (Managed Workflows for Apache Airflow)、Outposts 生命周期操作，在北弗吉尼亚 (us-east-1) 区域也受到了此次事件的影响。请参考事件历史记录以获取受影响服务的完整列表。
针对此次运营事件，我们将采取多项改进措施。目前已在全球范围内禁用了 DynamoDB 的 DNS 规划器 (DNS Planner) 和 DNS 执行器 (DNS Enactor) 自动化功能。在重新启用该自动化功能之前，我们将修复竞态条件问题，并增加额外的保护措施，防止应用错误的 DNS 规划。对于 NLB 服务，我们将添加速率控制机制，以限制当健康检查失败导致可用区 (AZ) 故障转移时，单个 NLB 可移除的容量规模。对于 EC2 服务，我们将构建额外的测试套件，补充现有的规模测试，通过模拟 DWFM 恢复流程来识别未来可能出现的回归问题。同时，我们将改进 EC2 数据同步系统中的限流机制，根据等待队列的规模对传入任务进行速率限制，以在高负载期间保护服务稳定。最后，随着我们持续深入分析所有 AWS 服务在此次事件中的具体情况，我们将进一步寻找更多方法，以避免未来发生类似事件造成影响，并进一步缩短恢复时间。
结束语
对于此次事件给客户带来的影响，我们深表歉意。虽然我们在提供高可用性服务方面有着良好的记录，但我们深知我们的服务对客户，其应用程序，最终用户以及业务的重要性。我们了解此次事件对众多客户造成了重大影响。我们将全力以赴从此次事件中汲取经验教训，并以此为契机进一步提升服务的可用性。