客户可以离开但无法永远逃离的区域：AWS US-East-1 与弹性的代价

摘要

• 问责悖论不在于 AWS 是否提供多个区域。它确实提供。考验在于客户是否能在供应商事件期间无需先调用受损的控制平面、身份路径、DNS 管理 API、监控系统或支持渠道，即可利用这种多样性。一个存在但未预配置、未认证、不可观察或无法在无需实时配置变更的情况下到达的第二区域，是库存而非运营弹性。
• 2025 年 10 月 19 日至 20 日，DynamoDB 自动化 DNS 管理系统中的潜在竞态条件导致 US-East-1 的公共区域端点丢失所有 IP 地址。三个跨三个可用区独立运行的 DNS Enactor 未能控制故障，因为它们共享一个区域计划序列和一种清理逻辑。自动化进入不一致状态，需要手动修复。
• DynamoDB 端点解析在约三小时后恢复，但这并未恢复整个区域。EC2 的主机管理系统已失去租约并进入拥塞崩溃；网络状态传播积累了积压；网络负载均衡器健康检查移除了健康容量（其配置尚未到达）；依赖服务在更多小时内进行限流、失败或排空队列。AWS 描述了三个主要的客户影响时段，部分 Redshift 恢复持续到 10 月 21 日。
• 该事件并不意味着 US-East-1 的每台机器都故障。现有 EC2 实例保持健康，一些静态预配置的数据平面继续提供服务。故障影响的是找到 DynamoDB、启动或网络化新容量、处理事件、认证某些请求、替换不健康组件以及运营支持与联络中心功能的能力。这一区别既解释了为何部分客户未受影响，也解释了为何常规自动扩展设计在日间负载下后来失败。
• 公共部门记录使得连续性后果具体化，而无需声称政府普遍宕机。NOAA 报告几乎所有 NESDIS 产品受到影响，出现延迟而非丢失。USPTO 报告 Patent Center 间歇性中断，并指示提交者使用替代方法。NASA 科学平台警告笔记本分配可能超时。每个案例展示了不同的连续性要求：保护时效性产品、保护法律提交途径、或保护对替代计算资源的访问。
• AWS 控制托管服务内部、全局服务架构、恢复算法、状态发布和修复证据。客户和下游软件提供商控制工作负载放置、预配置、依赖映射、降级模式、独立监控和连续性程序。公共机构还控制任务分类、采购要求和非数字回退。共担责任并非责任等同：它遵循谁能在事件前改变故障能力。

一个区域产品，带有非区域逃脱问题

云销售主张建立在可选择故障域的基础上。客户可以将应用程序跨一个区域内的可用区分布，将数据复制到另一个区域，并为其他地方的热备用或活动副本付费。理论上，这使得弹性成为一种可购买属性。实际上，只有当客户在主要环境受损时能够行使该购买时，购买才成为现实。

这就是控制平面悖论的起点。一台已运行的服务器可以在用于描述或替换它的 API 不可用时继续处理。一个 DNS 记录可以在用于更改它的 API 宕机时继续应答。另一个区域中的副本可以保持健康，而应用程序仍将所有请求发送到故障的区域端点。一个支持服务可以故障转移到另一个区域，但仍拒绝用户，因为账户元数据依赖项返回了一个权威性看似正确但实际无效的答案。

AWS 自身的故障隔离边界指南（全局服务）对此异常明确。在标准商业分区中，IAM、AWS Organizations、账户管理、Route 53 公共 DNS、CloudFront 及若干相关控制平面托管在单一区域（通常是 US-East-1）中。它们的数据平面可能全局分布，这种分离可以保留已建立的服务。但该指南告诉客户不要依赖这些控制平面进行恢复，并列出了其他区域服务中仍依赖于 Route 53 或其他单区域控制功能的操作。

因此，正确的问责问题不是“客户购买第二个区域了吗？”。而是：客户是否能够通过已经存活且无需受损权限的路径来进入、观察、授权、路由和操作第二个区域？

该测试比架构图更严格。它询问容量是否已预配置；数据是否足够新；凭据和信任策略是否工作；故障转移控制是否是数据平面操作；工作人员是否有独立通信；状态证据是否来自供应商外部；系统背后的公共服务能否容忍过渡。它还询问 AWS 是否将自己的恢复和客户信息系统保持在其试图解释的故障之外。

