災害対策（DR の 4 方式 / AWS Backup）
災害対策（DR: Disaster Recovery）は、リージョン全体が使えなくなるような大きな障害から、システムとデータを取り戻すための備えです。SAA では「RPO と RTO の要件を満たし、しかも最もコストの低い方式はどれか」という形で、4 つの DR 方式の選び分けがよく出ます。バックアップをまとめて管理する AWS Backup もあわせて押さえます。
ひとことで言うと: 「どこまでのデータを失ってよいか（RPO）」と「どれくらいで復旧すべきか（RTO）」が厳しいほど、別リージョンに多くの設備を動かしておく必要があり、コストが上がります。
たとえるなら、バックアップと復元は「家が焼けたら保管庫の写真から建て直す」、パイロットライトは「ガスの種火だけつけておく」、ウォームスタンバイは「小さな別宅をいつでも住める状態にしておく」、マルチサイトは「最初から 2 軒で同時に暮らす」です。
このページで押さえる論点
RPO と RTO
DR の方式は、次の 2 つの目標値で選びます。どちらも「0 に近いほど厳しい要件」です。
| 指標 | 意味 | 決め手になるもの |
|---|---|---|
| RPO（Recovery Point Objective: 目標復旧時点） | 障害が起きたとき、どの時点までのデータを取り戻せればよいか。「最大で何分ぶんのデータを失ってよいか」とも言える | データをどれくらいの頻度でコピーしているか（バックアップの間隔、継続的なレプリケーションか） |
| RTO（Recovery Time Objective: 目標復旧時間） | 障害が起きてから、どれくらいの時間でサービスを再開できればよいか | 復旧先でどれだけの設備が動いているか（ゼロから作るか、すでに動いているか） |
たとえば「毎晩 0 時にバックアップを取る」構成で、夕方 18 時に障害が起きると、0 時から 18 時までの 18 時間ぶんのデータを失います。このとき RPO は「最大 24 時間」です。RPO を小さくしたければ、バックアップの間隔を短くするか、データを継続的に別リージョンへコピー（レプリケーション）します。
一方 RTO は、復旧先の準備の度合いで決まります。何もない状態からサーバーやネットワークを作ってデータを復元するなら時間がかかり、すでに同じ環境が動いていれば、利用者の行き先を切り替えるだけで済みます。
DR の 4 方式の比較
AWS のホワイトペーパー「AWS でのワークロードのディザスタリカバリ」では、DR の方式を次の 4 つに分けています。下にいくほど RPO・RTO は小さく（速く・失うデータが少なく）なり、その分コストと複雑さが増えます。
| 方式 | 復旧先（DR リージョン）の状態 | RPO・RTO の目安 | コスト |
|---|---|---|---|
| バックアップと復元 | バックアップ（データ・AMI など）だけを置く。障害時にインフラを作り直し、データを復元する | 時間単位 | 最も低い |
| パイロットライト | データベースなどデータを持つ部分は常に動かし、データを継続的にコピーしておく。アプリのサーバーは「オフ」（未起動・未作成）で、障害時に起動して台数を増やす | 数十分 | 低い |
| ウォームスタンバイ | 本番と同じ構成を縮小した規模で常に動かしておく。すぐに（少ない容量で）リクエストを処理でき、障害時は台数を増やす（スケールアップ）だけ | 数分 | 高い |
| マルチサイト（アクティブ/アクティブ） | 複数のリージョンで本番と同じ規模の環境を動かし、すべてのリージョンで利用者のリクエストを処理する | ほぼゼロ | 最も高い |
RPO・RTO の目安は、ホワイトペーパーの図に示された大まかな目安です。実際の値は、使うサービスや作り込みによって変わります。
いちばん紛らわしいのがパイロットライトとウォームスタンバイの違いです。どちらも DR リージョンにデータのコピーと環境の一部を持ちますが、パイロットライトは追加の操作（サーバーを起動する・作る）をしないとリクエストを処理できないのに対し、ウォームスタンバイは小さい規模ながら今すぐ処理できる点が違います。問題文に「縮小版の環境が常に稼働している」「完全に機能するコピー」とあればウォームスタンバイ、「コアとなる部分（データベース）だけを稼働」とあればパイロットライトです。
マルチサイトの仲間にホットスタンバイもあります。本番と同じ規模の環境を 2 つ目のリージョンに用意しますが、ふだんは 1 つのリージョンだけでリクエストを受け、もう一方は DR 専用にするアクティブ/パッシブの構成です。
なお、マルチサイトでも、データの破損や誤削除はレプリケーションでそのままコピーされてしまいます。どの方式でも、ある時点の状態に戻せるポイントインタイムのバックアップは別に必要です。
要件から方式を選ぶ
試験の問題は、たいてい「RPO と RTO の要件を満たしつつ、最もコスト効率の良い方式はどれか」という形です。考え方は次の 2 段階です。
- RPO と RTO のうち、厳しい方の要件を満たせる方式まで絞る（上の表で下の方式ほど厳しい要件を満たせる）。
- 満たせる方式のうち、最もコストの低い方式を選ぶ。要件を大きく上回る方式は、コストの面で不正解になる。
下のシミュレーターで、要件を変えると選ぶべき方式がどう変わるかを確かめてみましょう。
RPO・RTO の要件から DR 方式を選ぶ
RTO と RPO の要件を選んでください。要件を満たす方式に ✓、満たさない方式に ✕ が付き、最もコストの低い方式が「選ぶ」と表示されます。
※簡略化しています: RPO・RTO の目安は AWS ホワイトペーパーの図にある大まかな値で、方式の境目は実際にはきっちり分かれていません。方式の中でも、使うサービス（例: Aurora Global Database か、スナップショットのコピーか）によって RPO・RTO は変わります。コストは相対的な順番だけを示しています。
方式を支える AWS のサービス
DR は、「データを別リージョンへ運ぶ」「環境をすばやく作る」「利用者の行き先を切り替える」の 3 つの部品の組み合わせです。
| 部品 | 主なサービス・機能 | 主に使う方式 |
|---|---|---|
| 定期的なバックアップ（ある時点のコピー） | EBS スナップショット、RDS・Aurora のスナップショット、DynamoDB のバックアップ、AWS Backup（別リージョン・別アカウントへのコピー）、AMI のコピー | すべて（バックアップと復元では中心） |
| 継続的なレプリケーション（非同期コピー） | S3 のクロスリージョンレプリケーション、RDS のクロスリージョンリードレプリカ、Aurora Global Database、DynamoDB グローバルテーブル | パイロットライト以上 |
| 環境をすばやく作る | AWS CloudFormation などの IaC（Infrastructure as Code: インフラをコードで定義して自動で作る方法）、EC2 Auto Scaling で台数を増やす | すべて（パイロットライト・ウォームスタンバイでは台数を増やすのに Auto Scaling） |
| 利用者の行き先を切り替える | Route 53 のヘルスチェックとフェイルオーバールーティング、AWS Global Accelerator | パイロットライト以上 |
パイロットライトで RDS のクロスリージョンリードレプリカを使う場合、障害時にはリードレプリカを昇格させて書き込みできるようにします（数分かかり、再起動を伴います）。Aurora Global Database なら、リージョン全体の障害でもセカンダリリージョンを 1 分未満で読み書き可能にできます。詳しくは RDS と Aurora のページ、切り替えの仕組みは Route 53 のページを参照してください。
ホワイトペーパーでは、切り替えの操作にはデータプレーン（実際にサービスを提供する部分）の機能を使うことを勧めています。設定を変えるコントロールプレーンの操作より可用性の目標が高いためです。Route 53 のヘルスチェックによる DNS フェイルオーバーはデータプレーンの操作です。
AWS Backup
AWS Backup は、EC2・EBS・RDS / Aurora・DynamoDB・EFS・FSx・Storage Gateway など、複数の AWS サービスのバックアップを1 か所でまとめて設定・スケジュール・監視できるサービスです。サービスごとにバックアップの仕組みを作る代わりに、ポリシーで一元管理します。
| 機能 | 内容 |
|---|---|
| バックアッププラン | 「いつ・どれくらいの頻度でバックアップし、どれだけ保持するか」を決めたルールの集まり。タグで対象のリソースを指定できるので、タグを付けるだけで新しいリソースもバックアップ対象になる |
| ライフサイクル | 決めたスケジュールで、バックアップをウォームストレージから安いコールドストレージへ自動で移す |
| バックアップボールト | バックアップを保管する入れ物。バックアップの中身はイミュータブル（誰も変更できない）で、元のリソースから切り離して保護される。リソースベースのアクセスポリシーで権限を制御できる |
| 別リージョン・別アカウントへのコピー | バックアップをプランの一部として自動で別リージョンにコピーできる（DR 用）。別アカウントにコピーすれば、アカウントが乗っ取られた場合の備えにもなる |
| AWS Backup ボールトロック | WORM（Write Once Read Many: 一度書いたら変更できない）モデルで、自分を含む誰もバックアップを削除したり保持期間を変えたりできないようにする |
| AWS Organizations との連携 | バックアップポリシーで、組織内の複数アカウントにまとめてバックアッププランを適用する |
| AWS Backup Audit Manager | バックアップが社内ルールどおりに行われているかをチェックし、日次レポートで証跡を残す |
ボールトロックには 2 つのモードがあり、ランサムウェア対策や法令対応の問題で区別が問われます。
| 項目 | ガバナンスモード | コンプライアンスモード |
|---|---|---|
| ロックの解除・削除 | 十分な IAM 権限があるユーザーならできる | 猶予期間が終わると、ルートユーザーや AWS を含め誰もできない |
| 猶予期間（設定を取り消せる期間） | なし | 必要。最短 3 日（72 時間） |
| 向いている用途 | 誤削除を防ぎつつ、管理者は設定を変えられるようにしたい | 規制で「誰にも削除させない」ことが求められる |
ボールトロックでは、バックアップの最小保持日数と最大保持日数も設定できます。ロックを有効にしたあとに作られるバックアップに適用されます。
問題文のキーワード → 選ぶべき答え
| 問題文の言い回し | 答えと理由 |
|---|---|
| 「RPO・RTO は数時間でよい」「最もコストの低い DR」 | バックアップと復元。バックアップを別リージョンにコピーし、障害時に作り直す |
| 「データベースだけ DR リージョンで常に稼働」「アプリのサーバーは障害時に起動」 | パイロットライト |
| 「縮小版の完全に機能する環境を常に稼働」「障害時はスケールアップするだけ」 | ウォームスタンバイ |
| 「RPO・RTO をほぼゼロに」「複数リージョンで同時にリクエストを処理」 | マルチサイト（アクティブ/アクティブ） |
| 「RTO は数十分、コストは最小限に」 | パイロットライト。ウォームスタンバイでも満たせるが、コストの面で劣る |
| 「複数サービスのバックアップを一元管理」「タグでバックアップ対象を指定」 | AWS Backup のバックアッププラン |
| 「バックアップを別リージョンにも自動で保管」 | AWS Backup のクロスリージョンコピー |
| 「ルートユーザーでもバックアップを削除できないように」「WORM」 | AWS Backup ボールトロック（コンプライアンスモード） |
| 「組織内の全アカウントに同じバックアップ方針を適用」 | AWS Organizations と AWS Backup のバックアップポリシー |
| 「障害時に DNS で DR リージョンへ自動で切り替え」 | Route 53 のフェイルオーバールーティングとヘルスチェック |
引っかけポイント
- 「要件を満たすなら、いちばん速く復旧できるマルチサイトを選ぶ」→ ✕（問題文が「最もコスト効率の良い」を求めている場合）。要件を満たす方式のうち最も安いものを選ぶ
- 「パイロットライトでは、DR リージョンで小さな規模のアプリがすぐリクエストを処理できる」→ ✕。それはウォームスタンバイ。パイロットライトはアプリのサーバーを起動するまで処理できない
- 「マルチ AZ にしたのでリージョン障害にも備えられている」→ ✕。マルチ AZ は同じリージョンの中の備え。リージョン障害には別リージョンへのコピーが必要
- 「レプリケーションしているのでバックアップは不要」→ ✕。誤削除やデータ破損もコピーされてしまう。ある時点に戻せるバックアップが別に必要
- 「ガバナンスモードのボールトロックなら、誰もバックアップを削除できない」→ ✕。十分な権限を持つユーザーは解除できる。誰にも削除させないのはコンプライアンスモード（猶予期間の後）
- 「RPO は復旧にかかる時間のこと」→ ✕。RPO は失ってよいデータの範囲（どの時点まで戻せるか）、復旧にかかる時間は RTO
まとめ: SAA 試験で押さえるポイント
- RPO = どこまでのデータを失ってよいか（コピーの頻度で決まる）。RTO = どれくらいで復旧すべきか（復旧先の準備の度合いで決まる）
- 4 方式はコストの低い順に バックアップと復元 → パイロットライト → ウォームスタンバイ → マルチサイト。RPO・RTO の目安は時間単位 → 数十分 → 数分 → ほぼゼロ
- パイロットライトは「データは常にコピー、アプリはオフ」。ウォームスタンバイは「縮小版がすぐ処理できる状態で稼働」
- 選び方は「厳しい方の要件を満たす方式のうち、最もコストの低いもの」
- レプリケーションしていても、誤削除・破損に備えてポイントインタイムのバックアップは必要
- AWS Backup は複数サービスのバックアップをプランで一元管理。タグで対象指定、ライフサイクルでコールドストレージへ、別リージョン・別アカウントへコピー
- ボールトロックは WORM。コンプライアンスモードは猶予期間（最短 3 日）の後、ルートユーザーも削除できない
確認問題
参考リンク
AWS 公式ドキュメント（外部サイトが開きます）。