AWS DR戦略4パターン比較｜Backup & Restore・Pilot Light・Warm Standby・Multi-Siteの違いと設計判断ガイド

「上長にDR費用の概算を出してほしいと言われたが、パターンが多すぎてどこから見積もればいいかわからない」「Pilot LightとWarm Standbyは名前が似ているが実際にどう違うのか」——こうした疑問はDR設計を初めて担当するインフラエンジニアが必ずぶつかる壁だ。

AWSはDR（Disaster Recovery/災害復旧）アーキテクチャを4つのパターンで整理しており、それぞれRTO・RPO・コストのトレードオフが大きく異なる。パターンを正しく理解していないと、「RPO 1時間で十分なシステムにMulti-Site Active/Activeを採用してコストが10倍になった」という本末転倒な設計ミスにつながる。

本記事では4パターンの仕組み・違い・AWS実装のポイントを整理し、東京リージョンを想定した月額コスト試算と選定の判断フローまで現場視点で解説する。

RTO・RPOの基礎（知っている方は読み飛ばしてOK）

DR戦略を語る前に2つの指標を確認しておく。

・RTO（Recovery Time Objective）：目標復旧時間。障害発生からサービス再開まで許容できる最大時間
・RPO（Recovery Point Objective）：目標復旧時点。障害発生時に「どこまでデータが戻ることを許容するか」を示す損失の上限

例えば「RTO 2時間・RPO 30分」という要件なら、障害から2時間以内に復旧でき、最大30分前のデータ状態まで巻き戻ることを許容するという意味だ。RTOとRPOの基礎についてはAWS災害復旧（DR）設計入門で詳しく解説しているので、初めて触れる方はあわせて参照してほしい。

AWS DR戦略4パターンの全体像

AWSが公式に整理している4パターンを一覧で比較する。

重要なのは「RTOとRPOの要件が厳しいほどコストが指数的に上がる」点だ。要件は机上の最良値ではなく、ビジネスが実際に許容できるラインを経営層に確認してから設定する。

各パターンの詳細

1. Backup & Restore——コスト最小・シンプルな原点

最も基本的なパターン。本番環境のデータを定期的にS3やAWS Backupに保存しておき、障害時にバックアップからリストアしてシステムを再起動する。

仕組み

・定期バックアップ（AWS BackupまたはRDSスナップショット）を別リージョンへクロスリージョンコピー
・障害時: スナップショットからRDSを復元し、AMIからEC2を起動する
・Route 53のDNSをDRリージョンへ向け直してトラフィックを切り替える

CLIでのスナップショットコピー例

# RDSスナップショットを東京から大阪へクロスリージョンコピー（AWS CLI）
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:ap-northeast-1:123456789012:snapshot:mydb-snap-20260721 \
  --target-db-snapshot-identifier mydb-dr-snap-20260721 \
  --region ap-northeast-3

# EC2 AMIを大阪リージョンへコピー
aws ec2 copy-image \
  --source-image-id ami-xxxxxxxx \
  --source-region ap-northeast-1 \
  --region ap-northeast-3 \
  --name "dr-ami-$(date +%Y%m%d)"

メリット・デメリット

・メリット: DR用インフラを常時稼働させないので追加コストが最小限
・メリット: 設計がシンプルで理解・実装・テストが容易
・デメリット: リストアに時間がかかる（EC2起動・データリストア・アプリ設定確認で合計数時間）
・デメリット: バックアップ間隔がRPOの上限になる（1時間ごとのバックアップ → 最大1時間のデータ消失）

向いているシステム

・社内業務ツール・開発環境など、数時間の停止が許容できるシステム
・バックアップさえあれば再構築できる比較的シンプルな構成のシステム
・DR予算をほとんど取れないがデータ保護は最低限必要なケース

AWS Backupを活用した具体的なバックアップポリシー設計についてはAWS Backup入門で詳しく解説している。

2. Pilot Light——データベースだけ火を灯しておく

「パイロットランプ（pilot light）」という名前の通り、大きな炎を点けるために必要な小さな火種（＝DBのレプリカ）だけを常時稼働させておく考え方だ。

仕組み

・DRリージョンのRDSにクロスリージョンリードレプリカを作成し、常時データを同期
・Web/アプリサーバー用AMIは用意しておくが、EC2インスタンスは停止状態（またはt3.microなど最小サイズ）を維持
・障害時: リードレプリカをスタンドアロン（書き込み可能）に昇格 → EC2をAMIから起動 → Route 53を切り替え

フェイルオーバー時のCLI例

# 大阪リージョンのリードレプリカをプライマリに昇格（AWS CLI）
aws rds promote-read-replica \
  --db-instance-identifier mydb-dr-replica \
  --region ap-northeast-3

# レプリカ昇格完了後、EC2をAMIから起動
aws ec2 run-instances \
  --image-id ami-yyyyyyyy \
  --instance-type m5.large \
  --count 2 \
  --region ap-northeast-3 \
  --user-data file://startup-script.sh

