AWS DR 設計 完全攻略 — SAA-C03 で問われる RTO/RPO と 4 つの復旧戦略

AWS SAA-C03 回復性設計 完全攻略（2026-06-02 公開）では、平常運転の備え——冗長化と疎結合——を扱いました。しかし、リージョン全体に影響する大規模障害や、人為的ミスによるデータ破壊といった「平常運転の備えが破られる瞬間」は必ず想定しなければなりません。その最後の砦が災害復旧（DR: Disaster Recovery）です。

AWS DR 設計の核心は、コストと復旧速度のトレードオフをどう取るかにあります。速く復旧できる構成ほど高くつき、安い構成ほど復旧に時間がかかる。この天秤を、ビジネス要件から逆算して適切な位置で止める。それが Domain 2 後編で問われる設計判断です。本記事では、4 つの DR 戦略を RTO/RPO 要件から選び分ける思考を整理します。

なぜ DR が SAA-C03 で頻出なのか

DR は Domain 2「Design Resilient Architectures」の中でも特に出題されやすいテーマです。理由は明快で、DR の設計判断には「正解がひとつに定まる構造」があるからです。問題文で復旧目標（どれくらいの時間で・どれくらいのデータ損失まで許容するか）とコスト制約が提示され、その条件に最も合う戦略を選ばせる。出題者にとって作りやすく、受験者の理解度を測りやすい、理想的な設問形式なのです。

だからこそ、AWS DR 設計を「なんとなく」で覚えるのは危険です。4 つの戦略それぞれの RTO/RPO レンジとコスト感を、明確な順序として頭に入れておく必要があります。逆に言えば、この順序さえ体に入れば、DR の問題は得点源に変わります。

RTO と RPO の定義と違い — 復旧目標を数値化する

すべての出発点は、2 つの指標を正しく区別することです。

RTO は「時間」の話、RPO は「データ」の話です。たとえば RTO 1 時間・RPO 5 分という要件なら、「1 時間以内にシステムを復旧させ、失うデータは直近 5 分ぶんまで」という意味になります。

この 2 つは独立して設定されます。RTO は短くてよいが RPO は長くて構わない、あるいはその逆、という組み合わせもありえます。たとえば分析用のデータ基盤なら、多少のダウンタイム（長い RTO）は許せても、貴重なデータの損失（長い RPO）は避けたい、という要件が成り立ちます。設問では、この RTO と RPO の値が戦略選択の決定打になります。値が厳しい（小さい）ほど高コストな戦略が必要になる、という相関を押さえてください。

ここで強調したいのは、RTO と RPO は技術的に決まる値ではなく、ビジネスが決める値だという点です。「どれくらい止まると、いくら損失が出るのか」「どれだけのデータを失うと、業務が成り立たなくなるのか」——この問いに答えるのは経営判断であり、ソリューションアーキテクトの仕事はその答えを技術構成に翻訳することです。試験でも、問題文に登場する業種やシステムの性質（基幹系か、社内ツールか、決済か）が、暗黙のうちに許容される RTO/RPO の水準を示唆しています。文中の「ミッションクリティカル」「即時」「許容できない」といった語は短い RTO/RPO を、「夜間バッチ」「翌営業日まで」といった語は長い RTO/RPO を示すシグナルです。こうした語彙の読み取りが、戦略選択の最初の手がかりになります。

DR 戦略① バックアップ＆リストア — 最安・最も遅い

ここから 4 つの戦略を、コストの安い順（＝復旧の遅い順）に見ていきます。AWS の災害復旧ホワイトペーパーが定義する 4 段階です。

最初がバックアップ＆リストアです。データを定期的にバックアップしておき、障害時に別リージョンでインフラを構築してリストアする方式です。RPO は時間単位、RTO は 24 時間以内が目安とされます。継続的なバックアップを使えば RPO を数分まで下げられる場合もあります。