2025 年 10 月给出了详细答案。部分运作正如静态稳定性理论预测的那样。现有 EC2 实例保持可用。其他区域的 DynamoDB 全局表副本可直接访问。其他部分揭示了隐藏控制依赖的代价：区域数据库端点消失，主机租约到期，无法启动容量，新实例缺乏网络状态，健康检查撤回了可用的负载均衡器容量，支持访问被阻止，尽管有区域故障转移。

2025 年 10 月的时钟内部包含三次中断

AWS 的事件后总结将事件日期定为 10 月 19 日太平洋时间晚上 11:48 至 10 月 20 日下午 2:20，并分为三个时段：DynamoDB API 错误、EC2 启动和连接故障、以及网络负载均衡器连接错误。这比分配一个开始和一个结束时间更为准确。不同服务、控制路径和客户积压按不同时钟恢复。

外部测量有助于测试供应商账户的边界。Cisco ThousandEyes 的中断分析在阿什本附近的 AWS 边缘观察到早期数据包丢失，随后随着故障通过恢复阶段移动，出现应用程序超时和 503 响应。这些观测无法揭示专有内部信息，但它们支持网络可达性和应用程序就绪在不同时间恢复的结论。

AWS 的公共事件历史作为同期沟通记录仍然有用。它不应被视为完整的取证报告。状态历史记录供应商在特定时刻知道并选择发布的内容；事件后报告增加了机制和后期对账。

时间线也说明了为什么“DNS 已修复”是一个不充分的恢复声明。DNS 修复恢复了到达 DynamoDB 的路由。它没有恢复已过期的租约、已排队的网络更新、尚未创建的实例、已被限流的事件交付、已失败的联系中心会话，或已超时的客户流程。恢复持续时间是依赖状态转换的总和，而非第一个缺陷的持续时间。

触发因素是 DNS；根本原因是对状态的共享权威

启动机制很精确。DynamoDB 维护数十万条针对大型区域负载均衡器集群的 DNS 记录。DNS Planner 创建描述端点、负载均衡器和权重的计划。DNS Enactor 在三个可用区独立运行，通过 Route 53 应用这些计划。在执行前，Enactor 检查其计划是否比已应用的计划更新。

一个 Enactor 变得异常缓慢，并在多个端点重试更新。当它进行时，Planner 生成了较新的计划，另一个 Enactor 快速应用了其中一个。然后较新的 Enactor 开始清理旧计划。此时，延迟的 Enactor 到达主要的 DynamoDB 区域端点并应用了其较旧的计划。其新鲜度检查早已完成，现在已过时。清理删除了刚刚变为活跃状态的旧计划。所有端点 IP 地址消失，自动化的状态变得不一致，以至于后续计划无法应用。

“DNS 错误”描述了客户可见的触发因素。它没有解释控制故障。更深层的条件包括：

• 新鲜度仅在多端点操作开始时检查一次，而不是在每次决定性写入时原子化检查；
• 较旧的计划在长时间延迟后可以覆盖较新的代；
• 清理可以在未证明不再活跃的情况下删除计划；
• 不同区域的独立工作者共享相同的排序和删除假设；
• 一个区域计划简化了多种端点类型的管理，增加了计划所附带的权威；
• 无效状态超出了自动化的自我修复范围，需要人工恢复。

这种区别很重要，因为添加第四个 Enactor 并不一定能解决所有 Enactor 共享的协议缺陷。可用区隔离了流程和基础设施；它们没有创建独立的正确性。冗余复制了执行相同不安全转换的参与者。

AWS 的修复承诺遵循这一诊断。公司全球禁用 Planner 和 Enactor 自动化以等待变更，承诺修复竞态并防止应用不正确的计划，提议对单个 NLB 在可用区故障转移期间可移除的容量设置速度限制，添加 EC2 恢复测试，并承诺对网络状态传播进行队列感知限流。这些措施比简单的扩容更强有力，因为它们限制了权威和恢复速度。

它们仍然是供应商撰写报告中的承诺。这里审查的公共记录不包含一个独立审计的关闭注册表，显示每个行动的部署日期、测试覆盖范围、失败的测试用例、剩余异常和持续性能。对因果说明的信心可以很高，而对当前修复有效性的信心则较低。

