AWS 将 US-East-1 的通知质量打造为云依赖问责记录

摘要

• AWS US-East-1 的问责记录不仅仅是区域故障的记录。它是对通知质量的记录：客户在判断自身架构是否失效、AWS 服务是否失效、或者托管在 US-East-1 的全局依赖是否阻塞恢复路径时，是否收到了及时、精确、与账户相关的证据。
• 2025 年 10 月 19 日至 20 日的 DynamoDB 中断始于 DNS 自动化从 US-East-1 的公共 DynamoDB 区域端点中移除了所有 IP 地址。最初的触发因素是区域 DNS 状态，但后果通过 EC2 租约恢复、网络状态传播、网络负载均衡器健康检查、依赖的 AWS 服务、客户支持、下游 SaaS 提供商以及公共部门服务蔓延开来。
• AWS 控制了内部服务架构、健康事件发布、特定账户通知渠道、支持连续性、事后证据以及修复证明。客户控制了依赖映射、预配置、独立监控、EventBridge 规则、公共事件页面以及降级模式。共享责任并非平等责任；它遵循了各方在事件前能够操作的控件。
• 执行风险在于，精度不足的通知将成本和不确定性转移给客户。提供商的状态页面可能显示"多种服务"，而事件指挥官需要知道 IAM、DynamoDB、EC2 启动、DNS、支持、健康事件以及下游公共服务截止日期是否以决定故障转移的特定方式受到影响。

通知质量是一项连续性控制

云状态信息通常被视为一种礼貌，是提供商在工程师开始修复问题后发布的。这种框架太弱了。在控制平面事件期间，状态质量本身就是一项连续性控制。它告诉事件指挥官是冻结部署、卸载负载、故障转移、保留队列、切换到手动流程、警告用户，还是等待，因为观察到的故障属于提供商并且将在上游解决。

AWS 的2025 年 10 月 DynamoDB 服务中断摘要很有价值，因为它提供的不仅仅是一个通用的中断标签。它描述了 DNS Planner 和 DNS Enactor 竞态、从 DynamoDB 区域端点丢失所有 IP 地址、手动修复、EC2 主机租约崩溃、网络管理器积压、网络负载均衡器健康检查不稳定、支持中心受损以及特定服务的影响。这种程度的事后证据是客户所需的标准。问题在于时机：这些知识中的大部分是在客户已经做出实时连续性决策之后才到来。

同时期的AWS Health 事件历史显示了事件期间的公共通信界面。这是一份必要的记录，但实时状态历史不能替代客户特定的依赖映射。SaaS 提供商需要知道其账户是否受 DynamoDB 端点解析影响、EC2 启动是否失败、NLB 是否正在撤出容量、支持案例是否无法打开，以及特定账户的健康事件是否到达其备用区域。"US-East-1 运营问题"是一个开始；它并非决策树。

Cisco ThousandEyes 的外部中断分析观察到从 AWS 边缘附近的丢包到后来应用程序超时和 503 响应的早期转变。这种外部视角是有用的，因为它从另一个角度测试了提供商的叙事。它也展示了客户的困境。外部监控可以在提供商解释原因之前揭示症状，但它无法识别专有的内部依赖。一个成熟的故障处理流程需要两者：独立的客户探针和提供商控制的状态，且状态需具有足够详细的信息以指导行动。

问责问题因此不在于 AWS 是否发布了任何东西。AWS 发布了。问题在于状态、特定账户通知、支持和事后证据是否足以让客户避免在错误的本地修复、有风险的故障转移或延迟的公共通信上浪费时间。通知质量通过缩短每个客户不得不独自重新发现提供商事件的时间来减少损害。

2025 年 10 月的事件有几个时钟

