AWS Elastic Disaster Recovery

解決する課題

従来のディザスタリカバリ（DR）は、待機系のサーバーやストレージを常時フル稼働させて二重投資になったり、テープや手作業のリストアでRTO（復旧目標時間）が数時間〜数日に伸びたりしがちでした。AWS Elastic Disaster Recovery（DRS）なら：

• オンプレミスや他クラウド、別リージョンのサーバーをそのままAWSへ複製して待機させられる
• 障害発生時に必要なときだけEC2を起動するため、待機コストを小さく抑えられる
• 復旧手順をドリル（演習）として繰り返しテストでき、本番切替の不確実性を減らせる

主要概念と用語

• ソースサーバー: 保護対象の元サーバー。オンプレミス、他クラウド、別AWSリージョンのいずれでもよい
• レプリケーションエージェント: ソースサーバーにインストールし、ブロックレベルで継続的にデータを送出するエージェント
• ステージングエリア（待機領域）: 複製データを受け取る低コストの領域。安価なボリュームと小さめのレプリケーションサーバーで構成される
• レプリケーションサーバー: ステージングエリアで複製データを受け取る軽量なEC2インスタンス
• リカバリインスタンス: フェイルオーバーやドリル時に、複製データから実際に起動される本番用EC2インスタンス
• ポイントインタイムリカバリ: 過去の特定時点のスナップショットから復旧する機能。ランサムウェアなどデータ破損時に有効
• 起動設定（Launch settings）: リカバリ時のインスタンスタイプやサブネット、IAMなどの起動条件
• フェイルバック: 障害復旧後に、AWS上のリカバリインスタンスから元の環境へデータを戻す逆方向の処理

仕様・制限・クォータ

• 対応OSは主要なLinuxディストリビューションとWindows Serverの広い範囲をカバーする
• 継続ブロックレプリケーションにより、RPO（復旧目標時点）は秒単位、RTO（復旧目標時間）は数分〜十数分単位を狙える
• 1アカウント・1リージョンあたりで保護できるソースサーバー数や同時ジョブ数などにクォータがあり、必要に応じて引き上げを申請できる
• 物理サーバー、VMware、Hyper-V、他クラウドのVMなどを区別なく扱える（エージェントベースのため）
• アプリケーション一貫性は、復旧後にOSやアプリ側の整合性チェックに依存する点に注意する

内部の仕組み

DRSは、ソースサーバーにインストールしたエージェントがディスクのブロック変更を継続的に転送し、AWS上のステージングエリアへ低コストで保持し続ける構成です。本番リソースは普段起動せず、複製データだけを安価なボリュームに溜めておきます。

• 平常時は小さなレプリケーションサーバーと安価なボリュームだけが動き、待機コストを最小化する
• フェイルオーバー時には、ステージングのデータからEBSスナップショットを作り、起動設定に従ってEC2を即時起動する
• ドリルとフェイルオーバーは同じ仕組みで、ドリルは本番影響なく繰り返しテストできる
• 復旧後はフェイルバックで逆方向にレプリケーションし、元環境または別の場所へ戻せる

設計パターン / ベストプラクティス

• オンプレからAWSへのDR: データセンター障害に備え、主要サーバーをDRSでAWSへ複製しておく
• AWSリージョン間DR: 別リージョンへ複製し、リージョン規模の障害に備える
• 起動設定の事前整備: サブネット、セキュリティグループ、インスタンスタイプ、IAMを前もって定義し、切替時の手戻りをなくす
• 定期的なドリル: 本番に影響しないドリル起動を定期実行し、RTO/RPOと手順を継続的に検証する
• ポイントインタイムの活用: ランサムウェアやデータ破損に備え、破損前の時点へ戻せるようにしておく

運用・監視

• レプリケーションの遅延やエラー、各サーバーの状態をコンソールやAPIで横断的に確認する
• CloudWatchやイベント通知でレプリケーションの停止・遅延を検知し、アラートを出す
• フェイルオーバー/フェイルバックのジョブ進捗を監視し、所要時間を実測してRTOの妥当性を確認する
• ドリル結果を記録し、手順書（ランブック）を最新に保つ

コスト

• 課金は主に、ステージングで使う安価なボリュームと小型レプリケーションサーバー、および複製データのストレージとデータ転送に基づく
• リカバリインスタンスは起動している間だけ通常のEC2/EBS料金が発生するため、ドリルやフェイルオーバー後は不要なインスタンスを停止・削除する
• 待機系をフル稼働させるパイロットライトやウォームスタンバイより、平常時コストを抑えやすい

セキュリティ

• 複製データは保存時・転送時に暗号化でき、ステージングのボリュームはKMSで暗号化できる
• レプリケーションのネットワーク経路はVPC内に閉じ、必要に応じてプライベート接続（VPN/Direct Connect）を使う
• IAMで誰がレプリケーション設定・フェイルオーバー・フェイルバックを実行できるかを最小権限で制御する
• ポイントインタイムリカバリにより、ランサムウェア感染前の時点へ復旧できる

関連サービス・比較

サーバー単位でAWSへ複製するという点では AWS Application Migration Service（MGN）と仕組みが共通ですが、MGNは「一度きりの移行（カットオーバー）」、DRSは「継続的なDRと復旧」を目的とします。

ハンズオン / CLI例

# 保護中のソースサーバー一覧を確認
aws drs describe-source-servers

# ドリル（テスト）としてリカバリを開始（本番に影響しない演習）
aws drs start-recovery \
  --is-drill \
  --source-servers sourceServerID=s-1234567890abcdef0

# 起動したリカバリインスタンス（ジョブ）の状況を確認
aws drs describe-jobs