AWS はディザスタリカバリ (DR) 戦略として 4 つのパターン を定義しています。 RTO（目標復旧時間）と RPO（目標復旧時点）の要件、コスト制約から最適なパターンを選びます。本記事では DR 4 パターンを SAA / SAP 両面から整理します。

SAA レベル：基礎概念

DR の 4 パターン概観

AWS は DR 戦略を以下の 4 パターンに分類します。

パターン	RTO	RPO	コスト	特徴
1. バックアップ & 復元	時間単位	時間単位	最低	バックアップから新規構築
2. パイロットライト	分〜十分	分	低	リードレプリカだけ常時稼働
3. ウォームスタンバイ	分	秒	中	小規模版を常時稼働
4. マルチサイト (アクティブ・アクティブ)	リアルタイム	ほぼ 0	最高	両サイト常時稼働

SAA レベル：基礎概念

DR 4 パターンの核心は 「RTO/RPO が短いほどコストが高い」 というトレードオフです。

バックアップ & 復元: コスト最低、復旧に時間がかかる
マルチサイト: リアルタイム切替、コスト最高要件と予算のバランスで最適なパターンを選ぶのが SAA の基本判断です。

RTO と RPO の定義

指標	定義	意味
RTO (Recovery Time Objective)	目標復旧時間	障害から復旧までの許容時間
RPO (Recovery Point Objective)	目標復旧時点	復旧時に失っても良いデータの期間

SAA 試験のポイント

RTO = 「どれだけ早く復旧できるか」
RPO = 「どれだけ最近のデータまで復旧できるか」この 2 つが DR 戦略の核心指標です。SAA では定義と意味を問う問題が頻出します。

パターン 1: バックアップ & 復元

最もシンプルで低コストな DR パターンです。

仕組み: 定期バックアップを取得し、障害時に別リージョンで復元
RTO: 時間単位（バックアップからの復元時間）
RPO: 時間単位（最後のバックアップ以降のデータはロス）
コスト: バックアップ保管料金のみ

[プライマリリージョン] ──定期バックアップ── [別リージョン S3]
                                        (Glacier 等で低コスト保管)

# 障害時
[別リージョン] でバックアップから RDS / EBS / EC2 を復元 → サービス再開

SAA 頻出

バックアップ & 復元は RTO/RPO が長いがコスト最低 です。「コスト重視、数時間の停止許容」なシナリオで選択されるパターン。 SAA では「最も低コストな DR」= バックアップ & 復元、が定番の正解です。

パターン 2: パイロットライト

DR 側にデータベースのレプリカだけ常時稼働 させるパターンです。

仕組み: DB のリードレプリカを別リージョンで常時稼働、障害時に昇格 + アプリ構築
RTO: 分〜十分（DB 昇格 + アプリ起動）
RPO: 分（レプリケーション遅延分）
コスト: リードレプリカ料金のみ（アプリは停止）

[プライマリリージョン]
  EC2 + RDS Primary
        │ (非同期レプリケーション)
        ▼
[DR リージョン]
  RDS Read Replica (常時稼働)   ← パイロットライト
  EC2 (停止、AMI だけ用意)      ← 障害時に起動

パイロットライトの特徴

「DB のレプリカだけ常時稼働、アプリは停止」 がパイロットライトの核心です。 DB 同期だけ常に走っているため RPO は分単位。障害時にアプリを起動する時間が RTO。 SAA では「コストと RTO/RPO の中間」として位置づけます。

パターン 3: ウォームスタンバイ

DR 側に小規模版の環境を常時稼働 させるパターンです。

仕組み: プライマリより小さい規模のスタンバイ環境を常時稼働
RTO: 分（スケールアップ + トラフィック切替）
RPO: 秒（レプリケーション遅延分）
コスト: 小規模環境の常時稼働分

SAA 頻出

ウォームスタンバイは「小規模版を常時稼働」 が核心です。障害時にスケールアップして本番規模に引き上げる。「パイロットライトよりは常時動いている分速い、マルチサイトよりは安い」が SAA の位置づけです。

パターン 4: マルチサイト (アクティブ・アクティブ)

両リージョンを常時稼働し、トラフィックを負荷分散 するパターンです。

仕組み: 両サイトで常時トラフィック処理、片側障害で他側が全トラフィック
RTO: リアルタイム（DNS 切替のみ）
RPO: ほぼ 0（双方向レプリケーション or 最終的整合性）
コスト: 両サイトの完全稼働 + リージョン間データ転送

[ユーザー] ── Route 53 (加重ルーティング 50/50)
              │                      │
              ▼                      ▼
     [プライマリリージョン]    [DR リージョン]
       50% トラフィック          50% トラフィック
       完全稼働                  完全稼働

SAP レベル：高度な設計シナリオ

