AWSのDR設計入門｜バックアップ&リストア・パイロットライトなど4戦略とRTO/RPOの決め方

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWSのDR設計入門｜バックアップ&リストア・パイロットライトなど4戦略とRTO/RPOの決め方
「障害が起きたとき、御社のシステムはどれくらいで復旧できますか？」
この質問に即答できないまま本番環境を動かしているケースは、現場でも決して少なくありません。

この記事では、AWS上でシステムの事業継続性を担保するDR（ディザスタリカバリ）設計の基本を解説します。具体的には、AWSが推奨する4つのDR戦略の違いと、RTO（復旧目標時間）・RPO（復旧目標時点）をもとに最適な戦略を選ぶ判断フローを整理します。
Route 53フェイルオーバーの設定操作やAWS Backupの実装手順は対象外です。「どの設計を選ぶか」の判断軸を身につけることが目的の記事です。
動作確認環境: AWS Well-Architected Framework（信頼性の柱）に基づく設計概念（2026年7月時点）。

この記事のポイント

・RTOは「何時間以内に復旧するか」、RPOは「どこまでのデータを戻せるか」を決める指標
・DR戦略はバックアップ&リストア・パイロットライト・ウォームスタンバイ・マルチサイトの4段階
・RTO/RPO目標が短いほどコストは指数関数的に上昇する
・まずRTO/RPO目標をビジネス側と合意してから戦略を選ぶ順序が正しい


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

RTOとRPOとは何か——DR設計の2つの指標

DR設計を始める前に、「RTO」と「RPO」という2つの目標値を必ず先に定義します。この2つを曖昧にしたまま設計を進めると、「どのくらいのコストをかけるべきか」が決まらず、設計が迷走します。

1. RTO（Recovery Time Objective）——復旧目標時間

RTO（リカバリータイムオブジェクティブ）は「障害発生からサービスが再開できるまでの時間の上限」です。

「RTOは4時間」と定義した場合、障害が起きてから4時間以内にシステムが使える状態に戻らなければSLA違反となります。ユーザーや取引先との契約内容によっては、損害賠償や信頼の失墜に直結します。

2. RPO（Recovery Point Objective）——復旧目標時点

RPO（リカバリーポイントオブジェクティブ）は「システムが復旧したとき、どの時点のデータまで復元できるか」の目標値です。

「RPOは1時間」と定めた場合、直近1時間以内に書き込まれたデータが失われることは許容しますが、1時間以上前のデータは必ず復元できなければなりません。ECサイトの注文データや金融取引のように、「データが失われること自体が事業上許容できない」業種では、RPOを数分以内や0に設定するケースもあります。

3. RTO/RPOはビジネス側が決める数字

重要なのは、RTO/RPOは技術部門が単独で決める数字ではないという点です。「障害で1時間サービスが止まったとき、事業上いくらの損失が発生するか」という観点で、経営層やサービス責任者が設定します。

エンジニアの役割は、その目標値を受け取り「技術的にどのDR戦略なら実現できるか」を判断することです。RTO/RPOを厳しく設定するほどコストは跳ね上がりますが、その判断軸を持っていることがAWSで設計を任されるエンジニアの要件になります。

AWSのDR戦略4パターンを理解する

AWSはWell-Architected Frameworkの「信頼性の柱」で、DR戦略を復旧速度とコストのトレードオフ軸で4段階に整理しています。復旧が遅い（コストが低い）順から、速い（コストが高い）順に並べると次の通りです。


# AWSのDR戦略スペクトラム（コスト低 ←→ コスト高）

[バックアップ&リストア] → [パイロットライト] → [ウォームスタンバイ] → [マルチサイト]
  RTO: 時間単位以上        RTO: 数十分～数時間   RTO: 数分～十数分      RTO: ほぼ0分
  RPO: バックアップ間隔    RPO: 数分以内         RPO: 数秒～数分        RPO: 数秒以内
  コスト: 最低             コスト: 低            コスト: 中             コスト: 最高

1. バックアップ&リストア（Backup and Restore）

