AWS ディザスタリカバリ戦略完全ガイド ​

ディザスタリカバリ（DR）は、企業が自然災害、システム障害、サイバー攻撃などの重大な事象から迅速に回復するための戦略です。AWSのグローバルインフラストラクチャと多彩なサービスを活用すると、ビジネス要件に応じた柔軟なDR戦略を構築することができます。

この記事では、AWSにおけるディザスタリカバリの基本概念から実装パターンまで、初学者にも理解しやすい形で包括的に解説します。RTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧ポイント）の概念を理解し、実際のビジネス要件に合わせた最適な戦略選択ができるようになります。

ディザスタリカバリの基本概念 ​

RTO と RPO の理解 ​

ディザスタリカバリ戦略を設計する際は、まず2つの重要な指標を理解する必要があります。

**RTO（Recovery Time Objective：目標復旧時間）**とは、災害発生からシステムが復旧するまでの目標時間です。例えば、ECサイトが停止した場合、どのくらいの時間で復旧させる必要があるかを定義します。RTOが短いほど高い可用性が求められ、そのぶんコストも増加します。

**RPO（Recovery Point Objective：目標復旧ポイント）**とは、災害発生時に許容可能なデータ損失の時間です。1時間のRPOであれば、最大1時間分のデータ損失までは許容するという意味になります。RPOが短いほど頻繁なバックアップや同期が必要になります。

AWS DR戦略の4つのパターン ​

AWSでは、コストと可用性のバランスを考慮した4つのDR戦略パターンを提供しています。

戦略パターンRTORPO月額コスト目安適用場面
バックアップ＆リストア数時間〜数日数時間〜1日最低（本番の5-10%）開発環境、重要度の低いシステム
パイロットライト数十分〜数時間数分〜数時間低（本番の10-20%）重要システム、限定的ダウンタイム許容
ウォームスタンバイ数分〜数十分秒〜数分中（本番の30-50%）ミッションクリティカルシステム
マルチサイトアクティブ/アクティブ即座〜数分ほぼゼロ〜秒最高（本番の200-300%）最重要システム、ダウンタイム不許可

ビジネス影響分析とDR戦略の選択 ​

適切なDR戦略を選択するには、まずビジネス影響分析（BIA：Business Impact Analysis）を実施します。

システム停止による影響の評価

  • 1時間停止した場合の損失額
  • 顧客への影響度
  • 法的・規制要件への準拠
  • 社会的信用への影響

重要度による分類

  • クリティカル: 30分以内の復旧が必要（金融取引システムなど）
  • 重要: 2-4時間以内の復旧が必要（ECサイト本体など）
  • 一般: 1-2日以内の復旧で許容（社内情報システムなど）

この分析結果に基づいて、各システムに適したDR戦略を選択します。

バックアップ＆リストア戦略 ​

戦略の概要と適用場面 ​

バックアップ＆リストア戦略は、最もコスト効率に優れたDR手法です。定期的にデータとシステムのバックアップを取得し、災害時にはこのバックアップから復元を行います。開発環境や重要度の低い業務システムに適用されることが多く、復旧時間よりもコスト削減を重視する場合に選択されます。

主要なAWSサービスと役割 ​

バックアップ＆リストア戦略では、以下のAWSサービスが中心的な役割を担います。

AWS Backup

  • 複数のAWSサービスを統合的にバックアップ
  • 自動化されたバックアップスケジュール設定
  • 暗号化とライフサイクル管理

Amazon S3

  • バックアップデータの長期保存
  • 複数のストレージクラスによるコスト最適化
  • クロスリージョンレプリケーション

Amazon RDS の自動バックアップ

  • データベースの自動バックアップとポイントインタイム復旧
  • スナップショットによる手動バックアップ

実装における重要な設計ポイント ​

バックアップ＆リストア戦略を実装する際は、以下の点を考慮して設計を行います。

バックアップ頻度とタイミング

  • 日次バックアップ: 業務時間外（深夜2-4時）に実行
  • 週次バックアップ: 長期保存用として週末に実行
  • トランザクションログバックアップ: 15分間隔でRPOを最小化

保存期間とライフサイクル管理

  • 日次バックアップ: 30日間保存後、コールドストレージに移行
  • 週次バックアップ: 1年間保存し、その後削除
  • 法規制により長期保存が必要な場合は2-7年間保存

暗号化とセキュリティ

  • 保存時暗号化（AES-256）
  • 転送時暗号化（TLS 1.2以上）
  • アクセス制御（IAMロールベース）
  • 監査ログの記録