健康的服务器并不等于可恢复的服务

AWS 正确强调了事件前启动的 EC2 实例保持健康。这一事实防止分析滑入 US-East-1 物理离线的错误说法。它也暴露了客户正在购买的精确风险。

AWS 将控制平面定义为创建、描述、更新、删除和列出资源的系统，而数据平面执行服务的主要工作。其控制平面和数据平面指南解释了为什么启动 EC2 是涉及主机、网络接口、存储、凭据和安全配置的复杂编排。运行中的实例更简单。它可以在无法创建新实例的编排期间存活。

这就是静态稳定性的实际形式。服务之所以存活，是因为它无需更改。弱点出现在需求上升、主机故障、部署替换容量、证书或秘密需要续订、容器退出、或运营商尝试故障转移时。然后所谓稳定的服务在最不宽容的时刻调用控制平面。

Buildkite 的客户事故后审查说明了延迟故障。其客户体验最初稳定。随着美国业务流量增加，EC2 启动失败阻止了自动扩展，分片耗尽不同的容量余量，延迟和错误在 AWS 事件开始数小时后上升。Buildkite 通过暂停部署来保留容量，后来将负载转移到另一个未使用的分片。决定性的弹性资产是备用且已运行的算力，而非自动扩展策略的存在。

Postman 记录了第二种耦合形式。其中断回顾表示关键流程受损，其 AWS 托管的 status page 延迟了沟通，其自动创建内部事件通道依赖于受影响的基础设施。Postman 接受了自己的一份责任，并描述了优雅降级、多区域能力、冗余通信以及最终跨区域和跨供应商的主动-主动运行的工作。这是正确的分配：AWS 承担上游故障；Postman 承担让客户沟通和协调继承该故障的决定。

因此，十月份的事件将客户架构分为比“单区域”和“多区域”更有用的类别：

1. 运行但依赖变更。现有服务持续直到扩展、替换、部署或凭据刷新需要控制活动。
2. 多可用区但依赖区域控制。物理可用区故障被覆盖，而共享区域端点、控制平面和恢复系统仍然是共同的。
3. 多区域但依赖激活。数据和模板存在于其他地方，但故障转移需要预配置、IAM 更改、Route 53 更改或不可用的运营商。
4. 静态稳定多区域。容量、数据路径、身份、健康检查和路由控制已就位，故障转移使用预定位的数据平面机制。
5. 供应商多样化或手动持续。关键子集可在 AWS 之外运行，或公共功能在云操作不经济时通过有限非数字过程继续。

只有第四和第五类别直接回答了控制平面悖论。其他类别对于低影响工作负载可能仍然是合理选择，但不应被视为同等的弹性。

恢复自动化成了第二次事件

一旦 DynamoDB DNS 恢复，EC2 的 DropletWorkflow Manager 试图与其管理的物理主机重新建立租约。在端点中断期间，这些租约已超时。没有活动租约的主机无法安全接受新实例。集群的尝试耗时较长，导致工作过期并再次排队。AWS 表示系统进入了拥塞崩溃，并且没有针对该恢复状态的既定程序。

这是一个重要的承认。原始竞态是罕见的排序故障。长时间的 EC2 损害源于一类可预见的恢复负载：许多过期对象试图同时变为当前状态。确切规模可能异常，但队列、超时、重试和租约是普通的分布式系统机制。恢复设计必须在其预期恢复的集群规模下进行测试，而不仅仅是针对稳态性能或增量主机损失。

下一阶段使依赖对运行流量可见。网络管理器需要传播大量新实例或变更实例的配置。一些新实例在网络状态完成之前就已存在。NLB 健康检查看到失败，在健康和不健康之间交替，并从 DNS 中移除节点和目标。检查系统本身变得负载，自动可用区故障转移从多可用区负载均衡器中移除了容量。AWS 在上午 9:36 禁用了自动保护，以防止它基于误导性证据行动。

没有单个组件在隔离中不合理地行动。租约管理拒绝了无主主机。网络管理器将配置排队。健康检查移除了不可达目标。可用区故障转移撤回了受损容量。级联之所以出现，是因为每个机制将部分恢复解释为普通的局部故障。问责在于跨系统设计：恢复状态必须得到充分表示，以便一个安全控制不会因为另一个系统暂时不完整而惩罚它。

