AWS Enterprise Disaster Recovery Runbook

1. 场景与边界#

以企业订单与履约平台为例：客户登录、浏览商品、上传附件、下单付款，后台完成库存分配、发货、通知和报表。采用 双 Region Warm Standby、业务单写、跨账号隔离备份。

本文是参考架构和操作手册。Region、规模、时间预算是设计假设；部署前需要绑定实际资源清单、完成脚本实现和演练，不能把本文当作已验证的生产恢复能力。

服务、引擎版本、实例类型及备份复制能力必须在 A/B 实测。跨 Region 运行副本仍在生产账号，不能替代跨账号防破坏备份。

2. 业务目标与恢复口径#

这些数值是本方案的目标，不是 AWS SLA。附件和交易不能共享一个含糊的“RPO 1 分钟”。法规要求绝对不丢失的交易，需要另行设计并验证同步持久化及业务确认协议；异步 Aurora 跨 Region 复制不能承诺区域故障下零丢失。

记录四个时间：T0 首次业务中断、Tdeclare 宣布灾备、Tdata 数据可用、Tservice 用户旅程恢复。实际 RTO 为 Tservice - T0，不从宣布灾备后重新计时。

3. 应用架构#

A/B 各有一套区域应用栈。图中展示单区业务路径，跨区数据路径如下：

A Aurora writer        -> B Aurora Global Database secondary
A DynamoDB replica     <-> B Global Tables replica（应用只允许活动区写）
A Valkey primary       -> B Global Datastore secondary
A S3 object versions   -> B S3 CRR destination
A EventBridge bus      -> B bus（global endpoint event replication）
A ECR / secrets        -> B 本地镜像与密钥副本
生产备份                -> 独立备份账号及目标 Region

A SQS backlog          -X-> B SQS（本方案不依赖队列透明复制）
Aurora outbox / ledger -> B 重建需要执行的任务

ECS 承载订单、账户和常规 worker；EKS 承载已有 Kubernetes 平台的库存与履约服务；Lambda 处理轻量回调、对象事件和通知。它们承担不同职责，不让同一笔业务同时走三套消费者。

4. 服务恢复矩阵#

Global Tables 使用 MREC，并通过应用保持单写。MRSC 有区域集合和部署条件限制，不应直接套用到任意两个 Region。DynamoDB 设计说明

5. 灾前建设#

5.1 网络、账号与访问#

• A/B 各建 VPC，应用跨可用的多个 AZ；数据库、缓存和容器位于私有子网。
• 准备 NAT 或 VPC endpoints、DNS、网络策略、回调入口和合作方 IP 白名单；避免 B 出网依赖 A。
• 预建恢复角色和 break-glass 访问，演练从独立运维终端取得凭证。SCP 不得阻止已批准的 B 区恢复操作。
• 生产账号不能删除备份账号的恢复点；备份 KMS 权限与密钥保留时间覆盖备份保留期。
• Terraform state、锁、Git、制品和恢复文档有独立可用路径；事故时先冻结常规 apply，避免自动化把切换结果改回去。

恢复清单至少记录：账号 ID、Region、集群 ARN、数据库全局标识、bucket、queue URL、EventBridge endpoint ID、Lambda mapping UUID、域名、ACM ARN、KMS ARN、恢复角色、负责人和最近一次验证时间。

5.2 数据与备份#

每次发布都在 B 验证 schema、镜像和配置兼容性。ECR 复制规则启用前的既有镜像需单独补齐；恢复指定 digest，避免依赖可变的 latest。ECR 复制

Secrets Manager 复制凭据，但区域数据库地址等配置应独立管理，避免 B 副本仍连接 A。验证 B 的 KMS 解密与应用角色授权，不把私钥或数据库密码写进运行记录。Secrets 跨区复制

AWS Backup 对不同服务、Region 的复制、PITR 和恢复测试支持不同；不能默认一种备份计划覆盖全部服务。连续备份复制后可能成为快照恢复点，不能假定仍有相同 PITR 能力。功能矩阵

5.3 容量与版本#

示例负载基线：正常 500 请求/秒，关键交易峰值 1,500 请求/秒。B 常态保留经测试可服务小流量的实例，目标在切流前承载关键峰值；暂停报表和批处理，为交易预留容量。

容量预留是否适用于所选计算方式需单独核对；提升配额不能代替真实的满载演练。若 30 分钟内扩容达不到关键吞吐，就增加 B 常驻容量或调整 RTO。

5.4 身份和外部依赖#