この戦略の長所は圧倒的な安さです。平常時は復旧先にインフラを動かしておく必要がなく、バックアップの保管コストだけで済みます。短所は復旧の遅さで、障害時にゼロからインフラを立ち上げるため時間がかかります。開発・検証環境や、長いダウンタイムが許容される非クリティカルなワークロードに向きます。

実装の鍵を握るのが、バックアップの取得方法とリストア手順の自動化です。手作業でインフラを再構築していては RTO が際限なく延びてしまいます。そこで、インフラ構成をコード化（IaC: Infrastructure as Code）しておき、障害時にはそのテンプレートから一気にリソースを立ち上げる。データは別リージョンに複製したバックアップからリストアする。この「構成はコード、データはバックアップ」という分離が、バックアップ＆リストアを現実的な戦略に押し上げます。安いからといって運用設計を怠ると、いざという時に復旧できないという最悪の事態を招きかねません。

DR 戦略② パイロットライト — 最小限の種火を残す

次がパイロットライトです。コアとなる部分（主にデータベース）だけを復旧リージョンで常時稼働させ、データを継続的にレプリケーションしておく方式です。アプリケーション層のサーバーは停止または未作成の状態で待機させます。RPO は分単位、RTO は数十分が目安です。

「パイロットライト」という名前は、ガス機器の種火に由来します。普段は小さな火（データベースのレプリケーション）だけを灯しておき、いざという時にそこから全体を起こす、というイメージです。障害時には待機させていたサーバーを起動し、必要なら追加のインフラをデプロイしてスケールアップする手順が必要になります。バックアップ＆リストアより速く、ウォームスタンバイより安い、中間的な選択肢です。

バックアップ＆リストアとの本質的な違いは、データが「すでに復旧先で生きている」点にあります。バックアップ＆リストアではバックアップからデータベースを復元する時間がかかりますが、パイロットライトでは継続的なレプリケーションによってデータが常に最新に近い状態で復旧先に存在します。これが RPO を分単位まで縮める理由です。残る作業はアプリケーション層の起動とスケールアップだけなので、RTO も数十分に収まります。コストと復旧速度のバランスが良く、多くの業務システムにとって現実的な落としどころになる戦略です。

DR 戦略③ ウォームスタンバイ — 縮小版を常時稼働

3 つ目がウォームスタンバイです。本番環境の縮小版を復旧リージョンで常時稼働させておく方式です。パイロットライトとの違いは、アプリケーション層まで含めて「すでに動いている」点にあります。

このため、障害時にはトラフィックを流すだけで（縮小された容量のまま）即座にリクエストを処理できます。あとは本番の負荷に耐えられるようスケールアップするだけです。RTO はパイロットライトよりさらに短くなります。パイロットライトとウォームスタンバイの違いは混同しやすいので、「パイロットライトは起動が必要、ウォームスタンバイは縮小稼働で即応」と覚えておきましょう。コストはパイロットライトより高くなりますが、復旧の速さと引き換えです。

ウォームスタンバイにはもうひとつ実務上の利点があります。復旧先が常に動いているため、定期的に少量のトラフィックを流して「本当に動くか」を検証できる点です。DR 構成で最も恐ろしいのは、いざ障害が起きた時に復旧先が想定通り動かないことです。普段から稼働しているウォームスタンバイなら、構成のドリフト（本番との設定のずれ）を早期に発見でき、DR テストも現実的に回せます。「作って終わり」にせず、復旧能力を継続的に検証できることが、この戦略の隠れた価値です。

DR 戦略④ マルチサイト Active/Active — 最速・最高コスト

最後がマルチサイト（Active/Active）です。複数のリージョンで本番環境をフル稼働させ、両方で同時にトラフィックを処理する方式です。リージョン間でデータを同期し続けます。

