目次

AWS災害復旧プレイブック

周辺資料: 学習インデックス · AWSサービス一覧（2026） · Well-Architectedチェックリスト · アーキテクチャパターン集

DR 戦略の選定・設計・テスト・フェイルオーバー実行まで、AWS 災害復旧の実践プレイブック。

1. DR 戦略の選定

RTO / RPO の定義

RTO（Recovery Time Objective）: 障害発生から業務再開まで許容できる時間
RPO（Recovery Point Objective）: 障害発生時点から遡って許容できるデータ損失時間

例:
  RTO = 4時間 → 障害から4時間以内にサービスを再開する必要がある
  RPO = 1時間 → 最大1時間分のデータ損失は許容できる

ビジネス要件との対応:
  EC サイトの注文機能 → RTO: 30分 / RPO: 0（データ損失不可）
  社内管理ツール     → RTO: 4時間 / RPO: 24時間
  分析レポート基盤   → RTO: 24時間 / RPO: 24時間

4つの DR 戦略比較

戦略 RTO RPO コスト 複雑度 適用例
Backup & Restore 数時間〜1日 数時間〜1日 最低 低 社内ツール・非重要データ
Pilot Light 10〜30分 数分〜1時間 低 中 バックオフィス・中規模サービス
Warm Standby 数分〜10分 秒〜数分 中〜高 中 主要業務システム
Active-Active 秒以下 秒以下 最高 高 決済・重要 API

戦略選定フロー

RTO の要件は？
        │
        ├── RTO > 4時間 → Backup & Restore
        │     • AWS Backup で定期バックアップ
        │     • S3 Cross-Region Replication でデータ複製
        │
        ├── RTO = 1〜4時間 → Pilot Light
        │     • DB のみ別リージョンにレプリカ維持
        │     • アプリは停止中（フェイルオーバー時にスケールアップ）
        │
        ├── RTO = 数分 → Warm Standby
        │     • 本番の 1/3〜1/5 規模で別リージョンに常時稼働
        │     • フェイルオーバー時にフルスケールに拡張
        │
        └── RTO < 1分 → Active-Active
              • 複数リージョンで同時にトラフィックを処理
              • DynamoDB Global Tables / Aurora Global Database

2. 戦略別の設計パターン

Backup & Restore（バックアップ・リストア）

[構成]
  ap-northeast-1（Primary）
    RDS Aurora → スナップショット
    EC2 → AMI
    S3 → CRR（Cross-Region Replication）
         ↓ 自動コピー
  ap-southeast-1（DR）
    RDS スナップショット → リストア時に起動
    EC2 AMI → フェイルオーバー時に起動

[AWS Backup の設定]
  バックアップ計画:
    Daily: 保持 35日
    Weekly: 保持 3ヶ月
    Monthly: 保持 1年
  クロスリージョンコピー: ap-northeast-1 → ap-southeast-1

[フェイルオーバー手順（手動）]
  1. DR リージョンで RDS スナップショットをリストア（30〜60分）
  2. EC2 AMI から新インスタンスを起動（5〜10分）
  3. アプリの設定を DR 環境の DB エンドポイントに変更
  4. Route 53 ヘルスチェックフェイルオーバー or DNS 変更

[コスト概算]
  追加コスト: スナップショット保管費 + S3 CRR 転送費
  例: 100GB DB スナップショット × 35日 ≒ $3.5/月

Pilot Light（パイロットライト）

[構成]
  ap-northeast-1（Primary）
    Route 53 → ALB → ECS Fargate（本番規模）
                    └── Aurora Primary（書き込み）
                              ↓ Global Database レプリカ
  ap-northeast-3（DR）
    Aurora Secondary（読み取り専用・常時同期）
    ← フェイルオーバー時に起動
    Route 53 → ALB → ECS Fargate（停止中 → フェイルオーバー時にスケールアップ）