本文假设企业已有多区域可用的 OIDC 身份平台。B 预置 issuer、audience、回调 URL、JWKS 获取路径与密钥缓存，验证新登录、刷新 token 和注销。

若实际使用 Cognito，必须单独设计用户池、密码、MFA、会话和故障期登录策略；本方案不假定区域用户池透明跨区恢复。

支付平台、仓储系统、邮件/SMS、第三方风控都要认可 B 的出口和 webhook 地址。A 区域已签发的预签名 S3 URL 可能失效，B 应重新签发本地 bucket URL。

6. 一致性与消息恢复设计#

6.1 明确数据权威来源#

• Aurora 的订单、库存预留、付款状态、Outbox 和消费者处理账本是交易事实。
• DynamoDB 是商品及订单查询投影；跨区出现比 Aurora 更新的投影时，不能据此执行付款或发货。
• Valkey 仅保存可丢弃缓存；不保存唯一库存、长期会话、支付幂等记录或跨区锁。
• S3 保存附件内容；数据库记录对象 key、version ID、内容摘要和复制确认状态。
• 支付平台的真实交易流水用于核对外部扣款事实，不能因本地记录缺失就再次扣款。

6.2 Transactional Outbox#

订单和 Outbox 在同一个 Aurora 事务内提交：

BEGIN
  写订单 / 更新业务版本
  写 outbox(event_id, aggregate_id, aggregate_version, event_type, payload)
COMMIT

relay -> EventBridge -> SQS -> consumer
consumer -> 业务更新 + processed_events 唯一键（同一数据库事务）

Relay 遇到 PutEvents 部分失败需逐条重试；“成功发送”不等于业务执行完成。切换后从恢复检查点前的重叠窗口重新发布，覆盖已经发送但未完成消费的事件，而不是只查 published = false。

示例保留 Outbox 14 天、处理账本 30 天；保留窗口必须大于最大故障时间、队列保留时间和人工补偿周期。不能提前清理仍未确认的业务事件。

消费者以稳定 event_id 去重，以聚合版本控制乱序；更新事实与记录完成状态在同一事务内。外部付款/退款/发货使用下游幂等键和查询接口，解决“下游成功、本地未提交”的不确定结果。

支付 webhook 只有在事件及其稳定幂等键写入权威存储后才确认接收；故障期依赖合作方重试和主动流水查询。只将回调放入 A 的队列就返回成功，会留下本方案无法从 B 重建的缺口。

6.3 SQS、Lambda 与 EventBridge#

本方案的 B 队列是独立队列，恢复时从已恢复的 Outbox 和业务账本重建任务，不对旧队列进行破坏性读取搬运。SQS 消费需容忍重复交付，不能依靠短期 FIFO 去重窗口获得跨区恰好一次处理。SQS 故障恢复

Lambda 的 SQS event source mapping 使用同 Region 队列；B 的映射单独部署并保持 disabled，直到单写权和数据就绪。Lambda SQS 配置

启用 EventBridge global endpoint 的事件复制，并确保生产者实际使用该 endpoint ID。双区规则可把事件写入各自队列，但 B 消费者保持关闭；禁止备用规则直接触发支付等副作用。复制副本、客户端重试和重放都必须沿用同一业务 event_id。

EventBridge 的区域切换时间不等于订单平台 RTO；事件复制也不保证本例 1 分钟交易 RPO，所以恢复权威仍是数据库中的 Outbox。global endpoint 的 SDK、健康检查和复制配置要按官方要求验证。Global endpoints

两区分别建立 archive。Archive replay 只能回到原接收事件的 bus，不应计划从故障区不可访问的 archive 直接恢复到 B；恢复优先使用 B 已有事件和 Outbox。归档与重放

B 队列可能包含已复制到 EventBridge、但对应 Aurora 事务尚未复制到 B 的事件。消费者必须先核对订单事实与版本；缺少事实的事件进入隔离待对账，不能仅凭消息内容执行扣款或发货。

EventBridge Scheduler、EKS CronJob、ECS scheduled task 和数据库定时作业均需列入生产者清单。B 配置预建但默认关闭，切换后对遗漏时间段补跑，使用稳定任务 ID 去重。

6.4 跨数据源恢复水位#

定义应用检查点 checkpoint_id，记录 Aurora 已提交业务序号、DynamoDB 投影版本、关键 S3 对象复制状态、Outbox 范围和消费者完成位置。跨服务没有统一事务快照，检查点由应用验证生成，不能仅比较 wall clock。

恢复时选择可验证的共同业务边界；边界后的订单、投影和对象进入对账或隔离列表。对有序业务按聚合序号补齐，不能把日志中最大的时间戳视为所有业务都已恢复。

