DR設計の相談で最初に確認するのは、技術構成ではなく「そのシステムは何分止まると、いくら損をするのか」です。RPOとRTOという2つの目標を事業影響度から先に決めれば、どのDR戦略を選ぶかはほぼ自動的に絞れます。この記事では4つの類型とコストのトレードオフ、レプリケーションとフェイルオーバーの実装、そして訓練までを実務目線で整理します。
01まずRPOとRTOを事業影響度から決める
DR設計は技術選定の前に、2つの目標値を握ることから始まります。この2つが決まらないまま「とりあえずマルチリージョンで」と進めると、過剰投資か、いざという時に守れない設計のどちらかに着地します。
- RPO（Recovery Point Objective）：どこまでのデータ損失を許容できるか。「災害時に直近1時間分のデータは失っても業務が回るか」という問いです。RPOを短くするほど、データレプリケーションを高頻度・低遅延にする必要があり、コストが上がります。
- RTO（Recovery Time Objective）：何分・何時間で復旧させるか。「気づいてから業務再開まで許される時間」です。RTOを短くするほど、待機系を常時温めておく必要があり、これもコストに直結します。
重要なのは、この2つを情シスやインフラ担当だけで決めないことです。RPO/RTOは本来、事業部門が負う「止まった時の損失」から逆算すべき数値です。受注が止まる基幹系と、社内向けの情報共有系では、許容できる停止時間が桁で違います。まず対象システムを影響度でランク分けし、ランクごとに目標値を置く——これがDR設計の出発点です。
02DR戦略の4類型 — コストと復旧時間のトレードオフ
AWSのDR戦略は、大きく4つの類型に整理できます。上から下へ行くほどRPO/RTOは短くなりますが、待機側リソースを常時動かす分だけコストが増えます。逆に言えば、目標値が緩ければ、下の類型を選ぶ理由はありません。
- Backup & Restore：バックアップを別リージョンに保管し、災害時に一から構築・復元します。RTOは数時間〜。平常時のコストは最も低く、保管料が主。RPOはバックアップ間隔に依存します。
- Pilot Light：データベースなど「核」だけを別リージョンで常時レプリケーションし、アプリ層は最小構成（あるいは停止）で待機。災害時にアプリ層を起動・スケールアウトします。RTOは数十分〜数時間。
- Warm Standby：本番の縮小版を別リージョンで常時稼働させておき、災害時に本番規模へスケールアップします。RTOは数分〜数十分。縮小版とはいえ常時課金が発生します。
- Multi-site Active/Active：複数リージョンで同時に本番トラフィックを処理します。RTOはほぼゼロ、RPOも極小にできますが、コストと設計・運用の複雑さは最も高くなります。データ整合性の設計が本質的に難しくなる点も見逃せません。
一般論として全社を1つの類型に揃える必要はありません。基幹系はWarm Standby、社内系はBackup & Restore、というように、システムのランクごとに類型を割り当てるのが現実的です。この考え方はアカウントやVPCの構成方針とも絡むため、マルチアカウント統制の設計と合わせて検討すると整理しやすくなります。
03データレプリケーション — RPOを決める本丸
RPOを実際に決めるのは、データをどう別リージョンへ複製するかです。データの種類ごとにAWSのマネージド機能が用意されており、「自前でrsyncを組む」といった発想はまず不要です。
- S3クロスリージョンレプリケーション（CRR）：バケット単位で別リージョンへ非同期複製します。オブジェクト更新を検知して自動でコピーするため、静的コンテンツやファイル資産のDRに向きます。到達までの遅延は非同期である点を前提に設計します。データレイクを別リージョンへ持つ設計はS3データレイク設計の観点も併せて確認してください。
- RDS / Auroraのクロスリージョンリードレプリカ：非同期レプリケーションでDRリージョンに読み取り可能な複製を維持します。災害時にはこれを昇格（プロモート）して書き込み可能にします。Auroraには複数リージョンにまたがるグローバルデータベースの機能もあり、より短いRPO/RTOを狙えます。具体的なレプリケーション遅延の数値は構成と負荷に依存するため、公式ドキュメントで前提を確認してください。
- DynamoDB Global Table：複数リージョンでマルチアクティブに書き込めるテーブルを構成でき、リージョン間を自動でレプリケーションします。Active/Active構成でセッションやカート情報のような分散させたいデータに向きます。
04Route 53でフェイルオーバーを切り替える
待機系を用意しても、トラフィックをそこへ向ける仕組みがなければDRは完成しません。ここで中心になるのがRoute 53のヘルスチェックとフェイルオーバールーティングです。
プライマリのエンドポイントにヘルスチェックを設定し、異常を検知したらセカンダリ（DRリージョン）のレコードへ自動で切り替える——これがフェイルオーバールーティングの基本形です。TTLを短めに設定しておくことで、切り替え後のDNS浸透を早められます。ただしDNSキャッシュはクライアント側の挙動に左右されるため、切り替えが瞬時に全ユーザーへ伝わるわけではない点は前提に置きます。
- フェイルオーバー：プライマリ/セカンダリを定義し、ヘルスチェック連動で自動切替。最も一般的なDR構成。
- レイテンシー / 加重ルーティング：Active/Active寄りの構成で、複数リージョンへトラフィックを分配。加重を操作して段階的に寄せる運用も可能。
フェイルオーバーは「切り替わること」だけでなく「切り戻し（フェイルバック）」の手順まで設計しておく必要があります。プライマリ復旧後にどうデータを整合させ、いつ本番を戻すか——ここが抜けると、片系運用が長期化しがちです。
05DR訓練 — 作った仕組みは、回して初めて価値になる
DR構成で最も多い失敗は、構築して満足し、一度も切り替えを試さないことです。テープ時代の「復元テスト」と同じで、レプリケーションが流れていることと、実際にフェイルオーバーして業務が回ることは別物です。この点はテープバックアップのAWS移行で述べた「変わらないのは復元テストだけ」という原則がそのまま当てはまります。
- 定期的なフェイルオーバー訓練：半年〜1年に一度は、実際にDRリージョンへ切り替え、アプリが起動し、想定RTO内に業務が再開できるかを計測します。「机上で確認」ではなく「実際に切り替える」ことに価値があります。
- Runbookの整備：誰が、何を、どの順で操作するかを手順化します。深夜・休日に発動する前提で、属人性を排します。
- 監視との接続：フェイルオーバーの引き金となる異常検知が正しく機能するかも訓練対象です。監視の設計方針はCloudWatch監視の第一歩も参考にしてください。
訓練で得られる最大の価値は、RTOの「実測値」です。設計上のRTOと実際にかかった時間には、たいていギャップがあります。このギャップを訓練で埋めていく作業こそが、DRを「絵に描いた餅」で終わらせないための現実的なプロセスです。
—まとめ
マルチリージョンDRは、技術の派手さで選ぶものではありません。順序はいつも同じです。まず事業影響度からRPO/RTOを決め、その目標値に見合う類型（Backup & Restore / Pilot Light / Warm Standby / Active/Active）を選び、データの種類に応じたレプリケーションとRoute 53フェイルオーバーで実装し、最後に訓練で実測して詰める——この流れを外さないことが肝です。
「どこまでやるか」は、全社一律ではなくシステムのランクごとに変わります。全部をActive/Activeにするのは過剰ですし、基幹系をBackup & Restoreだけで済ませるのは危険です。ちょうどよい線を、損失額とコストのバランスで引く——ここにDR設計の判断が詰まっています。コスト面の考え方は料金や導入事例も併せてご覧ください。
マルチリージョンDRは「どこまでやるか」を事業影響度から逆算する設計判断が肝で、EMWの実務経験が活きる領域です。要件整理からDR訓練の設計まで、お気軽にお問い合わせからご相談ください。
相談する