下游影响因服务而异。Lambda 对异步和队列驱动的工作进行限流，以保护同步调用。ECS、EKS 和 Fargate 遇到启动和扩展故障。Amazon Connect 经历入站和出站呼叫失败、忙音、静音、音频消息和呼叫路由故障、联络中心员工登录问题以及报告延迟。STS 经历两段错误率上升。Redshift 既有区域依赖，也有缺陷使其从所有区域向 US-East-1 发送 IAM 组解析请求；本地数据库用户不受该特定跨区域故障影响。

这个 Redshift 细节尤其具有启示意义。资源可以物理上位于 US-East-1 之外，但仍然因为实现选择而调用那里的端点。地理部署和依赖地理不是同一回事。客户需要后者的地图，但只有供应商能够权威地披露每个内部服务对服务的依赖。

状态和支持是安全系统的一部分

在云事件期间，客户需要决定他们是否看到自己的缺陷、账户特定限制、区域事件还是全局依赖。他们需要知道是否要故障转移、冻结部署、甩负荷、保留队列或调用手动连续性。因此，状态信息是运营控制，而非事后公关。

在 2025 年 10 月，AWS 支持中心确实故障转移到了另一个区域。然而，一个账户元数据子系统返回了阻止合法用户查看或更新工单的响应。AWS 设计了一个绕过失败响应的机制；依赖项返回了无效响应。从晚上 11:48 到凌晨 2:40，客户无法通过控制台或 API 创建、查看或更新支持工单。

这是一个经典的语义故障问题。依赖项可能不可用、缓慢、错误、过时或自信地错误。仅处理超时的故障转移逻辑并不独立于返回错误权威的系统。支持连续性必须验证账户状态的含义，保留有限的最佳已知路径，并为严重供应商事件提供单独认证的途径。

记录同时显示改进和复发。在 2021 年 12 月 7 日的AWS 服务事件中，AWS 主网络与内部网络之间的拥塞损害了监控、部署工具、控制平面、支持联系中心以及服务健康仪表板向备用区域的故障转移。AWS 承诺建立跨多个区域活跃的新支持架构。2025 年的支持中心确实按设计移动了区域，这证明了架构进步。但其元数据依赖仍阻止了服务履行其目的。

客户还需要区分 AWS 的公共状态与个性化证据。当前的AWS Health Dashboard 文档指出，未签名的公共页面显示公共服务事件，而登录视图提供账户特定事件和资源。AWS 推荐通过 EventBridge 进行程序化监控。其公共和账户特定健康事件指南建议使用备份规则，以便事件可以传送到备用区域。AWS 的区域事件规则指南指出，全局健康事件（如 IAM 通知）需要在 US-East-1 中设置规则，这是另一个测试而非假设独立性的理由。

任何组织都不应依赖单一渠道。一个防御性安排结合了供应商公共健康、跨多个区域传送的账户特定事件、来自另一个供应商或本地网络的合成探测、应用程序级别的业务指标，以及具有独立托管和身份的 incident page。联系清单、会议桥详情和决策阈值应无需普通云账户即可检索。

公共服务影响是连续性问题，而非网站计数

十月份的中断以简单的中断总数无法准确反映的方式影响了公共系统。最佳证据是因服务而异。

美国国家海洋和大气管理局报告，其国家环境信息中心云设施在 UTC 时间约 06:57 开始接收到低摄入警报。一份NOAA/NESDIS 运营消息表示几乎所有 NESDIS 产品受到影响，数据出现延迟而非丢失。这是一个与永久数据破坏实质上不同的后果。但它仍然可能很严重：环境产品是时间敏感的，六小时的延迟会压缩用于在预报、规划或下游分析中使用观测数据的时间。

美国专利商标局表示其Patent Center 经历了间歇性中断，并指示无法提交申报的用户使用替代提交方法。该通知展示了成熟的连续性原则：法律或行政功能是申报，而非单个 Web 应用程序的可用性。替代途径即使在主要界面降级时也能保留功能。记录未确定有多少用户调用了替代途径，每个申报是否满足截止日期，或为何事件直到 10 月 23 日才标记为解决；这些问题应保持开放。