2025 年 10 月的事件无法用一个开始和一个结束来表示。根据 AWS 的说法，最初的 DNS 缺陷在太平洋时间 10 月 19 日晚些时候开始，主要事件于 10 月 20 日下午 2:20 结束。亚马逊的简短公开更新称所有 AWS 服务在太平洋时间下午 3:01 恢复正常运营。详细报告称某些 Redshift 集群直到 10 月 21 日早些时候才恢复。这些并非矛盾；它们是不同的时钟：端点修复、依赖服务恢复、广泛正常化以及残余资源修复。

这种区分是通知质量的要求。如果 DynamoDB 端点解析已修复，客户仍然需要知道 EC2 是否可以启动实例、网络状态是否已传播、NLB 健康检查是否可靠、Lambda 异步工作是否受限、Connect 通话是否失败、STS 错误是否仍然升高，以及另一个区域的 Redshift 是否依赖于发往 US-East-1 的 IAM 请求。每个服务时钟对应不同的客户操作。

Buildkite 的事后审查说明了延迟的客户影响。其系统最初稳定，随后业务时段负载显示 EC2 启动故障阻止了自动扩缩，某些分片耗尽了余量。Buildkite 通过冻结部署并将工作转移到已有容量来缓解。教训是针对通知的：客户需要在白天的需求证明之前就知道自动扩缩和启动是否受损。

Postman 的中断回顾显示了一个通信依赖。其状态页面托管在 AWS 上，自动内部事件通道创建也依赖受影响的基础设施。Postman 对这些依赖承担了责任，并计划更优雅的降级、冗余通信以及多区域或多提供商能力。AWS 拥有上游故障；Postman 拥有自己的通信设计。两个事实都可以成立。

对于公共部门服务，时钟又有所不同。NOAA 的NESDIS 运营消息称几乎所有 NESDIS 产品都受到影响，数据似乎延迟而非丢失。USPTO 报告了Patent Center 间歇性中断，并指示用户使用替代提交方法。NASA 的 Fornax 平台警告笔记本分配可能超时。这些通知显示了特定任务的连续性：延迟数据、保留法律申报或分配计算。

控制平面依赖使得难以逃离该区域

AWS 提供多个区域，许多客户应使用它们。问责问题在于在事件期间离开一个区域可能需要使用已经受损或托管在要离开的区域的同一控制平面和全局服务。AWS 自身的关于全局服务的故障隔离指南解释说，在标准商业分区中，几个全局服务控制平面，包括 IAM、Organizations、Account Management、Route 53 Public DNS 和 CloudFront，都托管在一个区域（通常是 US-East-1），而它们的数据平面可能分布在各处。

AWS 的控制平面和数据平面指南解释了为什么这种区分很重要。控制平面创建、更新、删除、描述和列出资源。数据平面执行服务的主要工作。现有的 EC2 实例可以保持健康，而启动新实例则失败。现有的 DNS 答案可以继续服务，而更改它们所需的 API 不可用。一个说"在另一个区域创建资源"的灾难恢复计划可能是一个控制平面操作，而不是一个恢复保证。

AWS 的 Well-Architected 可靠性支柱，包括REL11-BP04 关于在恢复期间依赖数据平面，告诉客户在恢复期间尽量减少控制平面操作。AWS 灾难恢复选项指南区分了备份和恢复、pilot light、温备和主动-主动模式。这些是有用的客户控件。它们也定义了一项通知义务：客户需要知道哪些提供商控制平面受到影响，以便决定其恢复模式是否真正可执行。

2025 年 10 月的摘要展示了这一悖论。 DynamoDB Global Tables 在其他区域中的副本可以直接寻址，并且已被报告为同步。但应用程序必须知道如何路由到它们，自身身份和 DNS 控件是否正常工作，写入是否需要一致性协调，以及下游服务是否健康。EC2 启动在初始端点问题修复后仍然失败了许多小时。NLB 健康检查移除了容量，因为网络状态尚未完全到达新实例。另一个区域具有韧性仅当客户能够进入并操作它而不先调用受损权威。