S3 RTC 的 15 分钟承诺针对规定比例的新对象，不代表每个对象绝不会超时；历史对象需要另外回填。关键附件若必须与订单一起恢复，应在确认 B 对象可读且摘要匹配后再把业务状态标记为“跨区保护完成”。S3 复制

7. 防止双写：切流前置条件#

DNS、ARC、停止容器都不能单独证明旧区域已停止写入。 A 可能仍可被旧 DNS 缓存访问，后台 worker 也可能继续运行。

本方案要求实现独立的写入权控制：恢复管理面维护 active_region、单调递增的 epoch 和短期租约。权威状态使用强一致存储和条件更新；不能使用最终一致的 Global Tables 各副本独立抢锁。

可采用独立管理账号、第三 Region 的单区 DynamoDB 表作为租约权威，由受控服务串行签发租约。该方案引入明确的可用性取舍：权威服务不可用时，租约到期后业务停止写入，不能两区各自续租。若采用多区域仲裁系统，需要另行验证其一致性和区域支持。

必须实现并验证：

1. 所有入口、worker、定时任务和人工写入工具都受控；绕过网关的 DB 账号不能留下长期写权限。
2. 请求携带 epoch；数据库写入适配层和副作用执行层校验租约，过期拒绝操作。单次启动时检查配置不够。
3. 为事务和外部调用规定最大执行时间，控制时钟偏差；切换要等待旧租约以及旧操作的最大剩余时间结束。
4. 支付等外部系统未必识别 epoch，必须另外依赖全局稳定幂等键和流水查询。
5. 隔离 A 可达路径时，同时停止生产者、消费者和调度器；网络或权限收紧作为附加保护。

无法证明写入隔离时，保持 B 只读或暂停交易。 业务风险批准不能把尚未实现的防双写能力变成安全保证。上述租约不是 AWS 自动附带的特性，应作为应用工程交付和演练的必要验收项。

8. 事故指挥与切换门禁#

建议触发条件：外部业务探针连续失败超过约定窗口，同时存在独立网络或服务信号；预计原地恢复将超过剩余 RTO 预算。一次 ALB 5xx 或单个 AZ 故障不直接触发跨区提升。

复制指标过期或源区不可达时，只能报告“当前可验证的恢复边界与未知区间”，不能依据最后一个低延迟采样宣称 RPO 已达标。

9. A 故障后的完整执行过程#

阶段一：发现与冻结（目标 T+0～5 分钟）#

1. 从独立探针确认登录、查询和下单是否故障，记录 T0；排查单 AZ、发布错误、第三方支付故障。
2. 指定 Incident Commander，创建事件记录，冻结部署、schema migration、Terraform apply 和数据清理任务。
3. 保存 A/B 最近的复制水位、错误率、队列积压和发布版本。不要记录明文密钥。
4. 确认 B 无数据污染；若是误删、攻击或错误数据扩散，跳转到第 12 节。

阶段二：隔离与恢复授权（目标 T+5～10 分钟）#

1. 宣布启用灾备；进入维护/只读模式，保留客户端稳定的幂等请求 ID。
2. 停止给 A 签发写租约，等待租约与在途操作的安全窗口结束。A 可访问时停 worker、调度器、Lambda 映射和 Relay。
3. 记录 G1 证据，再将新 epoch 的活动区设为 B；B 的生产写入开关此时仍关闭。
4. 数据负责人提交预期缺失窗口；超出既定目标时记录业务决策与补偿路径，不能隐去 RPO 超标。

阶段三：恢复数据与容量（目标 T+10～20 分钟）#

以下工作可并行准备，但必须在数据角色确认后才启动有副作用的业务。

Aurora 计划 switchover 和故障 failover 不能混用；后者可能丢失未复制事务。托管切换的引擎版本兼容性应在灾前验证。rds.global_db_rpo 可用于受支持 Aurora PostgreSQL 的 RPO 控制，但可能阻塞主库提交，需提前压测配置。Aurora 切换与 RPO

Valkey Global Datastore 的跨区提升需显式操作，应用重新加载目标 endpoint；不要误认为区域内 Multi-AZ 自动 failover 会自动完成跨区切换。Global Datastore

阶段四：内部业务验证（目标 T+20～25 分钟）#

