RPO / RTO

RPO / RTO とは

RPO (Recovery Point Objective) は「どこまでのデータ損失を許容するか」、RTO (Recovery Time Objective) は「どれだけの時間で復旧するか」を定義する ディザスタリカバリ の目標指標である。

2 つは障害発生時点を挟んで逆方向を向いている。RPO は過去方向に測る量で、単位は時間だが問うているのは失われるデータの範囲である。RTO は未来方向に測る時間で、問うているのはサービスが止まっている長さである。取り違えると「RPO 1 時間」を「1 時間で復旧する」と読んでしまい、必要な仕組みを丸ごと間違える。

もう 1 つ押さえておきたいのは、どちらも目標 (Objective) であって実測値ではないことだ。設計上の理論値を書いただけの RTO は、復旧訓練で実際に計測するまで根拠を持たない。

RPO と RTO

RPO と RTO を図で示す。

                    RPO                    RTO
  ←─────────────────┤─────────────────────→
  最後のバックアップ   障害発生              復旧完了
  ↑ この間のデータは失われる    ↑ この間はサービス停止

指標	測る方向	定義	例
RPO	障害発生時点から過去へ	許容できるデータ損失量	RPO 1 時間 = 最大 1 時間分のデータ損失
RTO	障害発生時点から未来へ	許容できるダウンタイム	RTO 4 時間 = 4 時間以内に復旧

RTO を見積もるときに落としやすいのが、復旧作業そのものより前の時間である。障害の検知、影響範囲の切り分け、切り替えを実行するという判断、関係者への連絡までが RTO の中に入る。手順書の実行時間だけを積み上げた RTO は、実際の停止時間の半分も説明できていないことが多い。

AWS サービスの RPO / RTO

代表的なサービスの目安を示す (2026 年 8 月時点)。

サービス	RPO	RTO
DynamoDB (PITR)	数分 (復旧できる最新時点は現在の 5 分前が目安)	新テーブルへの復元 + 参照切り替えの時間
DynamoDB (グローバルテーブル)	秒単位 (非同期複製の遅延分)	秒〜分 (書き込み先リージョンの切り替え)
RDS Multi-AZ (DB インスタンス)	0 (同期レプリケーション)	60〜120 秒が目安
Aurora	0 (クラスターボリュームは 3 AZ に多重化)	レプリカありで 60 秒未満・多くは 30 秒未満 / レプリカなしは 10 分程度
EBS スナップショット	スナップショット間隔	ボリューム再作成とアタッチの時間

PITR とグローバルテーブルの数字は特に誤解されやすい。PITR は「秒単位で時刻を指定できる」だけで、復旧できる最新の時点は現在より 5 分ほど手前に留まる。さらに復元先は必ず新しいテーブルになるため、元のテーブル名で動いているアプリを戻すには参照の切り替えかリネーム相当の段取りが要る。グローバルテーブルの複製は非同期で、衝突は後書き優先で解決される。強整合モードを選ばない限り RPO は 0 にならない。

S3 のように「11 9's の耐久性」で語られるサービスを RPO 0 と書くのも避けたい。耐久性は保存済みオブジェクトが失われない確率の話で、リージョン障害時に別リージョンから読めるかどうかは複製設定の有無で決まる。耐久性と可用性、そして RPO は別の指標である。

表の値はいずれもサービス単体の性能でもある。アプリ全体の RPO / RTO は最も遅い依存先に律速されるので、データベースだけ秒単位にしても、設定情報の復旧に 2 時間かかるなら全体の RTO は 2 時間側に寄る。

DR 戦略

AWS が整理している 4 段階が出発点になる (2026 年 8 月時点)。上から順に RPO / RTO が短くなり、待機のために払う費用が増える。

戦略	RPO	RTO	コスト	待機側の状態
バックアップ & リストア	時間	時間	最低	何も動いていない
パイロットライト	分	分〜時間	低い	データ複製のみ稼働・処理層は停止
ウォームスタンバイ	秒〜分	分	中程度	縮小構成が常時稼働
マルチサイトアクティブ / アクティブ	秒	秒	最高	両系が本番トラフィックを処理

段階を上げる判断材料はコストだけではない。パイロットライト以上は待機側の構成が本番と乖離していく問題を抱える。バックアップ & リストアなら復旧手順の中で最新の構成が作られるが、常時稼働の待機系は「作った当時のまま」放置されやすい。切り替えた瞬間に古いバージョンが立ち上がる事故は、この乖離が原因である。構成をコードで管理し、待機側にも同じ変更を流す仕組みまで含めて 1 つの戦略と考える。

バックアップ & リストア

バックアップ & リストアを図で示す。

通常時: S3 にバックアップを定期保存
障害時: バックアップから新環境を構築
RPO: バックアップ間隔 (例: 24 時間)
RTO: 環境構築時間 (例: 数時間)

マルチサイトアクティブ

マルチサイトアクティブを図で示す。

Route 53 (レイテンシベースルーティング)
  ├── ap-northeast-1 (東京) ← アクティブ
  └── us-east-1 (バージニア) ← アクティブ

DynamoDB グローバルテーブルで双方向レプリケーション
RPO: 秒 (複製は非同期・衝突は後書き優先)
RTO: 秒 (トラフィックの振り替え)

両系が書き込みを受けるため、切り替えという操作が要らないのがこの戦略の強みである。一方で「どちらの書き込みが残るか」をアプリ側で扱える設計になっていなければ採用できない。同じレコードを両リージョンで同時に更新する処理があるなら、フェイルオーバー 型で書き込み先を 1 つに寄せる構成のほうが安全なこともある。

ビジネス要件との対応

個人ブログなら RPO / RTO ともに 24 時間、バックアップ & リストアで足りる。EC サイトで注文データを扱うなら RPO は分単位に寄せたい。決済や取引の記録では、失った注文を後から復元できないことが直接の損害になるため、書き込みを複数リージョンへ広げる構成まで検討することになる。

決め方の順番を逆にしないことが肝心だ。先に技術を選んでから RPO / RTO を後付けすると、実現できた値がそのまま目標として書かれる。まず「1 時間分の注文が消えたら何が起きるか」を業務側と詰め、そこから逆算して戦略を選ぶ。厳しくするほど費用は増えるので、全システムを一律に扱わず、業務影響の大きい範囲だけ上の段階に置く切り分けが実務的である。

RPO / RTO で最も多い失敗は、値を決めていないことではなく、決めた値を一度も検証しないことである。復旧手順を実際に走らせれば、バックアップの復元だけで RTO を使い切っていた、復旧に必要な認証情報が失われた環境の中にしかなかった、といった事実が出てくる。年に一度でも切り替えを実行し、計測した時間で目標を書き直す。この更新をやめた時点で RPO / RTO は数字が入っただけの書類になる。