NASA 的 Fornax 科学平台警告称，启动笔记本服务器可能超时，同时正在分配计算资源。这直接映射到 EC2 控制平面故障。现有科学数据或笔记本无需消失，研究就会停止；无法分配工作环境就足够了。

这些记录并未证明所有使用 AWS 的政府服务都受影响，紧急呼叫因该事件失败，或发生了任何公共安全后果。它们确实表明采购必须超越数据存储位置。公共服务可能依赖云控制进行产品生成、申报、分析、通信，或检查数据所需的计算。

CISA 2024 年 8 月关于公共安全通信依赖的论文警告，非机构基础设施可能带来相关的连续性风险，并建议明确的冗余、停机程序、备份、人员配备和支持要求。CISA 更广泛的基础设施依赖入门询问冗余供应商是否也被其他系统共享，以及变通方案可以维持多长时间。这些问题完美契合云架构。

公共机构应在任务层面分类连续性：

• 如果云控制不可用三小时、十五小时或四十八小时，必须产生什么结果？
• 哪些工作可以在已运行容量上继续，存在多少需求余量？
• 哪些记录可能延迟，哪些法律或安全截止日期需要替代途径？
• 工作人员能否在不依赖受影响供应商的情况下进行认证、沟通和发布公共建议？
• 第二个区域是否真正活跃，还是组织必须通过故障控制平面进行预配置？
• 手动流程能否接受工作、创建时间戳收据并稍后对账而不丢失完整性？
• 合同是否提供技术证据和支持途径，而不仅仅是事件后的积分？

NIST 的应急规划指南仍然相关，因为它以业务影响、恢复优先级、替代处理和测试计划为中心。技术变了，保护公共功能的职责未变。

US-East-1 有记录，而非一个重复 bug

将每一次北弗吉尼亚事件描述为相同的控制平面缺陷会产生误导。机制各不相同。记录的价值在于不同的触发因素反复暴露了关于范围、内部依赖、恢复速度和客户可见性的共同问题。

2012 年服务摘要是对悖论的早期陈述：控制平面在中断期间尤其重要，因为那时客户试图创建或移动资源。2017 年 S3 报告显示了具有比预期更多权限的运营命令以及该区域新规模下未经历过的重启持续时间。2020 年 Kinesis 报告明确将触发因素与根本原因分开，然后描述了数小时的可控集群重启和状态工具依赖。2021 年的报告暴露了供应商自身可见性降低和部署受损。

重复的模式不是指定操作员的疏忽，也不是 AWS 未能学习的证明。而是规模改变了安全操作的含义；冗余组件可以共享一个逻辑故障；恢复需求可能大于稳态需求；事件工具可以与生产共享命运。因此，每个事件后行动都应针对下一个机制进行测试，而不仅仅是最后一个精确触发因素。

有证据表明在学习。2025 年支持中心具有区域故障转移，而 2021 年架构未保护工单创建。DynamoDB 使用了三个独立的 DNS Enactor。EC2 保留了现有实例。全局表副本在其他地方仍然可访问。AWS 发布了异常详细的因果报告。剩下的问题是这些控制措施在接收到缓慢、过时或无效状态而非干净故障时，是否能够安全失败。

实际上可以购买什么弹性

AWS 当前的可靠性支柱告诉客户定义恢复目标、测试灾难恢复、进行游戏日、使用静态稳定性，并在恢复期间依赖数据平面。具体的REL11-BP04 指南识别了常见的反模式：在事件期间更改 DNS 记录、扩展控制平面容量因为故障转移资源未充分预配置、或依赖管理 API 链。

该指南在技术上是合理的。它也定义了账单。静态稳定性意味着在需要之前付费购买资源，限制会移除预留容量的部署，在另一个区域保持身份和数据就绪，以及操作路由控制其数据平面已分布。仅为备份付费的客户购买了数据保护，而非即时服务连续性。拥有 Pilot Light 的客户购买了更快的重建，而非对控制平面故障的免疫力。拥有热备用的客户购买了具有扩展依赖的容量，除非备用能够按预配置承载承诺负载。

AWS 的灾难恢复选项描述了备份与恢复、Pilot Light、热备用和主动-主动模型。他们还建议仅使用数据平面操作以实现最大弹性。其含义应写入商业案例：较低的成本通常意味着在故障时刻购买更多控制平面工作。工作负载所有者必须决定该权衡是否可以接受，高管必须资助与他们批准的冲击容忍度相匹配的答案。