実務上の注意点

・リードレプリカ昇格はインスタンス再起動を伴うため、昇格完了まで数分のダウンタイムが発生する
・EC2起動後のアプリ設定（DB接続先・環境変数・シークレット等）の変更を手動で行うとRTOが大幅に伸びる。AWS Secrets ManagerやSSMパラメータストアに接続情報を格納し、起動時に自動取得する設計が必須だ
・AMIは本番と同期した最新版を維持しておく（古いAMIから起動するとアプリバージョン不一致が発生する）

3. Warm Standby——縮小版本番を常時稼働させる

本番環境と同じシステム構成をスケールダウンした形でDRリージョンに常時稼働させるパターン。「小さな本番環境が常に動いている」イメージだ。

仕組み

・DRリージョンに本番の50～70%規模のEC2クラスター + RDSレプリカを常時稼働
・Route 53のヘルスチェックが本番の異常を検知すると、フェイルオーバーレコードへ自動切り替え
・切り替え後: Auto ScalingグループのDesired Capacityを本番相当まで引き上げてトラフィックを受け切る

フェイルオーバーの流れ

Pilot Lightとの最大の違い

Pilot LightではEC2を起動する時間がRTOに直接影響する（インスタンス起動に1～2分 + アプリ初期化に数分）。Warm Standbyはすでにインスタンスが稼働しているため、DB昇格が完了すれば即座にリクエストを受け付けられる。その分、常時稼働のEC2コストが余計にかかる。

メリット・デメリット

・メリット: フェイルオーバー後のスケールアップまでの間も縮小版で本番トラフィックを受け付けられる
・メリット: DR環境を定期的に本番トラフィックの一部（例: 10%）に使うことができ、フェイルオーバーテストが現実的になる
・デメリット: 常時EC2を稼働させるため、Pilot Lightより月額コストが高い

4. Multi-Site Active/Active——2リージョンで本番を同時稼働

最も高コスト・最高可用性のパターン。2つのリージョン（例: 東京 + 大阪）で同時に本番トラフィックを処理し、片方のリージョンが完全に落ちても残りのリージョンでサービスを継続する。

仕組み

・AWS Global AcceleratorまたはRoute 53の加重ルーティングで両リージョンに均等にトラフィックを分散
・DBはAurora Global Database（レプリケーション遅延1秒未満）またはDynamoDB Global Tablesで双方向同期
・片方のリージョンが落ちた場合: Global Acceleratorが正常リージョンへ自動で100%ルーティングを切り替え
・RTO・RPOともに秒単位で実現できる

設計上の最難関: 書き込み競合の扱い

Active/Activeの最大の難しさは「2つのリージョンに同時に書き込みが発生したとき、データの整合性をどう保つか」だ。Aurora Global DatabaseはリージョンをまたいだACIDトランザクションをサポートしていないため、アプリケーション側での書き込みルーティング設計（プライマリリージョンに常に書き込む、または結果整合性を許容するデータモデル設計）が必要になる。このアーキテクチャ的な複雑さがコスト以上のネックになるケースも多い。

マルチリージョン設計のより詳しいアーキテクチャパターンについてはAWSマルチリージョン設計入門を参照してほしい。

コスト試算——3層Webアプリを例に比較する

以下のシステム構成を東京リージョン（ap-northeast-1）で稼働させているケースを想定した、DRパターン別の追加コスト概算だ（2026年7月時点のオンデマンド料金をベースにした試算）。

前提: 本番システム構成（東京リージョン月額 約$500）

・Web/App: m5.large × 2台（$0.124/hr × 2 × 730h ≈ $181）
・DB: RDS MySQL db.m5.large Multi-AZ（$0.34/hr × 730h ≈ $248）
・その他（ALB・S3・データ転送等）: 約$70

【注意】上記はあくまでも概算目安であり、実際のシステム規模・データ量・データ転送量によって大きく変わる。正確な見積もりはAWS Pricing Calculator実践ガイドを参考にして個別試算することを推奨する。

コスト感を一言でまとめると: Backup & Restoreから1段階上げるたびに月額コストが100～200ドル単位で増加する。RTO要件を1時間緩めるだけでコストが大幅に下がるケースもあるため、ビジネス側と要件を詰める際にコスト試算をセットで提示することが重要だ。

パターン選定の判断フロー

Step 1: RTOを確認する

・RTO 4時間以上が許容できる → Backup & Restore を検討
・RTO 1時間前後が必要 → Pilot Light を検討
・RTO 30分以内が必要 → Warm Standby を検討
・RTO 数分以内・ほぼゼロダウンタイムが必要 → Multi-Site Active/Active を検討

Step 2: RPOを確認する

・RPO 数時間まで許容 → Backup & Restore
・RPO 数分まで許容 → Pilot Light 以上
・RPO 1分以内が必要 → Warm Standby 以上
・RPO ほぼゼロが必要 → Multi-Site Active/Active

