セクション 03 · タスク 1.3 · SAP-C02-024
バックアップと復元戦略の設計
バックアップ / スナップショット / AWS Backup / クロスリージョンバックアップ / クロスアカウントバックアップ / 復元 / RTO / RPO
このページのゴール
ビジネスが要求するRTO / RPOと障害範囲から、必要な復旧ポイント・バックアップ配置・管理境界・復元方法を設計できることをゴールにします。
何を復旧する?
↓
どの時点へ戻す?
↓
どの頻度で復旧ポイントを作る?
↓
どこへ保存する?
↓
リージョン / アカウントを分離する?
↓
実際に復元できる?
↓
RTO / RPOを満たす?バックアップが存在すること自体ではなく、必要な時点へ、必要な時間内に、本当に復旧できることが重要です。
1. バックアップは「復旧に使える復旧ポイント」を残す
AWS Backupでは、バックアップまたは復旧ポイントを、ある時点におけるリソースの内容を表すものとして扱います。
Amazon EBS スナップショットやDynamoDB バックアップなど、サービスによって実体は異なりますが、AWS Backupではこれらを復旧ポイントとして統一的に扱います。
アーキテクチャで重要なのは、データコピーがあることではなく、必要な時点の状態へ戻せることです。
現在状態を別場所へ同期しているだけでは、誤削除やデータ破損まで複製される可能性があります。
可用性用のレプリケーション
≠
過去の状態へ戻すバックアップ2. スナップショットはポイントインタイムバックアップの代表例
スナップショットは、リソースをある時点の状態として保持する仕組みです。
例えばAmazon EBS スナップショットは、EBS ボリュームのポイントインタイムコピーです。
最初のスナップショットは完全スナップショットとして作成され、その後は原則として変更・追加されたブロックだけを保存する増分スナップショットになります。
ただし、各スナップショットにはその時点のボリュームを復元するために必要な情報があります。
ボリューム
│
├─ 10:00 スナップショット
├─ 11:00 スナップショット
└─ 12:00 スナップショット
↓
必要な時点から
新しいボリュームを復元「増分だから最後の差分だけしか復元できない」とは考えません。
また、スナップショットという名称や挙動はサービスごとに異なります。すべてのAWS BackupがEBS スナップショットと同じ仕組みであるとは考えません。
3. RPOから復旧ポイントの作成間隔を決める
RPOが短いほど、より新しい復旧ポイントを残せる仕組みが必要です。
例えばRPO 24時間なら日次バックアップで満たせる可能性があります。一方、RPO 15分なのに1日1回バックアップでは要件を満たせません。
許容データ損失
↓
RPO
↓
バックアップ頻度
または
継続的バックアップ / PITRAWS Backupでは、バックアップ計画による定期バックアップに加え、対応リソースでは継続的バックアップによるポイントインタイム復旧も利用できます。
ただしサービスごとに対応機能が異なるため、「RPOが短いから、どのリソースでもAWS BackupのPITRを使える」とは判断しません。
4. RTOは「バックアップ取得時間」ではなく復元完了までを見る
バックアップが頻繁に作成されていても、復旧に数時間かかれば短いRTOを満たせない場合があります。
障害検知
↓
復旧ポイント選択
↓
必要ならバックアップコピー
↓
リソース復元
↓
設定 / 依存関係復旧
↓
アプリケーション検証
↓
サービス再開したがって、バックアップ成功 = RTO達成ではありません。
AWS Backupの復元テストでは、実際の復旧ポイントを使った定期的な復元テストを自動化し、復元ジョブの完了時間を確認できます。
5. AWS Backupはバックアップ管理を中央化する
リソースごとに個別のバックアップスクリプトやスケジュールを作成すると、EC2、RDS、EFS、アカウントごとに運用が分散します。
AWS Backupは、対応するAWSサービスなどのデータ保護を中央管理・自動化するマネージドサービスです。
バックアップ要件
↓
バックアップ計画
↓
バックアップルール
↓
対象リソース
↓
復旧ポイント
↓
バックアップボールトバックアップ計画には、バックアップ頻度、バックアップウィンドウ、ライフサイクル、コピールールなどを定義できます。
ワークロードごとにRPOや保持期間要件が違うなら、異なるバックアップ計画を使い分けます。
6. AWS Backupは「すべてのサービスを同じ仕組みに変える」サービスではない
AWS Backupはバックアップポリシーや運用を中央化しますが、基盤となるバックアップの仕組みはリソースタイプによって異なります。
AWS Backupとサービスネイティブバックアップの関係はサービスによって異なり、ネイティブバックアップと同じ基盤となるインフラストラクチャを利用する場合と、別のバックアップレイヤーとして動作する場合があります。
したがって、AWS Backup対応だからといって、すべて同じバックアップ機能・コピー機能・復元方法が利用できるとは考えません。
クロスリージョン / クロスアカウント / PITR / 復元テストなどの機能サポートはリソースタイプごとに確認します。
7. クロスリージョンバックアップはリージョン障害への復旧コピー
プライマリリージョンそのものを利用できなくなる障害まで想定するなら、バックアップを同じリージョンだけに置く設計では復旧要件を満たせない可能性があります。
AWS Backupでは、対応リソースについてバックアップを別AWSリージョンへオンデマンドまたはバックアップ計画のコピールールでコピーできます。
プライマリリージョン
東京
復旧ポイント
│
│ クロスリージョンコピー
▼
復旧リージョン
大阪 / シンガポールなどクロスリージョンバックアップの主な決定要因は、リージョン単位の障害や地理的分離要件です。
コンプライアンス上、本番データから一定距離を離してバックアップを保存する要件にも利用できます。
8. クロスアカウントバックアップは管理境界を分離する
リージョンが異なっていても、プライマリデータとバックアップの両方が同じAWSアカウントに存在すると、アカウント内の強い権限を持つ管理者や認証情報侵害の影響を同時に受ける可能性があります。
AWS Backupの標準のクロスアカウントコピーでは、AWS Organizations内の別アカウントへバックアップをコピーできます。
本番アカウント
│
│ クロスアカウントコピー
▼
バックアップアカウントクロスアカウントバックアップの主な決定要因は、管理上の分離 / セキュリティ分離です。
この標準のクロスアカウントコピーやAWS Backupのクロスアカウント管理を利用するアカウントは、同じAWS Organizations組織に属している必要があります。後述する論理エアギャップボールトのAWS RAM共有は別の仕組みです。
9. クロスリージョンとクロスアカウントは解決する障害が違う
| 要件 | 主な選択 | 分離するもの |
|---|---|---|
| リージョン障害から復旧したい | クロスリージョンバックアップ | 場所 / リージョン |
| 本番アカウントの操作や侵害からバックアップを分離したい | クロスアカウントバックアップ | 管理上の境界 |
| リージョン障害とアカウント障害の両方を想定する | リージョンとアカウントの両方を分離する構成を評価 | 場所 + 管理上の境界 |
クロスリージョン ≠ クロスアカウントです。異なる障害ドメインを分離します。
リソースタイプによって利用可能なコピー機能は異なるため、両方必要だからといってすべてのリソースで同じ構成が使えるとは限りません。
10. 標準のクロスアカウント復元は「コピーしてから復元」
標準のバックアップボールトを使うクロスアカウント復元では、アカウント Aの復旧ポイントからアカウント Bへそのまま復元するのではなく、まず復旧ポイントをアカウント Bへコピーします。
アカウント A
復旧ポイント
│
│ コピー
▼
アカウント B
復旧ポイント
│
│ 復元
▼
復旧済みリソースその後、アカウント B側の復旧ポイントからリソースを復元します。
論理エアギャップボールトの共有は別経路
論理エアギャップボールトはAWS Resource Access Manager(AWS RAM)で個別のAWSアカウントへ共有できます。共有先は同じAWS Organizations組織内に限定されず、別の組織のアカウントも指定できます。
共有されたアカウントは、対応するバックアップを共有された論理エアギャップボールトから復元できます。したがって、「別アカウントで復旧する場合は必ず復旧ポイントを先にコピーする」と一般化してはいけません。
クロスアカウントの復旧設計では、標準のクロスアカウントコピーと論理エアギャップボールトの共有を区別し、災害時にどのアカウントから復元するのかまで決めます。
11. 現行仕様:継続的バックアップをコピーしてもPITRがそのまま残るとは限らない
現在 AWS Backupでは、継続的バックアップにクロスリージョンまたはクロスアカウントコピーを行うと、対応リソースではコピー先復旧ポイントは定期スナップショットバックアップになります。
そのコピーにはPITR能力は引き継がれません。
プライマリ
継続的バックアップ / PITR
│
│ コピー
▼
リモート復旧ポイント
≠
必ず同じPITR機能短いRPOが復旧リージョン側でも必要なら、コピー先がどの復旧機能を持つのかまで確認します。
12. 復旧リージョン側のRPOはコピー完了まで含めて確認する
送信元側で短い間隔の復旧ポイントを作成していても、それだけで復旧リージョン側のRPOが同じ値になるとは限りません。
送信元バックアップ頻度
= 15分
≠
復旧リージョン RPO
= 必ず15分クロスリージョン / クロスアカウントコピーには完了までの時間があり、AWS Backupはコピージョブの完了時間についてSLAを提供していません。コピー時間はリソースサイズ、システム負荷、キャパシティなどによって変動します。
リージョン障害時に利用できるのは、宛先側ですでにコピーが完了して利用可能な復旧ポイントです。
送信元側の復旧ポイント作成間隔
+
コピー完了までの遅延
↓
復旧リージョン側の実効RPOへ影響短いRPOが復旧リージョン側でも要件なら、送信元側のバックアップ頻度だけでなく、コピージョブの完了状況と宛先側復旧ポイントの新しさまで監視・検証します。
13. 復元できなければバックアップ戦略は成立していない
バックアップジョブが毎日成功していても、必要な復旧ポイントが選べない、復元権限がない、必要な設定が足りない、リソース作成に時間がかかる、アプリケーションが正常起動しないのであれば、災害復旧としては不十分です。
AWS Backupの復元テストは、復旧ポイントを使って定期的に復元ジョブを実行し、復元できたかと復元に何分かかったかを確認できます。
必要に応じてEventBridgeとLambdaなどを利用し、復元後のアプリケーション検証を追加することもできます。
14. 復元テストの時間とRTO全体は同じとは限らない
復元ジョブが20分で完了したからといって、RTOが自動的に20分になるわけではありません。
障害検知
判断
復元
アプリケーション検証
トラフィック切り替え
サービス再開RTOにはこれら全体が含まれる可能性があります。復元テストで測定した時間は、RTOを構成する重要な一部です。
復元ジョブの所要時間 ≤ 合計復旧時間と考えます。
15. バックアップと復元戦略の設計順序
バックアップ製品を先に選ぶのではなく、次の順で決めます。
ビジネス要件
↓
RTO / RPO
↓
対象データ / リソース
↓
復旧ポイント方式
定期 / 継続的
↓
バックアップ頻度 / 保持
↓
障害範囲
↓
同一リージョン?
クロスリージョン?
↓
管理上の分離
同一アカウント?
クロスアカウント?
↓
復元方法
↓
復元テスト
↓
RTO / RPOを満たせるか確認ここまで決まって初めて、バックアップと復元戦略として成立します。
16. 代表シナリオ
企業は東京リージョンの本番アカウントで注文システムを運用しています。
最大30分分までデータ損失を許容
リージョン障害から復旧可能
本番管理者が
バックアップを誤削除しても復旧可能
4時間以内にサービスを再開
複数AWSサービスのバックアップポリシーを
可能な限り中央管理設計要件へ変換すると、RPOには30分以内の復旧ポイント、リージョン障害にはクロスリージョンバックアップ、本番アカウントからの分離にはクロスアカウントバックアップ、一元管理にはAWS Backup、RTOには復元テストによる実際の復旧時間確認が対応します。
重要なのはAWS Backupを使うことから始めるのではなく、要件 → 障害ドメイン → 復旧目標 → バックアップアーキテクチャの順で判断することです。
17. 混同ポイント
| 混同 | 正しい考え方 |
|---|---|
| レプリケーションがあればバックアップ不要 | レプリケーションと過去時点への復旧は異なる責任 |
| スナップショットはすべて完全コピー | 例えばEBSでは最初が完全、その後は増分 |
| AWS Backupなら全リソースで同じ機能が使える | 機能サポートはリソースタイプごとに異なる |
| クロスリージョン = クロスアカウント | リージョン障害と管理上の障害を分けて考える |
| バックアップ成功 = 復旧可能 | 復元を実行・検証して初めて確認できる |
| バックアップ頻度だけでRTOが決まる | バックアップ頻度は主にRPO、復元プロセスはRTOへ影響 |
| 継続的バックアップのコピーにも必ずPITRが残る | クロスリージョン / クロスアカウントコピーでは定期復旧ポイントになる場合がある |
18. SAP-C02判断フロー
バックアップ / 復元要件
↓
許容データ損失は?
→ RPO
↓
定期 / 継続的
バックアップ頻度
↓
どの障害まで想定?
↓
リージョン障害
→ クロスリージョン
アカウント / 管理者 障害
→ クロスアカウント
↓
復旧ポイントを復元
↓
復元継続時間とアプリケーション復旧を確認
↓
RTOを満たす?
↓
満たせばバックアップと復元戦略成立19. まとめ
バックアップ戦略で判断するのは、バックアップを取るかどうかだけではありません。
RPO
→ どの時点まで戻れる必要があるか
スナップショット / 復旧ポイント
→ 何を復旧元として残すか
AWS Backup
→ どう中央管理・自動化するか
クロスリージョン
→ リージョン障害をどう分離するか
クロスアカウント
→ 管理上の境界をどう分離するか
復元
→ 本当に復旧できるか
RTO
→ 許容時間内にサービスを戻せるかバックアップが存在することではなく、要求された復旧ポイントへ、要求された時間内に復旧できることがアーキテクチャの完成条件です。
20. 主要AWS公式資料
バックアップと復元戦略を確認するための主要なAWS公式資料を以下に示します。
理解確認
このページの内容を11問で確認します。
理解確認11問へ →