最もシンプルかつコストが低いDR戦略です。定期的にデータやシステムイメージをバックアップし、障害時にそこからリストアします。

・通常時の構成：EC2のAMIスナップショット、RDSの自動バックアップ、S3クロスリージョンレプリケーションなどでバックアップデータを定期保管する
・障害時の対応：スナップショットからEC2を復元し、RDSバックアップをリストアしてデータを戻す。作業の多くは手動または半自動になる

典型的な実効値は「RTO: 数時間以上」「RPO: バックアップ間隔（1日1回バックアップなら最大24時間のデータが失われる可能性がある）」です。開発・検証環境や、「数時間の停止は許容できる」社内業務システムに向いています。


# AWS CLIでRDSスナップショットの最新一覧を確認する（リストア前の確認に使う）
$ aws rds describe-db-snapshots \
    --db-instance-identifier mydb \
    --query 'DBSnapshots[*].[DBSnapshotIdentifier,SnapshotCreateTime,Status]' \
    --output table

# 実行例（出力イメージ）
--------------------------------------------------------------------------------
|                          DescribeDBSnapshots                                  |
+------------------------------------------+---------------------------+----------+
|  mydb-snapshot-2026-07-19-03-00          | 2026-07-19T03:00:22.000Z | available |
|  mydb-snapshot-2026-07-18-03-00          | 2026-07-18T03:01:05.000Z | available |
+------------------------------------------+---------------------------+----------+

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

「パイロットライトのように、常に最小限の火種だけを灯しておく」設計です。コアとなるデータ層（DBなど）だけをDRリージョンに常時稼働させておき、障害時にアプリ層を素早く起動して本番トラフィックを引き受けます。

・通常時：RDSのリードレプリカやAurora Global DatabaseのセカンダリクラスタをDRリージョンに常時稼働。アプリサーバー（EC2）はDRリージョンでは停止中か、AMI・起動テンプレートのみ準備した状態にする
・障害時：リードレプリカをプライマリに昇格、EC2を起動してRoute 53のフェイルオーバーレコードを切り替えてトラフィックを流す

典型的な値は「RTO: 数十分～数時間（EC2起動・設定変更の時間）」「RPO: 数分以内（レプリケーションのラグ次第）」です。「データは守りたいが、アプリの再起動を許容できる」用途に有効です。

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

DRリージョンに「縮小版の本番環境」を常時稼働させておく設計です。障害時はその縮小版をスケールアウトするだけで本番トラフィックを引き受けられます。

・通常時：本番がEC2×4台なら、DRリージョンはEC2×1台（最小スペック）で同じアプリを稼働。RDSもDRリージョンにレプリカを常時稼働させておく
・障害時：DRリージョン側のEC2をスケールアウト（4台に増やす）し、Route 53のフェイルオーバーでトラフィックを切り替える

典型的な値は「RTO: 数分～十数分（スケールアウト＋DNS切り替えの時間のみ）」「RPO: 数秒～数分（DBレプリケーションのラグ次第）」です。通常時も「縮小版本番」が動くためパイロットライトより費用がかかりますが、RTOを大幅に短縮できます。

4. マルチサイト（Active-Active）

2つ以上のAWSリージョンで同時に本番環境を完全稼働させ、どちらが障害を起こしても残りがそのままサービスを継続する設計です。

・通常時：両リージョンが同時に本番稼働。Route 53のジオロケーションルーティングや加重ルーティングで複数リージョンにトラフィックを常時分散する
・障害時：片方のリージョンが落ちてもRoute 53ヘルスチェックがそれを検知し、自動でもう一方のリージョンにトラフィックを集中させる。ユーザーにはほぼ無停止に見える

典型的な値は「RTO: ほぼ0分（DNSのTTL分の遅延のみ）」「RPO: 数秒以内（同期レプリケーション使用時はほぼ0）」です。コストは最も高く、「停止が事業上絶対に許容できない」金融・医療・グローバルECサービス向けの設計です。

Route 53フェイルオーバー設定後のDNSレコード動作確認には、dig コマンドで DNS を調べるが参考になります。