AWS 并不独自负责客户是否预配了温容量。客户做出成本和架构选择。但 AWS 控制着内部依赖的披露、服务健康通知的精度，以及允许客户更新其计划的事后解释。当某些全局控制路径和状态通道受区域限制时，提供商不能简单地说"使用多个区域"。它还必须告诉客户这些依赖在提供商事件期间如何行为。

支持和健康通道需要独立的故障行为

2025 年 10 月的报告称，AWS Support Center 确实故障转移到了另一个区域，但一个账户元数据依赖返回了无效响应，阻止了合法用户查看或更新支持案例。这是一个微妙而严重的教训。支持通道仅处理超时是不够的。它还必须处理来自依赖的错误、过时或格式错误的权威，而不会在客户最需要帮助的确切时刻拒绝帮助。

AWS 在其2021 年 12 月 US-East-1 服务事件摘要中有一个类似的通信教训。内部网络和主网络之间的拥塞损害了监控、部署工具、控制平面、Support Contact Center 和 Service Health Dashboard 故障转移。AWS 承诺了一个新的支持架构，跨多个区域激活。2025 年的行为显示了改进，因为存在区域故障转移；它也显示了一个剩余的语义依赖，因为无效的账户元数据阻止了访问。

健康通知同样分层。AWS 的Health Dashboard 文档区分了公共事件和特定账户事件。其关于公共和特定账户事件的文档建议客户使用 EventBridge 和备份规则，而其区域事件规则指南解释说，像 IAM 这样的全局事件需要 US-East-1 的规则。2025 年 11 月，AWS 宣布了AWS Health 的新 EventBridge 灵活性，以提高健康事件交付的弹性。这是一个有价值的方向，但客户仍然必须配置和测试交付路径。

支持和健康事件需要一个特定的故障模型。如果客户身份受损怎么办？如果账户元数据错误怎么办？如果客户的 EventBridge 规则在受影响的区域怎么办？如果事件是全局的，但全局服务的事件规则受区域限制怎么办？如果客户的事件页面依赖于受影响的云怎么办？这些不是边缘问题。它们决定了客户是否能在提供商的事后分析到来之前采取行动。

提供商控制着服务真理的官方来源，并且应维护外部可访问的状态、特定账户通知和紧急支持路径，其故障行为假定自身控制平面可能受损。客户控制着对真理的摄取，并应结合 AWS Health、独立探针、应用程序指标、外部通信和手动升级。因此，通知质量在操作上是共享的，但在源权威上是由提供商主导的。

历史上的 US-East-1 事件显示出重复的通知压力

US-East-1 有很长的记录，但并非一个重复的缺陷。比较事件的价值在于看到客户通知、支持独立性、内部依赖和恢复证据上的重复压力。AWS 的2012 年 US-East 服务事件摘要描述了一个可用区电力事件和区域 EC2/EBS 控制平面受损，限制了试图替换资源的客户。2017 年 S3 中断摘要描述了一个错误命令移除了超过预期的容量，并影响了 Service Health Dashboard 的管理控制台，因为它依赖 S3。2020 年 Kinesis 事件摘要描述了一个容量新增暴露了线程限制，影响了 Cognito、CloudWatch、Lambda、EventBridge、ECS、EKS，并延迟了手动状态工具的使用。

机制不同，它们应在分析中保持不同。电力传输、运营命令权威、线程耗尽、内部网络拥塞和 DNS 计划竞态不是一个缺陷。重复的问责问题是客户是否能够看到足够的信息以做出正确响应，而 AWS 自身正在修复内部控制系统。当提供商的监控、部署、支持或状态工具共享故障域时，通知变成了一个首要的可靠性问题。

AWS 的事件后摘要存档和政策是有用的，因为它为重大事件创建了一个公共记录。公共摘要应根据其将触发器、根因、促成条件、影响类别、客户可见症状、修复和残余限制连接起来的程度来评估。2025 年 10 月的摘要按这个标准很强，因为它没有止步于 "DynamoDB DNS"。它跟踪故障进入 EC2 租约、网络管理器、NLB 健康检查、服务依赖和支持。客户需要那个细节来纠正他们自己的假设。