クロスリージョン複製

  • メインバックアップとは異なるリージョンへの複製
  • 地理的に離れた場所への保存（東京→オレゴンなど）
  • 複製の自動化とスケジューリング

復旧プロセスと所要時間 ​

災害発生時の復旧は以下の手順で進行します。

  1. インシデント確認（30分-1時間）

    • システム障害の範囲特定
    • 復旧方針の決定

  2. インフラストラクチャ再構築（2-4時間）

    • VPC、サブネット等のネットワーク設定
    • セキュリティグループ、IAMロールの設定
    • Infrastructure as Code（CloudFormation/Terraform）を利用した場合は30分-1時間で自動再構築可能

  3. データ復元（1-6時間）

    • データベースの復旧
    • ファイルシステムの復元
    • アプリケーションコンテンツの配備

  4. サービス検証とテスト（1-2時間）

    • 機能テスト実施
    • データ整合性確認
    • 性能テスト

合計で4-13時間程度の復旧時間（RTO）を見込みます。

パイロットライト戦略 ​

戦略の概要と仕組み ​

パイロットライト戦略は、災害復旧用の最小限のシステムを常時稼働させておく手法です。「パイロットライト」という名前の通り、ガス機器の種火のように小さな炎を維持しておき、必要な時に大きな火に育てるというコンセプトです。

通常時は最小限のリソース（データベースのレプリケーションと小規模なWebサーバーなど）のみを稼働させ、災害時には迅速にリソースをスケールアップしてサービスを復旧します。バックアップ＆リストアよりも復旧時間が短く、ウォームスタンバイよりもコストを抑えることができる、バランスの取れた戦略です。

主要コンポーネントと役割 ​

パイロットライト戦略では、以下のAWSサービスが協調して最小限の種火を維持し、災害時に迅速な復旧を実現します。

RDS リードレプリカ

  • プライマリデータベースのリアルタイム複製を維持
  • 災害時にはマスターに昇格（プロモート）
  • 読み取り専用として平時は参照クエリの負荷分散に活用可能

Auto Scaling Group（停止状態）

  • 初期設定では最小インスタンス数を0に設定
  • AMIには最新のアプリケーションを事前にベイキング
  • 災害時の自動スケールアップ設定を準備済み

Application Load Balancer

  • 災害時のトラフィック分散用に事前設定
  • ヘルスチェックの設定により自動的な負荷分散
  • 平時はトラフィックを処理しないため、コストを最小限に維持

Route 53 DNS

  • 災害時の自動フェイルオーバー設定
  • ヘルスチェック機能による自動切り替え
  • 地理的DNS ルーティング

フェイルオーバーの自動化 ​

パイロットライト戦略の真価は、災害時の迅速な自動復旧にあります。Step Functionsを使用した自動化により、人的オペレーションを最小限に抑えて復旧プロセスを実行します。

自動フェイルオーバーのワークフロー

  1. 障害検知と検証（1-3分）

    • CloudWatch アラームによる障害検知
    • Route 53 ヘルスチェックでの確認
    • 複数の監視ポイントでの検証

  2. データベース昇格（2-5分）

    • RDS リードレプリカのマスターへのプロモート
    • 書き込み権限の有効化
    • 接続エンドポイントの更新

  3. アプリケーションサーバーの起動（3-8分）

    • Auto Scaling Groupの最小容量を増加
    • インスタンスの自動起動と設定
    • アプリケーションの開始とヘルスチェック

  4. DNS とロードバランサーの更新（1-2分）

    • Route 53 レコードの自動切り替え
    • ALB のターゲットグループ登録
    • SSL証明書とセキュリティ設定の確認

  5. サービス確認と通知（1-2分）

    • エンドツーエンドテストの実行
    • 関係者への自動通知
    • 監視システムの状態更新

復旧時間の実績

  • 自動検知から復旧完了まで：15-30分
  • 手動介入が必要な場合：30-60分
  • データ損失：通常5分以内（RPO）

コストと運用上の注意点 ​

パイロットライト戦略は、バックアップ＆リストアとウォームスタンバイの間のバランスの取れた選択肢です。

月額コスト構成

  • RDS リードレプリカ: 本番データベースの約50-70%
  • 停止状態のインフラ: ほぼゼロ（設定のみ維持）
  • 監視とオートメーション: 月額$50-200程度
  • 合計: 本番環境の10-20%程度

運用のポイント

  • AMI の定期更新（月1回程度）
  • フェイルオーバーテストの実施（四半期に1回）
  • 監視アラートの定期見直し
  • DR実行手順書の最新化