1. 使用 B 专用验证域名，从真实 ingress 访问 ALB 和 API Gateway；只给测试租户写入权限。
2. 完成登录、创建测试订单、库存预留、上传/下载附件、查询投影和退款模拟。支付测试使用沙箱或经过批准的可撤销测试交易。
3. 检查 Aurora 的事实与 DynamoDB 投影，确认缓存未命中可回源。
4. 启用小批量 B 消费者，限制并发，回放检查点前的重叠窗口。先核对订单，再处理有外部副作用的付款/履约任务。
5. 验证同一事件重复投递、乱序事件、失败重试和 DLQ 路径；确认重复请求不重复扣款或发货。
6. 验证 G2/G3，通过后开放 B 的正式写入开关。

阶段五：公众切流（目标 T+25～30 分钟）#

1. 通过预建 ARC routing controls 切换 A/B 状态；使用预配置的数据面端点和安全规则，避免事故时临时创建恢复控制资源。
2. app.example.com 切至 B ALB；api.example.com 切至 B Regional API Gateway 自定义域。分别验证两条入口，不能只测首页。
3. API Gateway 的 stage、authorizer、usage plan、WAF、区域证书与 Lambda alias 必须提前一致。Route 53 不会代替这些配置的部署。
4. 观察 DNS 缓存与长连接，应用引导重连；旧 A 请求保持拒绝写入，不依赖 DNS 收敛作为隔离证据。
5. 若实际部署只有 failover 路由，本次直接切换活动目标；若需要百分比灰度，应预建并演练 weighted 路由，不能事故时临时混改路由模型。
6. 从多个网络位置持续验证业务旅程和容量，记录 Tservice。剩余报表积压不影响已约定的核心 RTO，但要独立记录恢复时间。

ARC 控制路由，不负责数据库写入权；Route 53 健康状态异常时也不应被当作 fail-closed 的写入保护。ARC routing control

双区域 Regional API 的域名与切换方式参考 API Gateway 多 Region failover。

阶段六：稳定运行与补偿（T+30 分钟以后）#

• 逐步提高 worker 并发，观察最老任务年龄、DLQ、数据库连接和下游节流，避免恢复流量再次压垮系统。
• 从 Outbox / 业务账本识别缺失任务，重放时保留原 event_id；不得为了消除告警直接清空 DLQ。
• 对账支付成功但订单缺失、订单存在但附件缺失、库存预留无后续状态等异常。
• 客户报告已成功但 B 无记录的请求，使用请求 ID、外部流水和审计证据恢复，不能凭日志批量伪造已提交交易。
• A 恢复可达后先保留只读证据，检查是否存在 B 未收到的尾部数据，再决定补偿；禁止直接把旧库接回生产写入。
• 确认 B 作为新主已有备份、监控和再次故障时的恢复路径，再宣布事故进入稳定阶段。

10. EKS 与状态型组件恢复#

本例尽量把交易状态放在托管数据服务中。EKS 的 Deployment、Service、Ingress、CRD、配置和策略由 GitOps 恢复；集群身份、IAM、Pod Identity / IRSA、CSI、Load Balancer Controller、DNS 和网络策略必须适配 B。

存在 PV 时，为每个 workload 记录备份一致性方式、PVC / PV 映射、StorageClass、AZ 和 KMS。EBS 卷不能原样跨 Region 挂载，应从可用的目标区恢复点创建卷；在隔离命名空间验证后再接入生产。

AWS Backup 支持 EKS 集群状态与持久卷的组合恢复点，但复制与恢复能力需按资源类型和 Region 核对。不要把“备份成功”当作应用事务一致性验证。EKS 备份、EKS 恢复

B 温备集群已经运行时，不盲目用整集群恢复覆盖现有环境；优先恢复缺失对象或在新集群验证，再通过预先验证的迁移步骤接入。恢复工具若会重建 ALB、IAM 或 DNS，必须审查变更边界。

11. 切换失败时怎么处理#

禁止在健康检查反复变化时让数据库、生产者和公众 DNS 来回自动切换。应用版本回滚、流量回切和数据回切是三个不同操作。

12. 数据污染或账号失陷：隔离恢复路径#

在线复制可能已经复制误删或恶意修改。此时以最近可信恢复点为基础恢复到新资源，RTO/RPO 单独计算，不能承诺沿用 30 分钟区域切换目标。

1. 安全负责人确认隔离范围，停止受污染生产者和凭据，保存 CloudTrail、审计日志和恢复点证据。
2. 从独立备份账号选择污染发生前的可信恢复点，验证其 KMS 可用；在干净恢复账号/VPC 建立受控环境。
3. 按服务能力分别恢复 Aurora 新集群、DynamoDB 新表、S3 历史对象与必要 PV。不要覆盖原证据资源。
4. 使用同一业务检查点做跨数据源对账；若时间点不同，先恢复事实，再重建投影和缓存。
5. 重建镜像与部署定义的可信版本，轮换密钥、凭据、签名材料，验证 IAM 和供应链没有残留入口。
6. 按第 9 节的内部旅程和单写门禁切流；清理污染数据前获得证据保留确认。