多区域并非自动裁决。2025 年事件中，US-East-1 之外的 DynamoDB 全局表副本可用，但应用程序仍需要经过测试的路径、可接受的一致性行为、足够的容量以及协调恢复副本的方式。身份策略、KMS 密钥、机密、证书、容器镜像、队列、可观测性和第三方 API 都需要同样的审查。带有两个数据库图标的图表并不证明完整的业务事务可以在两个地方完成。

多云也并非自动裁决。针对第二个供应商重建每个托管服务可能引入数据不一致、运营错误、更高成本，以及仅在紧急情况下运行的系统。最新的GAO 联邦云采购审查发现，使用多个供应商的机构也面临互操作性、人员配置、工具和管理挑战。报告记录了国防部提供的更有用的表述：管理集中风险，维护架构意识，并为关键任务工作负载制定退出策略，而非将所有供应商特定能力视为固有错误。

实用的答案是选择性独立。将最时间关键的路径在区域间保持静态稳定。当全服务太昂贵时，保留一个小型只读或接收模式。对可能需要另一个提供商的功能使用开放数据格式和测试导出。在法律和公共义务允许的情况下维护手动或离线流程。不要在公共信息页面、福利支付指令、内部分析作业和安全调度功能上花费同等的弹性资金；它们的后果不同。

责任遵循本可改变结果的能力

“共担责任”如果被用来均分每个故障，可能变成迷雾。AWS 自身的弹性模型将云基础设施和托管服务的弹性分配给 AWS，而客户选择配置、放置、复制、备份和工作负载架构。这种划分只有转化为具体的控制能力时才有用。

这种分配避免了两个错误。客户不能修补 DynamoDB 的 DNS Enactor 或在 AWS 内部创建 EC2 恢复程序。AWS 不能决定市政申报门户是否值得主动-主动运行，或公共机构是否有可接受的手动接收流程。下游 SaaS 公司不能因将自己的状态页面托管在同一故障域而责备 AWS，但它也不能仅通过架构纪律发现未公开的供应商内部信息。

责任也随服务抽象程度而变化。管理 EC2 的客户有更多选择，也有更多工作。购买 DynamoDB 的客户委托更多平台操作，并应期望 AWS 正确管理服务的内部 DNS 和恢复。客户仍然控制复制和应用程序故障转移。托管服务并未消除客户连续性职责；它缩小了客户可以控制的内部事项，并增加了供应商披露可用故障边界的职责。

积分为服务指标定价，而非公共后果

商业问责有一个狭窄的合同层和更广泛的运营层。当前的DynamoDB SLA承诺月度区域可用性水平，并为符合条件的全局表使用设置更高目标。陈述的补救措施通常是服务积分，受资格、计算、排除、日志和通过 AWS Support 提交的索赔影响。

该机制可以执行可衡量的服务承诺。它不赔偿延迟的环境产品、错过的开发人员工作、失败的客户通话、丢失的下游交易，或转而进行手动处理的公共员工。SLA 也不确定特定客户的设计是否负责。合同条款各不相同，本分析未断定 AWS 对任何客户负有超出管辖协议的损害赔偿责任。

2025 年事件暴露了一个程序性讽刺而未证明法律缺陷：标准积分流程使用支持中心，而支持工单功能在 DynamoDB 初始阶段不可用。客户有后来的索赔窗口，因此临时阻塞不一定阻止索赔。它确实说明了为什么积分所需的证据应在受影响的监控堆栈之外收集。CloudWatch、应用程序日志、合成探测、供应商事件、客户交易记录和手动事件笔记应独立保存。

供应商的规模增加了治理期望。亚马逊 2025 年的10-K 表格报告 AWS 净销售额 1,287.25 亿美元，同比增长 20%，并单独承认系统中断和不完全冗余的风险。收入不是故障证据。它是容量、覆盖范围和经济关系的证据，在此关系中可靠性控制、透明事件后报告和修复保证是核心产品义务，而非慈善附加品。

哪些证据会改变结论