片方のリージョンが完全に停止しても、もう片方が通常通りトラフィックを受け続けるため、RPO はほぼゼロ、RTO もほぼゼロを実現できます。これが 4 戦略で最速の復旧能力です。一方、2 つの本番環境を常時フル稼働させるため、コストは最も高くなります。金融取引や決済基盤のように、わずかなダウンタイムも許されないミッションクリティカルなシステムでのみ正当化される戦略です。

マルチサイト構成では、データの整合性をどう保つかが最大の技術的課題になります。両リージョンで同時に書き込みを受け付ける場合、同じデータへの競合をどう解決するかを設計しなければなりません。DynamoDB グローバルテーブルのような複数リージョン書き込みに対応したサービスを使うか、書き込みは片方のリージョンに寄せて読み取りだけを分散させる（Active/Passive 寄りの構成にする）か、といった判断が必要です。「最速だから常に最善」ではなく、整合性と運用の複雑さという代償を理解したうえで選ぶ。それが成熟した DR 設計の姿勢です。

ここまでの 4 戦略を一覧にすると、コストと復旧速度の対応関係が見えてきます。

この表が AWS DR 設計の全体地図です。コスト順と復旧速度順が完全に対応している点が、選択を機械的にする鍵になります。

データレプリケーション設計 — リージョンをまたいでデータを運ぶ

どの DR 戦略も、データを復旧先へ運ぶレプリケーションが前提になります。代表的な仕組みを押さえましょう。

• S3 クロスリージョンレプリケーション（CRR）: オブジェクトを別リージョンのバケットへ自動複製。バックアップやコンテンツ配信の冗長化に
• RDS / Aurora クロスリージョンレプリカ: データベースを別リージョンへ非同期複製。パイロットライトのコア部分に
• Aurora グローバルデータベース: 専用の高速レプリケーションで、標準で RPO 1 秒・RTO 1 分を実現

Aurora グローバルデータベースは、リージョン間レプリケーションを低遅延で行うために設計された仕組みです。通常のクロスリージョンレプリカより高速で、グローバル展開するアプリの DR 基盤として頻出します。「リージョン障害に備えつつ、世界中で低レイテンシの読み取りを提供したい」という要件で選ばれます。レプリケーション方式の選択は、達成可能な RPO を直接左右します。同期レプリケーションはデータ損失をほぼゼロにできる代わりに書き込みレイテンシが増え、非同期レプリケーションは高速な書き込みと引き換えに僅かなデータ損失の可能性を残します。要件の RPO から逆算して方式を選ぶ、という思考が DR 設計の精度を決めます。

Route 53 フェイルオーバールーティングとヘルスチェック

復旧先を用意しても、ユーザーのトラフィックをそこへ向け直さなければ意味がありません。その役割を担うのが Amazon Route 53 のフェイルオーバールーティングです。

Route 53 はヘルスチェックでプライマリの健全性を監視し、異常を検知すると DNS の応答をセカンダリ（復旧先）に切り替えます。これにより、障害時に自動でトラフィックが復旧リージョンへ流れます。パイロットライトやウォームスタンバイと組み合わせる定番構成です。Route 53 には他にも加重・レイテンシ・地理的位置など多彩なルーティングポリシーがありますが、DR の文脈ではフェイルオーバールーティングとヘルスチェックの組み合わせが中心になります。

設計時の注意点として、DNS には TTL（Time To Live）によるキャッシュが効くため、切り替えが瞬時に全ユーザーへ反映されるわけではない、という性質を理解しておく必要があります。フェイルオーバーを素早く効かせたい場合は、レコードの TTL を短めに設定しておく。一方で短すぎる TTL は Route 53 への問い合わせを増やすため、要件に応じたバランスが求められます。こうした細部の理解が、AWS DR 設計を「絵に描いた餅」で終わらせないための実装力につながります。

AWS Backup による一元バックアップ管理

複数のサービスにまたがるバックアップを個別に管理すると、設定漏れや運用ミスの温床になります。これを一元化するのが AWS Backup です。

