RTO / RPOからDR Architectureを選択する

1. DR戦略選択は制約問題

最初から「パイロットライトか、ウォームスタンバイか」と戦略名から考えません。シナリオからまず要件を抽出します。

災害範囲
RTO
RPO
復旧時に許容できる運用
復旧環境の平常状態
コスト
運用の複雑さ

その後、この戦略で要件を満たせるかを候補ごとに判定します。

2. 必須制約と最適化基準を分ける

コストが安くてもRTOやRPOを満たさない戦略は採用できません。まずアーキテクチャとして成立するかを判定し、その後にコストや複雑さを最適化します。

3. 4つの戦略は候補として扱う

各戦略の詳細は既習事項として、選択に必要な差だけを使います。

戦略そのものを再暗記するのではなく、シナリオの制約によってどの候補を残せるかを判断します。

4. 最初に災害範囲を見る

まず「何が失われても復旧する必要があるか」を確認します。例えばプライマリリージョン全体の喪失を災害として定義しているなら、復旧に必要なデータやリソースがプライマリリージョン内だけに存在するアーキテクチャは成立しません。

復旧資産
↓
災害範囲の外に存在するか？

戦略名以前に、復旧に必要なもの自体が災害と一緒に失われないことが必要です。

5. RTOとRPOは両方必須制約

RTOとRPOはどちらか一方だけではなく、両方を満たす必要があります。

RTO 適合 + RPO 不適合 = 候補から除外
RTO 不適合 + RPO 適合 = 候補から除外

片方だけを満たしても復旧要件を満たしたことにはなりません。

6. AWSガイダンスの代表値は候補を考える目安

AWSガイダンスには各DR戦略の代表的なRTO / RPO傾向がありますが、戦略名だけで実際の復旧目標が保証されるわけではありません。

実際の復旧時間や復旧ポイントは、データレプリケーション、プロビジョニング、スケーリング、依存関係、アプリケーション起動、トラフィック切り替え、検証などによって変わります。

最終判断では戦略名より、設計したアーキテクチャを復旧テストした結果を重視します。

7. 復旧テスト結果で候補を絞る

例えば復旧テストの結果が次のようになったとします。

ビジネス要件がRTO 30分以内、RPO 5分以内なら、バックアップと復元とパイロットライトは必須制約を満たさず除外され、ウォームスタンバイとマルチサイトが候補として残ります。ここで初めてコスト / 複雑さを比較します。

8. 候補を落とす順序

① 災害範囲
↓
② RPO
↓
③ RTO
↓
④ 復旧時に許容される運用
↓
⑤ 復旧環境の必要状態
↓
⑥ コスト / 運用の複雑さ

前半は主に「成立する / 成立しない」を決める制約です。後半は成立する候補のどれを選ぶかを決める最適化です。

9. コストが安いだけでは選べない

最安戦略でもRTO / RPOなどの必須制約を満たさなければ除外します。一方、バックアップと復元でも実測RTO / RPOが要件を満たし、コスト最小化が求められるなら正当な候補になります。

必須制約を満たす
↓
候補として成立
↓
コスト / 複雑さを比較

10. 複数候補が成立したら過剰設計を避ける

ウォームスタンバイとマルチサイト アクティブ/アクティブの両方が復旧目標を満たしていても、平常時から複数リージョンで本番トラフィックを処理する要件がなく、コスト / 複雑さを抑えたいなら、より単純な候補を優先して評価できます。

要件を満たす + 不要なコスト / 複雑さを増やさないことが最終選択の基本です。

11. 「最安」を先に選ぶのも間違い

コスト
↓
戦略決定
↓
RTO / RPO確認

これは誤り

正しい順序は、必須制約で候補を確定したあとにコストを最適化することです。コスト最適化は復旧要件を壊してよいという意味ではありません。

12. 復旧時の操作制約も候補を変える

複数戦略が同じRTO / RPOを達成できるとしても、「災害後に大量のプロビジョニングを許容しない」といった要件があれば、復旧時に多くの制御プレーン運用を必要とするアーキテクチャは不利になります。

逆に復旧時の自動プロビジョニングを許容し、稼働コストを抑えたいなら、その運用を受け入れることで平常時コストを下げられる場合があります。復旧運用もアーキテクチャ選択の制約です。

13. 要件を満たす候補がない場合

4つの戦略の中から「一番近いもの」を無理に選びません。例えばウォームスタンバイはRTOを満たさず、マルチサイトはRPOを満たさないなら、どちらも候補ではありません。

候補 = 0
↓
データ保護 / 復旧アーキテクチャを再設計
↓
再度復旧テスト

必須制約を満たさないアーキテクチャを近似値で採用しないことが重要です。

14. ワークロードごとに戦略を分けられる

組織全体で1つのDR戦略へ統一する必要はありません。決済と内部レポートのビジネス影響が異なれば、復旧目標も異なります。

ワークロード
↓
ビジネスへの影響
↓
復旧要件
↓
DR戦略

最も厳しいワークロードに全システムを合わせると、他ワークロードが過剰設計になる可能性があります。

15. アーキテクチャ選択マトリクス

最終判断では候補ごとに同じ要件を並べて評価します。

戦略名から答えを出すのではなく、各列を要件で評価して候補を消していくのが基本です。

16. 障害モード

コストから先に決める

最安でもRTO / RPO未達ならアーキテクチャとして成立しません。

RTOだけで決める

RTOに適合してもRPOが不適合なら候補から除外します。

AWSガイダンスの代表値を保証値として使う

実際のアーキテクチャと復旧テスト結果で確認します。

最も強い戦略を無条件に選ぶ

要件以上のコスト / 複雑さを追加する可能性があります。

候補がないのに最も近いものを選ぶ

アーキテクチャまたはデータ保護戦略を再設計します。

全ワークロードへ同じ戦略を適用する

ビジネス影響が異なるなら復旧要件も分離します。

17. SAP-C02判断フロー

シナリオ
  │
  ▼
災害範囲
  │
  ▼
RPO
  │
  ▼
RTO
  │
  ▼
復旧運用 /
平常時の復旧環境
  │
  ▼
必須制約を満たす候補だけ残す
  │
  ├─ 0個 → アーキテクチャ再設計
  ├─ 1個 → 候補確定
  └─ 複数 → コスト / 運用の複雑さで最適化

18. まとめ

DRアーキテクチャ選択は戦略名から始めません。

復旧要件
↓
必須制約
↓
候補の除外
↓
コスト / 複雑さの最適化
↓
アーキテクチャ選択

特にRTO、RPO、災害範囲などを満たすことが候補成立の前提です。AWSガイダンスの代表値は候補を考える材料として使い、最終判断は実際のアーキテクチャと復旧テスト結果で確認します。

要件を満たす候補の中から、不要なコストと運用の複雑さを増やさないアーキテクチャを選択します。

19. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) 試験ガイド — ドメイン 1 / タスク 1.3
• AWS Well-Architected 信頼性 柱 — 災害復旧の計画 (DR)
• AWS Well-Architected — 定義済みの復旧戦略を使用して復旧目標を満たす
• AWS上のワークロードの災害復旧 — ビジネス継続性計画
• AWS上のワークロードの災害復旧 — クラウドでの災害復旧オプション