パターン選択の判断基準

SAP では ビジネス要件とコストから DR パターンを選択 します。

SAP レベル：高度な設計シナリオ

SAP の DR パターン選択は 「ビジネスインパクト × コスト許容度」 で判断します。

課金システム: 停止 = 収益ロス → マルチサイト
社内向け FAQ: 数時間停止 OK → バックアップ & 復元
部門別アプリ: 数十分停止許容 → ウォームスタンバイこの層別判断が SAP の核心です。

要件	推奨パターン	理由
RTO リアルタイム、コスト不問	マルチサイト	最高可用性
RTO 分単位、DB 同期重視	パイロットライト	DB だけ常時稼働で中コスト
RTO 分単位、アプリ常時も必要	ウォームスタンバイ	小規模アプリ常時稼働
RTO 数時間 OK、コスト最低	バックアップ & 復元	最も低コスト

Aurora Global Database によるパターン実装

Aurora Global DB は マルチリージョン DR の強力な実装手段 です。

レプリケーション: 通常 1 秒未満で別リージョンに複製
フェイルオーバー: 管理コンソール / API で数十分以内に昇格
RPO: 秒単位
適合パターン: パイロットライト / ウォームスタンバイ

Aurora Global DB の利点

Aurora Global DB は 管理コンソール 1 クリックで昇格 できます。通常 1 秒未満のレプリケーション遅延のため、RPO は秒単位。 SAP では「Aurora ベースのパイロットライト/ウォームスタンバイ」が DR 定石です。

DynamoDB Global Tables によるマルチサイト

DynamoDB は Global Tables でマルチサイト (アクティブ・アクティブ) を実現します。

複数リージョンで読み書き: 全リージョンで Read/Write 可能
最終的整合性: リージョン間は非同期複製（数秒）
アプリ層もマルチリージョン: 各リージョンのアプリがローカル DB にアクセス

マルチサイト時の競合解決

DynamoDB Global Tables は最終的整合性 で、同時更新の競合は「最後の書き込み勝ち」。これを許容できるかがマルチサイト採用の前提。SAP では「競合許容性」の確認が論点です。

AWS Elastic Disaster Recovery (DRS)

AWS DRS は EC2 / オンプレミスサーバーを別リージョンに継続レプリケートするサービスです。

ブロックレベルレプリケート: ディスク全体を継続複製
RPO: 数秒〜分
RTO: 数分（復旧インスタンス起動）
適合: パイロットライト相当、低コスト実現

DRS の活用場面

DRS は「既存の EC2 / オンプレを別リージョンに低成本で DR」したい場面で強力です。従来の CloudEndure を統合したサービスで、設定がシンプル。 SAP では「EC2 ベースアプリの低成本 DR」として DRS が頻出します。

Route 53 による DR フェイルオーバー

DR パターン共通で Route 53 のフェイルオーバールーティング が使われます。

ルーティングポリシー	用途	設計論点
フェイルオーバー	プライマリ→セカンダリ切替	ヘルスチェック必須
加重ルーティング	マルチサイトの負荷分散	重みで段階切替も可能
レイテンシルーティング	最小レイテンシへ誘導	マルチサイトの性能最適化

Route 53 ヘルスチェックの設計

DR 切替の鍵は Route 53 ヘルスチェックの閾値設計 です。「1 回失敗で切替」は誤検知リスクが高く、「10 回失敗で切替」は RTO が延びる。 SAP では「連続 N 回失敗」のチューニングが運用論点です。

バックアップ & 復元の最適化

最も低コストなパターンでも、設計次第で RTO/RPO を改善できます。

手法	効果	実装
バックアップ頻度増	RPO 短縮	AWS Backup で頻度設定
クロスリージョンコピー	DR リージョンに自動複製	AWS Backup のクロスリージョン
事前復元テスト	RTO 短縮	定期 DR 訓練で手順最適化
IaC による迅速構築	RTO 短縮	CloudFormation / Terraform

バックアップ & 復元の落とし穴

「バックアップは取っているが復元テストをしていない」 が最も危険です。いざという時に「復元に想定以上の時間がかかる」「手順に不備」が発覚します。 SAP では定期 DR 訓練（最低半年に 1 回）がコンプライアンス要件化されることも多いです。

コスト比較と層別設計

4 パターンの概算コスト比較（プライマリ環境 = 1.0 とした場合）：

パターン	DR 側コスト	総コスト	RTO	RPO
バックアップ & 復元	0.05〜0.1	1.05〜1.1	時間	時間
パイロットライト	0.2〜0.3	1.2〜1.3	分〜十分	分
ウォームスタンバイ	0.5〜0.7	1.5〜1.7	分	秒
マルチサイト	1.0	2.0+	リアルタイム	ほぼ 0