この記事で扱うこと
「AWSは勝手に冗長化してくれるから、災害が起きても大丈夫」と思っていませんか。実は、そのままだと大きな地震や大規模障害でサービス全体が止まることがあります。
この記事では、そうした最悪の事態に備える「DR（災害復旧）」の考え方を、なるべく専門用語を避けてやさしく説明します。
まず前提を整えよう
そもそも「リージョン」と「AZ」とは？
用語メモ：リージョン とは？
「東京」「シンガポール」といった、地理的に離れた大きなデータセンター群のことです（例: 東京 =ap-northeast-1）。
用語メモ： AZ（アベイラビリティーゾーン） とは？
1つのリージョンの中にある、電源やネットワークが独立した複数の建物（データセンター）のことです。1リージョンに複数のAZがあります。
イメージとしては以下です。
- リージョン = 「東京という街にあるデータセンター団地」
- AZ = 「その団地の中の、別々の棟」
Multi-AZ だけでは「災害」には足りない
用語メモ：Multi-AZ とは？
データベースやサーバーを、1つのリージョン内の 複数のAZ（別々の棟）に分けて置く 冗長化の仕組みです。
片方の棟が停電しても、もう片方の棟で動き続けます。
ここが最初のポイントです。Multi-AZ は「同じ街（リージョン）の中で棟を分ける」だけなので、街全体（リージョン全体）が災害で止まると両方の棟が同時に止まります。
たとえるなら、
- Multi-AZ = 「同じマンションの1階と5階に予備の鍵を隠す」→ 火事でマンションごと燃えたら両方だめ
- クロスリージョンDR = 「別の街の実家にも予備の鍵を置く」→ 地元が災害でも実家の鍵が使える
用語メモ：DR / クロスリージョンDR とは？
DR（Disaster Recovery、災害復旧） は、リージョン全体が止まるような大災害を想定した復旧計画のことです。
クロスリージョンDR は、本番（例: 東京）とは別のリージョン（例: シンガポール）にもサービスの控えを用意しておく構成です。
さらに注意点として、同じリージョン内に取ったバックアップ（RDSの自動バックアップやEBSスナップショット）も、そのリージョンが災害でアクセス不能になれば取り出せなくなります。
だから「別の街」にコピーを置いておくことが大事なのです。
DRを測る2つのものさし：「RTO」と「RPO」
DR方式を選ぶとき必ず出てくる2つの目標があります。
ここは丸暗記でなく、意味をイメージで持っておくと後がラクです。
用語メモ：RTO と RPO とは？
RTO（Recovery Time Objective / 目標復旧時間） = 「障害が起きてから、何分（何時間）以内に復旧させたいか」という時間の目標。RPO（Recovery Point Objective / 目標復旧時点） = 「最悪、どれくらい前のデータまでなら失ってもガマンできるか」というデータ損失の許容量（時間で表す）。
出典: AWS公式ホワイトペーパー「 Disaster recovery objectives（RTO/RPO の定義） 」
例えるとするとゲームのセーブポイントのようなものです。
| ものさし | 意味 | ゲームでの例え |
|---|---|---|
| RTO | 復旧までにかけてよい時間 | ゲームオーバーから再開までにかかる読み込み時間 |
| RPO | 失ってよいデータの量 | 最後のセーブから何分前まで戻されるか |
RTOもRPOも「短い（少ない）ほど安心だけど、その分お金と手間がかかる」という関係にあります。
DRの4パターン：控えの用意の"本気度"
DRには、控えをどれくらい本気で用意しておくかで4段階あります。
下にいくほど「すぐ復旧できる」代わりに「お金と手間がかかる」と覚えてください。
| パターン | ざっくり言うと | 復旧の速さ | コスト |
|---|---|---|---|
| Backup & Restore | 定期バックアップを別リージョンに保存。いざという時に組み立て直す | 遅い（数時間〜） | 安い |
| Pilot Light | データだけ常にコピー。アプリは"種火"だけ用意して止めておく | 中（数十分〜） | 中 |
| Warm Standby | アプリも小さい規模で常に起動しておく | 速い（数分〜） | 高い |
| Multi-Site Active/Active | 複数リージョンで同時に本番稼働。切り替え自体が不要 | 最速（ほぼゼロ） | 最も高い |
この4パターンの分類は、AWS公式ホワイトペーパー「クラウド内での災害対策オプション」に基づきます。
用語メモ：Pilot Light（パイロットライト）とは？
ガス給湯器の「種火」が由来です。
普段は小さな火（＝データのコピーだけ）を灯しておき、必要な時に一気に本火（＝アプリ）へ広げる、というイメージです。
簡略化した全体像です。
大災害のときに「意外と落とし穴」になる話
DR設計で一番大事な考え方で押さえてほしいポイントです。
用語メモ：コントロールプレーン / データプレーン とは？
コントロールプレーン = AWSに「サーバーを新しく作って」「台数を増やして」と指示・設定を出す仕組み（管理者の操作）。データプレーン = すでに動いているサーバーが実際のリクエストをさばく仕組み（普段の通信そのもの）。
例えると、
- コントロールプレーン = 「レストランの厨房に"新しいテーブルを増設して"と指示する本部」
- データプレーン = 「今あるテーブルでお客さんに料理を出している現場」
AWSでは、大規模障害のときにコントロールプレーン（本部への指示）のほうが先に効かなくなりやすいという設計上の性質があります。
つまり、「災害が起きたら、その場で新しくサーバーを作って切り替えよう」という手順（＝コントロールプレーンに頼る手順）は、いざという時に動かないことがあるのです。
この「フェイルオーバー操作はデータプレーン操作のみで完結させるべき（データプレーンはコントロールプレーンより高い可用性設計目標を持つ）」という原則は、AWS公式の クラウド内での災害対策オプション、および Route 53 のコントロールプレーンとデータプレーンの概念 で説明されています。
だからDRの合言葉は「切り替えは"すでに用意してあるもの"を使うだけで済むようにしておく」（＝データプレーン中心で設計する）になります。
「切り替えたのに、なかなか切り替わらない」DNSの話
初級者がよくつまずくのが、Route 53（AWSのDNSサービス）の切り替えです。
用語メモ：Route 53 / DNS / ヘルスチェック とは？
DNSは「app.example.comという名前を、実際のサーバーの住所（IP）に変換する電話帳」のような仕組みです。Route 53はAWSのDNSサービスです。ヘルスチェックは、サーバーが元気かどうかを定期的に確認する「見回り」です。異常なら「こっちは使わないで」と切り替えてくれます。
「Route 53で自動フェイルオーバー（切り替え）を設定したのに、切り替わりが遅い！」という誤解がとても多いです。
実は切り替え時間は、次の3つの合計になります。
| 時間の内訳 | ざっくり言うと | 目安 |
|---|---|---|
| 異常検知の時間 | 見回りが「これは異常だ」と確信するまで | 標準: 30秒 × 3回 = 約90秒（高速: 10秒 × 3回 = 約30秒） |
| DNS反映の時間（TTL） | 電話帳のキャッシュが切れて新住所に更新されるまで | TTLが60秒なら最大60秒 |
| 再接続の時間 | アプリ側が古い接続を捨てて繋ぎ直すまで | アプリの作りしだい |
出典:
それぞれの参照元配下
- ヘルスチェックの間隔（10秒／30秒）はAmazon Route 53 でヘルスチェックの正常性を判断する方法
- フェイルオーバー時のTTL推奨（60秒以下）はフェイルオーバーレコードに固有の値
用語メモ：TTL とは？
Time To Live の略で、「DNSの答え（住所）を、どれくらいの間キャッシュ（一時保存）してよいか」の秒数です。TTLが60秒なら、一度住所を調べた人は60秒間は古い住所を使い続けます。
要するに、Route 53のDNS切り替えは「ボタンを押したら秒で切り替わる」ものではなく、検知の遅れ + TTL が最短ラインになります。
もっと速く切り替えたい場合は、ARC（AWS Application Recovery Controller）の「ルーティングコントロール」という仕組みを併用します。
これはTTLの影響を受けず、しかも先ほどの「データプレーン操作」なので、大規模障害時にも動きやすいという利点があります（ルーティングコントロールのデータプレーンが高可用である点はARC のデータプレーンとコントロールプレーンを参照）。
簡略化した流れです。
障害が起きたとき「どこまで壊れたか」を見分ける
災害対応で怖いのが過剰反応です。
実は「棟が1つ壊れただけ（AZ障害）」なのに、あわてて「街ごと引っ越す（クロスリージョン切り替え）」をやってしまうと、かえって手間もリスクも増えます。
そこで、2つの数字を組み合わせて「AZ障害」か「リージョン障害」かを見分けます。
用語メモ：メトリクス とは？
AWSが自動で記録してくれる「監視の数値」です。
CloudWatchという画面で確認できます。
ここでは名前を覚える必要はなく、「こういう数字で状況を見分けるんだな」と眺めるだけでOKです。
| 見る数字 | 何を表す？ | 見分けのヒント |
|---|---|---|
HealthyHostCount（ALBの正常なサーバー数） |
元気なサーバーが何台あるか | 0より多いなら一部だけ生存 = AZ障害の可能性 |
HealthCheckStatus（Route 53の判定） |
エンドポイントが正常(1)か異常(0)か | 全部異常(0)が続く = リージョン障害の疑い |
考え方をやさしくした図です。
いざという時の切り替え：Aurora のフェイルオーバー
データベースに Aurora Global Database を使っている場合、災害時は「控えのDB（セカンダリ）を本番（プライマリ）に昇格させる」操作をします。
用語メモ：フェイルオーバー / Switchover とは？
フェイルオーバー = 障害時に、控えを本番に切り替えること。Switchover（スイッチオーバー） = 障害ではなく計画的に（メンテナンスなどで）切り替えること。計画的なので、データを1件も失わずに切り替えられます（Switchover は RPO=0、計画外の Failover は数秒程度の非ゼロ RPO になり得ることは予期しない停止からの Amazon Aurora Global Database の復旧を参照）。
ここで初級者がハマりやすい罠を1つだけ紹介します。
フェイルオーバーが完了しても、アプリが自動で新しいDBに繋がるとは限らない
なぜかというと、アプリが「古いDBへの接続」を握ったまま離さないことがあるからです。
設定やコードは「こういうものがある」と眺めるだけでOK
初級のうちは、細部を理解しようとしなくて大丈夫です。
「本番リージョンと控えリージョンに、同じような構成をあらかじめ用意しておくんだな」という全体像だけつかめれば十分です。
本番リージョン (東京)
├─ アプリ (本番規模で稼働)
├─ Aurora (グローバルDB プライマリ)
└─ Route 53 (Primary)
控えリージョン (シンガポール)
├─ アプリ (待機: 台数ゼロで用意だけ)
├─ Aurora (グローバルDB セカンダリ)
└─ Route 53 (Secondary)
セキュリティ上の注意
検証で「わざと障害を起こす」ときは、セキュリティグループ（通信のファイアウォール）で必要な通信だけを遮断 して確認します。テストのために不要なポートを広く開けっぱなしにするようなことはしないでください。
よくある誤解（初級者がとくに間違えやすいもの）
ここでは特に大事な3つだけ紹介します。
誤解1：「Multi-AZ にしてあるからDRは完璧」
Multi-AZは「同じ街の中で棟を分ける」高可用性の仕組みで、街全体が止まる災害には無力です。
DRには「別の街（リージョン）」へのコピーと切り替え経路が必要です。
誤解2：「S3のクロスリージョンコピーは一瞬で終わる」
用語メモ：S3 CRR とは？
S3（AWSのファイル置き場）のファイルを、別リージョンのS3へ自動でコピーする機能（Cross-Region Replication）です。
CRRは「できるだけ速くコピーする」けれど一瞬ではなく、少し遅れます（非同期コピー）。時間の保証がほしいときは S3 RTC を有効にします。RTCでも「99.9%のオブジェクトを15分以内」であって即時ではありません（転送レートの既定クォータは 1 Gbps）。
誤解3：「Aurora Global DBなら1件もデータを失わない（RPO=0）」
通常のコピー遅れは1秒未満ですが、災害時の突然の切り替えでは、その遅れ分のデータが失われることがあります（RPO > 0）。1件も失いたくないなら、計画的な Switchover を使います。
まとめ
| # | ポイント | 内容 |
|---|---|---|
| 1 | Multi-AZ はDRではない | 同じ街の棟分けなので、街ごと止まる災害には別の街（リージョン）が必要 |
| 2 | RTOとRPOで方式を選ぶ | 「どれだけ速く戻すか」「どれだけデータを失ってよいか」の2軸。短い（少ない）ほど高コスト |
| 3 | 4パターンは"控えの本気度" | Backup & Restore（安い・遅い）〜 Multi-Site（高い・最速） |
| 4 | DNS切り替えは即時ではない | 検知の遅れ + TTL が最短ライン。秒単位で速くしたいなら ARC を併用 |
| 5 | 切り替えは"用意済みのもの"で | 大災害では新規作成（コントロールプレーン）が効かないことがあるので、既存リソースへの切り替え（データプレーン）中心に設計する |
もっと深く知りたくなったら
以下の記事を参照ください。