弱点不在于摘要的存在；而是每个修复缺乏独立验证的闭环。AWS 表示已禁用全球的 DNS Planner 和 Enactor 自动化，等待变更，修复竞态，添加 NLB 容量移除限制，改进 EC2 恢复测试，并为网络状态添加队列感知速率限制。这些行动符合已披露的机制。此处审查的公共记录没有提供一个完整的独立闭幕登记册，包含日期、测试和持续结果。客户必须决定他们能从提供商撰写的报告中接受多少保证。

这就是执行风险进入的地方。如果提供商的事后分析是唯一的证据，客户和监管机构可能缺乏在采购压力和合同谈判之外要求闭合的方法。云依赖已成为许多服务的公共基础设施，但许多修复措施仍然是合同性或声誉性的。通知质量和事后证据不仅仅是技术实践；它们是客户能够在不查看提供商内部系统的情况下强制更好行为的机制。

公共机构需要任务级连续性，而不是云传说

公共部门客户面临与私营公司相同的提供商依赖，但他们的连续性职责与公共职能紧密相连。NOAA 产品、USPTO 申报和 NASA 科学工作各自显示了一种不同的依赖类型。天气或环境数据产品可以延迟而非丢失，但延迟仍然重要。专利申报系统可以中断，但替代申报方法可以保留法律权利。科学平台可以保留数据但无法分配笔记本，从而阻止分析。云事件是任务影响的一个输入，而非全部故事。

CISA 关于公共安全通信对非机构基础设施的依赖的论文警告说，外部基础设施和服务可能创造相关的连续性风险。CISA 的基础设施依赖入门询问冗余提供商是否共享依赖以及变通方法可以持续多久。NIST 的SP 800-34 应急计划指南保持对业务影响、恢复优先级、备用处理和测试计划的关注。

这些公共部门控件应精确应用于云。"多云"并不自动是一个恢复计划。GAO 2026 年关于联邦云采购挑战的报告指出了多供应商复杂性、劳动力需求和互操作性成本。第二个云提供商只有在数据、身份、部署、DNS、可观测性和员工程序在那里工作时才能减少集中。否则，第二个提供商是一个采购标签而非连续性能力。

AWS 自身的弹性共享责任模型说 AWS 负责云的弹性，而客户负责工作负载配置、放置、备份、版本控制和复制。公共机构应将此转化为任务问题。如果 US-East-1 API 失败，哪些公共功能必须继续？哪些操作可以在已预配的容量上运行？哪些截止日期需要手动处理？哪些状态和支持通道在 AWS 之外？哪些记录可以延迟，哪些不能？

公共机构还应在采购中要求提供商证据。他们需要事件后摘要、特定账户影响数据、支持连续性期望、通知时间、全局服务的架构说明，以及在公共功能受影响时请求更多详细信息的权利。他们不需要每个专有细节来询问文件截止日期、公共数据产品或紧急支持应用程序是否能在当要离开的区域仍然托管着他们无法逃离的控制平面时继续运行。

SLA 和收入不能解决问责问题

AWS 是一家非常大的企业。亚马逊的2025 年 10-K 表格报告 AWS 净销售额为 1287.25 亿美元，并承认了涉及系统中断、冗余和灾难恢复的风险。规模重要，因为它给了提供商资源和公共意义。它并不自动证明每个控件都是充分的或每个中断在法律上都是可诉的。

服务水平协议同样有限。DynamoDB SLA定义了月度正常运行时间承诺、信用额度、索赔流程、排除项和 Global Tables 处理。SLA 信用额度可能有意义，但它不是公共服务延迟、丢失的开发者时间、错失的收入、失败的申报、客户信任或事件劳动强度的度量。信用额度也不识别失败的内部依赖或证明修复。它是一个合同补救措施，而不是一个连续性报告。

