Disaster Recovery復習メモ ― Security Specialty向け

RPOとは（Recovery Point Objective）

どれくらい過去に戻れるか”の目安。災害直前の最新データからどこまで古くても許せるか、という「データの許容損失時間」を表します（例：RPO=15分なら、最悪15分分のデータは失う想定）。AWSの公式ホワイトペーパーでも、RPOは“DRサイト上のデータと最新データの最大許容の差”として説明されています。

RTO（RTO: Recovery Time Objective）

どれくらい“早く戻すか”の目安。サービス停止から復旧までの最大許容ダウンタイム（例：RTO=1時間なら、1時間以内に業務を再開したい）。こちらもAWS資料で“中断から復旧までの最大許容遅延”と定義されています。

DRパターンの基本（コスト↔復旧性のトレードオフ）

Backup & Restore（バックアップ＆リストア）

いちばんシンプル。 通常時は本番のみ。障害時にバックアップから環境・データをリストアして立ち上げ直します。

• 目安：RPO中～長 / RTO中～長（時間～日）。
• 使うものの例：AWS Backup, Amazon S3/Glacier, IaC（CloudFormation, CDK）で環境再構築、テーブル系ならポイントインタイムリカバリ（RDS/DynamoDB）など。
• 向き：コスト最優先、停止許容が大きめのワークロード。

コールドスタンバイ

最小限の資源だけ“冷やして”置く。 代替リージョン/アカウントにAMI/スナップショット・テンプレートなどを用意。障害時に必要な台数を起動・スケール。

• 目安：RPO中 / RTO中（数時間想定）。
• 向き：復旧時間は欲しいが、普段の固定費は抑えたい。

パイロットライト（Pilot Light）

“火種”だけ常時稼働。 コアDBや最小構成だけは動かし続け、障害時に周辺を一気にスケールアウト。

• 目安：RPO短～中 / RTO短～中。
• 向き：DBの起動時間やデータ同期の不確実性を減らしたい。AWSのDR設計でもよく登場する現実解。 AWS ドキュメント

ウォームスタンバイ（Warm Standby）

“細め”に常時待機。 本番の縮小版をDR側で常時提供しておき、障害時にスケールアップ＆ルーティング切替。

• 目安：RPO短 / RTO短（分～短時間）。
• 向き：重要システム。コストは上がるが復旧は速い。

ホットスタンバイ（Hot Standby / マルチサイト・アクティブ/アクティブ）

“いつでも本番”。 複数サイトで同時稼働し、ヘルス次第で即時フェイルオーバー。

• 目安：RPO最短 / RTO最短（秒～分）。
• 向き：停められないワークロード。コスト・複雑性は最大。Route 53、グローバルアクセラレータ、マルチAZ/マルチリージョンDB、キューやイベントの冪等設計などがカギ。

AWS Backupの概要（手を動かす系の要点だけ）

“バックアップ運用の共通部分をまとめてお任せ”できるフルマネージドサービス。ポリシーで各リソースのバックアップ頻度・保持を集中管理できます。
主なポイント：

• バックアッププランとバックアップボールトで、スケジュール・保持・保存先を一括管理。Organizations連携でアカウント横断ポリシーも。
• 対応サービスが広い（EBS/EC2, RDS/Aurora, DynamoDB, EFS, FSx, S3 など）。＊最新の対応・地域はドキュメントで要確認。
• ライフサイクルで低コスト階層へ自動移行、クロスアカウント/クロスリージョンコピーでDR耐性を上げやすい。
• Vault Lock（WORM）で“消せない/改ざんできない”バックアップ（ランサム対策）。監査・コンプライアンス観点で強い。
• 復元テストの自動化も設計に入れると◎（“取れてる”と“戻せる”は別物）。IaCと合わせて定期リストア演習を回すのが実務の安定運用。

ちょい実務Tip：

• まずRPO/RTOの“数字”を合意 → それに合わせてDR方式を選択 → AWS Backupのポリシーで頻度・保持・コピー先をセット → 定期復元演習で検証、の順がスムーズ。
• データとアプリは別物。スナップショットだけでなく、アプリの再構築（IaC）や依存関係（IAM/シークレット/ネットワーク）まで“戻せる”計画を。