[フェイルオーバー手順]
  1. Aurora Global Database のフェイルオーバー（1〜2分）
     → Secondary が Primary に昇格
  2. DR リージョンの ECS サービスを最小 → 本番規模にスケール（3〜5分）
  3. Route 53 ヘルスチェックが Primary を Unhealthy と判定
     → DR リージョンに自動切替（Route 53 フェイルオーバールーティング）
  4. 合計 RTO: 10〜15分

[常時稼働するリソース]
  Aurora Secondary（継続的レプリカ）
  ECS サービス（タスク数 = 0 でクラスターのみ）
  ALB（料金発生 ~$16/月）
  
[コスト概算]
  Aurora Global Database: $0.20/時間（書き込みI/O転送費）
  ALB: ~$16/月
  本番の 5〜10% の追加コスト

Warm Standby（ウォームスタンバイ）

[構成]
  ap-northeast-1（Primary）                ap-northeast-3（DR）
    Route 53 ──────────────────────────── Route 53
    ALB ← 100% トラフィック              ALB ← 0% トラフィック（待機）
    ECS: 10タスク                         ECS: 3タスク（本番の30%で稼働）
    Aurora Primary ── Global DB ──────→  Aurora Secondary
    DynamoDB ────── Global Tables ──── DynamoDB
    S3 ─────────── CRR ─────────────→ S3

[フェイルオーバー手順（自動化推奨）]
  Step 1: Route 53 ヘルスチェックが Primary を Unhealthy 検知（1〜2分）
  Step 2: DNS フェイルオーバー → DR リージョンへ全トラフィック移行（1分）
  Step 3: DR の ECS Auto Scaling が本番規模に拡張（2〜5分）
  Step 4: Aurora フェイルオーバー（1〜2分）
  合計 RTO: 5〜10分

[EventBridge + Lambda で自動フェイルオーバーを実装]
  Route 53 ヘルスチェック Unhealthy → SNS → Lambda
    → Aurora: promote-read-replica-db-cluster
    → ECS: update-service でタスク数を最大に
    → Route 53 ウェイト: Primary=0, DR=100 に変更

Active-Active（アクティブ-アクティブ）

[構成]
  Global Accelerator（エニーキャストIP）
      ├── ap-northeast-1（Tokyo） ← Asia トラフィック
      │     ALB → ECS Fargate
      │         DynamoDB Global Tables（書き込み可）
      │
      └── us-east-1（Virginia） ← Americas トラフィック
            ALB → ECS Fargate
                DynamoDB Global Tables（書き込み可）

  Aurora Global Database:
    Tokyo: Primary（書き込み）
    Virginia: Secondary（読み取りのみ）
    → Aurora は書き込みを Primary にルーティング

[整合性の注意点]
  DynamoDB Global Tables:
    最終的整合性（数秒〜数十秒の遅延）
    同じキーを複数リージョンから同時書き込み → 最後の書き込みが勝つ
    → ユーザーIDごとにホームリージョンを固定する設計が安全

  Aurora Global Database:
    書き込みは Primary リージョンのみ（最大1秒のレプリカラグ）
    読み取りはどのリージョンからも OK

[障害時の動作]
  Tokyo で障害 → Global Accelerator が Virginia に全トラフィック自動転送
  Aurora: Tokyo の Primary が停止 → Virginia を Primary に昇格（手動 or 自動）

3. コンポーネント別 DR 設計

データベースの DR

[Aurora / RDS]
  Multi-AZ（同一リージョン内）:
    フェイルオーバー: 30〜60秒（自動）
    RPO: 0（同期レプリケーション）

  Aurora Global Database（クロスリージョン）:
    セカンダリへの昇格: < 1分
    レプリケーションラグ: 通常 < 1秒
    RTO: 1〜3分 / RPO: 秒以下

  RDS Read Replica（クロスリージョン）:
    昇格: 数分（手動操作が必要）
    レプリケーションラグ: 1〜60秒（非同期）
    RTO: 5〜15分 / RPO: 秒〜分

[DynamoDB]
  Global Tables:
    全リージョンで読み書き可能（マルチマスター）
    レプリケーション: 通常 < 1秒
    単一リージョン障害でも自動継続

