AWS災害復旧（DR）設計入門 RPO・RTOの基礎からマルチリージョン構成まで オンプレ経験者のための実践ガイド

「本番障害が起きたとき、どのくらいで復旧できますか？」——この質問にすぐ答えられないエンジニアは多い。オンプレミスの現場では、DR（Disaster Recovery）といえば別データセンターへのテープバックアップ、あるいは高額な専用線を引いたホットスタンバイが定番だった。費用も時間も膨大にかかるため、「DR対策は大企業だけのもの」という空気さえあった。

AWSではその常識が変わる。マルチリージョン構成もパイロットライト運用も、必要なときだけリソースを起動できる従量課金の恩恵で、中小規模のシステムでも現実的に実装できる。ただし、RPO・RTOという設計指標を正しく理解していないと、コストばかりかかって目標通りに復旧できない失敗に陥りがちだ。

この記事では、RPO・RTOの定義から始まり、AWSが提供するDR戦略の4パターン、マルチリージョン構成の実装手順、そして実務でのコスト試算まで、オンプレ経験者が「あのときの感覚」と紐付けながら理解できるよう解説する。

なぜDR設計がクラウド移行で重要なのか？（オンプレとの違い）

オンプレミスのDR設計では、物理インフラの準備が最大のボトルネックだった。予備機を調達して、ラッキングして、OSを入れて、アプリをデプロイして——復旧まで数日かかることも珍しくなかった。それゆえ「どうせ時間がかかるなら、まずバックアップだけ押さえておく」という割り切りもあった。

AWSでは前提が違う。インフラはAPIで即座に起動でき、AMI（Amazon Machine Image）やスナップショットから数分でサーバーを復元できる。問題は技術的な制約ではなく、「どこまでの停止時間・データ損失を許容するか」という設計上の意思決定にある。

この意思決定を数値化したのがRPOとRTOだ。

・RPO（Recovery Point Objective）: 障害発生時に「どの時点まで戻ることを許容するか」。例：RPO=1時間なら、最悪1時間分のデータ損失まで許容する
・RTO（Recovery Time Objective）: 障害発生から「何時間以内にサービスを再開しなければならないか」。例：RTO=4時間なら、4時間以内に復旧する必要がある

オンプレ時代は「とにかく早く復旧したい」という感覚論で動いていたケースも多いが、AWSの世界ではRPOとRTOを先に決め、それに見合った構成とコストを選ぶ設計アプローチが標準になっている。

AWSのDR戦略4パターン

AWSは公式ドキュメントで4つのDR戦略を定義している。RTOとRPOが小さいほど（＝高可用性）コストが上がる構造だ。

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

最もシンプルで安価な方法。定期的にデータをバックアップし、障害時にリストアして起動する。

・RTO目安: 数時間〜1日
・RPO目安: バックアップ間隔に依存（1時間〜1日）
・向いているケース: 停止が数時間許容される非クリティカルシステム

オンプレのテープバックアップに近い感覚だが、AWSではAmazon S3への自動バックアップ、AWS Backupによる一元管理が使える点が大きく異なる。

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

最小限のコアコンポーネント（データベースなど）だけをDRリージョンで常時稼働させ、障害時にアプリサーバーなどを起動して拡張する方式。

・RTO目安: 数十分〜数時間
・RPO目安: 数分〜数十分
・向いているケース: コストを抑えながら数時間以内のRTOを目指す場合

名前の由来は「パイロットランプ（種火）」。常に小さな火を灯しておき、必要なときに大きく燃え上がらせるイメージだ。

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

DRリージョンで本番より小さいスペックのシステムを常時稼働させ、障害時にスケールアップして本番トラフィックを引き受ける。

・RTO目安: 数分〜数十分
・RPO目安: 数秒〜数分
・向いているケース: 短時間での切り替えが求められるが、ホットスタンバイほどコストをかけられない場合

4. マルチサイトアクティブ/アクティブ（Multi-Site Active/Active）

複数リージョンで本番環境を同時稼働させ、障害が発生しても他のリージョンが全トラフィックを引き受ける。RTOはほぼゼロ。

・RTO目安: 秒〜数秒
・RPO目安: ほぼゼロ
・向いているケース: 金融・EC・医療など、ダウンタイムが許容できないクリティカルシステム

パイロットライト構成の実装手順（AWS CLIで確認）

ここではパイロットライト構成を題材に、具体的な実装の流れをAWS CLIのコマンドと合わせて解説する。東京リージョン（ap-northeast-1）をプライマリ、大阪リージョン（ap-northeast-3）をDRとする構成を想定している。

1. データベースのクロスリージョンレプリカを作成する

Amazon RDSのリードレプリカをDRリージョンに作成し、データ同期を常時維持する。

# プライマリリージョン（東京）のRDSインスタンスARNを確認
aws rds describe-db-instances   --region ap-northeast-1   --query "DBInstances[*].{ID:DBInstanceIdentifier,ARN:DBInstanceArn}"   --output table

# DRリージョン（大阪）にクロスリージョンリードレプリカを作成
aws rds create-db-instance-read-replica   --db-instance-identifier mydb-dr-replica   --source-db-instance-identifier arn:aws:rds:ap-northeast-1:123456789012:db:mydb-primary   --region ap-northeast-3   --db-instance-class db.t3.small   --availability-zone ap-northeast-3a

2. AMIをDRリージョンにコピーする

アプリサーバーのAMIをDRリージョンにコピーしておく。障害時はこのAMIからEC2インスタンスを素早く起動できる。

# プライマリリージョンのAMI IDを確認
aws ec2 describe-images   --owners self   --region ap-northeast-1   --query "Images[*].{ID:ImageId,Name:Name}"   --output table