这种区分是通知执行风险的核心。客户通常很少对提供商内部有直接杠杆，除了通过合同、采购要求、架构选择和公共问责。如果提供商的通知含糊不清，客户承担调查成本。如果事件后摘要缺乏闭合证据，客户承担残余不确定性。如果全局服务依赖没有清晰映射，客户可能购买了无法行使的弹性。执行风险是提供商的内部控制权威与客户验证能力之间的距离。

不应期望 AWS 披露会帮助攻击者或破坏运营的敏感架构。应期望它披露足够多的故障域、状态和修复信息，以便客户设计和验证连续性。这包括哪个服务类失败、哪些依赖受到影响、特定账户事件是否延迟、支持是否受损、数据平面是否继续、控制操作是否失败以及哪些客户行动被推荐。

客户不应将自己的连续性判断外包给 AWS。他们应预配关键容量，避免在恢复期间最后一刻的控制平面操作，从 AWS 外部进行监控，独立托管事件通信，配置具有区域备份的健康事件交付，演练手动程序，并根据后果对公共功能进行分类。这些客户职责是真实的。它们不抹除 AWS 在其拥有的控制平面失败时提供精确通知和证据的职责。

特定账户通知必须在账户不确定时存活

最有价值的提供商通知是特定于账户的，因为一个全局事件很少以相同方式影响每个客户。一个客户可能有使用 Global Tables 和就绪区域端点的 DynamoDB 表。另一个可能有一个单区域工作负载但有足够的备用容量。另一个可能没有直接的 DynamoDB 依赖，但有一个内部队列、身份路径或客户支持产品，依赖于一个依赖 DynamoDB 的服务。公共状态告诉每个人存在火灾。特定账户通知告诉每个客户他们自己建筑中的哪些房间可能正在充满烟雾。

2025 年 10 月的 Support Center 问题显示了为什么特定账户通知必须在账户不确定时存活。如果账户元数据是过时的或错误的，支持系统不应自信地在提供商事件期间拒绝合法访问。它应转向一个有限的紧急模式：最后已知良好的账户状态、受限的支持功能、已验证的计费联系人、备用身份验证或针对严重事件的紧急通道。目标不是让任何人冒充客户。目标是避免一个设计，其中来自一个依赖的错误答案比没有答案更能完全阻止帮助。

同样的原则适用于 Health 事件。客户可以配置 EventBridge 交付和备份规则，但事件源和全局服务处理仍然是提供商定义的。如果一个全局事件需要 US-East-1 配置，客户需要文档使这种依赖明确，并且他们需要定期测试证明备用交付工作。AWS 2025 年 11 月 Health/EventBridge 灵活性公告是一个有用的方向，因为它识别了事件交付弹性作为一个产品问题，而不仅仅是客户脚本。下一步是客户证据：组织能否证明当他们主要区域受损时，他们能收到公共和特定账户事件？

特定账户通知还应对影响类型进行分类。一个资源可以是健康的但不可恢复，如果无法启动新容量。一个服务可以在读取时提供服务，而写入或控制操作失败。一个队列可以接受消息，而消费者被限制。一个负载均衡器可以路由流量，而健康检查正在做不安全的决策。一个支持案例可能因为账户元数据错误而失败。客户需要映射到行动的类别：不要部署、不要缩容、切换到温容量、保留队列、使用手动申报、停止破坏性重试，或将用户路由到降级模式。

这就是为什么通知质量与安全自动化相关。许多客户系统自动响应提供商信号：自动扩缩器、部署管道、健康检查、混沌工具、流量路由器、队列消费者和事件机器人。如果提供商信号缺失或过于模糊，自动化可能错误分类事件。它可能持续重试进入失败的控制平面，启动无法附加网络状态的替换，或因不完整的依赖检查而移除健康容量。精确的提供商信号让客户更安全地自动化。

