「DR 対策をしておいて」と言われた。マルチ AZ にはしてある。でも、東京リージョン全体が止まったら、誤ってデータベースを消したら、ランサムウェアで暗号化されたらどうなるのか。別リージョンに同じ環境を置けば安心だが、費用は倍になる。どこまでやれば「対策した」と言えるのか、根拠を持って説明できない。
DR の方式は、技術から選ぶと過剰か不足のどちらかになります。この記事は、業務が許せる停止時間（RTO）とデータ損失（RPO）から方式を逆算し、AWS の部品の位置づけ・切り替えの作り方・訓練・データの置き場所までを判断の順番として整理します。
この記事の結論
- DR の方式は、業務が許せる停止時間（RTO）とデータ損失（RPO）をワークロードごとに決めてから、それを満たす最も安い方式を選びます。
- AWS の DR ホワイトペーパーは方式を、バックアップと復元・パイロットライト・ウォームスタンバイ・マルチサイト（アクティブ/アクティブ）の4つに分け、後ろほど RTO と RPO が短く、費用と複雑さが増えます。
- マルチ AZ は AZ の障害への備えで、リージョン全体の障害やデータの破損には、別リージョン・別アカウントのバックアップが要ります。
- 切り替えは、障害中のリージョンのコントロールプレーンに頼らず、Route 53 のヘルスチェックや ARC のルーティングコントロールのようなデータプレーンの操作で行います。
- 訓練していない DR 計画は、RTO と RPO を満たせるかが分からないので、定期的に切り替えと復元を試して方式を見直します。
DR の設計で先に決める要件とは ─ RTO と RPO
Well-Architected フレームワークの信頼性の柱は、ワークロードごとに2つの目標を決めることを求めています。
- RTO（目標復旧時間）: サービスが中断してから再開するまでに許せる最大の時間
- RPO（目標復旧時点）: 最後の復旧ポイントから、失ってよいデータの最大の時間
この2つは技術者が決める数字ではありません。「1時間止まると売上と信用にどれだけ響くか」「最後の15分の注文が消えたら誰がどう困るか」を業務の側と話して決めます。そのうえで、次の要件を書き出します。
| 軸 | 何を確かめるか | 答えが変えるもの |
|---|---|---|
| RTO と RPO | ワークロードごとの停止とデータ損失の許容 | 4つの方式のどれを選ぶか |
| 災害の範囲 | AZ の障害か、リージョンの障害か、誤操作・破損・ランサムウェアか | マルチ AZ で足りるか、別リージョン・別アカウントが要るか |
| 規制 | データを置いてよい国と地域、保存期間、改ざんの防止 | 復旧先のリージョン、バックアップの不変化 |
| コスト | 平常時に払える費用、障害時の拡張の費用 | 平常時に動かしておく範囲 |
| 運用体制 | 切り替えの判断者、手順を実行できる人、訓練の頻度 | 自動で切り替えるか、人が判断して切り替えるか |
RECOVERY OBJECTIVES先に書き出す要件
方式は技術からではなくRTO と RPOから逆算する
-
1.RTO と RPO — 許せる停止時間とデータ損失
ワークロードごとに、業務の側と影響から決める
-
2.災害の範囲 — AZ か、リージョンか、破損か
マルチ AZ で足りるか、別リージョン・別アカウントが要るか
-
3.規制 — データを置いてよい場所と保存の条件
復旧先とコピー先のリージョン、バックアップの不変化
-
4.費用と体制 — 平常時に払える額、切り替えの判断者
平常時に動かす範囲、自動か人の判断か
とくに「災害の範囲」の書き分けが重要です。マルチ AZ の構成は、1つの AZ が止まっても動き続けるための高可用性の仕組みで、リージョン全体の障害には備えていません。さらに、同期や複製の仕組みは、誤って消したデータや暗号化されたデータもそのまま相手に写します。DR ホワイトペーパーも、データの複製は一部の災害から守るが、時点を指定して戻す手段を含まない限りデータの破損や破壊からは守らない、と書いています。
4つの方式は何が違うのか?
AWS のホワイトペーパー「Disaster Recovery of Workloads on AWS」は、DR の方式を4つに分けています。後ろに行くほど RTO と RPO は短くなり、平常時の費用と構成の複雑さが増えます。目安は Well-Architected の信頼性の柱（REL13）とホワイトペーパーの記載です。
| 方式 | 平常時に復旧先で動いているもの | RPO の目安 | RTO の目安 | 向くワークロード |
|---|---|---|---|---|
| バックアップと復元 | バックアップだけ | 時間単位 | 24時間以内 | 社内向け、止まっても翌日に戻せばよい |
| パイロットライト | データの複製と中核の部品。アプリのサーバーは止めている | 分単位 | 数十分 | データは失いたくないが、数十分の停止は許せる |
| ウォームスタンバイ | 縮小した完全な環境が常に稼働 | 秒単位 | 分単位 | 数分で再開したいが、2倍の費用は払えない |
| マルチサイト（アクティブ/アクティブ） | 複数リージョンで本番の規模が稼働し、両方で処理 | ほぼゼロ | ゼロに近づけられる | 止まると事業に直結し、費用より継続を優先する |
FOUR DR STRATEGIES4つの方式
後ろほど早く戻るが、平常時の費用と複雑さが増える
-
B&R
バックアップと復元 — バックアップだけを別リージョンへ
RPO は時間単位、RTO は24時間以内。IaC で作り直して復元
-
Pilot
パイロットライト — データの複製と中核の部品だけ
RPO は分単位、RTO は数十分。サーバーを起動してから受ける
-
Warm
ウォームスタンバイ — 縮小した完全な環境が稼働
RPO は秒単位、RTO は分単位。拡張するだけで受けられる
-
Multi
マルチサイト — 複数リージョンで本番が稼働
RPO はほぼゼロ。両方で処理し、費用と整合の設計が最も重い
いちばん取り違えやすいのが、パイロットライトとウォームスタンバイの違いです。ホワイトペーパーは、パイロットライトは追加の操作（サーバーの起動、中核以外の部品の展開、拡張）をしないと要求を処理できず、ウォームスタンバイは縮小した規模ですぐに要求を処理でき、切り替えのときは拡張するだけ、と区別しています。「復旧先に何かが動いているか」ではなく「そのまま要求を受けられるか」で見分けます。
バックアップと復元でも、自動化の程度で RTO は大きく変わります。復旧先のインフラを IaC で作り直せるようにしておけば、手作業で作るより早く戻せます。継続的なバックアップで時点を指定した復元（PITR）を使えば、RPO を短くできる場合もあります。
方式は1つの組織で1つに揃える必要はありません。ワークロードごとに RTO と RPO が違うので、基幹の注文処理はウォームスタンバイ、社内の申請システムはバックアップと復元、と分けるのが普通です。
CHECK 1ここまでの確認
別リージョンに縮小した完全な環境を常に動かしておき、切り替えのときに台数を増やすだけで本番を受けられる方式はどれ?
答えと解説
答え: 3. ウォームスタンバイ
ウォームスタンバイは、規模は小さくてもそのまま要求を処理できる環境が動いています。パイロットライトはデータの複製と中核の部品だけが動いていて、アプリのサーバーを起動しないと要求を処理できません（「4つの方式は何が違うのか」の表）。
方式ごとに AWS のどの部品を使うか
同じ方式でも、データの種類によって使う部品が違います。どの部品が「データを守る」もので、どれが「利用者を切り替える」ものかを分けて考えます。
| 部品 | 役割 | 主に使う方式 | 設計で気をつけること |
|---|---|---|---|
| AWS Backup | 複数のサービスのバックアップを計画で一元管理し、別リージョン・別アカウントへコピー | バックアップと復元（ほかの方式でも破損への備えに併用） | 組織のバックアップポリシーで OU に適用。コールドの階層はコピーできない。Vault Lock で削除と変更を防ぐ |
| Aurora Global Database | ストレージの層でリージョン間に複製し、セカンダリを昇格 | パイロットライト〜マルチサイト | 計画した切り替え（switchover）は RPO ゼロ、障害時のフェイルオーバーは通常秒単位の RPO |
| DynamoDB グローバルテーブル | 複数リージョンのどこでも読み書きできる複製 | ウォームスタンバイ〜マルチサイト | 結果整合（MREC）は同じ項目の同時書き込みを「最後の書き込みが勝つ」で解決。強い整合（MRSC）はちょうど3リージョンの構成 |
| AWS Elastic Disaster Recovery | オンプレミスやクラウドのサーバーをブロック単位で継続的に複製し、時点を指定して起動 | パイロットライトに近い形 | 平常時は安いストレージと最小の計算資源。訓練用のインスタンスを起動して試せる |
| Amazon Route 53 | ヘルスチェックとフェイルオーバールーティングで利用者を切り替え | すべて（切り替えの入口） | ヘルスチェックはデータプレーンで動く。TTL が切り替えの速さに効く |
複製とバックアップは別のものとして両方持ちます。複製は RPO を短くしますが、破損も写します。バックアップは破損から戻れますが、復元に時間がかかります。とくに別アカウントの保管庫へのコピーは、本番アカウントの認証情報が漏れても消されない場所にバックアップを置くための設計です。別アカウントへのコピーは同じ組織のアカウント間で行い、AWS Backup が完全に管理しない種類のリソースでは、コピー先に共有できるカスタマー管理のキーが要ります。
Elastic Disaster Recovery は、オンプレミスの VMware 上のサーバー群のように、アプリケーションを作り変えずに AWS を DR サイトにしたいときの選択肢です。データベースごとの複製の仕組みを1つずつ組むのではなく、サーバー単位で守れます。
READ ALSO — 学習中向け・段2 構成
Amazon Route 53 とは何か｜ホストゾーン・レコード・ルーティングポリシーを「名前の案内係」で理解する
CHECK 2ここまでの確認
データベースを別リージョンへ継続的に複製しているのに、別途時点を指定して戻せるバックアップも持つのはなぜ?
答えと解説
答え: 1. 複製は誤削除や破損もそのまま相手に写すため
複製は同期の仕組みで、壊れたデータも複製します。ランサムウェアや誤操作から戻すには、時点を指定して戻せるバックアップが要ります（「方式ごとに AWS のどの部品を使うか」の章）。
切り替えはどう作るか ─ データプレーンに頼る
障害のときに「別リージョンに新しいリソースを作る」「DNS レコードを書き換える」といったコントロールプレーンの操作は、混雑や障害で失敗することがあります。信頼性の柱は、復旧のときはコントロールプレーンではなくデータプレーンに頼ることを求めています。
- 自動で切り替える: Route 53 のヘルスチェックとフェイルオーバールーティングで、プライマリが異常になったらセカンダリに向けます。ヘルスチェックはデータプレーンで動く可用性の高い仕組みです。
- 人が判断して切り替える: Amazon Application Recovery Controller（ARC）のルーティングコントロールは、実際の正常性を見る代わりにオン／オフを自分で操作できるヘルスチェックとして働きます。切り替えの操作は、複数のリージョンに分散した可用性の高いデータプレーンの API で行えます。
- 静的に安定させる: 切り替えのときに何かを作らずに済むよう、必要な部品は平時から用意しておきます。ウォームスタンバイで切り替え時の拡張を Auto Scaling に任せる場合も、拡張の上限や容量が足りるかは平時に確かめます。
データベースの切り替えも同じ考え方です。Aurora Global Database では、計画した切り替え（メンテナンスや訓練）には同期してから入れ替える switchover を、障害時にはセカンダリを昇格する failover を使い分けます。前者はデータを失わず、後者は複製の遅れの分だけデータを失い得る、という違いを RPO の説明に含めておきます。
自動で切り替えるか人が判断するかも要件です。ヘルスチェックの誤検知で切り替わると、切り戻しの手間とデータの食い違いが生まれます。重い判断を伴うワークロードでは、検知は自動・切り替えは人、という分担が選ばれます。
CHECK 3ここまでの確認
障害中のリージョンに頼らずに切り替えるため、平時に用意しておくべきものはどれ?
答えと解説
答え: 2. データプレーンの操作だけで済むヘルスチェックやルーティングコントロール
障害のときはコントロールプレーンの操作が失敗することがあります。Route 53 のヘルスチェックや ARC のルーティングコントロールのように、データプレーンで切り替わる仕組みを平時に作っておきます（「切り替えはどう作るか」の章）。
テストしない DR はなぜ無いのと同じか?
DR の計画は、実際に切り替えてみるまで RTO と RPO を満たせるかが分かりません。信頼性の柱は、復旧先への切り替えを定期的に試し、正しく動くこと・RTO と RPO を満たすことを確かめるよう求めていて、これを実施しないリスクを「高」としています。バックアップについても、定期的に復元して中身と手順を確かめることがベストプラクティスに挙がっています。
訓練で確かめることは次のとおりです。
- 実際の復旧時間とデータの欠損を計る。 目標ではなく、計った値を記録する。
- 手順書どおりに、担当者が実行できるか。 詳しい人がいない時間帯でも回るか。
- 復旧先の構成が本番とずれていないか。 本番だけに足した設定、上限値、証明書、シークレット。
- 切り戻しまでできるか。 戻すときのデータの同期と、戻したあとの確認。
Elastic Disaster Recovery は本番の複製を止めずに訓練用のインスタンスを起動でき、Direct Connect や Route 53 の切り替えも意図的に片方を落として試せます。訓練の結果が目標に届かなければ、方式を1段上げるか、業務の側と RTO と RPO を見直します。
DR でよくある失敗の型
- マルチ AZ を DR と呼び、リージョンの障害とデータの破損への備えが無い
- 複製だけを持ち、誤削除やランサムウェアから戻せるバックアップが無い
- バックアップを本番と同じアカウントに置き、認証情報の漏えいで一緒に消される
- 切り替えの手順を一度も試しておらず、障害のときに初めて手順の穴が見つかる
リージョンを跨ぐときのデータの置き場所と、判断の順番
別リージョンにバックアップや複製を置くと、データは別の国や地域に移ります。個人情報や規制のあるデータは、移してよい場所が決まっている場合があります。日本国内に置くことが求められるなら、東京リージョンと大阪リージョンの組み合わせのように、復旧先も国内で選びます。バックアップのコピーもデータそのものなので、コピー先のリージョンも同じ規制の対象です。
組織で守るなら、AWS Control Tower のリージョン拒否のコントロールや SCP で、許可したリージョン以外への作成を止めておきます。DR のために一時的に別のリージョンを使う計画があるなら、その例外も平時に決めておきます。障害の最中に規制を確かめる時間はありません。
判断の順番をまとめます。
- ワークロードごとに RTO と RPO を決める。 業務の側と、停止とデータ損失の影響から決める。
- 備える災害の範囲を書く。 AZ・リージョン・誤操作と破損・認証情報の漏えい。
- 満たす方式のうち最も安いものを選ぶ。 バックアップと復元 → パイロットライト → ウォームスタンバイ → マルチサイトの順に検討する。
- データの部品を選ぶ。 複製（Aurora Global Database・DynamoDB グローバルテーブル・Elastic Disaster Recovery）と、別アカウントのバックアップ（AWS Backup）を組にする。
- 切り替えの仕組みを決める。 データプレーンで切り替わる Route 53 と ARC を使い、自動か人の判断かを決める。
- 復旧先のリージョンを規制で確かめる。 コピー先も含めて、置いてよい場所か。
- 訓練して、結果で見直す。 計った値を記録し、選ばなかった方式とその理由を残す。
どの方式にも得るものと捨てるものがあります。平常時の費用を抑えれば復旧に時間がかかり、すぐ戻したければ平常時に払い続けることになります。その天秤を業務の言葉で説明し、判断を記録に残す型は、次に読む記事で扱います。
COST AND RECOVERYDR の天秤
平常時に払うか、復旧に時間を払うか
平常時の費用を抑える
- バックアップと復元
- パイロットライト
- 復旧に時間と手順がかかる
すぐ戻す
- ウォームスタンバイ
- マルチサイト
- 平常時に払い続ける
支点は「業務が許す RTO と RPO」
参照ソース
- Disaster recovery options in the cloud（Disaster Recovery of Workloads on AWS） — 4つの方式の名前と定義、パイロットライトとウォームスタンバイの違い、複製が破損から守らないこと（2026-09 時点の記載）
- REL13-BP01 Define recovery objectives for downtime and data loss・REL13-BP02 Use defined recovery strategies・REL13-BP03 Test disaster recovery implementation（Well-Architected 信頼性の柱） — RTO と RPO の定義、方式ごとの目安、訓練の必要性（2026-09 時点の記載）
- REL09-BP04 Perform periodic recovery of the data と REL11-BP04 Rely on the data plane and not the control plane during recovery — バックアップの定期的な復元と、復旧時にデータプレーンに頼ること（2026-09 時点の記載）
- What is AWS Backup?・Creating backup copies across AWS Regions・Creating backup copies across AWS accounts・AWS Backup Vault Lock — 一元管理、リージョン間・アカウント間のコピーの条件、不変化（2026-09 時点の記載）
- Using switchover or failover in Amazon Aurora Global Database — switchover と failover の違いと RPO（2026-09 時点の記載）
- How DynamoDB global tables work — MREC と MRSC、最後の書き込みが勝つ解決（2026-09 時点の記載）
- What is Elastic Disaster Recovery? — 継続的な複製、時点を指定した復旧、訓練（2026-09 時点の記載）
- Configuring DNS failover（Amazon Route 53） と Data and control planes for routing control（ARC） — ヘルスチェックによる切り替えと、ルーティングコントロールのデータプレーン（2026-09 時点の記載）
- Configure the Region deny control（AWS Control Tower） — 許可したリージョン以外での作成を止めるコントロール（2026-09 時点の記載）