# AMIをDRリージョン（大阪）へコピー
aws ec2 copy-image   --source-image-id ami-0123456789abcdef0   --source-region ap-northeast-1   --region ap-northeast-3   --name "myapp-dr-ami-$(date +%Y%m%d)"

3. DRリージョンにVPC・サブネットを事前作成する

障害発生後に慌ててネットワーク設計をしていては復旧時間が伸びる。VPC・サブネット・セキュリティグループはあらかじめ作成しておく。AWS CloudFormationを使うとプライマリと同一の構成を再現しやすい。

# CloudFormationスタックをDRリージョンにデプロイ（ネットワーク層のみ）
aws cloudformation deploy   --template-file network-stack.yaml   --stack-name myapp-network-dr   --region ap-northeast-3   --parameter-overrides Environment=dr VpcCidr=10.1.0.0/16

4. Route 53フェイルオーバールーティングを設定する

Amazon Route 53のヘルスチェックとフェイルオーバールーティングを組み合わせると、プライマリの障害を自動検知してDRへトラフィックを切り替えられる。

# Route 53ヘルスチェックの作成（プライマリエンドポイント監視）
aws route53 create-health-check   --caller-reference "hc-$(date +%s)"   --health-check-config '{
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# フェイルオーバーレコードの確認（マネジメントコンソールでの設定を推奨）
aws route53 list-resource-record-sets   --hosted-zone-id Z1234567890ABC   --query "ResourceRecordSets[?Failover!=null]"   --output table

料金の仕組み（コスト感覚）

DR構成でもっとも気になるのがコストだ。パイロットライト構成を例に、執筆時点（2025年）の料金感覚を示す。なお、AWSの料金は変動するため、実際の設計時はAWS Pricing Calculatorで最新値を確認してほしい。

・Amazon RDSリードレプリカ（db.t3.small、大阪リージョン）: 約$0.044/時間 → 月額約$32（USD）
・AMIストレージ（EBSスナップショット、100GB）: 約$0.05/GB/月 → 月額約$5（USD）
・Route 53ヘルスチェック: 約$0.50/ヘルスチェック/月（USD）
・障害時のEC2起動費用: 復旧期間のみ課金（通常運用中は0円）

上記の例では月額4,000〜5,000円程度（USD換算、為替レートにより変動）でパイロットライト構成が維持できる計算になる。オンプレのDRサイトを別データセンターに構えていたころと比べると、桁が違うコスト感だ。

ただし、マルチサイトアクティブ/アクティブ構成になると本番環境を2リージョンで動かすことになり、コストはほぼ2倍になる。RTOの目標値と予算のバランスをとることが重要だ。

応用・実務Tips

DR設計を現場で運用するうえで、知っておきたいポイントをまとめる。

・DR訓練を定期実施する: 構成を作っても、実際にフェイルオーバーテストをしていないと本番障害時に想定外の問題が出る。AWSではDRリージョンを本番から完全に切り離した状態でテストできるため、年1〜2回の訓練を強く推奨する
・AWS Elastic Disaster Recoveryを検討する: AWS Elastic Disaster Recovery（DRS）サービスを使うと、オンプレミスやEC2の継続的レプリケーションと自動フェイルオーバーを一元管理できる。自前でレプリケーション機構を組むより運用負荷が低い
・データベースはAmazon Auroraグローバルデータベースが強力: Auroraのグローバルデータベースはリージョン間のレプリカ遅延が1秒未満、フェイルオーバーは通常1分以内。RPO/RTO要件が厳しい場合の第一候補になる
・DNS TTLを短く設定しておく: Route 53のフェイルオーバー切り替えはTTLの時間だけ遅延する。DR用レコードのTTLは60秒以下に設定しておくと切り替えが速くなる
・インフラをコードで管理する: AWS CloudFormationやTerraformでインフラをコード化しておくと、DRリージョンへの展開がコマンド一発で完了する。手動構築では「本番と設定が微妙に違う」という問題が起きやすい

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。オンプレのサーバー運用スキルをクラウドに活かしたい方はあわせて参照してください。

よくあるトラブルと対処法

DR設計で現場がはまりやすい落とし穴と対策をまとめる。

・フェイルオーバー後にデータが1時間前の状態だった: バックアップ間隔とRPO目標が合っていないケース。RPO=15分ならAWS Backupのスケジュールも15分以内に設定する必要がある。RPO目標を先に決め、バックアップ設定をそれに合わせる順序が重要
・DR起動後にアプリの設定が本番と違う: AMIをコピーしたが、環境変数やシークレット（AWS Secrets Manager）の参照先がプライマリリージョン固定になっていたケース。設定値をハードコードせず、AWS Systems Manager Parameter Storeからリージョン自動解決で取得する設計にする
・Route 53の切り替えが遅い: ヘルスチェックの失敗閾値（FailureThreshold）が大きすぎる設定の場合。デフォルトは3回失敗で検知。1回失敗→30秒間隔の設定でも最短90秒かかるため、RTOが数十秒単位のシステムではApplication Load Balancerのヘルスチェックとの組み合わせも検討する
・テストで成功したのに本番障害では失敗した: テスト時はDNSキャッシュをクリアしていたが、本番ではクライアント側のTTLキャッシュが残っていたケース。DR訓練時もクライアント側のDNS挙動を含めて検証することが重要

本記事のまとめ

AWS DR設計の要点を整理する。

オンプレ時代のDRは「お金と時間がかかる大工事」だったが、AWSではRPO/RTOの目標を設定して構成を選べば、中小規模のシステムでも現実的に実装できる。まずはバックアップ＆リストアから始め、業務の重要度に応じてパイロットライト、ウォームスタンバイへとステップアップしていくアプローチが現場では無理がない。