客户需要自己的证据证明状态路径有效

一个阅读 AWS 指南并配置 Health 事件的客户并没有完成工作。它必须测试该路径。事件是否到达受影响区域之外的通道？事故管理系统是否依赖于可能随同一事件失败的 AWS 身份、聊天工具或电子邮件交付？值班工程师是否有离线访问运行手册？公共状态页面是否依赖 AWS 托管？故障转移决策是否需要可能受损的控制台登录？这些问题很平凡，这就是为什么它们经常被错过。

客户侧的证据可以很简单。每季度一次，将一个模拟提供商事件注入监控路径。确认公共状态页面可以在没有 AWS 的情况下更新。确认主要和备用区域的 EventBridge 规则交付到不同的目的地。确认值班人员可以从非 AWS 存储中检索联系人和运行手册。确认故障转移命令要么使用预先定位的数据平面控件，要么在提供商控制平面故障期间明确标记为不可用。确认业务所有者，而不仅仅是基础设施团队，知道调用哪个降级模式。

2025 年 10 月的下游报告显示了缺少此点的成本。Buildkite 的主要服务降级与随着需求增加扩展到缺失的 EC2 容量有关。Postman 的通信工具与 AWS 托管服务纠缠在一起。这些不是道德失败；它们是提供商事件揭示的架构差距。他们的事后分析是有用的，因为它们将差距转化为行动项。其他客户不应等待自己的事件来学习同样的教训。

公共部门版本应为正式。专利申报系统应测试云提供商事件期间的替代申报，并验证公共通知在提供商外部可用。环境数据服务应测试延迟数据程序和下游通知。科学平台应测试现有笔记本、排队工作和新分配是否具有不同的故障行为。如果失去云控制会造成生命安全隐患，支持公共安全的系统应维护非云或备云最小运行模式。

AWS 可以通过使 Health 和故障注入模式更易于测试来鼓励这种证明。客户应能够运行一个经过批准的演习，模拟特定账户服务降级，而无需等待真实中断。提供商指南可以包括示例决策树：如果控制平面不可用，不要尝试这些操作；如果数据平面健康，保留这些路径；如果支持受损，使用这个紧急通道；如果 Global Tables 可直接访问，验证这些协调步骤。目标不是预测每个事件。目标是在第一个小时内减少混乱行动。

事件后摘要应具有闭合字段

AWS 的事件后摘要通常解释发生了什么并列出纠正措施。缺失的公共层是闭合证据。摘要可以包括行动状态字段，而不暴露敏感细节：已完成、进行中、被不同控件替代、在生产演习中测试过、在模拟中测试过或不可公开验证。它可以说明是否已将类似故障注入到测试环境、是否更改了告警阈值、是否演练了支持故障转移、以及是否更新了面向客户的指南。

那种闭合将帮助采购和风险团队。一个客户在 2025 年 10 月后决定是否依赖 DynamoDB Global Tables、EC2 自动扩缩、NLB 健康检查、AWS Health 事件或支持连续性，需要知道修复承诺是否变成了运营控件。提供商撰写的报告可以保持为真理来源，同时给客户提供比承诺更多的东西。对于像 AWS 这样规模的云提供商，闭合字段的存在本身就是一项问责控件。

闭合字段也减少了重复的客户问卷。大客户通常通过向提供商发送私有的安全和弹性问卷来回应事件。该过程成本高昂且不一致。一个针对重大事件后行动的公共闭合登记册可以一次性回答许多常见问题，同时为有特殊职责的客户保留私人简报。它还将帮助缺乏获取私人细节杠杆的小客户。

存在风险。如果闭合字段不与有意义的测试联系，它可能变成一个复选框。公共日期可能给过早关闭行动带来压力。过多细节可能暴露内部设计。这些风险是可管理的。替代方案是一个公共记录，客户知道出了什么问题和 AWS 打算做什么，但不知道修复是否实际改变了下一个事件的路径。

