変更要約: in-scope サービス網羅: Elastic Disaster Recovery, Resilience Hub, Compute Optimizer, FSx 4種, Aurora Serverless v2, DocumentDB, MemoryDB for Redis, Redshift, EKS Distro, ROSA, DMS, Transit Gateway, PrivateLink, Client VPN, Site-to-Site VPN
3.3バックアップとディザスタリカバリ
データ保護と復旧——AWS Backup、スナップショット、クロスリージョンレプリケーション、DR 戦略（RTO/RPO）——を理解します。障害やデータ消失から確実に復旧します。
回復力にはデータの保護と復旧が不可欠です。AWS Backup で一元的にバックアップし、DR 戦略を RTO/RPO に応じて選びます。
3.3.1バックアップと DR
- AWS Backup：EBS/RDS/DynamoDB/EFS 等をポリシーで一元バックアップ・スケジュール・保持管理。
- クロスリージョンコピー：スナップショットやデータを別リージョンへ複製し地域障害に備える。
- DR 戦略：RTO/RPO に応じ、バックアップ&リストア→パイロットライト→ウォームスタンバイ→マルチサイトから選ぶ。
- 自動化：バックアップ・復旧手順をコード化/自動化して、復旧を確実かつ反復可能にする。
「一元バックアップ＝AWS Backup」「地域障害対策＝クロスリージョンコピー」「DR は RTO/RPO で戦略選択（backup&restore＜pilot light＜warm standby＜multi-site）」 は DOP-C02 で頻出です。DR 手順は自動化し、定期的にリストアをテストするのが要点です。
DOP-C02 では「RTO/RPO の要件を、どの DR 戦略とどの自動化で満たすか」が核心です。RPO（目標復旧時点）はどこまでのデータ損失を許すか、RTO（目標復旧時間）はどれだけ早く復旧するかで、両者が厳しいほどコストの高い戦略になります。バックアップ&リストアは最も安価で RTO/RPO が時間〜日単位、パイロットライトはコアのみ（DB レプリカ等）を別リージョンで常時稼働させ残りは停止待機、ウォームスタンバイは縮小版を常時稼働させて素早く拡張、マルチサイト（アクティブ/アクティブ）は両リージョンで本番処理し RTO/RPO がほぼゼロです。AWS Backup は EBS/RDS/Aurora/DynamoDB/EFS/Storage Gateway 等をバックアッププランで一元管理し、クロスリージョン/クロスアカウントコピー、Backup Vault Lock（WORM）でランサムウェアや誤削除に耐性を持たせます。データ複製は S3 CRR/SRR、Aurora Global Database（< 1 秒の RPO・高速リージョン昇格）、DynamoDB グローバルテーブル（マルチアクティブ）を要件に応じて選びます。DR は手順をコード化（IaC＋SSM Automation／Step Functions）して反復可能にし、Route 53 フェイルオーバーや Application Recovery Controller（ルーティングコントロール）で切替を制御、定期的にリストア演習（ゲームデー）で実効性を検証します。
| DR 戦略 | RTO/RPO | コストと特徴 |
|---|---|---|
| バックアップ&リストア | 時間〜日 | 最も安価・障害時に復元 |
| パイロットライト | 数十分〜時間 | コアのみ常時稼働・残りは停止待機 |
| ウォームスタンバイ | 数分〜数十分 | 縮小版を常時稼働・素早く拡張 |
| マルチサイト（アクティブ/アクティブ） | ほぼゼロ | 最も高コスト・両系で本番処理 |
シナリオ：基幹 DB は「データ損失をほぼ許さず（RPO 数秒）、リージョン障害でも数分で復旧（RTO 数分）」が要件。コストは相応に許容。→ Aurora Global Database で別リージョンへ秒未満の遅延でレプリケーションし、リージョン障害時はセカンダリを昇格。アプリ層はウォームスタンバイで縮小版を常時稼働させ、Route 53／Application Recovery Controllerで切替。手順は SSM Automation/Step Functions に落として演習で検証します。
FAQ：パイロットライトとウォームスタンバイの違いは？ どちらも別リージョンに事前準備しますが、パイロットライトはコア（主に DB レプリカ）だけ常時稼働し、アプリ層は停止/未起動でフェイルオーバー時に起動・スケール。ウォームスタンバイは縮小版のアプリ層まで常時稼働しておき、より短い RTO を得ます。RTO 要件とコストのトレードオフで選びます。
ひっかけ：「バックアップを取っている」だけでは DR は完成しません。リストアを定期的にテストしていないと、いざという時に復元できない/RTO を超過します。また AWS Backup のクロスリージョン/クロスアカウントコピーを設定していないと、リージョン障害やアカウント侵害時にバックアップごと失う恐れがあります。
3.3.2AWS Elastic Disaster Recovery（AWS DRS）
Elastic Disaster Recovery（AWS DRS）は、オンプレミスや他クラウドのサーバーを AWS にブロックレベルで継続レプリケーションし、災害時に短い RTO/RPO でフェイルオーバーするサービスです（旧 CloudEndure Disaster Recovery の後継）。レプリケーションエージェントをソースサーバーにインストールすると、ブロックストレージの差分が継続的にステージングエリアへ転送されます。ステージングエリアでは低コストのステージングインスタンスとストレージだけが常時稼働し、通常運用時のコストを最小化します。障害が発生したらフェイルオーバーを開始（数回のクリックまたは API 呼び出し）するだけで、最新の複製状態から起動準備済みの EC2 インスタンスが起動し、アクセス可能になります。RTO は分単位、RPO は秒単位（直近のレプリケーションポイントまで）を実現します。ポイントインタイム（PITR）で過去の任意の時点に復元することも可能で、ランサムウェア感染前の状態への復元などに使います。フェイルオーバー後、元の環境が復旧したらフェイルバックでオンプレに戻すことも、AWS にそのまま移行（Cutover）することもできます。DevOps 文脈では、従来のウォームスタンバイや大規模スナップショット戦略と比べ「インフラの手動構築なしに継続レプリケーション＋迅速起動」を実現する点が特徴で、主に物理/仮想サーバーや他クラウドの AWS への DR、あるいはマルチリージョン構成を持てないが RTO を短くしたいワークロードに使います。
- 継続レプリケーション：ブロックレベルの差分を常時転送。ステージングエリアは低コストで待機。
- 短い RTO/RPO：フェイルオーバー開始から分単位で起動、RPO は秒単位。
- PITR 復元：過去の任意のポイントに戻せる（ランサムウェア対策などに有効）。
- フェイルバック/カットオーバー：復旧後にオンプレへ戻すか、AWS に移行するかを選べる。
「オンプレサーバーを AWS に継続レプリケーションして分単位で DR」「ブロックレベルレプリケーション＋ステージングで低コスト待機」「CloudEndure DR の後継」＝Elastic Disaster Recovery（AWS DRS） が DOP-C02 での答えです。AWS Backup（スナップショット・RTO 時間単位）と区別：DRS はブロックレプリカで RPO 秒・RTO 分を狙う、より積極的な DR です。
ひっかけ：DRS のステージングエリアは本番起動前の待機状態であり、サービスはまだ稼働していません。フェイルオーバーを「開始」して初めて EC2 が起動します。「常時本番稼働のウォームスタンバイ」とは異なります。また PITR で過去に戻す際は、その時点以降のデータは失われる点も確認が必要です。
3.3.3この節のまとめ
- 保護＝AWS Backup＋クロスリージョンコピー
- DR＝RTO/RPO で戦略選択＋自動化/復旧テスト
- 継続レプリカ DR＝Elastic Disaster Recovery（AWS DRS）（ブロックレベル・RPO 秒・RTO 分）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. EBS・RDS・DynamoDB のバックアップを、共通ポリシーで一元的にスケジュール・保持管理したい。何を使いますか？
Q2. リージョン全体の障害に備え、スナップショットを別リージョンにも保持したい。どうしますか？
Q3. 低コストを優先し、RTO/RPO が数時間でも許容される DR 戦略はどれですか？