备份保留策略可采用日备份 35 天、月备份 12 个月作为讨论起点，最终按数据分类和合规要求确定。Vault Lock compliance 模式冷静期结束后的不可变约束需在启用前审查，不能把它当作随时可撤销的开关。Vault Lock

13. B 回切 A 的完整流程#

回切是一次计划变更，不因 A 恢复健康就自动执行。

1. 确认条件：A 根因已修复，B 稳定运行；双方容量、版本、配置、权限和外部依赖复验通过。
2. 恢复反向保护：按 Aurora 当前拓扑重新加入或重建 A 为 B 的副本；不能假定旧 A 已自动具备最新数据。Valkey 同样检查真实主从关系。
3. 处理双向数据：DynamoDB 等待副本收敛并对账；S3 在 B 开始生产写入前就应具备或补建 B→A 复制，使用独立前缀/规则和副本策略验证，补齐故障期对象。
4. 重建消息路径：检查 A 的规则、队列、DLQ 与 archive；旧积压按业务账本去重，不能无条件重新放开旧消费者。
5. 建立回切检查点：暂停新写入、Relay、消费者和调度，等待在途事务和外部操作结束；记录最后业务序号和对象集合。
6. 同步确认：确认 A 已覆盖检查点，核对订单、库存、付款和对象；源数据仍落后则延后回切。
7. 计划提升：Aurora 执行支持的 managed switchover；缓存按计划切换或重建，更新区域配置与连接池。
8. 交接写入权：结束 B 租约及旧操作，生成新 epoch 授予 A；内部旅程通过后开放 A 写入，再切公众入口。
9. 恢复异步任务：从检查点重叠重放，逐步恢复 worker 与定时任务；确认只有 A 执行生产副作用。
10. 重新建立温备：B 降为灾备但不立即销毁。验证 A→B 数据保护、备份和告警后再缩容。

B 已产生新写入后，直接把 DNS 指回旧 A 会造成数据丢失或分叉。回切失败时同样依据“当前哪个区域已接受新写入”决定恢复方向。

14. 演练与验收#

演练节奏#

故障注入覆盖：A 入口不可达但 worker 仍运行、跨区复制延迟、B 容量不足、KMS 拒绝、Secret 仍指向 A、支付成功后消费者崩溃、S3 附件未复制、DynamoDB 投影领先于恢复订单、旧 DNS 长连接持续访问、身份提供方故障。

实施记录使用 变更执行边界；计划切换的具体命令与分阶段中止方式见 Aurora 切换实操。无计划故障继续遵循本篇单写门禁，不因源区失联而绕过。

必须保存的验收证据#

每次演练报告包含：版本/拓扑、场景、负责人、完整时间线、门禁证据、丢失数据明细、人工步骤、失败项、整改责任人与期限。未通过的问题必须进入发布和灾备准入条件。

15. 恢复编排与日常维护#

用 Step Functions 或 SSM Automation 承载可重入步骤，执行环境放在不依赖 A 的恢复管理面。每一步记录执行 ID、目标 ARN、前置状态、结果与重试策略；不可逆步骤如提升数据库、开放写入和切流需要事故角色确认。

Detect -> Classify -> Freeze -> Fence A -> Approve recovery boundary
       -> Promote data + Scale B -> Validate internally
       -> Enable B writes -> Route traffic -> Reconcile -> Reprotect

编排必须支持从已完成步骤继续，重试前先查询真实状态。A 控制面不可用时不要无限等待停机 API 成功，应依赖已验证的租约隔离；如果没有这种隔离能力，则停在 G1。

日常监控至少包括：Aurora 恢复水位、DynamoDB 复制延迟、S3 未复制对象、ECR 发布 digest、备份复制失败、B 登录和下单探针、队列最老消息、DLQ、消费者进度、租约续期失败、KMS/Secrets 拒绝和 B 的容量余量。

成本按双区常驻数据库/缓存、EKS 集群与节点、容器容量、跨区传输、对象副本、备份保留、ARC、日志和演练计算。本方案通过缩减备用计算和暂停非关键业务控制成本，不通过取消恢复验证降低成本。

可执行配套#

Aurora Global 计划切换实操 提供角色隔离、状态比较交换、实际对账查询和切换脚本；前置拓扑与不支持的故障场景均明确列出。