>

# AWS us-east-1 电商订单系统容灾评估（目标 RTO 30分钟）

一、当前架构的优势

• RDS MySQL 多可用区：主库故障时自动切换到备库，通常在 1-5 分钟内完成，不占用你的 RTO 预算大头。
• EC2 位于成熟区域：us-east-1 可用区数量多（≥6 个），服务生态完善，恢复手段丰富。

二、主要风险点

1. 区域级故障无覆盖：3 台 EC2 + 多可用区 RDS 只解决 AZ 级故障；若 us-east-1 整体不可用（历史上曾发生大规模事故），当前架构 RTO 远超 30 分钟，实际可能是数小时甚至更久。

2. 单点风险待确认：3 台 EC2 是否跨可用区部署？前端是否有 ELB/ALB？若都在同一 AZ，单 AZ 故障即全站不可用。

3. RTO 未验证：30 分钟是目标还是实测值？未做过演练的 RTO 只是纸面数字。

4. 隐性依赖：DNS、ELB、缓存（如 ElastiCache）、SQS 等若未纳入容灾设计，会成为恢复瓶颈。

三、针对性建议

• 立即做（低成本）：
• 确认 3 台 EC2 跨 ≥3 个 AZ，前置 ALB + Auto Scaling（跨 AZ）。
• RDS 开启自动备份 + 保留期 ≥7 天，启用 PITR（时间点恢复）。
• 中期（满足真 30 分钟 RTO）：
• 部署跨区域容灾：RDS 只读副本搭建在备区域（如 us-west-2），EC2 用 AMI/启动模板 + 预置 VPC 实现快速拉起。
• Route 53 健康检查 + 故障转移路由，DNS 切换通常几分钟内生效。
• 常态化：
• 每季度做一次故障切换演练，实测端到端 RTO；用 AWS Resilience Hub 评估韧性得分。
• 制定并演练 runbook，明确切换决策人（避免故障时扯皮）。

四、结论

• AZ 级故障：若 EC2 已跨 AZ + 有 ALB，30 分钟 RTO 可达成（预计 10-15 分钟内）。
• 区域级故障：当前架构无法达成，需补齐跨区域方案。
• 建议优先级：验证现状 → 补跨区域副本与 DNS 切换 → 演练固化。