ウォームスタンバイ戦略 ​

戦略の概要と特徴 ​

ウォームスタンバイ戦略は、災害復旧用のシステムを縮小した規模で常時稼働させておく手法です。パイロットライト戦略よりも高い可用性を提供し、マルチサイトアクティブ/アクティブよりもコストを抑制できます。

この戦略では、本番環境よりも小さなリソースでDR環境を運用し、災害時には迅速にスケールアップして本番レベルの処理能力を確保します。データベースは常時同期されており、アプリケーションサーバーも最小限の台数で稼働しているため、数分から数十分での復旧が可能です。

システム構成と設計考慮事項 ​

ウォームスタンバイ戦略では、本番環境の約30-50%の規模でDR環境を常時稼働させます。

Application Load Balancer

  • 常時稼働してトラフィックを受け付け可能
  • ヘルスチェック設定により自動的な負荷分散
  • SSL終端とセキュリティ設定を本番と同一に保持

Auto Scaling Group（縮小稼働）

  • 通常時: 最小2台、最大10台で稼働
  • 災害時: 5分以内に本番レベル（6-8台）まで自動スケールアップ
  • 全インスタンスで最新のアプリケーションが稼働中

Aurora Cross-Region リードレプリカ

  • 本番のAurora クラスターから継続的に同期
  • 読み取りクエリによる動作確認を定期実行
  • 災害時は10-30秒でマスターに昇格可能

復旧プロセスとタイムライン ​

ウォームスタンバイからの復旧は以下の流れで実行されます。

  1. 自動検知と初期対応（30秒-2分）

    • Route 53 ヘルスチェックによる障害検知
    • 自動フェイルオーバーの開始

  2. データベース昇格（10秒-2分）

    • Aurora リードレプリカのプライマリ昇格
    • アプリケーションの接続先切り替え

  3. アプリケーション層のスケールアップ（3-8分）

    • Auto Scaling Group の目標容量増加
    • 新規インスタンスの起動と登録

  4. DNS 切り替えと最終確認（1-3分）

    • Route 53 レコードの更新
    • エンドツーエンドテストの実行

合計復旧時間: 5-15分程度 データ損失: 0-30秒程度（RPO）

コストと運用特性 ​

月額コスト構成（本番を100%とした場合）

  • インフラストラクチャ: 約35%（縮小稼働分）
  • データベース: 約40%（リードレプリカとストレージ）
  • ネットワーク・監視: 約5%
  • 合計: 本番の約30-50%

運用上のメリット

  • 常時稼働により本番環境との設定差異を最小化
  • 読み取り専用での動作確認が随時可能
  • DR環境での開発・テスト利用も可能（読み取り限定）

注意点

  • 本番とDR環境での設定同期管理が重要
  • 定期的なフェイルオーバーテストの実施が必要
  • データベースの同期遅延監視が重要

マルチサイトアクティブ/アクティブ戦略 ​

最高レベルの可用性とゼロダウンタイム ​

マルチサイトアクティブ/アクティブ戦略は、複数のリージョンで同時に本番レベルのシステムを稼働させる最も高可用性な災害復旧手法です。このアプローチでは「災害復旧」という概念を超えて、常時複数拠点での処理を前提としたアーキテクチャを構築します。

地理的に離れた複数のAWSリージョンに同規模のインフラを配置し、トラフィックを分散させることで、一つのリージョン全体に障害が発生しても、残りのリージョンでサービスを継続できます。金融機関の取引システムや、グローバルなWebサービスで採用される最高レベルの可用性戦略です。

グローバルアーキテクチャの設計 ​

マルチサイトアクティブ/アクティブ戦略では、複数のAWSリージョンに同等のインフラを配置し、グローバルなトラフィック分散とデータ同期を実現します。

Route 53 Global Load Balancer

  • Geolocation ルーティングによる最適な拠点への誘導
  • Health Check による自動フェイルオーバー
  • Latency-based ルーティングでの応答速度最適化

Aurora Global Database

  • プライマリリージョンからセカンダリへのミリ秒レベル同期
  • 読み取り専用レプリカによる地域最適化
  • 災害時のプライマリ切り替えが1分以内で完了

DynamoDB Global Tables

  • マルチマスター構成による双方向同期
  • eventual consistency での整合性管理
  • アプリケーション層での競合解決ロジック

アプリケーション層の考慮事項

  • セッション管理の外部化（ElastiCache Global）
  • ファイルストレージのクロスリージョン同期（S3 CRR）
  • 設定情報の一元管理（Systems Manager Parameter Store）

