SaaS 企業が本番環境の可用性向上を検討しています。現在の構成は us-east-1 のシングルリージョンで稼動しており、過去 12 ヶ月間で 3 回の重大インシデントが発生しました（RTO 4 時間、RPO 1 時間の SLA に対して、最長 6 時間のダウンタイムが発生）。アーキテクチャは以下の通りです。 ①ALB → ECS Fargate（10 タスク、Auto Scaling 5-30）。 ②Aurora MySQL クラスター（プライマリ 1、リーダー 2）。 ③ElastiCache Redis（クラスターモード有効、3 シャード）。 ④SQS キューを使用した非同期ジョブ処理。 ⑤S3 に保存された静的アセット（CloudFront 経由）。新しい SLA は RTO 30 分・RPO 5 分です。コストと複雑さのバランスを考慮した最適なマルチリージョン DR 戦略はどれですか？
RTO 30分・RPO 5分の要件にはWarm Standby（Active-Passive）がコスト・複雑さの最適バランスです。Aurora グローバルデータベースは通常1秒以下のRPOを提供し、セカンダリリージョン昇格は数分以内に完了します。Route 53 ARC（Application Recovery Controller）の準備完了チェックはDNSフェイルオーバー前に実際の稼動準備を確認し、不完全なフェイルオーバーを防ぎます。ElastiCache グローバルデータストアでセッション状態がクロスリージョンでレプリケーションされ、フェイルオーバー後もセッションが維持されます。 Active-Active構成は高可用性を提供しますが、コストと運用複雑性がWarm Standbyより大幅に高くなります。 CloudFormationデプロイとデータリストアに要する時間からRTO 30分の達成は困難です。 ECSタスク0からの起動は、タスク起動・ヘルスチェック通過・ウォームアップ時間が加算されRTO 30分を超過するリスクがあります。