Instiq
第2章 · 新しいソリューションの設計·v2.1.0·更新 2026/7/16·読了目安 約11分

変更要約: 軸B網羅: 構築ブロック(コンピュート/DB/ストレージ/ネットワーク=s4、分析/ML/IoT/メディア/統合=s5)のカタログ節を追加

2.1高可用性とディザスタリカバリ

この節の要点

可用性と回復力を高める設計——マルチ AZマルチリージョンRTO/RPO、4 つの DR 戦略(バックアップ&リストアパイロットライトウォームスタンバイマルチサイト)、Route 53 フェイルオーバー——を理解します。

可用性は AZ 冗長から始まり、災害対策は RTO/RPO の要件に応じて 4 つの戦略から選びます。コストと復旧速度はトレードオフです。

2.1.1DR 戦略の選択

4 つのディザスタリカバリ戦略を、コストと復旧速度(RTO/RPO)のトレードオフで並べた図。左から、バックアップ&リストア(最も安価・RTO/RPO は数時間)、パイロットライト(中核のみ最小起動・データは複製・RTO は数十分)、ウォームスタンバイ(縮小版を常時稼働・RTO は数分)、マルチサイト/アクティブ-アクティブ(フル稼働を複数リージョンで・RTO/RPO はほぼゼロ・最も高価)を示し、Route 53 のヘルスチェックとフェイルオーバールーティングで切り替える様子を添えた図。
4 つの DR 戦略と RTO/RPO
  • RTO/RPORTO=復旧までの許容時間RPO=失ってよいデータ量(時間)。要件が戦略を決める。
  • バックアップ&リストア:最も安価。RTO/RPO は時間単位。
  • パイロットライト:中核(DB 複製等)のみ最小起動。災害時に拡張。RTO は数十分。
  • ウォームスタンバイ:縮小版を常時稼働。すぐ拡張可能。RTO は数分。
  • マルチサイト(アクティブ-アクティブ):複数リージョンでフル稼働。RTO/RPO ほぼゼロ・最も高価。
試験ポイント

「最安・復旧遅い=バックアップ&リストア」「中核のみ起動=パイロットライト」「縮小版が常時稼働=ウォームスタンバイ」「複数リージョンでフル稼働=マルチサイト」、そして RTO=時間/RPO=データ量 の対応は SAP-C02 で最頻出です。要件の RTO/RPO が短いほど上位(高コスト)の戦略を選びます。

補足

Route 53 のヘルスチェック+フェイルオーバールーティングで、プライマリ障害時にスタンバイへ自動切替できます。データ層は RDS のクロスリージョンリードレプリカや DynamoDB グローバルテーブルで複製します。

可用性はまず1リージョン内で マルチ AZELB+複数 AZ の Auto Scaling、RDS マルチ AZ、データは 3 AZ 冗長の S3/DynamoDB)で確保し、リージョン障害には マルチリージョン DR を要件で選びます。RTO=復旧までの許容時間、RPO=失ってよいデータ量(時間)。4 戦略はコスト/速度のトレードオフで、バックアップ&リストアAWS Backup・スナップショットのクロスリージョンコピー・RTO/RPO 数時間)<パイロットライト(DB は クロスリージョンリードレプリカ 等で常時複製、アプリは停止/最小・災害時に起動・数十分)<ウォームスタンバイ(縮小フルスタックが常時稼働・即スケール・数分)<マルチサイト/アクティブ-アクティブ(複数リージョンで本番処理・DynamoDB グローバルテーブル・ほぼ 0)。切替は Route 53 ヘルスチェック+フェイルオーバー/レイテンシ/加重ルーティング、配信は CloudFront、IaC(CloudFormation/StackSets)で複製環境を再現します。RPO≈0 が要るならアクティブ-アクティブや同期複製、コスト優先なら下位戦略、と RTO/RPO の数値から逆算します。

戦略スタンバイRTO/RPOコスト
バックアップ&リストアなし(バックアップのみ)数時間最安
パイロットライト中核(DB)のみ数十分
ウォームスタンバイ縮小フルスタック常時数分
マルチサイトフル稼働×複数リージョンほぼ 0最高
補足

シナリオ: RPO 1 分・RTO 5 分が必須の決済系を、コストは抑えつつ満たしたい。→ ウォームスタンバイを選び、別リージョンに縮小版フルスタックを常時稼働。DB はクロスリージョンレプリカ(またはグローバルテーブル)で継続複製、災害時に Auto Scaling で本番容量へ拡張、Route 53 フェイルオーバーで切替えます。さらに厳しい RPO≈0 ならアクティブ-アクティブに上げます。

補足

FAQ: Q. RTO と RPO の違いは? → A. RTO は「どれだけ早く復旧するか(時間)」、RPO は「どれだけのデータ損失を許せるか(時間幅)」。Q. パイロットライトとウォームスタンバイの差は? → A. パイロットライトは中核(主に DB)だけ常時・アプリは災害時起動、ウォームスタンバイは縮小版フルスタックが常時稼働で即拡張できます。

注意

ひっかけ: 「コスト最優先なのにマルチサイト(アクティブ-アクティブ)を選ぶ」は誤りです。最安はバックアップ&リストア(RTO/RPO は数時間)。逆に「RPO≈0 をバックアップ&リストアで満たす」も誤り(ほぼ 0 には同期複製/アクティブ-アクティブが必要)。RTO/RPO の数値から戦略を逆算します。

2.1.2この節のまとめ

  • DR=バックアップ&リストア<パイロットライト<ウォームスタンバイ<マルチサイト(コスト/速度)
  • RTO=復旧時間/RPO=データ損失・切替=Route 53 フェイルオーバー

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. RPO が「ほぼゼロ」、RTO も「数分以内」という極めて厳しい要件のミッションクリティカルなシステムに適した DR 戦略はどれですか?

Q2. コストを最優先し、RTO/RPO が数時間でも許容される DR 戦略はどれですか?

Q3. プライマリリージョン障害時に、ユーザートラフィックを自動的にスタンバイリージョンへ振り向けたい。何を使いますか?

理解度を確認第2章「新しいソリューションの設計」の問題を解く