AWS Backup は、EBS・RDS・DynamoDB・EFS・S3 など多様なサービスのバックアップを、ポリシーベースで一括管理します。バックアップの取得頻度・保持期間・別リージョンへのコピーを集中設定でき、コンプライアンス要件への対応も容易になります。「組織全体のバックアップを統一ポリシーで管理したい」という要件では、サービスごとに手組みするのではなく AWS Backup を選ぶのが正解です。

さらに、ランサムウェア対策の観点で重要なのが Backup Vault Lock です。これは保管したバックアップを一定期間、削除・改変できないようにロックする機能で、内部不正や攻撃者によるバックアップ破壊を防ぎます。バックアップそのものが攻撃対象になる時代において、「消せないバックアップ」を持てることは、DR の信頼性を一段引き上げます。AWS DR 設計を考える際は、復旧の速さだけでなく、バックアップの保全性まで視野に入れると、より堅牢な構成にたどり着けます。

設計シナリオ演習 — RTO/RPO から戦略を選ぶ

判断軸を試験形式で確認します。提示される RTO/RPO とコスト制約から、戦略を逆算してください。

シナリオ 1: 開発環境。コスト最優先、復旧に半日かかってもよい。 高コストな常時稼働構成は過剰です。正解はバックアップ＆リストアです。

シナリオ 2: 業務システム。RTO は数十分、コストは抑えたい。 マルチサイトは過剰投資。正解はパイロットライト。コア DB だけ復旧先で動かし、障害時に起動します。

シナリオ 3: EC サイト。ダウンタイムは数分以内に抑えたいが、マルチサイトほどの予算はない。 正解はウォームスタンバイ。縮小版を常時稼働させ、即座にトラフィックを受けます。

シナリオ 4: 決済基盤。ダウンタイムもデータ損失も許されない。 コストは二の次。正解はマルチサイト Active/Active です。

シナリオ 5: グローバル展開アプリで、リージョン障害に備えつつ低遅延の読み取りも欲しい。 正解は Aurora グローバルデータベースを軸にした構成です。

5 問とも、判断は「RTO/RPO がどれだけ厳しいか」と「許容コスト」の交点で決まります。前掲の対応表を思い出せば、選択肢は自然に 1 つへ収束します。

まとめ — DR 戦略の選定チェックリスト

AWS DR 設計は、次のチェックリストに集約できます。

• RTO は「時間」、RPO は「データ」。両者を独立して読み取る
• 4 戦略はコスト順＝復旧速度順。バックアップ＆リストア → パイロットライト → ウォームスタンバイ → マルチサイト
• パイロットライトは「起動が必要」、ウォームスタンバイは「縮小稼働で即応」
• マルチサイトは最速かつ最高コスト。ミッションクリティカルのみ
• データ複製は S3 CRR、RDS/Aurora クロスリージョン、Aurora グローバル DB
• トラフィック切替は Route 53 フェイルオーバー＋ヘルスチェック
• バックアップの一元管理は AWS Backup

DR 設計で最後に強調したいのは、「定期的にテストして初めて DR は機能する」という点です。設計図上は完璧でも、実際に切り替えてみると想定外の依存関係でつまずくことは珍しくありません。復旧手順を定期的に演習し、RTO/RPO が本当に満たせるかを検証する。この継続的な訓練こそが、いざという時に効く DR の本質です。

ここまでで、可用性を保ち、壊れても復旧する設計が揃いました。次は配点 24% の Domain 3、高性能アーキテクチャの設計に進みます。ワークロードの特性から最適なサービスを逆引きする判断を、コンピュート・ストレージ・データベース・ネットワークの 4 領域で整理していきます。

参照

• AWS 災害復旧ホワイトペーパー — クラウドでの DR オプション
• AWS Well-Architected Reliability Pillar — 復旧戦略
• Amazon Route 53 フェイルオーバールーティング
• Amazon Aurora グローバルデータベース
• AWS Backup 公式

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.