はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した ディザスタリカバリ（DR）戦略 の知識をまとめました。
DR の4つの戦略レベル（Backup & Restore〜Multi-Site）の違いと、各サービスの DR オプションを整理しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
DR 戦略の4レベル（RTO / RPO 順）
| 戦略 | 説明 | RTO | コスト |
|---|---|---|---|
| Multi-Site（Active/Active） | 両環境で常時フル稼働 | 最小（ほぼゼロ） | 最高 |
| Warm Standby | 縮小版の完全機能環境が常時稼働 | 短い（分〜時間） | 高い |
| Pilot Light | 最小限のコアコンポーネントのみ稼働 | 中程度（時間） | 中 |
| Backup & Restore | バックアップから復元 | 長い（時間〜日） | 最低 |
キーワードで判断
| キーワード | 戦略 |
|---|---|
| 「縮小版の完全機能環境」 | Warm Standby |
| 「最小限のコア要素のみ」 | Pilot Light |
| 「Active/Active」「両サイト稼働」 | Multi-Site |
| 「バックアップから復元」 | Backup & Restore |
Warm Standby vs Pilot Light の違い
この2つは試験で混同させる問題が頻出です。
- Warm Standby: 縮小版だが「完全に機能する」環境が稼働中。スケールアップするだけで復旧
- Pilot Light: 最小限のコア要素のみ（DB 等）。復旧時にインフラのプロビジョニングが必要
サービス別の DR オプション
| サービス | DR オプション |
|---|---|
| RDS | クロスリージョン Read Replica、クロスリージョン自動バックアップ、Multi-AZ |
| Aurora | Global Database（RPO 1秒、RTO 1分未満） |
| DynamoDB | PITR（秒単位、35日）、Global Tables、Deletion Protection |
| ElastiCache Redis | Multi-AZ + 自動フェイルオーバー |
| EC2 / AMI | AMI のクロスリージョンコピー（事前に必要） |
| ネットワーク | Route 53 Failover、Global Accelerator |
試験で問われる設計パターン
DR 戦略の選択
「縮小版の完全機能環境が常時稼働」→ Warm Standby
シナリオ: DR サイトとして、本番環境の縮小版が常時稼働しています。障害時にはスケールアップするだけで本番を引き継げます。この DR 戦略は何でしょうか？
正解: Warm Standby
- 「完全機能の縮小版」= Warm Standby
- 「最小コア」= Pilot Light
オンプレ DR（最小ダウンタイム）→ 常時稼働の AWS 環境 + Route 53 フェイルオーバー
シナリオ: オンプレミス環境の DR を AWS で構築したいです。最小ダウンタイムで復旧できる構成はどれでしょうか？
正解: Route 53 フェイルオーバー + EC2（ALB + ASG）常時稼働 + Storage Gateway（stored volumes）
- CloudFormation はプロビジョニング時間があり、最小ダウンタイムには不向き
- リソースは事前にプロビジョニングしておく必要がある
マルチリージョン DR（RTO 5分）→ AMI を全リージョンに事前コピー
シナリオ: マルチリージョンの DR 構成で RTO 5分が要件です。ソフトウェアのインストールに45分かかります。
正解: AMI 作成 → 全リージョンにコピー → 各リージョンで復旧
- AMI はリージョン固有 → 事前コピーが必要
- 災害発生後にコピーしていては RTO 5分に間に合わない
サービス別 DR
RDS PostgreSQL の DR → クロスリージョン Read Replica + 自動バックアップ
シナリオ: RDS PostgreSQL の DR 策として適切なものを2つ選んでください。
正解:
- クロスリージョン Read Replica
- Multi-AZ の自動バックアップ（クロスリージョン）
- Provisioned IOPS は DR 機能ではない
- Database Cloning は Aurora のみ
ElastiCache Redis DR → Multi-AZ + 自動フェイルオーバー
シナリオ: ElastiCache Redis のデータ損失を最小限にする DR 構成は？
正解: Multi-AZ + 自動フェイルオーバー
- バックアップ（日次 / AOF）はデータ損失リスクがある
- Read Replica は DR 用ではない
DynamoDB の破損データ復旧 → PITR
シナリオ: アプリのバグで DynamoDB のデータが破損しました。破損前に戻すには？
正解: DynamoDB PITR
- On-Demand Backup は事前に取得している必要がある
- Global Tables は破損データもレプリケートしてしまう
グローバル + RPO 秒単位 + RTO 1分以内 → Aurora Global Database
シナリオ: グローバルアプリで RPO を秒単位、RTO を1分以内に抑えたいです。
正解: Aurora Global Database
- RPO = 1秒、RTO = 1分未満
マルチリージョン + 自動フェイルオーバー → Global Accelerator
シナリオ: マルチリージョンのアプリで数秒以内の自動フェイルオーバーを実現したいです。
正解: AWS Global Accelerator
- 静的 IP → DNS キャッシュの影響なし
- 数秒で自動フェイルオーバー
データ損失最小 + 2ノード同期 → RDS Multi-AZ
シナリオ: すべてのトランザクションを2つのノードに同期的に保存したいです。
正解: RDS MySQL Multi-AZ（同期レプリケーション）
- Read Replica は常に非同期（「同期 Read Replica」は矛盾 → 不正解）
おわりに
DR 戦略は「Warm Standby = 完全機能の縮小版」「Pilot Light = 最小コアのみ」という違いを正確に把握しておくことが重要です。サービス別の DR では「Aurora Global Database の RPO 1秒 / RTO 1分」「DynamoDB の PITR」「AMI の事前クロスリージョンコピー」が頻出です。
間違いや補足があればぜひコメントで教えてください。