这就是事后分析的执行含义。事后分析不仅是提供商的学习文档。它是客户用于强制执行自身风险决策的证据：续约、重新设计、添加提供商、要求温备、更改采购条款或接受残余风险。闭合证据越强，每个客户就越不需要发明自己的执行路径。

依赖映射应包括提供商控制的通知依赖

组织通常映射应用程序依赖但忽略通知依赖。他们列出数据库、队列、对象存储和计算。他们可能不列出 AWS Health、Support Center、Route 53 更改 API、IAM 控制平面操作、部署系统、聊天、分页、公共状态页面和 DNS 提供商。在提供商事件期间，这些通知和命令依赖可能决定技术恢复是否可用。

一个完整的映射应为 "需要决策" 和 "需要行动" 分别设置一列。需要决策的是 AWS Health、外部探针、日志和业务指标。需要行动的是 IAM、Route 53、EC2 API、CI/CD、密钥和运营商通信。如果同一区域或提供商故障可以移除这两列，那么组织不仅有一个服务依赖；它有一个事件指挥依赖。

映射还应标记提供商控制的隐藏依赖。客户看不到每个 AWS 内部服务间调用，但他们可以列出有文档的全局服务依赖，并在事件揭示更多后更新映射。Redshift 2025 年 10 月的跨区域 IAM 组解析依赖是应纳入未来映射的信息的一个例子。它表明在 US-East-1 之外的工作负载仍然可以依赖 US-East-1 的端点以实现特定功能。客户无法防御每个隐藏的内部调用，但他们可以要求当 AWS 知道此类调用受影响时提供更好的通知。

对于高后果工作负载，依赖映射应驱动合同语言。客户可以要求重大事件通知目标、支持升级路径、事件后摘要、特定账户影响数据以及全局服务的架构指南的可用性。公共机构可以添加任务影响报告和备用处理职责。这些条款不给予客户对 AWS 内部的控制。它们创建关于 AWS 必须提供的证据的可执行期望。

客户在下一次事件中需要的证据

一个有用的通知模型将给客户层次化的真理。公共状态页面应说明受影响的区域、服务、开始时间、观察到的症状、数据平面或控制平面是否受影响、支持或健康通知是否受损以及下一次更新时间。特定账户 Health 应在可能时识别受影响的资源或服务类别。支持应拥有一个在错误账户元数据中存活的紧急路由。事件后摘要应映射触发器、根因、促成条件、影响类别和修复证据。

客户无需被动等待。他们可以构建运行手册，询问：这是用户面向的错误、提供商公共事件、特定账户事件、外部探针故障、本地部署问题还是控制平面依赖？他们可以定义何时停止部署、何时保留队列、何时切换公共状态、何时使用手动输入以及何时故障转移。提供商的通知应为这些决策提供信息，而不是让每个客户在压力下发明它们。

2025 年 10 月的事件显示了更好的通知必须区分的点。DNS 端点修复不是区域恢复。现有实例不是新容量。Global Tables 可用性不是应用程序故障转移。支持区域故障转移不是支持可用性，如果账户元数据错误。公共机构的替代申报路径不是证明每个用户都赶上了截止日期。提供商的 "所有服务正常" 声明不是证明每个客户积压已清除。

这些区分应在下一个区域事件之前写入客户运行手册，因为第一个小时是模糊状态语言最可能变成昂贵行动的时候。

AWS 的问责记录应根据控制和证据来判断。AWS 控制着服务内部、全局依赖放置、健康系统、支持行为、状态措辞和修复证据。客户控制着工作负载架构、预配置、独立监控、事件摄取和公共连续性程序。公共机构控制着任务分类和备用服务通道。当 US-East-1 失败时，客户可以离开的区域可能仍然托管着他们无法逃离的控件。通知质量是穿越那种矛盾的地图。如果它延迟、模糊或不可用，提供商就在不确定性最昂贵的时刻将不确定性转移给每个依赖组织。