AWS Disaster Recovery
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| ALB | Application Load Balancer | 应用负载均衡器 |
| API | Application Programming Interface | 应用程序编程接口 |
| AWS | Amazon Web Services | 亚马逊云服务 |
| AZ | Availability Zone | 可用区 |
| ECS | Elastic Container Service | AWS 容器编排服务 |
| EKS | Elastic Kubernetes Service | AWS 托管 Kubernetes 服务 |
| S3 | Simple Storage Service | AWS 对象存储服务 |
| SQS | Simple Queue Service | AWS 消息队列服务 |
1. 灾备目标#
灾备（Disaster Recovery，DR）是在严重故障后恢复业务和数据的能力。恢复完成应以用户能够完成关键业务为准，而不是资源状态变成 Available。
| 指标 | 含义 | 示例 |
|---|---|---|
| RTO：Recovery Time Objective | 从业务中断到恢复约定服务能力的时间目标 | 14:00 中断，RTO 30 分钟，目标在 14:30 前恢复 |
| RPO：Recovery Point Objective | 最多允许丢失的数据时间窗口 | 14:00 故障，RPO 5 分钟，至少恢复至 13:55 的数据 |
实际 RTO 包括发现、决策、隔离、数据提升、应用恢复、切流和验证。复制延迟是评估 RPO 的输入，不代表整个业务已经达到同样的 RPO。
2. 高可用、复制与备份#
| 能力 | 主要处理的问题 | 边界 |
|---|---|---|
| 单 Region 多 AZ 高可用 | 实例或 AZ 故障 | 不覆盖整个 Region 失效 |
| 跨 Region 灾备 | Region 不可用、区域网络故障 | 需要恢复应用、数据、身份和外部依赖 |
| 数据复制 | 缩小数据落后窗口、缩短切换时间 | 误删、错误写入也可能被复制 |
| 隔离备份与时间点恢复 | 误删、数据污染、勒索软件 | 恢复通常慢于提升在线副本 |
生产方案应同时具备运行中的区域容灾和独立的备份恢复路径。
3. 策略选择#
以下是相对比较，实际恢复时间由数据量、容量准备和演练结果决定。AWS 灾备策略
| 策略 | 灾备区常态 | 恢复动作 | 成本 / 恢复速度 |
|---|---|---|---|
| Backup and Restore | 保存备份和部署定义 | 重建环境、恢复数据 | 成本低，恢复较慢 |
| Pilot Light | 关键数据层运行，应用未完整运行 | 启动应用并扩容 | 成本中低，恢复较快 |
| Warm Standby | 完整应用以较小规模运行 | 数据角色切换、扩容、切流 | 成本中高，恢复更快 |
| Multi-site Active/Active | 多地同时承载生产业务 | 隔离故障区域并转移负载 | 成本及数据一致性复杂度高 |
先确定业务目标，再选择策略。不要因为单个数据库支持多 Region，就把整套应用视为双活。
4. 标准灾备流程#
- 业务分级：明确关键旅程、数据权威来源、RTO/RPO、允许降级项。
- 建设准备：部署灾备区、配置复制和隔离备份、预置权限及容量。
- 持续验证：检查复制水位、备份可恢复性、镜像、密钥、依赖和备用区健康。
- 事故决策：确认影响、选定故障切换或备份恢复路径，指定事故负责人。
- 隔离旧主：阻止旧区域写入和外部副作用，确认单一写入权。
- 恢复业务：提升数据层，恢复应用与消息链路，验证后切换入口。
- 补偿与对账：恢复遗漏任务，处理重复事件和跨系统数据差异。
- 回切与复盘：先恢复反向保护，再执行计划切换，更新演练数据。
5. 企业级实战#
企业订单平台：双 Region 灾备全过程 覆盖 Aurora PostgreSQL、DynamoDB、Valkey、SQS、ECS、EKS、ALB、Route 53、S3、Lambda、API Gateway、EventBridge，以及身份、密钥、镜像、备份、监控和回切。
已有服务文档：
迁移文档用于补充服务操作细节；计划停机迁移的前提不等于区域突发故障时的前提。