[ElastiCache]
  Global Datastore（Redis）:
    クロスリージョンのパッシブレプリカ
    フェイルオーバー時にプライマリに昇格
    RPO: 秒〜分

  Global Tables がない Memcached:
    DR 時にキャッシュウォームアップが必要
    → キャッシュなしでも動作するコードになっていることが前提

ストレージの DR

[S3]
  CRR（Cross-Region Replication）:
    新しいオブジェクトをリアルタイムに別リージョンにコピー
    設定: S3 バケット → 管理 → レプリケーションルール
    S3 Replication Time Control（RTC）で 99.99% を15分以内に保証

  S3 Object Lock:
    WORM（Write Once, Read Many）で削除・改ざんを防止
    Governance Mode: 特定権限があれば削除可
    Compliance Mode: 誰も削除不可（コンプライアンス対応）

[EBS]
  自動スナップショット（Data Lifecycle Manager）:
    スナップショット間隔: 1〜24時間
    クロスリージョンコピーポリシーを設定
  
  EBS Multi-Attach（同一AZ内）:
    複数EC2から同一EBSをマウント（io1/io2 のみ）
    HA クラスター構成に使用

[EFS]
  EFS Replication:
    別リージョンに自動レプリカを作成
    RPO: < 1時間
    DR 時にレプリカを本番昇格（読み取り専用 → 書き込み可に変更）

4. Route 53 フェイルオーバー設計

ヘルスチェックの設定

[ヘルスチェックの種類]
  エンドポイント監視:
    HTTP/HTTPS/TCP でアプリの /health を定期確認
    間隔: 10秒（高速）or 30秒（通常）
    失敗しきい値: 3回連続失敗でアラーム

  CloudWatch アラームへの連携:
    複合ヘルスチェック（複数エンドポイントのAND/OR）
    CloudWatch アラームと連動（DB障害も含めて総合判定）

[推奨設定]
  Protocol: HTTPS（TLS 検証あり）
  Path: /health（アプリ + DB の疎通を返す深いヘルスチェック）
  Interval: 10秒（高速フェイルオーバーのため）
  FailureThreshold: 3（30秒で判断 = 10s × 3）
  Latency Graphs: 有効化

フェイルオーバールーティングポリシー

[設定例: Active-Passive フェイルオーバー]

  プライマリレコード（ap-northeast-1）:
    タイプ: A（Alias → ALB）
    ルーティング: Failover（Primary）
    ヘルスチェック: 有効
    TTL: 60秒

  セカンダリレコード（ap-northeast-3）:
    タイプ: A（Alias → ALB）
    ルーティング: Failover（Secondary）
    ヘルスチェック: 有効（または無効）
    TTL: 60秒

[Global Accelerator を使う場合]
  利点:
    DNS ではなく BGP レベルでの経路制御（DNS TTL の影響なし）
    フェイルオーバー: 30秒以内（DNS フェイルオーバーより高速）
    エニーキャスト IP（静的 IP アドレスが変わらない）
  
  向いている用途:
    TCP/UDP 低レイテンシが必要（ゲーム / IoT）
    DNS キャッシュの影響を受けたくない
    静的 IP が必要（許可リスト登録が必要な場合）

5. DR 訓練（ゲームデイ）

DR テスト計画テンプレート

[DR テストの目的]
  1. 実際の RTO / RPO を計測し、目標値と比較
  2. フェイルオーバー手順の問題点を洗い出す
  3. チームの対応スキルを訓練
  4. コンプライアンス要件を満たす証跡を作成

[テストシナリオの種類]
  シナリオ1: アプリ層障害
    手順: プライマリリージョンの ECS タスクを強制停止
    確認: DR リージョンへ自動フェイルオーバーするか

  シナリオ2: DB 障害
    手順: Aurora Primary を強制フェイルオーバー（Manual Failover）
    確認: Read Replica が Primary に昇格し、アプリが再接続するか

  シナリオ3: リージョン全体障害（最重要テスト）
    手順: プライマリリージョンの全サービスを停止（手動）
    確認: DR リージョンで業務継続できるか / RTO/RPO を達成できるか

  シナリオ4: データ破損（ランサムウェア想定）
    手順: テスト DB に意図的に誤データを書き込む
    確認: AWS Backup のスナップショットから正確に復元できるか