運用コストと技術的課題 ​

月額コスト構成

  • インフラストラクチャ: 本番と同等×拠点数
  • データ転送コスト: 月額$500-2,000（同期とレプリケーション）
  • 監視・運用ツール: 月額$200-500
  • 合計: 本番の2-3倍（2拠点構成の場合）

技術的な課題と対応

  • データ整合性: eventual consistency 前提の設計
  • ネットワーク分断: スプリットブレイン対策の実装
  • 設定同期: Infrastructure as Code での一元管理
  • 監視複雑性: 統合監視ダッシュボードの必要性

適用すべき場面

  • ミッションクリティカルな金融システム
  • グローバル展開のWebサービス
  • 法規制でゼロダウンタイムが要求されるシステム
  • SLA 99.99%以上の可用性が必要な場合

DR テストと監視 ​

継続的なDR有効性の確保 ​

ディザスタリカバリ戦略は構築しただけでは意味がありません。実際の災害時に確実に機能するよう、定期的なテストと継続的な監視が不可欠です。

自動化されたテストフレームワーク ​

テスト実行のワークフロー

  1. テスト環境の準備

    • 本番データの匿名化コピー作成
    • テスト用インスタンスの起動
    • 監視システムの設定

  2. フェイルオーバーテストの実行

    • 自動的な本番障害シミュレーション
    • DR環境への切り替え実行
    • RTO/RPO目標値との比較測定

  3. 機能検証テストの実施

    • エンドツーエンドの業務シナリオ実行
    • データ整合性の確認
    • 性能要件の検証

  4. 復旧とレポート作成

    • 本番環境への切り戻し
    • テスト結果の自動レポート生成
    • 改善点の抽出と推奨事項の作成

監視とアラートの設計 ​

多層防御的な監視

  • インフラレベル: EC2、RDS、ネットワークの基本メトリクス
  • アプリケーションレベル: 応答時間、エラー率、トランザクション成功率
  • ビジネスレベル: 売上、注文数など業務KPIの異常検知

アラートの段階的エスカレーション

  • Level 1（自動対応）: 自動スケーリング、自動復旧の実行
  • Level 2（運用チーム）: 運用チームへの即座の通知
  • Level 3（管理職）: 重大インシデント時の経営層への報告

定期的な手動検証

  • 月次: DR環境の動作確認
  • 四半期: 部分的フェイルオーバーテスト
  • 年次: 全社規模の災害復旧訓練

まとめ ​

AWSを活用したディザスタリカバリ戦略は、企業の事業継続性を支える重要な基盤技術です。適切な戦略選択により、災害や障害からの迅速な回復と、顧客サービスの継続的な提供が可能になります。

戦略選択の指針 ​

各DR戦略には明確な適用場面があり、コストと可用性のバランスを考慮した選択が重要です。

考慮要素バックアップ＆リストアパイロットライトウォームスタンバイマルチサイトアクティブ
適用システム開発環境、低重要度重要業務システムミッションクリティカル最重要・金融システム
月額コスト本番の5-10%本番の10-20%本番の30-50%本番の200-300%
復旧時間4-13時間15-60分5-15分即座-数分
データ損失15分〜数時間5分以内30秒以内ほぼゼロ

実装の成功要因 ​

要件の明確化 まずビジネス影響分析を実施し、システム停止による損失を定量化します。RTO/RPO要件を明確に定義することで、過度な投資を避けつつ必要十分な災害対策を構築できます。

段階的な実装 すべてのシステムを一度に最高レベルのDR戦略で保護するのではなく、重要度に応じて段階的に実装することで、コストを抑制しながら適切な保護を実現します。

自動化の活用 Step Functions、Lambda、CloudWatch を組み合わせることで、障害検知から復旧までの一連の流れを自動化できます。人的ミスを排除し、復旧時間の短縮に寄与します。

継続的な検証 DR戦略は構築して終わりではありません。定期的なテスト実施により実際の災害時にも確実に機能することを保証し、システム変更に応じた戦略の見直しも必要です。

今後の技術動向 ​

クラウドネイティブなアプリケーション設計の普及により、従来よりも簡単で低コストなDR戦略の実現が可能になっています。コンテナ技術、サーバーレスアーキテクチャ、マネージドサービスの活用により、インフラの複雑性を抑えながら高可用性を実現する手法が主流になりつつあります。

適切なDR戦略の実装により、企業は災害リスクに対する強固な防御体制を構築し、ステークホルダーからの信頼を獲得できるでしょう。