RTO/RPO目標からDR戦略を選ぶ判断フロー

実際の選定では、次のステップで進めることを推奨します。

・ステップ1——RTO/RPO目標を確認する：「停止は最大何時間まで許容できるか」「データは何分前まで戻せればよいか」をビジネス側と合意する。SLA・契約書・障害インパクト試算などを根拠にする
・ステップ2——コスト上限を確認する：DRに投じられる月額予算をCFOや事業部門と確認する。RTOを短くするほどコストが上がる相関を説明した上で上限を引き出す
・ステップ3——判断マトリクスで戦略を絞り込む：下記のまとめテーブルをもとに、RTO/RPO目標とコスト感が交差する戦略を選ぶ
・ステップ4——リストア演習を計画する：戦略を決めたら即座にリストア演習の日程を設定する。設計だけで演習しない状態は「DR設計がない」と同じ

RTO目標を軸に絞り込む場合、「数時間以上許容できる → バックアップ&リストア」「1時間以内に収めたい → パイロットライト以上」「数分以内 → ウォームスタンバイ以上」「ほぼ無停止 → マルチサイト一択」という整理が実務上は使いやすいです。

DR設計でよくある落とし穴

1. リストアテストをしていない

バックアップ&リストア戦略を採用していても、「実際にリストアして何時間かかるか」を一度も測定したことがない現場は多くあります。テストしていないDR設計は、有事に機能しません。四半期に1回でもよいので、実際にリストアして目標RTOを達成できるかを確認してください。

2. RPO目標とバックアップ間隔がずれている

「RPOは1時間」と定義したのに、RDSの自動バックアップが「1日1回」に設定されているケースです。ポイントインタイムリカバリ（PITR）の有効化や、バックアップ頻度の設定をRPO目標に合わせて必ず見直してください。

3. DRリージョンのIAM・ネットワーク設定が本番と乖離している

DRリージョンに切り替えたら「IAMロールがなかった」「セキュリティグループが未設定だった」というケースは後を絶ちません。TerraformやAWS CloudFormationでInfrastructure as Code（IaC）化し、本番とDRの構成を常に同期させることが根本的な対策です。

4. データ量増加でRTO目標を満たせなくなっている

500GBのEBSスナップショットから復元するのに実際には40分かかる場合があります。「RTO=30分」と決めていても、リストア時間だけでオーバーすることがあります。データ量が増えるほど復元に時間がかかることを考慮し、定期的にデータ量とRTOの整合性を見直してください。

本記事のまとめ

AWSのDR戦略4パターンとRTO/RPOの選び方をまとめます。

DR戦略 典型的なRTO 典型的なRPO 通常時コスト感 向いているケース
バックアップ&リストア 数時間以上 バックアップ間隔（時間～日単位） 最低 コスト優先・停止許容時間が長い業務系
パイロットライト 数十分～数時間 数分以内 低（DB常時稼働のみ） データは守りたい・アプリ再起動は許容できる
ウォームスタンバイ 数分～十数分 数秒～数分 中（縮小本番を常時稼働） 停止時間短縮優先・中規模の本番環境
マルチサイト（Active-Active） ほぼ0分 ほぼ0 最高（本番×2リージョン以上） 無停止必須・金融・医療・グローバルECサービス

DR設計は「作って終わり」ではなく、「定期的にリストア演習をして有事に機能することを確認し続ける」継続的なプロセスです。まずRTO/RPO目標をビジネス側と合意し、コスト感を照らし合わせて戦略を選定する。その順序を守ることが、現場で機能するDR設計への出発点です。

AWSの冗長設計・マルチAZ構成を体系的に学ぶには下記もご覧ください。
＞＞ AWSの冗長設計・構築を体系的に学ぶ（上級LPはこちら）

＞＞ AWSをはじめて学ぶ方はこちら（入門LP）

AWSのDR設計を「説明できる」エンジニアになることが、現場での信頼につながります

RTOとRPOの違いを理解し、「この要件にはウォームスタンバイが適切です」と即答できるかどうかで、設計を任されるかどうかが変わります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。