DR 訓練実施手順

[事前準備（1週間前）]
  □ テスト環境の確認（本番相当データが DR 環境にあるか）
  □ 参加者への通知と役割分担の確認
  □ メンテナンスウィンドウの設定（ユーザーへの告知）
  □ 監視ダッシュボードの準備
  □ 記録テンプレートの準備

[テスト実施]
  T-0: テスト開始宣言・記録開始
  T+N: 各手順の実施時刻を記録
  実測 RTO / RPO を計測

  確認項目:
    □ サービスが DR リージョンで正常動作しているか
    □ データ整合性は保たれているか
    □ 監視アラームが DR 環境で正常に動作しているか
    □ 顧客向けのURLやエンドポイントが変わっていないか

[テスト後の復旧（フェイルバック）]
  1. プライマリリージョンを復旧（または元のサービスを再起動）
  2. DR から Primary へのデータ同期を確認
  3. Route 53 / Global Accelerator をプライマリに戻す
  4. DR リージョンを待機状態に戻す

[テスト記録テンプレート]
  訓練日: YYYY-MM-DD
  参加者: N名
  テストシナリオ: リージョン全体障害
  
  | ステップ | 計画時刻 | 実績時刻 | 担当 | 結果 |
  |---|---|---|---|---|
  | フェイルオーバー開始 | T+0 | T+0:02 | Ops | ○ |
  | Aurora 昇格完了 | T+3 | T+3:45 | Ops | ○ |
  | ECS スケールアップ完了 | T+5 | T+6:10 | Infra | ○ |
  | 疎通確認完了 | T+8 | T+9:30 | Dev | ○ |
  
  実測 RTO: 9分30秒（目標: 10分 → 達成）
  実測 RPO: 45秒（目標: 1分 → 達成）
  
  課題:
    Aurora 昇格が想定より45秒遅かった
    → レプリカラグの監視アラームを設定する（次回対応）

6. Elastic Disaster Recovery（CloudEndure DRS の後継）

[特徴]
  継続的なブロックレベルのレプリケーション
  DR サーバーをクラウドに常時複製し、数分でフェイルオーバー

[使い方]
  1. ソースサーバーにエージェントをインストール
  2. Elastic DR がブロックレベルのデータをリアルタイムに AWS に複製
  3. テストフェイルオーバー（本番に影響なし）
  4. 本番フェイルオーバー（ソース障害時）:
     → 最新のレプリカから EC2 インスタンスを起動
     → 数分で RTO 達成

[MGN との違い]
  MGN: オンプレ → AWS への一方向の移行ツール
  Elastic DR: 継続的な DR（移行後もオンプレと同期し続ける）

7. DR チェックリスト

[設計フェーズ]
□ RTO / RPO の目標値をビジネスオーナーと合意した
□ DR 戦略（Backup / Pilot Light / Warm Standby / Active-Active）を選定した
□ DR リージョンを選定した（主要リージョンとは別の地域）
□ DR 構成を IaC（CDK/Terraform）で管理している
□ フェイルオーバーの自動化 vs 手動承認を決定した

[実装フェーズ]
□ Aurora Global Database / DynamoDB Global Tables を設定した
□ S3 CRR でデータを DR リージョンに複製している
□ Route 53 ヘルスチェック + フェイルオーバールーティングを設定した
□ DR リージョンのセキュリティ設定（IAM / SG）がプライマリと同等である
□ 監視・アラームが DR 環境にも設定されている

[運用フェーズ]
□ DR テストを年2回以上実施している（記録あり）
□ テスト結果に基づく改善を次回テスト前に完了している
□ フェイルオーバー手順書が最新状態に維持されている
□ DR 対応可能な担当者が複数名いる（単一担当者依存でない）
□ RTO/RPO の目標値をコンプライアンス要件と照合している