マルチリージョンは目的じゃない — RTO/RPOから選ぶAWS DR戦略4択と、data planeで組むフェイルオーバー

災害復旧（DR）の設計で最初に外しやすいのが、「マルチリージョン化すること」自体を目的にしてしまう発想です。本来の目的は、障害が起きても許容できる時間内にサービスを戻し、許容できる範囲のデータ損失に抑えることです。マルチリージョンは、その目的を満たすための手段の一つにすぎません。本記事は、本番システムのDRを設計する実務者に向けて、RTO/RPOから4つのDR戦略（Backup&Restore / Pilot Light / Warm Standby / Active-Active）を過不足なく1つ選び、フェイルオーバーをdata plane操作で堅牢に組む考え方を整理します。これは過去障害の解説ではなく、平時に備える事前設計（proactive）の話です。なお復旧時間やコストの具体値は構成に依存するため相対比較で扱い、サービスの仕様・対応リージョンは2026年6月時点として、適用前に公式の最新情報をご確認ください。

なぜ平時の事前設計なのか

過去の大規模障害を振り返る記事は、何が起きたかと、そこから何を学ぶかを教えてくれます。一方で本記事が扱うのは、その教訓を「では平時にどのDR戦略を選んでおくか」という事前設計に落とすことです。障害が起きてから戦略を考えるのでは間に合いません。

事前設計の骨格になるのが、RTO と RPO という2つの目標です。RTO（Recovery Time Objective）は、サービス中断から復旧までに許容できる最大時間、つまりどれだけ速く戻すかです。RPO（Recovery Point Objective）は、直近の復旧可能点からの許容できる最大時間、つまりどれだけのデータ損失を許すかで、バックアップやレプリケーションの頻度で決まります。この2つを先に決め、そこから戦略を逆算するのが設計の出発点です。可用性目標（SLO）を扱う設計と同じく、「目標から逆算する」という型でつながります。

まず RTO/RPO を決める — 復旧目標から逆算する

戦略を比べる前に、自分のシステムのRTO/RPOを事業影響から決めます。停止が1日続いても許容できる社内バッチと、数分の停止も許されない決済系では、必要な戦略がまったく異なります。RTO/RPOを曖昧にしたまま「とりあえず冗長化」を進めると、過剰投資にも、いざというとき目標未達にもなりかねません。

あわせて、備えるべき災害のレベルを定義します。単一AZの冗長性が一時的に欠ける程度なのか、データセンター単位の損失なのか、リージョン全体の損失なのか、あるいは規制要件として地理的分散が求められるのか。どのレベルまで耐える必要があるかで、選ぶ戦略の右端がどこまで必要かが変わります。RTO/RPOと災害レベルが決まって初めて、戦略の比較に意味が出ます。

4つのDR戦略 — Backup&Restore / Pilot Light / Warm Standby / Active-Active

AWS公式が示すDR戦略は4つで、左ほど低コスト・低複雑だがRTO/RPOが大きく、右ほど高コスト・高複雑だがRTO/RPOが小さい、連続したスペクトラムとして並びます。

戦略	構成	RTO/RPO	コスト・複雑度	代表的な要素
Backup & Restore	active/passive	最も大きい	最小	バックアップ＋IaCで再デプロイ
Pilot Light	active/passive	RPO低・RTO中	小〜中	データ継続レプリ＋コア基盤常時（DRS＝この方式）
Warm Standby	active/passive	RTO短	中〜大	縮小版の本番が常時稼働
Active-Active	active/active	ほぼゼロ	最大	複数リージョンで同時稼働

Backup & Restore は、データをバックアップし（別リージョンへも複製し）、災害時にインフラ・構成・コードを再デプロイして復旧します。RPOはバックアップ頻度、RTOは再デプロイ時間で決まり、4戦略で最もRTO/RPOが大きくなります。復旧を速めるにはIaC（CloudFormationやCDK）が事実上必須です。RTO/RPOが緩い、あるいは単一AZ・単一データセンター損失レベルへの備えなら、これで十分なケースもあります。

Pilot Light は、データを継続的にレプリケーションし、データベースなどのコア基盤は常時稼働させたまま、アプリケーションサーバーは停止状態で待機させます。災害時にそれを「点火」してスケールアウトします。継続レプリのぶんBackup&RestoreよりRPOが低く、RTOも短くなります。AWS Elastic Disaster Recovery（DRS）はこのPilot Light方式です。

Warm Standby は、能力を縮小しているものの完全に機能する本番のコピーを常時稼働させます。Pilot Lightとの違いは、Pilot Lightが「点火」を要するのに対し、Warm Standbyは「スケールアップ」だけで本番容量に戻せる点です。そのぶんRTOが短くなります。

Active-Active（Multi-site Active/Active）は、複数リージョンで同時にワークロードを稼働させ、全リージョンがトラフィックを処理します。正しく実装すればRTOをほぼゼロにでき、そもそも「フェイルオーバー」という概念がありません。1リージョンのみが配信するactive/passive版は Hot Standby と呼ばれます。

どれを選ぶか — RTO/RPO×二重運用コストの判断木

4戦略を並べたら、RTO/RPO、二重運用コスト、運用複雑度のトレードオフから1つを選びます。ここで重要なのは、右側の戦略ほど常時並行で動かすリソースが増え、二重運用コストと運用負荷が膨らむことです。RTO/RPOが緩いのにActive-Activeを選ぶのは、典型的な過剰投資です。