Step 3: コスト予算を確認し、ビジネス判断に落とす

Step 1・2で必要なパターンが絞れたら、そのパターンの追加コストを試算してビジネス側に提示する。RTO・RPOとコストのトレードオフは、エンジニアではなく経営層・事業責任者が決裁すべき判断だ。「このRTO要件を2時間緩めると月額100ドル削減できる」という形で選択肢を提示するのが理想的な進め方だ。

DRリージョン選びのヒント

東京（ap-northeast-1）をプライマリにしている場合、DRには大阪（ap-northeast-3）が現実的な選択肢だ。同一国内でデータ主権の問題がなく、レイテンシも低い。料金は東京とほぼ同水準（一部サービスはわずかに安い）。海外リージョンは料金が安いケースもあるが、法規制・データ主権・レイテンシのリスクをあわせて評価する必要がある。

実装で押さえておくべき3つのポイント

1. フェイルオーバーテストを定期実施する

「DR構成を作ったが一度もテストしていない」は最も危険な状態だ。Pilot LightやWarm Standbyは仕組みが複雑なため、実際に動かすと手順書が陳腐化していたり、Lambdaスクリプトがエラーを出したりすることが多い。最低でも年1回、可能なら四半期ごとにフェイルオーバーテスト（Gameday）を実施する。AWS Fault Injection Service（FIS）を活用すれば、本番を止めることなく特定のAZやリージョンへの障害シナリオを注入できる。

2. Route 53のTTLを事前に短縮しておく

フェイルオーバー時にRoute 53がDNSを切り替えても、クライアント側のDNSキャッシュが残っている間は切り替えが完了しない。TTLが3600秒（1時間）だと、フェイルオーバー後1時間は古いIPへアクセスが続く可能性がある。Route 53のTTLは平常時から60秒前後に設定しておくのが鉄則だ（通常のパフォーマンスへの影響は微小）。

3. フェイルオーバー操作を自動化する

Pilot LightとWarm Standbyではフェイルオーバー時に手動作業が残るとRTOが一気に延びる。以下をAWS Lambda + EventBridgeで自動化しておくことを推奨する。

・Route 53ヘルスチェック失敗 → EventBridgeアラーム発火 → Lambdaがリードレプリカ昇格コマンドを実行
・レプリカ昇格完了 → Auto ScalingグループのDesired Capacityを更新して本番規模に拡張
・Amazon SNSでSlack/メールへアラート通知（オペレーターへの即時連絡）

よくある設計ミスと対処法

ミス1: DR要件をエンジニアだけで決めてしまう

インフラエンジニアが「RTO 1時間にしておこう」と一人で決めてしまい、後からビジネス側が「2時間の停止でも倒産リスクがある」と発覚するケースは珍しくない。DR要件の定義はビジネスインパクト分析（BIA）として、経営層・事業責任者を巻き込んで決めるプロセスだ。エンジニアがRTO・RPOの「選択肢と費用感」を提示し、ビジネス側が「どれだけ払うか」を決める役割分担を守ること。

ミス2: コンポーネントごとにパターンをバラバラにする

コスト削減の意図で「DBはWarm Standby・WebはBackup & Restore」といったレイヤーごとに異なるパターンを混在させると、フェイルオーバー手順が複雑になり全体RTOの見通しが立ちにくくなる。コンポーネントは可能な限り同じDRパターンで統一し、全体RTOを一本のラインで管理することを推奨する。

ミス3: バックアップ成否のモニタリングを省略する

「AWS Backupを設定した」だけで満足して、バックアップ失敗の通知と定期的なリストアテストを省略するケースが多い。いざDRが必要になったとき、バックアップが3か月間失敗していたという事態はシャレにならない。AWS BackupのジョブステータスはCloudWatchメトリクスで取得でき、失敗時にアラームを上げる設定をセットで実施すること。

まとめ

AWS DR戦略4パターンを比較した。

・Backup & Restore: コスト最小（追加+$15～30/月）。RTO数時間・RPO数時間。非クリティカルなシステム向け
・Pilot Light: DBだけ常時レプリカ（追加+$120～150/月）。RTO 30分～1時間・RPO数分。コストと速度のバランス型
・Warm Standby: 縮小版本番を常時稼働（追加+$280～320/月）。RTO 5～30分・RPO1分以内。ビジネスクリティカル向け
・Multi-Site Active/Active: ゼロダウンタイムに限りなく近い（追加+$480～530/月）。ミッションクリティカル向け

「一番いいパターンを採用しよう」ではなく「ビジネスが必要とするRTO・RPOを満たす最もコスト効率の高いパターンを選ぶ」という視点が現場では重要だ。まずRTO・RPO要件をビジネス側と合意し、試算したコストをセットで提示して承認を得てから設計に進むのが正しい順序だ。

マルチクラウド環境でのDR設計に関心がある場合は、マルチクラウド災害対策設計入門もあわせて参照してほしい。