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/シークレット/ネットワーク)まで“戻せる”計画を。