目前的结论是，AWS 提供了大量物理和数据平面弹性，但 2025 年 10 月的事件暴露了区域 DNS 自动化中可预防的常见假设，以及准备不足的恢复路径。客户可以购买有意义的弹性，但只能通过预定位服务和避免 AWS 自身记录的依赖于控制平面。一些跨区域和支持依赖的独立性低于客户仅凭地理位置合理推断的程度。

有几种证据会使得评估更有利：

• DNS 竞态修复、每端点新鲜度强制、活跃计划删除保护和从计划不一致状态自动恢复的带日期的公共关闭记录；
• 故障注入结果显示延迟的 Enactor、过时代、并发清理、部分 Route 53 写入和失败恢复无法移除区域端点；
• 在现实 US-East-1 规模下显示完整租约重构在有限时间内完成且无拥塞崩溃的 EC2 测试；
• 网络管理器的队列深度和准入控制证据，包括在大于十月的区域积压下的行为；
• NLB 测试证明速度控制可防止虚假健康转换撤回过多的多可用区容量；
• 服务依赖清单，识别可能影响 US-East-1 外部工作负载的全局或单区域控制操作，并随时间跟踪变更；
• 展示身份、账户元数据、控制台、EventBridge 传送和每个区域独立故障的支持和 AWS Health 演习；
• 面向客户的恢复指标，区分端点修复、控制平面修复、数据平面稳定性、积压清除和资源对账；
• 独立保证抽样严重事件纠正措施的完成情况和耐久性。

证据也可能使评估更不利。自动化重新启用后同一竞态重复发生、另一次无既定程序的集群恢复、未记录的跨区域向 US-East-1 的调用，或通过同一元数据路径的状态和支持失败，将表明修复处理了症状而非权威边界。仅靠更短的中断不会解决问题；幸运的工作负载模式可能掩盖不安全的控制。

客户证据也很重要。一个公共机构如果能展示完整的区域游戏日、独立通信、次要区域的最新数据、预配置容量、有界手动服务和成功截止日期对账，已将云多样性转化为连续性。一个将备份或模板标记为“多区域”而未进行计时演习的客户则没有。

AWS 发布了有用标准，规定何时发布公共事件后总结，包括涉及重大控制平面故障或基础设施影响的广泛事件。该档案很有价值。更强的保证会将每个严重报告链接到持久的行动登记册，以便客户和公共买家能够区分宣布的修复与经过测试、完成且持续的控制。

问责发现

2025 年 10 月的中断始于两个自动化组件在时间上的分歧。一个缓慢应用了旧计划；另一个应用了新计划并删除了旧计划；它们共同擦除了区域数据库服务的地址。长时间的事件源于一切信任该地址的东西，以及在其缺失期间恶化的状态。

AWS 在云内部拥有该链。它设计了计划协议、清理权限、主机租约、恢复队列、健康检查、服务依赖和支持路径。其事件后报告在技术上是详细的，其即时修复与所披露的机制相符，其保留现有 EC2 实例验证了控制平面分离的价值。未解决的问责问题是修复在区域规模下有效的证明，以及隐藏的跨区域依赖是否足够可见以让客户采取行动。

客户拥有不同的链。他们决定峰值需求是否可由运行容量服务，副本是否无需新的控制操作即可到达，状态和事件协调是否独立，以及商业或公共功能能否安全降级。Buildkite 耗尽的分片和 Postman 受损的状态路由并非 AWS 故障的原因；它们是客户控制的放大倍数。NOAA 延迟的产品、USPTO 的替代提交路径和 NASA 的分配警告说明了为什么放大倍数必须从运营角度评估，而非服务器数量。

核心问题现在可以回答了。客户可以在 AWS 上购买区域弹性，但第二个区域不是购买的充分证据。可用的产品是完整的恢复路径：已预配置、已授权、可观察、可路由，并且在主要控制平面不可用时已经过演练。当全局控制或供应商内部因素仍汇聚于 US-East-1 时，AWS 必须要么移除依赖，要么明确说明其安全的数据平面替代方案，要么直接陈述限制。

云集中通常被讨论为市场份额。更直接的集中是可执行权威：一个计划、一个端点、一个元数据答案、一个健康解释或一个支持依赖，可以使许多冗余系统行为一致。问责始于在下一次事件之前命名该权威，然后证明当它错误时仍然存在独立路径。