判断の順序は、まずRTO/RPOを置き、次に備える災害レベルを確定し、そのうえで二重運用コストと運用複雑度に照らして1つに絞る、という流れです。RTO/RPOが緩ければBackup&Restoreで十分であり、それを堂々と選ぶことが健全な投資判断です。逆に、数分の停止も許されずデータ損失をほぼ許容できないなら、コストを払ってActive-Activeに寄せます。Pilot LightとWarm Standbyはその中間で、RTO要件と費用で選び分けます。

フェイルオーバーを data plane で組む — AZは zonal shift、リージョンは routing control の2段

戦略を選んだら、切り替えをどう実行するかが設計の肝になります。公式が示す原則は明快で、最大の回復性のためにフェイルオーバー操作は data plane の操作だけで構成する、というものです。data plane は control plane より高い可用性設計目標を持つため、障害時に頼る相手として信頼できます。切り替えを control plane に依存させると、その control plane 自体が障害の影響を受けて切り替えに失敗するリスクが残ります。

切り替えは2つの粒度で考えます。AZ粒度では、Amazon Application Recovery Controller（ARC）の Zonal shift / Zonal autoshift を使い、障害が起きたAZから同一リージョンの健全なAZへ一時的にトラフィックを退避させます（手動またはAWS発、最大3日）。リージョン粒度では、ARC の Routing control（safety rules を備えた信頼性の高い data plane のスイッチ）と Region switch（多リージョン復旧のオーケストレーション）を使います。つまり、AZ＝zonal shift から リージョン＝routing control へという2段で組み立てます。Route 53 のヘルスチェックによるDNSフェイルオーバーも data plane の手段です。

ここで誠実に押さえるべき落とし穴があります。ARC の Readiness check は、フェイルオーバーのクリティカルパスで使うものではありません。これは平時のreadiness監視であって、切り替えの瞬間にその判定へ依存させない、というのが公式の位置づけです。これは、切り替えを静的に安定させ data plane で完結させる考え方を裏打ちします。一方、Route 53 の重み付けルーティングの重み変更や Global Accelerator の traffic dial は control plane の操作で、相対的に回復性が低い手段です。Auto Scaling も control plane の活動であり、復旧時にスケールアウトを前提にすると全体の回復性が下がるトレードオフがあります。これを避けるには、十分な容量を静的に確保した Hot Standby（statically stable）にしてAuto Scaling非依存にしますが、そのぶんコストは上がります。自動フェイルオーバーは誤検知で不要な切り替えを招くため、手動起動と手順自動化（ボタン一押し）の組み合わせが現実的です。

データ災害対策を別建てし、テストで確かめる

戦略と切り替えを決めても、データの守りは別途必要です。レプリケーションは可用性を上げますが、破損や誤削除もそのまま複製先へ伝播します。Active-Active で near-zero RTO を実現していても、データ破損や人的ミスからの復旧時間は常にゼロより大きくなります。したがって、バージョニングやポイントインタイム復旧（PITR）は、active-active であっても別建てで必須です。

書き込みの設計も整理しておきます。全書き込みを1リージョンに集約する write global（Aurora Global Database。公式では典型的なレプリ遅延は1秒未満、1分未満での昇格やwrite forwardingが挙げられますが、いずれも2026年6月時点の値として公式で確認してください）、最寄りへ書き込む write local（DynamoDB global tables。last-writer-wins）、パーティションキーで割り当てる write partitioned（S3の双方向レプリケーション）という型があります。

書き込み設計	代表サービス	特徴
write global	Aurora Global Database	書き込みを1リージョンに集約
write local	DynamoDB global tables	最寄りへ書き込み（last-writer-wins）
write partitioned	S3双方向レプリケーション	パーティションキーで割り当て

そして、設計しただけで安心しないことです。ゲームデーやAWS Resilience Hubで、「本当に目標時間内に戻るか」を平時に検証します。Resilience Hub は構成がRTO/RPO目標を満たせるかを継続的に確認でき、机上の戦略を実証に変えます。

まとめ

DRは、マルチリージョン化を目的化せず、RTO/RPOと費用から戦略を1つ選ぶ投資判断です。設計は6つのステップに整理できます。RTO/RPOを決める、災害レベルを定義する、4戦略から1つ選ぶ、切り替えを data plane で組む、データ災害対策を別建てする、そしてテストで目標達成を確かめる、です。

要点は3つです。第一に、過剰投資を戒め、RTO/RPOが緩ければBackup&Restoreで十分と判断します。第二に、フェイルオーバーは data plane で組み、AZ＝zonal shift から リージョン＝routing control の2段で、control plane依存を避けます。第三に、レプリは破損も伝播するため、バージョニング/PITRは別建てで持ち、テストで実証します。過去の大規模障害から学んだ教訓を、どのDR戦略として平時に備えるかは、障害解説の記事から本記事のような事前設計へ、可用性目標の設計やアーキテクチャ意思決定の記録へと接続して具体化していくのが実務的です。

出典

• AWS Disaster Recovery whitepaper（Disaster Recovery Options in the Cloud・4戦略/RTO/RPO/data plane） — https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
• Amazon Application Recovery Controller（ARC・zonal shift / routing control / Region switch / readiness check） — https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html