摘要

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

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

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

AWS 的2025 年 10 月 DynamoDB 服务中断摘要很有价值，因为它提供了超出通用中断标签的信息。它描述了 DNS Planner 和 DNS Enactor 的竞争、DynamoDB 区域端点所有 IP 地址的丢失、手动修复、EC2 主机租约崩溃、Network Manager 积压、Network Load Balancer 健康检查不稳定、Support Center 受损以及各服务的具体影响。这种事后证据水平是客户需要的标准。问题在于时机：客户在进行实时连续性决策后，大部分信息才到达。

当时的AWS Health 事件历史记录展示了事件期间的公开通信界面。这是一份必要的记录，但实时状态历史记录无法替代客户特定的依赖映射图。SaaS 提供商需要知道其账户是否受到 DynamoDB 端点解析的影响、EC2 启动是否会失败、NLB 是否在减少容量、支持案例是否无法打开，以及账户特定的 Health 事件是否到达了其备用区域。“US-East-1 运行问题”是一个起点，但并非决策树。

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

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

2025 年 10 月的事件有多重时钟

2025 年 10 月的事件不能用单一的起点和终点来表示。据 AWS 称，最初的 DNS 缺陷始于太平洋时间 10 月 19 日深夜，主要事件于 10 月 20 日下午 2:20 结束。Amazon 简短的公开更新表示，所有 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 平台警告说，notebook 分配可能超时。这些通知显示了针对具体任务的连续性：延迟数据、保留法律提交或分配计算资源。

控制平面依赖使区域难以逃脱

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

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

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

2025 年 10 月的摘要展示了这一悖论。其他区域的 DynamoDB Global Tables 副本可以直接访问，并已报告赶上进度。但应用程序必须知道如何路由到它们，自身的身份和 DNS 控制是否有效，写入是否需要协调，以及下游服务是否健康。EC2 启动在第一个端点问题修复后仍失败了许多小时。NLB 健康检查因网络状态未完全到达新实例而移除容量。第二个区域只有在客户能够在不首先调用受损权威的情况下进入并运行它时，才是一种弹性。

AWS 并非客户是否预先配置了温容量一方的责任。客户做出成本和架构选择。但 AWS 控制着内部依赖的披露、服务健康通知的精确度，以及让客户更新计划的事件后解释。当某些全球控制路径和状态通道受限于区域时，提供商不能简单地说“使用多区域”。它还必须告诉客户，在提供商事件期间这些依赖项如何表现。

Support 和 Health 通道需要独立的故障行为

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

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

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

Support 和 Health 事件需要一个具体的故障模型。如果客户身份受损会发生什么？如果账户元数据错误会发生什么？如果客户的 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 租约、Network Manager、NLB 健康检查、服务依赖项和支持。客户需要这些细节来纠正自己的假设。

弱点不在于摘要的存在；而在于缺少针对每项修复措施的独立验证的闭环。AWS 表示已在全球范围内禁用了 DNS Planner 和 Enactor 自动化，等待更改，将修复竞争问题，添加 NLB 容量移除限制，改进 EC2 恢复测试，并为网络状态添加感知队列的速率限制。这些行动与披露的机制相符。这里审阅的公开记录并未提供一份完整的独立闭环登记册，包括日期、测试和持续结果。客户必须决定他们能从提供商撰写的报告中接受多少保证。

这就是执行风险进入之处。如果提供商的事后分析是唯一证据，客户和监管机构可能缺乏在采购压力和合同谈判之外要求闭环的途径。云依赖已成为许多服务的公共基础设施，但许多补救措施仍然是合同性或声誉性的。因此，通知质量和事件后证据不仅是技术实践；它们是客户无需看到提供商内部系统就能强制改善行为的机制。

公共机构需要任务级连续性，而非云民间传说

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

CISA 关于公共安全通信对非机构基础设施依赖的论文警告说，外部基础设施和服务可能产生相关的连续性风险。CISA 的Infrastructure Dependency Primer询问冗余提供商是否共享依赖项，以及变通方案能维持多久。NIST 的SP 800-34 应急规划指南将重点放在业务影响、恢复优先级、替代处理和经过测试的计划上。

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

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

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

SLA 和营收并不能确定问责

AWS 是一家规模非常大的企业。Amazon 的2025 年 Form 10-K报告了 AWS 净销售额为 1287.25 亿美元，并承认了涉及系统中断、冗余和灾难恢复的风险。规模很重要，因为它赋予了提供商资源和公共重要性。但这并不能自动证明每一项控制都足够，或者每一次中断都具有法律可诉性。

服务水平协议同样受到限制。DynamoDB SLA定义了月度正常运行时间承诺、积分、索赔程序、排除项和 Global Tables 的处理方式。SLA 积分可以有意义，但它不是公共服务延迟、损失开发者时间、错过营收、提交失败、客户信任或事件劳动量的衡量标准。积分也不能识别出故障的内部依赖项或证明修复措施。它是一个合同补救措施，而非连续性报告。

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

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

客户不应将自己的连续性判断外包给 AWS。他们应该预先配置关键容量，在恢复期间避免最后一刻的控制平面操作，从 AWS 外部进行监控，独立托管事件通信，配置带有区域备份的 Health 事件交付，演练手动程序，并按后果对公共职能进行分类。这些客户责任是真实的。它们并没有抹去 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 托管服务纠缠在一起。这些不是道德失败；它们是由提供商事件暴露的架构差距。它们的事后分析很有用，因为它们将差距转化为行动项。其他客户不应等待自己的事件来学习同样的教训。

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

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 可用性不是应用程序故障转移。如果账户元数据错误，支持的区域故障转移不是支持可用性。公共机构的替代提交路线不是每个用户都赶上截止时间的证明。提供商“所有服务正常”的声明不是每个客户积压已清除的证明。

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

排版是排列文字的艺术和技巧，使书面语言清晰、易读且视觉上吸引人。它涉及选择字体、字号、行长、行距和字间距。

  • 排版起源于 15 世纪 Johannes Gutenberg 发明的活字印刷。
  • 关键元素包括字体选择、字偶距调整、字间距和行距。
  • 良好的排版能增强可读性，并在设计中传达情绪或基调。

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

排版

排版是排列文字的艺术和技巧，使书面语言清晰、易读且视觉上吸引人。它涉及选择字体、字号、行长、行距和字间距。

  • 排版起源于 15 世纪 Johannes Gutenberg 发明的活字印刷。
  • 关键元素包括字体选择、字偶距调整、字间距和行距。
  • 良好的排版能增强可读性，并在设计中传达情绪或基调。