AWSレジリエンス/DR Vol2｜Elastic Disaster Recovery(DRS)実装

1. DR実装の本番課題とDRSの全体像

Vol1(Resilience Hub)からVol2(DRS)への接続

AWS レジリエンス/DR 本番運用シリーズは、エンタープライズシステムの事業継続設計を2つのステップで解説します。

Vol1では、Resilience Hub を使った「上流設計」を扱いました。Resilience HubはAWSアーキテクチャを継続的に解析し、設定したRTO(Recovery Time Objective: 目標復旧時間)/RPO(Recovery Point Objective: 目標復旧時点)を達成できるかアセスメントするサービスです。Vol1の役割は「どこまで守るか」の設計と評価です。保護ポリシーの策定・アーキテクチャギャップの可視化・ドリフト検知・改善リコメンデーションの提供を担います。

Vol1で設計した目標を実際に達成するためには「どう復旧するか」の実装が必要です。Resilience Hubがアーキテクチャのギャップを指摘しても、実際に復旧する仕組みがなければシステムは止まったままです。設計と実装は車の両輪です。

本Vol2では、AWS Elastic Disaster Recovery(DRS)を使った「DR実装」を扱います。DRSはサーバー単位の継続的レプリケーションとフェイルオーバーを提供し、Resilience HubのRTO/RPO目標を現実のインフラで達成するための実装ツールです。

Vol1(設計)とVol2(実装)の接続例:

• Resilience HubでRPO目標=15分と設定 → DRSの継続複製(秒〜分のRPO)で目標を達成
• Resilience HubでRTO目標=1時間と設定 → DRS Recovery PlansとPost-Launch Actionsで1時間以内の起動シーケンスを設計
• Resilience Hubのドリフト評価で劣化を検知 → DRS定期ドリルのRTO実測値をフィードバックして改善

Vol1を読んでいない方も本Vol2から入れるよう構成していますが、RTO/RPO設計の考え方を先に把握しておくとより理解が深まります。

DR実装の本番課題

設計段階では明確だった目標も、本番実装では多くの障壁に直面します。代表的な課題を整理します。

課題1 — 複製の継続性とRPO: スナップショット方式のバックアップはRPOが時間単位になりやすく、数分・数十分のRPO要件を満たせません。継続的なブロックレベルレプリケーションがRPOを秒〜分単位まで押し下げます。

課題2 — 異種環境からの変換: オンプレミスサーバーやVMware環境をAWSでEC2として起動するには、OSドライバ・ネットワーク設定・ブートプロセスの変換が必要です。DRSは自動変換を提供し、手作業のミスを排除します。

課題3 — ドリル未実施によるRTO劣化: 「DR構築済みだが実際に動くか不明」という状態は実質的にDRなしと同義です。システム構成変更や設定変化により、知らないうちにRTOが劣化するリスクを伴います。定期的な非破壊ドリルでRTOを実測・維持することが必要です。

課題4 — 複数サーバーの起動順序: DB→アプリ→Webというように複数サーバーが依存関係を持つ場合、起動順序を誤るとアプリが正常起動しません。Recovery Plans(起動順序の事前定義)とPost-Launch Actions(起動後処理の自動化)が必要です。

課題5 — フェイルバックの計画: 障害収束後に元の環境へ戻すフェイルバックを計画しておかないと、DR環境を使い続けてコストが増大します。DRSはVMware等へのフェイルバックも含めた柔軟な復帰を提供します。

課題6 — コスト管理: 本番品質のDRを維持しながらコストを抑えるには、平時は軽量なステージング環境で複製を維持し、復旧時のみ本格的なEC2を起動するアーキテクチャが必要です。DRSのアクティブ-パッシブ設計がこのコスト効率を実現します。

AWS Elastic Disaster Recovery(DRS)の全体像

AWS Elastic Disaster Recovery(DRS)は、オンプレミス/他クラウド/AWSのサーバーを継続的なブロックレベルレプリケーションでAWSへ複製し、災害時にEC2インスタンスとして起動する災害復旧マネージドサービスです。CloudEndure Disaster Recovery(2024年3月終了)の後継として正式提供されています。

DRSが保護できる環境:

DRSは幅広い環境のサーバーを保護対象にできます。

• オンプレミス: 物理サーバー・VMware vSphere仮想マシン・Microsoft Hyper-V仮想マシン
• 他クラウド: GCP・Azure上の仮想マシン
• AWS内: 別リージョンのEC2インスタンス(リージョン間DR)
• 対応OS: Windows Server・Red Hat Enterprise Linux・CentOS・Ubuntu 等

★ DRSの対応OSバージョン・対応リージョンは継続的に拡張されています。公開時にAWS公式ドキュメントで最新情報を必ず確認してください。

DRSの動作フェーズ:

DRSは以下の3フェーズで動作します。

フェーズ1 — 常時レプリケーション: 各ソースサーバーにレプリケーションエージェントを導入し、ブロック単位でデータをAWS上のステージングエリアサブネットへ継続複製します。ステージングエリアは安価なEBSストレージと最小限のコンピュートで構成され、平時のコストを最小化します。初回起動時にフル同期、以降は差分のみを継続複製します。

フェーズ2 — リカバリ実行(ドリル/フェイルオーバー): 非破壊ドリルや実際の災害時に、ステージングエリアのデータからEC2インスタンス(リカバリインスタンス)を起動します。ポイントインタイムスナップショットから任意の時点を復旧時点として選択できるため、ランサムウェア等による意図的なデータ破壊にも対応できます。

フェーズ3 — フェイルバック: 障害が収束した後、DRS環境から元のソースインフラへデータと制御を戻します。VMware環境への復帰なども含めた柔軟なフェイルバックが可能です。

アクティブ-パッシブDRの設計思想

DRSのコアとなるアクティブ-パッシブ(Active-Passive)設計を理解することで、DR全体の設計方針が明確になります。

アクティブ-パッシブDRは、本番環境(アクティブ)とDR環境(パッシブ)を常時同期しながら、平時はDR環境を低コストの待機状態に置き、障害時のみDR環境を本格起動する設計思想です。

アクティブ-アクティブ(常時マルチリージョン稼働)はRTOをほぼゼロにできますが、常時2倍以上のインフラコストが発生します。アクティブ-パッシブDRSは数分〜数十分のRTOを受け入れる代わりに平時のコストを大幅に抑えます。Vol1のResilience Hubで策定したRTO目標値がその判断基準になります。

DRSとCloudEndureの関係

DRSはAWS CloudEndure Disaster Recoveryの後継サービスです。CloudEndureは2024年3月にサービス終了し、DRSへの移行が推奨されています。技術的な複製基盤は継承しながら、以下の点でAWSエコシステムとの親和性が向上しています。

• AWSコンソール/AWS CLIへの完全統合
• AWS Organizations・Service Control Policy(SCP)対応
• IAM・CloudWatch・EventBridge・AWS Backupとのネイティブ連携
• AWS Systems Managerとの統合によるPost-Launch Actions

既存のCloudEndure環境からDRSへ移行する場合は、AWS公式の移行ガイドに従った計画的な移行を推奨します。

★ DRSの対応リージョン・対応OS・料金体系は変更される場合があります。最新の対応状況は公開時にAWS公式ドキュメントで必ず確認してください。

本記事の対象読者と読み方

対象読者:

• オンプレミス/VMware環境をAWSへDR移行しようとしているインフラエンジニア
• 既存AWSシステムのRTO/RPO要件を強化しようとしているクラウドエンジニア
• Vol1でResilience Hub設計を済ませ、DRS実装に進もうとしている方
• ランサムウェア対策としてポイントインタイムリカバリを検討している方

本記事で解説すること:

DRSの全体像・ソース設定・レプリケーション・ドリル/フェイルオーバー/フェイルバック・Recovery Plans・運用監視・コスト設計・既存DR部品との統合設計を解説します。

本記事で解説しないこと:

VPCの構築・Direct Connectの設定・EC2/EBSの基本操作は既存の関連記事を参照してください。本記事はDRSに固有の設計と実装に集中します。AWS KMSの詳細なキー管理やIAMポリシーの詳細設計も同様に関連記事へ誘導します。

上流のRTO/RPO設計はこちら（レジリエンス/DR Vol1 — Resilience Hub）

2. DRSの仕組み — 継続的ブロックレプリケーションとステージングエリア

AWS Elastic Disaster Recovery（DRS）の中核は「継続的ブロックレベルレプリケーション」にあります。ソースサーバーへ軽量エージェントを導入し、ブロック単位の変更をAWSへ継続転送することで、低コストなアクティブ-パッシブDRを実現します。平時はステージングエリアの最小構成のみが稼働し、フェイルオーバー時だけリカバリEC2インスタンスを本格起動します。

2-1. アーキテクチャ全体像

DRSは「ソース層 → ステージング層 → リカバリ層」の3層構造で動作します。

ソース層（保護対象サーバー）

保護対象となるソースサーバーは多様なプラットフォームに対応しています。

• オンプレミス物理サーバー（Windows / Linux）
• VMware vSphere 仮想マシン
• 他クラウドプロバイダーのインスタンス（GCP / Azure / IBMクラウド等）
• AWS上の別リージョン・別アカウントのEC2インスタンス

エージェントのインストールが可能であれば、インフラの種類を問わずDRSの保護対象にできます。対応OSとリージョンは随時更新されるため、設計時は必ずAWS公式ドキュメントで最新情報を確認してください。

ステージング層（平時の複製先）

ソースサーバーからの変更ブロックはターゲットAWSアカウントの「ステージングエリアサブネット」に継続格納されます。

• Replication Server: 最小スペック（t3.small等）のEC2インスタンスがエージェントとの通信を担当
• EBSボリューム群: ソースのディスク構成と対応した同等容量のEBSが割り当てられる
• ネットワーク経路: ソース→Replication ServerへのアウトバウンドはTCP 1500（暗号化）

平時はこの最小構成のみが稼働するため、通常のDR待機コストを大幅に削減できます。

リカバリ層（フェイルオーバー・ドリル時のみ起動）

フェイルオーバー実行またはドリル起動時にのみ、ステージングのブロックデータからリカバリEC2インスタンスが起動します。起動後はソースサーバーの代替として稼働し、元のアプリケーションサービスを提供します。

2-2. 継続的ブロックレベルレプリケーションの動作原理

DRSは「ブロックレベル」でディスクの変更を検知・転送します。ファイルベースの同期とは異なり、ディスクのブロック単位（512バイト〜4KiB）で差分を把握するため、OSやファイルシステムの種類に依存せず動作します。

初回フル同期

エージェント導入後、最初にソースディスクの全ブロックをAWSへ転送します。

1. エージェントがソースディスク全体をスキャン
2. 全ブロックをTCP 1500（暗号化）でReplication Serverへ転送
3. Replication ServerがステージングEBSへ書き込み
4. 全ブロックの転送完了後に「Protected」状態へ移行

初回同期はソースディスクの総容量に比例します。100GBのソースディスクに100Mbpsの帯域を割り当てた場合、理論上は2.2時間以上かかります（実際のオーバーヘッドを含むとさらに長くなります）。帯域計画を事前に立て、業務時間外に実施することを強く推奨します。

継続差分転送

初回同期完了後は変更ブロックのみを連続的に転送します。

1. ソースサーバー上のエージェントがブロック変更を検知
2. 変更ブロックをクラッシュ整合（Crash-consistent）状態で取り込む
3. 変更ブロックをAWSへ転送
4. DRSが定期的にCrash-consistentスナップショットをEBS上に保存

この差分転送がRPO（目標復旧時点）を数秒〜数分に維持する仕組みです。

クラッシュ整合性（Crash-consistent）とアプリ整合性

DRSの継続レプリケーションはCrash-consistentでブロックを取り込みます。これはサーバーが突然電源断した時点のディスク状態と等価です。OSやファイルシステムは再起動時のfsck・ジャーナルリプレイで整合性を回復しますが、RDBMSのようにアプリケーションがメモリ上のデータをまだディスクへフラッシュしていない場合、未フラッシュのトランザクションは失われる可能性があります。

アプリケーション整合性が必要な場合の対策：

• Post-Launch Actionsでリカバリ起動後にDB再起動・整合性チェックを自動化する
• ソース側でDBの定期フラッシュ・アプリ整合スナップショットを仕組み化する
• Vol1のResilience Hubで定義したRPO目標と実際の損失許容量を照合し、設計を適切に選択する

2-3. ステージングエリアサブネットの設計

ステージングエリアサブネットはDRSのコスト最適化の核心です。設計時のポイントを整理します。

VPCとサブネット構成

ターゲットAWSアカウント（リカバリリージョン）
└─ DRS用VPC
├─ ステージングエリアサブネット（プライベートサブネット推奨）
│├─ Replication Server（最小スペック・DRS自動管理）
│└─ EBSボリューム（ソースディスクと同容量・暗号化可）
└─ リカバリサブネット（フェイルオーバー時のEC2配置先）
 └─ リカバリEC2インスタンス（フェイルオーバー・ドリル時のみ起動）

ステージングエリアサブネットはインターネット公開不要なためプライベートサブネットに配置します。ソースからの通信経路（Direct Connect / VPN / インターネット）に合わせてルーティングを設計します。

Replication Serverの自動管理

Replication ServerはDRSが自動起動・管理するEC2インスタンスです。ユーザが手動で起動・停止する必要はありません。

• ソースサーバー追加時にDRSが自動でReplication Serverを起動
• DRS管理のAMIを使用（ユーザによるカスタマイズ不可）
• インスタンスタイプはDRSレプリケーション設定から変更可能

EBSボリューム容量の計画

ステージングEBSはソースディスクの容量と同等以上を確保する必要があります。過去スナップショットの蓄積も考慮し、ソースディスク総容量の1.1〜1.2倍程度を目安に設計することを推奨します。容量不足はレプリケーション停止の直接原因となるため、CloudWatchで定期的に残量を監視する設計が必要です。

ネットワーク接続方式の比較

2-4. RPO（目標復旧時点）の計測と制御

RPOの測定方法

DRSのRPOは「直近のCrash-consistentスナップショットがステージングに到達した時刻」から現時点までの差分で測定されます。CloudWatchメトリクス（BackloggedStorageBytes等）でレプリケーションラグを監視し、RPO目標との乖離を検知します。

RPO悪化の主要因と対策

2-5. DRS vs CloudEndure — 後継サービスとしての位置付け

DRSはCloudEndure Disaster Recovery（CEDR）の後継サービスとして2021年にGAリリースされ、AWSネイティブなDRを提供します。

主な違い

CloudEndure DRはサービス終了が発表されているため、既存ユーザはDRSへの移行が必要です。移行時はRecovery Plansによる起動順序の設計と、Post-Launch Actionsの再構築がポイントになります。

2-6. 自動サーバー変換の仕組み

DRSはリカバリインスタンス起動時に「自動サーバー変換」を実行し、オンプレ・他クラウドのサーバーをAWS EC2として起動可能な状態に変換します。

変換の内容

• ブート設定の変換（MBR / GPT / EFI → AWS EC2互換）
• AWS NVMe / ENAドライバの自動注入
• ネットワークドライバの差し替え（オンプレNIC → ENA）
• 元のSSH / RDP接続設定の維持

この変換はフェイルオーバー・ドリル時の起動プロセス内で自動実行されます。平時のレプリケーション中、変換処理は発生せず、ユーザは事前変換作業なしにDRSを利用できます。変換失敗時のエラーはDRSコンソールと起動ログで確認できます。

3. ソース設定とレプリケーション

3-1. レプリケーションエージェントの導入

DRSによるレプリケーションは、ソースサーバーへのエージェント導入から始まります。エージェントはオンプレミスサーバー・他クラウドVM・AWS上のEC2インスタンスの三種類に対応しており、ソース環境の種別を問わず同一のDRSエンドポイントへデータを送信します。

対応OSの鮮度注記: DRSが対応するOSはWindows ServerおよびLinuxの主要ディストリビューションを幅広くサポートしていますが、対応バージョン・対応リージョンは継続的に拡張されます。具体的なバージョンを本記事内に列挙することはせず、最新の対応状況は必ずAWS公式ドキュメント(AWS Elastic Disaster Recovery User Guide — Supported operating systems)を参照してください。

エージェント導入の主な手順は次のとおりです。

① IAM権限の準備

エージェントがDRSサービスエンドポイントへ接続するには、適切なIAM権限が必要です。ソースサーバー側で使用するIAMユーザーまたはロールには、DRSが提供するマネージドポリシー相当の権限をアタッチします。必要な権限には、レプリケーション開始・停止・ステータス取得、ステージングEBSボリュームへのアクセス、KMSキー操作(暗号化設定時)が含まれます。最小権限の原則に従い、DRS専用のIAMロールを作成することを推奨します。

② エージェントのダウンロードと実行

AWS DRSコンソールの「ソースサーバーの追加」画面からエージェントインストーラを取得します。Linuxではaws-replication-installer-init.pyをroot権限で実行し、プロンプトに従ってリージョン・IAM認証情報を入力します。Windowsでは専用インストーラEXEを管理者権限で実行します。インストールが完了するとエージェントはバックグラウンドサービスとして起動し、継続的なレプリケーションを開始します。

③ 接続確認とDRSコンソールへの登録

エージェントが正常に起動すると、DRSコンソールの「ソースサーバー」一覧にサーバーが登録されます。初期状態は「Initial sync(初回同期中)」として表示され、ディスク全体のフルコピーが実行されます。コンソールでレプリケーションラグ(Replication lag)が「Synced」状態に収まっていることを確認します。

3-2. ネットワーク要件

ソースサーバーからAWSのステージングエリアへの通信は、TCP/IPネットワーク経由で行われます。DRSが要求する主な通信要件は次のとおりです。

必要なポートとプロトコル:

• TCP 443: DRSサービスAPIエンドポイントへのHTTPS通信。エージェントの認証・制御に使用します
• TCP 1500: ステージングエリアサブネット内のレプリケーションサーバーへのデータ転送に使用します。このポートが遮断されるとブロックレベルのデータ転送ができないため、必ず許可が必要です

なお、具体的なエンドポイントIPレンジ・ポート要件は公式ドキュメントの「Network requirements」セクションで最新情報を確認してください。

ネットワーク経由の選択肢:

ソース環境とAWSステージングエリア間の接続方式は三種類から選択できます。

Direct Connect/VPNの構築手順については本記事では扱いません。

ファイアウォール・セキュリティグループの設定:

オンプレミス環境のファイアウォールでは、ソースサーバーからDRSサービスエンドポイント(TCP 443)およびステージングエリアサブネット内のレプリケーションサーバー(TCP 1500)への送信を許可します。AWS側のセキュリティグループでは、ステージングサブネットがDRSレプリケーションサーバーのTCP 1500インバウンドを受け入れるよう設定します。必要なIPレンジの詳細は公式ドキュメントのネットワーク要件セクションで確認してください。

ネットワーク接続・可観測性設計はこちら（AWS Network Observability Vol1）

3-3. レプリケーション設定テンプレート

DRSコンソールでは「レプリケーション設定テンプレート(Replication Settings Template)」を使用してステージングエリアの構成を一元管理します。主要な設定項目は次のとおりです。

ステージングサブネット:

レプリケーションデータの受信先となるサブネットを指定します。通常のアプリケーションサブネットとは分離した専用サブネットを使用することを推奨します。VPCのCIDR設計においてステージング専用のサブネットブロックを確保しておくことが重要です。

ステージングインスタンスタイプ:

ステージングサーバー(レプリケーション受信側のEC2インスタンス)のタイプを指定します。最小コスト維持のため、通常はt3.smallなどの低スペックインスタンスタイプを選択します。ステージング中はフルスペックのEC2を起動する必要はなく、コストを抑えながら継続複製を維持できます。

EBSボリューム種別:

レプリケーションデータを格納するEBSボリュームの種別を設定します。ステージングにはgp3を選択することでコストとI/Oバランスを最適化できます。リカバリ起動時には別途Launch Settingsでの設定により本番相当のEBS種別へ切り替えることが可能です。

帯域スロットリング:

ソースサーバーのネットワーク帯域を占有しないよう、レプリケーションに使用する帯域幅の上限を設定できます。特に業務時間帯に帯域を抑え、夜間バッチ処理時間帯に増加させる設定が一般的です。ただし、スロットリングを強くかけすぎると初回同期の完了まで想定以上の時間を要するため注意が必要です。

通信暗号化(KMS):

ステージングEBSボリュームのデータはAWS KMSで暗号化できます。デフォルトはAWSマネージドキー(aws/ebs)を使用しますが、カスタマーマネージドキー(CMK)を指定することでより細かな権限管理と監査が可能です。KMSキーポリシーにはDRSサービスロールからのkms:Decrypt・kms:GenerateDataKey*権限が必要です。

KMSキー管理の詳細については本記事では扱いません。

3-4. RPO制御とスナップショット保持

DRSのRPO(Recovery Point Objective)はcrash-consistentなブロックレプリケーションによって実現されます。ソースサーバーで書き込まれたブロックの変更がステージングエリアへ複製された最新時点が実効RPOとなり、通常は秒〜数分程度を達成できます。

ポイントインタイムスナップショット:

DRSはステージングに対して定期的なスナップショットを作成します。リカバリ時に「最新」ではなく「任意の過去時点」を選択できるのはこのスナップショットの仕組みによるものです。スナップショット保持数は設定で制御可能であり、保持期間を長くするほどEBSスナップショットのコストが増加します。ランサムウェア等の論理障害に備えて、適切な保持期間を事前に設計することが重要です。

RPOに影響する主な要因:

DRSコンソールで「Replication lag」の値を継続的にモニタリングし、目標RPO以内に収まっていることを定期的に確認します。

3-5. 初回同期と継続差分レプリケーション

エージェント導入直後に実行される「初回同期(Initial Sync)」では、ソースサーバーのディスク全体をブロック単位でステージングエリアへ転送します。この初回転送のデータ量はソースのディスク使用容量に比例するため、大容量ディスクでは数時間〜数十時間かかることがあります。

初回同期の帯域計画:

初回同期は帯域を大量に消費するため、業務影響を最小化する計画が必要です。

• 深夜・週末などの業務低負荷時間帯に初回同期を開始する
• スロットリング設定を初回同期中は適度に緩め、完了後に制限を再設定する
• 大容量ディスク(1TB以上)ではDirect Connect経由を検討し、インターネット帯域の影響を排除する

初回同期が完了すると、以後は変更ブロックのみを差分転送する「継続差分レプリケーション(Ongoing Replication)」へ自動的に移行します。この段階ではネットワーク転送量が大幅に減少し、通常業務への影響は軽微になります。

DRSコンソールのレプリケーションラグ表示を継続的に確認し、ラグが許容RPO以内に収まっていることをモニタリングすることが運用の基本となります。

3-6. 複数サーバーの同時レプリケーション設計

本番環境ではアプリケーションサーバー・DBサーバー・バッチサーバーなど複数サーバーを同時に保護するケースが一般的です。複数サーバーを同時にDRSへ登録する際の設計上の注意点を整理します。

レプリケーション帯域の合算:

DRSへの登録サーバー数が増えるほど、ステージングエリアへの通信帯域は合算されます。例えば10台のサーバーを同時に初回同期させると、各サーバーのディスク使用量×10台分の転送が同時に発生します。初回同期を分割してサーバーを段階的に追加することで、帯域の集中を分散できます。

ステージングエリアのVPC設計:

複数サーバーを保護する場合、ステージングエリアサブネットに十分なIPアドレス空間を確保します。ステージングサブネットにはサーバー台数分のIPアドレスが必要です。事前にVPCのCIDR設計でステージング専用のアドレスブロックを確保しておくことを推奨します。

依存関係を考慮した復旧優先度:

複数サーバーのリカバリ順序は、サービス間の依存関係(DB→アプリ→Web等)に基づいて設計します。この起動順序の詳細はRecovery Plans(§5)で設定しますが、DRSへのサーバー登録段階からアプリケーション構成を意識したグループ分けを計画しておくことで、後続のRecovery Plans設計がスムーズになります。

コスト試算の留意点:

DRSのコストはレプリケーション中のサーバー台数×時間で課金されます。100台のサーバーを常時レプリケーションした場合のコストは月額で相応の規模になるため、事前にAWS Pricing Calculatorで試算し、予算計画と照合することを推奨します。

エージェントの更新管理:

レプリケーションエージェントはソフトウェアコンポーネントであるため、定期的なアップデートが必要です。エージェントのバージョンが古い場合、DRSコンソールにアップデート推奨の通知が表示されます。OS側のパッチ管理と合わせて、エージェントのアップデート計画を運用スケジュールに組み込んでおくことを推奨します。エージェントアップデート中も継続的なレプリケーションは維持されますが、アップデート作業の影響を最小化するため業務低負荷時間帯に実施することが望ましいです。なお、対応エージェントバージョンの最新情報も公式ドキュメントで随時確認してください。

4. リカバリ実行 — ドリル・フェイルオーバー・フェイルバック

DRSが提供するリカバリ操作はドリル・フェイルオーバー・ポイントインタイムリカバリ・フェイルバックの4種類です。それぞれの用途と実行タイミングを正確に把握することが、DR計画を実際の障害時に確実に機能させる鍵となります。

4-1. ドリル — 非破壊でDR準備を定期検証する

ドリルは実際の障害を想定した「本番影響ゼロの練習実行」です。DRSはドリル用インスタンス（Drill Instance）を別途起動し、ソースサーバーの継続レプリケーションを中断することなくDR準備状況を検証できます。

ドリルが保証すること

ドリル実行中も、ソースサーバーへのレプリケーションは継続します。ドリルインスタンスはドリル専用のサブネット（Drill Subnet）に起動され、本番ネットワークや継続中のレプリケーション経路とは完全に分離されます。そのため、ドリル中にソースサーバーへの影響が出ることはありません。

ドリルの実行ステップ

1. DRSコンソールで対象ソースサーバーを選択します
2. 「Start Drill」アクションを実行し、ドリルサブネットとリカバリ時点（最新または過去スナップショット）を選択します
3. ドリルインスタンスが起動するまで待機します（通常数分〜十数分）
4. 起動後、アプリケーションの動作・ネットワーク疎通・データ整合性を検証します
5. 検証完了後、ドリルインスタンスを終了（Terminate Drill Instance）します

後片付けの徹底

ドリルインスタンスの終了を忘れると不要なEC2・EBS費用が発生し続けます。検証完了後は速やかに「終了」操作を実施してください。DRSコンソールからドリルインスタンスの一覧を確認し、残存していないかを定期チェックすることを推奨します。

推奨実施頻度

少なくとも四半期に1回のドリルを実施し、Vol1（Resilience Hub）で策定したRTO/RPO目標と照合します。ドリル結果（実際の起動時間・復旧後の動作確認結果）をログに残し、RTOの実測値として蓄積することで、目標値との乖離を早期検出できます。ドリルを実施しないまま本番フェイルオーバーに臨むことは、練習なしに本番を迎えるのと同義です。定期ドリルによるRTO実測と手順確認が、DRS活用の核心です。

APIによる実行例

aws drs start-recovery \
  --source-servers '[{"sourceServerID":"s-XXXXXXXX"}]' \
  --is-drill true

コンソール操作とAPIのどちらも同一のバックエンド処理が実行されます。EventBridgeルールやLambdaと組み合わせることで、定期ドリルの自動実行も実現できます。詳細なAPIパラメータは公式ドキュメントを参照してください。

4-2. フェイルオーバー — 本番DR実行でリカバリインスタンスを起動する

フェイルオーバーは、実際の障害・災害時に「リカバリインスタンスをAWSで起動する」操作です。ドリルと実行手順は類似していますが、本番影響を伴う点が根本的に異なります。

フェイルオーバーがDRSの担当範囲

DRSのフェイルオーバー操作が行うのは「リカバリインスタンスの起動」です。トラフィックの切替（Route 53のフェイルオーバーレコード変更やELBのターゲット切替など）はDRSの外側で実施します。DRSはEC2リカバリインスタンスを正常に起動する責務を持ち、その後のトラフィック切替は運用チームが担当します。

Route 53/ELBを使ったトラフィック切替設計はこちら（レジリエンス/DR Vol1）

フェイルオーバーの実行ステップ

1. DRSコンソールで対象ソースサーバーを選択します
2. 「Start Failover」アクションを実行し、リカバリ時点を選択します（最新または特定スナップショット）
3. リカバリインスタンスが起動するまで待機します
4. Post-Launch Actionsが設定されている場合、自動で追加処理（エージェント導入・設定適用など）が実行されます
5. リカバリインスタンスの動作確認後、Route 53・ELBなどでトラフィック切替を実施します

RTOとRPOの実測

フェイルオーバー実行時に「フェイルオーバー開始〜リカバリインスタンス起動完了」の時間を計測し、RTOの実測値として記録します。RPOは「最後に複製が完了したブロック書き込みタイムスタンプ」と「障害発生時刻」の差分で算出します。この実測値をVol1のResilience Hub評価結果と突き合わせることで、RTO/RPO達成状況を定量的に把握できます。

APIによる実行例

aws drs start-recovery \
  --source-servers '[{"sourceServerID":"s-XXXXXXXX"}]' \
  --is-drill false

--is-drill falseがフェイルオーバーの識別子です。ドリルと実行コマンドはほぼ同一で、このフラグの違いのみです。誤操作防止のためにも、ドリルとフェイルオーバーの実行ポリシー（誰が・どの承認を得て実行するか）をRunbookに明記しておくことを推奨します。

4-3. ポイントインタイムリカバリ（PITR）— 特定時点への復元

ポイントインタイムリカバリ（PITR）は、フェイルオーバーまたはドリルの実行時に「最新時点ではなく、過去の特定スナップショット時点」で復元する機能です。操作として独立したコマンドが存在するのではなく、ドリル/フェイルオーバーの実行時にリカバリポイントを選択することで実現します。

なぜ特定時点への復元が必要か

最も多い利用シナリオがランサムウェア感染への対応です。ランサムウェアが検知された場合、最新の複製データにもすでに感染ファイルが含まれている可能性があります。感染時刻より前の健全なスナップショットを選択して起動することで、暗号化前の状態に復元できます。

その他にも、ソフトウェアの誤デプロイやデータ破損が発生した場合に、問題発生前の特定時点への巻き戻しが可能です。継続的レプリケーションが「いつでも任意の時点に戻れる」という保険として機能する点がDRSの強みのひとつです。

利用可能なリカバリポイント

DRSは継続的ブロックレプリケーションの中でスナップショットを定期的に取得します。DRSコンソールでは「Recovery Points」として時系列順のスナップショット一覧が表示されます。保持されるリカバリポイント数と保持期間はAWS側の仕様で決まります（★最新の保持仕様は公式ドキュメントで確認してください）。

PITRの選択方法

ドリルまたはフェイルオーバーの実行画面で「Recovery point」オプションを選択します。

• Use most recent: 最新の複製時点で復元（デフォルト）
• Use a specific point in time: リカバリポイント一覧からスナップショットを選択して復元

ランサムウェア対応では感染タイムラインを正確に把握したうえで、感染前のリカバリポイントを選択することが重要です。感染時刻が不明な場合は、複数のリカバリポイントでドリルを実施して安全な時点を特定する方法も有効です。

APIによる実行例

aws drs start-recovery \
  --source-servers \
 '[{"sourceServerID":"s-XXXXXXXX","recoverySnapshotID":"rsn-YYYYYYYY"}]' \
  --is-drill false

recoverySnapshotIDを指定することで、特定のスナップショット時点への復元が可能です。スナップショットIDはDRSコンソールの「Recovery Points」画面またはAPIで取得できます。

4-4. フェイルバック — 障害収束後に元ソースへ復帰する

フェイルバックは、障害が収束しリカバリインスタンスで本番稼働が安定した後に「元のソース環境へ業務を戻す」操作です。フェイルバックはDRサイクルの最終ステップであり、フェイルバックなしでは「AWS上のリカバリインスタンスが本番環境として永続稼働」という本来意図しない状態が続きます。

フェイルバックの前提確認

フェイルバックを開始する前に以下を確認します。

• リカバリインスタンスが安定稼働し、本番データの書き込みが継続していること
• 元のソース環境（オンプレサーバーやvSphere VM等）が復旧可能な状態であること
• フェイルバック先へのネットワーク経路（Direct Connect/VPN）が再確立されていること

逆方向レプリケーションの開始

DRSコンソールで「Initiate Failback」を実行すると、DRSはリカバリインスタンス（AWS）からソース環境（オンプレ/他クラウド）への逆方向レプリケーションを開始します。逆方向レプリケーション中は、リカバリインスタンスへの書き込みがソース環境へ継続的に複製されます。これにより、フェイルバック切替時点でのデータ損失を最小化します。

フェイルバック専用エージェントの導入

オンプレミスのソース環境へフェイルバックする場合、対象サーバーへ「フェイルバックエージェント（Failback Client）」の導入が必要です。フェイルバックエージェントはフェイルバック用の一時的なブータブルシステムとして機能し、リカバリインスタンスのディスク内容をソースに書き戻します。

• フェイルバックエージェントはDRSコンソールからダウンロードし、対象ソースサーバーのライブCDまたは専用インスタンスから起動します
• VMware環境ではvSphereのVM設定に合わせた手順が必要です（★最新手順は公式ドキュメントを参照）

フェイルバックのステップ

1. DRSコンソールで「Initiate Failback」を実行し、逆方向レプリケーションを開始します
2. ソース環境の復旧準備（サーバー起動・ネットワーク疎通確認）を実施します
3. フェイルバックエージェントをソース環境に導入します
4. 逆方向の複製が完了したことを確認し、実際のカットバック（Failback）を実行します
5. トラフィックをリカバリインスタンスからソース環境へ切り戻します（Route 53/ELBで実施）
6. リカバリインスタンスを停止・削除し、DRSのソースサーバーとして元の設定を復元します

4操作の使い分け — 状況別の選択指針

4種の操作を正しく使い分けるための早見表です。

判断フロー

• 定期テスト → ドリル（本番影響なし）
• 本番障害・確実なデータで復旧 → フェイルオーバー（最新時点）
• データ破損・ランサムウェア感染 → フェイルオーバー（PITRで時点指定）
• 障害収束・元環境へ戻す → フェイルバック

この4操作を正しく把握しておくことで、DR計画書に「どの操作を・いつ・誰が・どのシステムに対して実行するか」を明記でき、実際の障害時に迷わず行動できます。定期ドリルでRTOを実測し、フェイルオーバー・フェイルバック手順をRunbookに落とし込んでおくことがDRS活用の要です。

5. オーケストレーション&自動化 — Recovery Plans・Launch templates

複数のサーバーを協調してリカバリする場面で、個別の起動操作を手動で行うことは困難です。DRSでは「Recovery Plans」「DRS Launch Settings」「EC2 Launch Template」「Post-Launch Actions」を組み合わせることで、複雑な依存関係を持つシステムを体系的にリカバリできます。本節ではこれらの機能を詳しく解説し、マルチリージョン戦略とAPI自動化による高度なDRオーケストレーション設計を説明します。

5-1. Recovery Plans — 複数サーバーの順序起動制御

Recovery Plansとは

DRSのRecovery Plansは、複数のソースサーバーをグループ化し、リカバリ時の起動順序と依存関係を定義する機能です。データベース・アプリケーションサーバー・Webフロントエンドといった依存関係を持つシステムでは、正しい順序での起動が不可欠です。Recovery Plansを事前に設計しておくことで、フェイルオーバー時の手動操作ミスを排除し、RTO短縮を実現します。

グループの概念と設計

Recovery Plansはグループ単位で起動順序を制御します。グループ内のサーバーは並列起動され、グループの処理が完了してから次のグループが起動します。典型的な3層Webアプリケーションでは、以下のようにグループを設計します。

• グループ1（データ層）: RDSやデータベースサーバーを配置します。後続グループの依存先となるため最初に起動します。
• グループ2（アプリケーション層）: APIサーバーや業務ロジックサーバーを配置します。グループ1の起動完了を待ってから起動します。
• グループ3（フロントエンド層）: WebサーバーやALBターゲットとなるサーバーを配置します。グループ2のヘルスチェック完了後に起動します。

グループ間の待機時間はRecovery Plan上で設定できます。各グループ後に一定時間のウェイトを挿入することで、起動直後の初期化処理が完了するまで次のグループ起動を抑制できます。

グループ設計の実践ポイント

同一グループ内のサーバーは並列起動するため、相互に依存するサーバーを同一グループに配置しないよう注意します。例えばMySQLのプライマリとレプリカを同一グループに入れると競合するケースがあるため、グループを分けた設計が安全です。

Recovery Plansには最大50台のサーバーを含められます。大規模システムではグループ数と各グループのサーバー台数を設計段階でシミュレーションし、RTO目標に収まる構成を事前検証します。

Recovery Plansは定期ドリルの際にも機能します。本番フェイルオーバーと同じPlansを使ってドリルを実施することで、起動順序の妥当性と各グループの所要時間を継続的に測定できます。

5-2. DRS Launch Settings — 起動前設定の標準化

Launch Settingsの役割

DRS Launch Settingsは、各ソースサーバーのリカバリインスタンスをどのEC2設定で起動するかを事前に定義する機能です。フェイルオーバーやドリルの都度設定を確認する必要がなくなり、設定ミスによるリカバリ失敗を防ぎます。

設定項目

DRS Launch Settingsで設定できる主要項目は以下の通りです。

インスタンスタイプ: ソースサーバーの要件に合わせてEC2インスタンスタイプを指定します。ドリル用に低コストのインスタンスタイプを設定し、フェイルオーバー時にプロダクション相当のタイプへ切り替える構成も可能です。テスト環境ではコスト削減を優先し、本番フェイルオーバー時に適切なスペックへ変更するパターンが広く採用されています。

ターゲットサブネット: リカバリインスタンスを起動するVPCのサブネットを指定します。ステージングエリアのサブネットとは別に、本番トラフィックを受け付けるサブネットを事前に用意して設定します。

セキュリティグループ: リカバリインスタンスに適用するセキュリティグループを指定します。ソース環境のセキュリティグループと同等のインバウンド/アウトバウンドルールをリカバリ先VPCで事前に用意しておく必要があります。

IAMインスタンスプロファイル: EC2に付与するIAMロールを指定します。アプリケーションからAWSサービスへのアクセスに必要な権限を持つIAMロールを事前設定します。ソース環境と同等の権限を持つロールをリカバリ先アカウントに用意しておきます。

EBSボリューム設定: リカバリ時に使用するEBSボリュームタイプとサイズを設定します。ソース環境から変換・調整できるため、コスト最適化のためにgp3への変更なども検討できます。

設定のバージョン管理と定期レビュー

Launch Settingsはインフラ変更に合わせた定期的なレビューが必要です。ソース環境でインスタンスタイプを変更した場合や、VPCを再設計した場合は、Launch Settingsも同期して更新します。インフラをコードで管理している環境ではTerraform等でLaunch Settings設定をコード化し、ドリフト検知の対象に含めることを推奨します。

5-3. EC2 Launch Template連携 — 起動設定の標準化とバージョン管理

Launch TemplateとDRSの連携

DRS Launch SettingsはEC2 Launch Templateと連携させることで、より詳細な起動設定をバージョン管理できます。Launch Templateにはユーザーデータ（起動スクリプト）・タグ付け・配置グループ設定など、DRS Launch Settings単独では設定できない項目を含められます。

Launch Template設計のポイント

Launch Templateでは「DR用」と「本番用」でテンプレートを分けることを推奨します。DR用テンプレートには以下の差分を含めます。

ユーザーデータ: DRリカバリ固有の初期化処理を記述します。設定ファイルのエンドポイント切り替え、レプリカDBから本番DBへの接続先変更、ログ出力先の変更などをスクリプト化します。

タグ付け: Environment: DR、LaunchType: DRS 等のタグをDR起動インスタンスに付与することで、本番インスタンスとの識別を明確にします。コスト配分タグとしても活用できます。

テナンシー設定: ドリル時はデフォルトテナンシー、フェイルオーバー時は本番要件に合わせた設定を選択します。専有ホストを使用している環境では事前に確認が必要です。

バージョン管理の活用

Launch Templateのバージョン管理によって、前回ドリル時の設定に戻せる安全ネットを確保できます。新しいLaunch Template設定は必ずドリルで検証してからフェイルオーバー用に昇格させます。設定変更の履歴がバージョンとして残るため、問題発生時の原因特定にも役立ちます。

5-4. Post-Launch Actions — リカバリ後の自動処理

Post-Launch Actionsの概要

Post-Launch Actionsは、DRSがリカバリインスタンスを起動した後に自動実行する処理を定義する機能です。起動直後のEC2はアプリケーションが完全な稼働状態になっていない場合があります。Post-Launch Actionsを使うことで、ヘルスチェックの確認・設定ファイルの適用・通知の送信といった処理を自動化できます。

実装できるアクションの種別

SSMドキュメントの実行: AWS Systems Managerのドキュメントを使って、インスタンス上でシェルスクリプトやPowerShellスクリプトを実行します。ミドルウェアの起動確認・接続先データベースのエンドポイント切り替え・ログ収集エージェントの設定変更などに活用します。

ヘルスチェックの実施: アプリケーションの起動確認URLにHTTPリクエストを送り、正常レスポンスを確認します。ヘルスチェックが通過するまでRecovery Planの次グループ起動を待機させることで、依存関係の整合性を保ちます。

通知の送信: SNSトピックやチャットツールへの通知送信を自動化し、リカバリ担当者への即時連絡を実現します。フェイルオーバーの進捗をリアルタイムで追跡できるため、対応チームの負担を軽減できます。

Post-Launch Actions設計の注意点

Post-Launch Actionsの実行にはSSMエージェントがリカバリインスタンス上で動作している必要があります。ソース環境のOSイメージにSSMエージェントが含まれているか事前に確認し、含まれていない場合はユーザーデータまたはLaunch Templateでインストールスクリプトを設定します。

実行タイムアウトは適切に設定します。起動に時間のかかるアプリケーション（JVMを使用するJavaアプリ等）では、デフォルトのタイムアウト値ではPost-Launch Actionsが失敗と判定される場合があります。定期ドリルで実際の起動時間を計測し、余裕を持ったタイムアウト値を設定します。

Post-Launch Actionsが失敗した場合の挙動も設計段階で決定します。失敗を検知した時点でアラートを発し、手動介入の手順書と合わせて運用フローを整備します。

5-5. マルチリージョン戦略 — リージョン障害への備え

マルチリージョンDRSの概念

DRSのデフォルト設定は、オンプレミスや別クラウドからAWS上のターゲットリージョンへのレプリケーションです。リージョン全体が影響を受ける大規模障害に備える場合、プライマリリージョンとは地理的に離れたセカンダリリージョンへのDRS複製設定が有効です。

設定方針

マルチリージョン構成では、各リージョンに対して独立したDRS設定を持ちます。プライマリリージョンのDRSがリージョン障害で利用できない場合でも、セカンダリリージョンのDRS設定から独立してリカバリを実行できます。

リージョン間のレプリケーションには追加の帯域コストとレイテンシが発生します。RPO目標を満たせる帯域を確保するために、DRS設定で帯域割り当てを適切に設定します。初回フルコピーの所要時間も事前に見積もり、スケジュールを計画します。

フェイルバックの設計

セカンダリリージョンでリカバリインスタンスが稼働した後、障害が収束した際には元のプライマリリージョンへのフェイルバックが必要です。マルチリージョン構成でのフェイルバック手順は複雑になるため、事前にドリルを通じて手順を確認し、フェイルバック用のRecovery PlanとLaunch Settingsも整備しておきます。

5-6. マルチAZ考慮 — DRSとAuto Scalingの役割分担

DRSはAZ障害の対策ではない

DRSはサーバー全体の複製と切替を行うディザスタリカバリサービスであり、AZ障害への対応には設計上適していません。AZ障害時の自動復旧にはEC2 Auto ScalingとELBを活用する設計が標準的です。この役割の違いを明確にしておくことで、設計の重複とコストの無駄を防げます。

障害スコープ別の役割分担

以下のように障害スコープで役割を分けることを推奨します。

• AZ障害: EC2 Auto Scalingによる別AZへの自動再起動とELBのヘルスチェックによるトラフィック切り替えで対応します。DRSは不要です。
• リージョン障害 / オンプレミス全体の障害 / 他クラウドからのAWS移行時のDR: DRSによるリカバリが有効です。

この役割分担をRecovery Plansの設計に反映させます。AZ内冗長はアーキテクチャ側で解決済みとし、DRSはリージョンをまたぐ大規模障害への対応に集中させる設計がコスト効率と運用性の両立につながります。

AZ障害への対応設計については、マルチリージョン・マルチAZ構成の関連記事も合わせて参照してください。

マルチリージョン/マルチAZ設計の詳細はこちら

5-7. API/SDK/EventBridge自動化

DRS APIによる自動化の概要

DRSはAWS SDKおよびAPIを通じて、ドリル実行・フェイルオーバー・フェイルバックなどの主要操作をプログラマティックに制御できます。EventBridgeと組み合わせることで、特定のイベント（例: Resilience Hubのドリフト検知やCloudWatchアラーム）をトリガーにした自動フェイルオーバーパイプラインを構築できます。

Lambdaを使ったDRS API呼び出しの詳細な実装手順は、既存のLambda関連記事を参照してください。

Lambda実装パターンの詳細はこちら（サーバーレス本番運用 — Lambda/API Gateway/Step Functions）

自動化設計のベストプラクティス

自動フェイルオーバーは誤トリガーによる意図しない切替リスクを伴います。本番環境では以下の安全策を組み込みます。

承認ゲートの挿入: Step Functionsを使い、自動フェイルオーバーの前に担当者承認ステップを挿入します。緊急時は承認をバイパスできるフローも用意しつつ、通常時は必ず人間の確認を経るよう設計します。

複数指標での判定: 単一のCloudWatchアラームではなく、複数のメトリクスを組み合わせた判定ロジックを設計します。ネットワーク一時断やスパイク負荷による誤検知を排除するために、閾値超過の継続時間条件も加えます。

自動化パイプライン自体のドリル: 自動化パイプラインそのものも定期的にドリルで検証します。パイプラインのコードやEventBridgeルールの変更後は必ず動作確認を行います。

Vol1のResilience Hubで設定したRTO/RPOポリシーと整合した自動化設計にすることで、DR目標達成の確実性を高めます。

6. 運用・監視・コスト設計

レプリケーションヘルスの監視

DRSの運用において最も重要なのは、レプリケーションが正常に継続していることの継続的な確認です。レプリケーションが停止・劣化していると、実際の災害時に複製が古い状態になっており、RPO目標を達成できません。

DRSコンソールによるステータス確認

DRSコンソールの「Source servers」一覧で各ソースサーバーのレプリケーション状態をリアルタイムで確認できます。

StalledやDisconnectedは即時P1対応が必要です。放置するとRPOが時間単位で劣化します。

コンソールの「Last lag」列で現在のRPO実測値(最後のcrash-consistent時点からの経過時間)を確認できます。RPO目標との乖離を定期監視します。

CloudWatch メトリクスによる定量監視

DRSはCloudWatchにメトリクスを自動発行します。以下のメトリクスを中心にアラームを設定します。

ElapsedReplicationDurationがRPO目標を超えた場合は即時アラームを設定します。ReplicationBacklogSizeの急増は帯域不足のサインです。

★ CloudWatchのDRSメトリクス一覧・ディメンション仕様は変更される場合があります。公開時にAWS公式ドキュメントで最新を確認してください。

EventBridge イベント連携

DRSはステータス変化をEventBridgeへイベントとして発行します。EventBridge Ruleを使って通知・自動対応を実装します。

主なEventBridgeイベント:

• DRS Source Server Status Changed — ソースサーバーのレプリケーション状態変化
• DRS Recovery Instance Status Changed — リカバリインスタンス状態変化
• DRS Launch Status Changed — 起動(ドリル/フェイルオーバー)の状態変化
• DRS Failback Status Changed — フェイルバックの状態変化

EventBridge RuleでイベントをフィルタしてSNSトピックへルーティングすることで、Slack・メール・PagerDutyへの即時通知が可能です。Lambdaを連携させると自動復旧スクリプトも実行できます。

アラート設計

DRSの運用アラートを重要度3段階で設計します。

Level 1 — 即時対応(P1 Critical):

• エージェント切断(Disconnected): ソースサーバーとの通信切断。RPO積算が即時停止
• 複製停止(Stalled): 帯域不足・ネットワーク障害等によりデータ複製が完全に停止
• ステージングEBSストレージ容量不足: 拡張またはアーカイブが必要

Level 2 — 当日対応(P2 Warning):

• RPO目標超過: ElapsedReplicationDurationがRPO目標値(例: 15分=900秒)を超過
• 複製バックログ急増: ReplicationBacklogSizeの急増により未送信データが積み上がっている
• エージェントバージョン古い: セキュリティ・安定性の観点からエージェント更新を推奨

Level 3 — 週次確認(P3 Info):

• ドリル未実施期間超過: 前回ドリルから規定期間(例: 3ヶ月)以上経過している
• ポイントインタイムスナップショット保持数が設定下限に近い

CloudWatch Alarmをそれぞれのメトリクスに設定し、SNSトピック経由でオペレーターへ通知するシンプルな構成から始めます。Level 1はオンコール通知、Level 2はメール通知、Level 3はダッシュボード記録のみとするなど、重要度に応じた通知ルーティングを設計します。

定期ドリルの運用設計

定期ドリルは「DRが実際に機能すること」を継続的に検証する最も重要な運用活動です。ドリルを怠ると構成変更による劣化に気づけません。

ドリルの実施方針

DRSドリルは本番のソースサーバーや継続複製に影響を与えない非破壊テストです。ドリルインスタンスを起動してアプリケーション動作を確認し、終了後にドリルインスタンスを削除します。

ドリル手順の概要

1. DRSコンソールの「Source servers」で対象サーバーを選択
2. 「Start drill」を実行し、復旧時点(最新 or 過去のポイントインタイム)を選択
3. DRS Launch Settingsに従ってドリルインスタンスを起動
4. 起動完了後、アプリケーション動作確認・RTO測定(起動指示〜疎通確認完了までの時間を計測)
5. 確認完了後「Terminate drill instances」でドリルインスタンスを削除
6. ドリル記録シートに結果を記録(RTO実測値/発見事項/対応事項)

ドリル中もソースサーバーの継続複製は停止しません。本番影響ゼロで実施できます。

ドリル結果の活用

測定したRTO実測値をVol1のResilience Hubで設定したRTO目標値と照合します。

• RTO実測 < RTO目標: 問題なし。次回ドリルまで監視継続
• RTO実測 ≈ RTO目標(余裕5%以内): 警告。Launch Settings見直しとPost-Launch Actions最適化を検討
• RTO実測 > RTO目標: 即時改善。起動順序の見直し・インスタンスタイプ変更・Post-Launch Actions並列化等を実施

ドリル結果のRTO実測値を定期的にResilience Hubのドリフト評価にフィードバックすることで、DR目標のポリシーベース管理が実現します。

ドリルコスト

ドリルインスタンス起動中はEC2インスタンス料金とEBSボリューム料金が発生します。数時間以内に終了すれば料金は限定的です。月次ドリルのコストを事前試算してドリル予算に組み込みます。

コスト構造の理解

DRSのコストは以下の4要素から構成されます。

コスト要素1 — レプリケーション料金(最大の比重)

常時レプリケーション中のソースサーバーごとに時間課金が発生します。以下の要素には依存しない一律料金です。

• ディスク枚数・容量に依らない
• ドリル実施回数・頻度に依らない
• データ変更量(差分サイズ)に依らない
• 対象リージョンによって単価が異なる場合あり

コスト要素2 — ステージングエリアのEBSストレージ

ステージングエリアに保持されるEBSボリュームのストレージ料金です。ソースのディスク容量に比例して増加します。大容量ディスクを持つサーバーを多数登録するほどストレージコストが増加します。

コスト要素3 — ドリル/フェイルオーバー時のEC2/EBS料金

ドリルインスタンスやリカバリインスタンスを起動している間のEC2インスタンス料金とEBS料金です。インスタンスを終了すると停止します。平時には発生しないコストです。

コスト要素4 — データ転送料金

オンプレミスやGCPなど外部からAWSへのレプリケーションデータ転送料金です。転送量・経路(Direct Connect/インターネット)によって変動します。AWS内のリージョン間DR(例: ap-northeast-1からap-northeast-3)の場合も、クロスリージョン転送料金が発生します。

★ DRSの具体的な単価は変更される場合があります。公開時にAWS公式料金ページで最新を確認してください。

コスト最適化の実践

最適化1 — 不要ソースサーバーの除外(最優先)

定期的にDRS登録サーバーを棚卸しし、廃止済みや保護不要なサーバーを削除します。レプリケーション料金がサーバー台数×時間に比例するため、不要サーバー削除が最も直接的な削減策です。

最適化2 — ステージングインスタンスタイプの最小化

ステージングエリアのインスタンスタイプは複製データを受け取るための最小構成にします。本番インスタンスと同スペックにする必要はありません。最小インスタンスタイプで複製が安定するか定期確認します。

最適化3 — ドリル時間の最小化

月次ドリルを実施する場合、アプリケーション確認が完了したらすぐにドリルインスタンスを削除します。長時間起動したままにするとEC2料金が積み上がります。

最適化4 — リージョン最適化

DRSのステージングエリアは料金の低いリージョンへ配置することでストレージ・転送コストを削減できます。ただし、RTOへの影響(レプリケーション転送レイテンシ・フェイルオーバー時のルーティング)と料金のトレードオフを慎重に検討します。

Lambda自動ドリルの実装パターン

定期ドリルの自動化にはEventBridgeスケジュールとLambdaを組み合わせる構成が一般的です。

# 自動ドリルの処理フロー概要
# EventBridge Scheduled Rule → Lambda → DRS API

# 1. ドリル開始
drs_client.start_recovery(
 sourceServers=[{"sourceServerID": server_id}],
 isDrill=True,
 tags={"Purpose": "scheduled-drill"}
)

# 2. 起動確認(ポーリング or EventBridge待機)
# drs_client.describe_recovery_instances(...)

# 3. アプリケーション疎通確認(SSM Run Command / HTTP確認)

# 4. RTO計測結果をCloudWatch Metricsへ送信

# 5. ドリルインスタンス削除
# drs_client.terminate_recovery_instances(...)

Lambda関数の詳細な実装手順は既存のServerless解説記事を参照してください。

Lambdaの実装基礎はこちら（Serverless本番運用 — Lambda × API Gateway × Step Functions）

自動ドリル運用の注意点:

• ドリルインスタンスは確認後に必ずTerminateRecoveryInstancesで削除する。削除漏れはEC2料金の継続発生につながります
• ドリル失敗(疎通確認不可等)はEventBridge/SNSで即時アラート通知を設定します
• ドリル結果(RTO実測値/成否/発見事項)をS3またはCloudWatch Logsへ記録し、後から参照できるようにします
• 自動ドリルの実行ログはResilience Hubのドリフト評価と連携させることで、DR目標の継続的な監視に活用できます

7. 実戦統合パターン — 既存DR部品との組合せ設計

7-1. Resilience Hub(Vol1)との連携サイクル

DRS単体でのDR実装を最大限に活かすには、Vol1で取り上げたAWS Resilience Hubとの連携が鍵となります。Resilience HubはRTO/RPOポリシーを定義し、アプリケーションの「設計上の回復性」を継続的にアセスメントするサービスです。DRSはその設計上の目標を実際の複製・切替として実装するサービスという位置付けになります。

連携の基本サイクル:

1. 上流設計(Vol1 — Resilience Hub): アプリケーションに対してRTO/RPO目標を定義し、現状のアーキテクチャが目標を達成できるかを評価します。「DRSによるアクティブ-パッシブ構成」が推奨アクションとして提示された場合、本Vol2の手順で実装します
2. 実装(Vol2 — DRS): Resilience Hubの評価に基づいてDRSを構成します。エージェント導入・ネットワーク要件・レプリケーション設定・Recovery Plansの設定を完了します
3. 検証(DRSドリル): ドリルを実施してRTO実測値を取得します。定期的なドリルによりRTO/RPOが目標範囲内に収まっていることを確認します
4. 継続評価(Resilience Hub再評価): DRS構成後にResilience Hubでアプリケーションを再評価します。回復性スコアが目標値に到達したことを確認します
5. ドリフト検知: アーキテクチャ変更やリソース追加があった際にResilience Hubが再評価し、DRS設定とのずれ(ドリフト)を検知します。ドリフトが検知された場合はDRS設定を更新して整合を維持します

このサイクルにより「設計 → 実装 → 検証 → 継続監視」の回復性管理ループが完成します。Vol1の上流設計とVol2の実装を連動させることで、DR設計は机上の計画ではなく実際の復旧能力として機能します。

上流のRTO/RPO設計・Resilience Hub評価はこちら（Vol1）

7-2. DRS + AWS Backup の相補設計

DRSとAWS Backupは似て非なるサービスであり、設計上は相補的に使い分けることで包括的なデータ保護を実現します。

組み合わせ設計の原則:

• DRSはサーバー全体のDR: 障害時にサーバー丸ごと別リージョンで起動させる用途に使います。アプリケーション全体の一括切替が主な目的です
• AWS BackupはデータDR: RDS・EFSの個別バックアップや長期保管(7年保持等のコンプライアンス要件)はBackupで管理します
• 重複レプリケーションを避ける: DRSですでにブロックレプリケーションしているEBSに対して別途Backupジョブを追加する場合は、コスト増とその必要性を慎重に判断します

この相補設計により「インフラ全体の切替(DRS)」と「データ個別の保護・長期保管(Backup)」の両軸をカバーできます。

AWS BackupによるクロスリージョンDRの詳細はこちら

7-3. DRS + FIS によるDR切替の完全検証サイクル

AWS FIS(Fault Injection Service)はカオスエンジニアリングツールであり、意図的な障害注入によってシステムの回復性を検証します。DRSのドリル機能と組み合わせることで、実際の障害発生から復旧までの完全なサイクルを事前に演習できます。

DRS + FIS の連携パターン:

1. FISで障害注入: FISの実験テンプレートを使用して、ソース環境のEC2インスタンス停止やネットワーク遮断を意図的に発生させます
2. DRSのドリルをトリガー: 障害注入後、DRSコンソールまたはAPIでドリルを開始します。ドリルインスタンスが起動し、アプリケーションが機能することを確認します
3. RTO計測: 障害検知からドリルインスタンスの稼働確認までの時間を計測し、Vol1で設計したRTO目標と比較します
4. 復旧検証と後片付け: 検証完了後にドリルインスタンスを削除し、ソース環境のレプリケーションが「Synced」状態に戻ったことを確認します

FISを使ったカオステストにより、DR手順書の手順漏れや担当者の不慣れを事前に洗い出すことができます。定期的な演習によってインシデント発生時の対応品質を維持します。

FISを使ったカオスエンジニアリングの詳細はこちら

7-4. Multi-regionとの使い分け — アクティブ-アクティブ vs アクティブ-パッシブ

DRSはアクティブ-パッシブ構成を前提とした災害復旧サービスです。常時マルチリージョン稼働(アクティブ-アクティブ)とは根本的に異なるアーキテクチャであり、要件に応じた使い分けが重要です。

選定の判断基準:

• RTOが数分以内かつコストより可用性を優先 → アクティブ-アクティブ(Multi-region)
• RTOが数分〜十数分許容できてコスト効率を重視 → アクティブ-パッシブ(DRS)
• オンプレミス・他クラウドからのDR構築 → DRS(エージェントベースで柔軟に対応)

7-5. 実際のDR発動シナリオ

DRSが実際に機能するシナリオは大きく三種類に分類されます。それぞれの特性を理解し、対応手順を事前に整備しておくことが重要です。

シナリオ①: リージョン障害

AWSリージョン全体またはアベイラビリティゾーンの大規模障害が発生した場合のDR発動シナリオです。ソースがAWS上のEC2の場合も、DRSのステージングが別リージョンにあれば切替が可能です。

• 障害検知 → DRSコンソールで「フェイルオーバー(Failover)」を選択
• リカバリインスタンスが復旧先リージョンで起動
• DNS切替またはロードバランサー変更でトラフィックを転送
• 障害収束後にフェイルバックを実施

シナリオ②: ランサムウェア・論理障害

ランサムウェアや誤操作による論理破損が発生した場合は、「ポイントインタイムリカバリ」が有効です。感染前のスナップショット時点を選択し、クリーンな状態でリカバリインスタンスを起動します。

• 感染検知 → 即座にソースサーバーをネットワークから切断(DRSレプリケーションも一時停止)
• DRSで感染前の時点のスナップショットを選択
• リカバリインスタンスを起動しクリーン状態を検証
• 検証後に本番トラフィックを切替、フェイルバックで元環境を修復

シナリオ③: 計画的な移行・メンテナンス

オンプレミスからAWSへの移行(リフトアンドシフト)や計画的なリージョン移行でもDRSが活用できます。本番影響ゼロで移行先環境を構築し、メンテナンスウィンドウ中に計画的にフェイルオーバーを実施します。移行完了後はDRSを解除し、通常のAWSネイティブ構成へ移行します。

7-6. DR部品選定フロー概説

本節で整理した各DR手法の選定は、以下の観点を起点に判断します。詳細なアンチパターンと選定マトリクスは§8で解説します。

選定の主要判断軸:

1. 保護対象の粒度: サーバー全体か / 特定データ・サービスか
2. RTO要件: ニアゼロか / 数分〜十数分許容か
3. 常時稼働要件: 常時マルチリージョン稼働が必要か / 待機でよいか
4. ソース環境: オンプレ・他クラウドか / AWS上のリソースか
5. コスト許容度: 低コスト待機を優先か / 可用性最大化を優先か

DRS・AWS Backup・Multi-region・Resilience Hubの四部品を正しく組み合わせることで、RTO/RPO目標を満たしながらコストを最適化した包括的なDR設計が実現します。各部品の詳細な使い分けフローは§8のアンチパターン・まとめ節で整理します。

DR部品選定の早見表:

DR設計の三段階:

本記事を通じて見えてきたDR設計の考え方は三段階に整理できます。

1. 設計(What to protect): Resilience HubでRTO/RPO目標を設定し、保護対象とDR方式を決める
2. 実装(How to protect): DRS・Backup・Multi-regionの適切な組み合わせで実際の保護を構築する
3. 検証(Prove it works): DRSドリル・FISカオステストで実測RTO/RPOを検証し、Vol1のResilience Hubで継続評価する

この三段階のサイクルを繰り返すことで、事業継続計画(BCP)が書類上の目標から実際の復旧能力へと昇華します。

個別データのバックアップDRはこちら（AWS Backup クロスリージョンDR）

DR切替のカオステストはこちら（AWS FIS カオスエンジニアリング）

8. つまずきポイント・アンチパターン・まとめ

つまずきポイント1: 初回同期の帯域計画を怠る

エージェントを導入するとすぐにレプリケーションが開始しますが、初回同期は全ブロックのフル転送です。ソースディスクが100GBあれば、利用可能な帯域が100Mbpsの場合でも理論上2.2時間以上の転送時間が必要です（実際のオーバーヘッドを含むとさらに長くなります）。この間、ソース側のネットワーク帯域が業務通信と競合し、業務影響を招くケースがあります。

症状:
– エージェント導入直後にソースサーバーのネットワーク帯域が逼迫する
– 「Protected」状態になるまでの時間が想定より大幅に長い
– 業務時間帯にユーザからレスポンス遅延の報告が入る

対処法:
– 初回同期は業務時間外（夜間・休日）に実施するよう計画する
– DRSレプリケーション設定で帯域スロットリングを設定し、業務帯域を確保する
– 初回同期前に「ソースディスク総容量 ÷ 割当帯域」で所要時間を見積もる
– Direct ConnectまたはVPN経由で専用帯域を確保することで業務影響を排除できる

つまずきポイント2: ドリルをせずに本番フェイルオーバー

最も重大な失敗パターンです。「レプリケーションが動いている＝フェイルオーバー成功」ではありません。ドリルなしで初めてのフェイルオーバーを本番障害時に実施すると、手順不備・IAM権限不足・ネットワーク設定ミス・Post-Launch Actions未設定によるアプリ不整合など、複数の問題が重なることで、復旧は大幅に遅延するリスクがあります。

症状:
– 本番フェイルオーバー時にリカバリインスタンスは起動したが、アプリが正常に動かない
– DBの起動順序の問題でサービス不全になる
– 想定RTOの数倍の時間がかかり、担当者が混乱する
– IAM権限エラーでリカバリインスタンスが起動できない

対処法:
– 本番運用開始前に必ず1回以上のドリルを実施する
– ドリルは非破壊テスト（ソース・継続レプリケーションに影響なし）なので安全に実施できる
– ドリル後はドリルインスタンスを必ず終了し、課金を最小化する
– 四半期または月次でドリルを定期スケジュール化し、手順書のアップデートを継続する

つまずきポイント3: ポイントインタイムスナップショットの選択を誤る

DRSのフェイルオーバー時は「最新スナップショット」または「指定した過去時点のスナップショット」を選択できます。ランサムウェア感染や誤ってファイルを削除した際は感染・削除前の時点を選ぶ必要がありますが、操作UIを誤って最古のスナップショット（データロスが最大）や最新（すでに汚染済み）を選ぶと、データロスが意図より大きくなります。

症状:
– フェイルオーバー後、ランサムウェアに感染した状態でインスタンスが起動する
– 必要以上に古い時点へ戻ってしまいデータ消失が増大する
– スナップショット一覧の並び順が直感に反していて誤選択を誘発する

対処法:
– ポイントインタイム選択のUIをドリルで事前に操作経験を積む
– スナップショット一覧の表示順序（新しい順/古い順）を事前確認する
– ランサムウェア対応時は感染検知時刻より1〜2時間前のスナップショットを選択するルールを文書化する
– フェイルオーバー前にチームで選択するスナップショットを合意するプロセスを設ける

つまずきポイント4: フェイルバック手順を設計しないままフェイルオーバー

DRSはフェイルオーバー（元サイト→AWS）だけでなく、フェイルバック（AWS→元サイト）の手順も事前設計が必要です。フェイルバック未設計でフェイルオーバーのみ実施すると、元サイト復旧後にAWSと元サイトのデータが乖離し、いつまでも元環境へ戻れない状況に陥ります。

症状:
– フェイルオーバー成功後、元のオンプレ環境が復旧してもAWSリカバリインスタンスとのデータ差分が把握できない
– フェイルバックをどう実行するか誰も把握しておらず、AWSで稼働し続けることになる
– 元環境とAWS環境でデータが乖離し、整合をとる方法がない

対処法:
– フェイルオーバー設計と同時にフェイルバック手順を文書化する
– DRSのフェイルバック機能（AWS→元ソースへの逆方向レプリケーション）を事前に確認する
– フェイルバックのRTO目標もVol1のRTO設計に含める
– ドリルの一環でフェイルバックのシミュレーションも実施する

つまずきポイント5: Recovery Plansを未作成で複数サーバーを手動復旧

複数サーバーで構成されるシステム（DB→アプリ→Webの3層等）を手動でフェイルオーバーすると、起動順序の管理が煩雑です。Recovery Plansを未作成のまま手動復旧を試みると、DBより先にアプリが起動してDB接続エラーが多発し、アプリの再起動が必要になるなどRTOが大幅に延びます。

症状:
– 複数サーバーのフェイルオーバー中、起動順序を誰が管理するか混乱する
– アプリがDBの起動完了を待てず接続エラーを多発させる
– 担当者のスキルにより復旧時間が大きくばらつく
– 手動実行のため特定手順の漏れが発生し、サービスが不完全な状態で立ち上がる

対処法:
– 本番運用開始前にRecovery Plansを作成し、起動グループ（DB先行・アプリ後続）を定義する
– Post-Launch Actionsでヘルスチェックスクリプトを組み込み、前段サーバーの準備完了を確認してから後段を起動する設計にする
– PlansはドリルとFailoverで共有利用でき、事前に動作確認できる

つまずきポイント6: ステージングEBS容量不足によるレプリケーション停止

ステージングEBSの容量がソースディスクより小さい、またはスナップショット蓄積により空きが不足すると、レプリケーションが停止します。停止を見落として放置すると、実際の災害時に古いデータからしか復旧できなくなります。

症状:
– DRSコンソールで特定ソースサーバーが「Stalled」または「Error」状態になっている
– CloudWatchアラートを設定していないため発見が遅れた
– レプリケーションラグの監視がなく、障害発生時に初めて気づく

対処法:
– ステージングEBSはソースディスク総容量の1.1〜1.2倍以上を確保する
– CloudWatchでレプリケーション状態メトリクスを監視し、アラームを設定する
– 定期的にDRSコンソールで全ソースサーバーの状態を確認する運用手順を組み込む
– スナップショット保持期間の設定を見直し、不要な古いスナップショットが蓄積しないよう管理する

つまずきポイント7: 対応OS・リージョンの非対応を設計段階で未確認

DRSがサポートするOSのバージョン・ディストリビューション、および利用可能なリージョンは随時変更されます。設計段階で確認していたOSが実装時点で非対応になっていたり、希望するリージョンへのレプリケーションが制限されている場合、設計の見直しが必要になります。

症状:
– エージェントインストールは完了したが、DRSコンソールでの登録が失敗する
– 特定のリージョンへのレプリケーション設定が選択できない
– 設計時にOSの対応確認をせず、実装フェーズで非対応が判明して設計変更を余儀なくされる

対処法:
– 設計段階だけでなく、実装開始前にも対応OS一覧と対応リージョン一覧をAWS公式ドキュメントで確認する
– 重要なソースサーバーのOS・バージョンをリスト化し、DRS対応状況をマッピングする
– 非対応OSのサーバーには代替DR方式（AWS Backup等）を検討する

つまずきポイント8: レプリケーション中のコスト積み上がりを見落とす

DRSのコスト構造は「保護対象サーバーの台数×時間」の継続課金です。ディスク枚数・容量・リージョン・ドリル回数に関わらず一定のサービス料金が積み上がります。サーバーを追加するたびにコストが増大しますが、増加分を事前に試算せず大規模保護を開始してしまうと、月次コストが予算を大幅に超過するケースがあります。

症状:
– DRS保護開始後の月次コストが事前予算を大幅に超過する
– 試験的に保護を開始したサーバーを削除せず放置しコストが積み上がる
– ステージングEBSのスナップショット蓄積によるストレージコストが想定外に増大する

対処法:
– 保護開始前にAWS Pricing Calculatorで月次コストを試算し、予算と照合する
– 本当に保護が必要なサーバーだけをDRSに登録し、試験用サーバーは終了したらDRS保護も解除する
– CloudWatchのCostExplorerアラートでDRS費用に上限を設定し、予算超過を事前検知する
– スナップショット保持数の設定を適切に絞り、EBSスナップショストレージコストを管理する

アンチパターン → 正解

まとめ

本記事では、AWS Elastic Disaster Recovery（DRS）を用いたDR実装の全体像を解説しました。

Vol1（上流設計）からVol2（DRS実装）への連環

Vol1ではAWS Resilience Hubを活用してRTO/RPO目標の策定・ポリシー設計・回復性アセスメントを実施しました。Vol2の本記事ではそのVol1の設計を実装に落とし込むステップとして、DRSの継続的ブロックレプリケーション・ステージングエリア設計・ドリル・フェイルオーバー・フェイルバック・Recovery Plansによるオーケストレーションを解説しました。

DRSを使いこなすための3つのポイント

1. ドリルの習慣化: レプリケーションが動いていても、ドリル未実施ではRTO/RPOの実値は不明です。四半期ごとのドリルでRTO/RPOを実測し、Vol1のResilience Hubポリシーと継続的に照合してください。

2. Recovery Plansによるオーケストレーション: 複数サーバーのDRは手動ではRTOが不安定です。Recovery Plansの起動グループとPost-Launch Actionsで依存関係を自動化することが、安定したRTO実現の鍵です。

3. コストの可視化と最適化: DRSはサーバー台数に比例したコストが継続的に発生します。保護対象の優先度を明確にし、本当に必要なサーバーだけをDRSで保護する判断も重要です。

この3つのポイントを軸に、Vol1のResilience Hubによる上流設計とVol2のDRS実装を組み合わせることで、書類上の目標に留まらない実際の復旧能力を継続的に維持できます。DR設計は「構築して終わり」ではなく、定期的な検証と改善のサイクルが事業継続計画（BCP）の実効性を支えます。

DRSを起点に、AWS BackupによるデータレベルのDR、AWS FISによるカオステスト、AWS Resilience Hubによる継続的な回復性評価を組み合わせることで、包括的なAWS上のレジリエンス運用体制を構築してください。

また、ドリルの結果をVol1のResilience Hub評価にフィードバックし、実測RTO/RPOが設計目標に収まっているかを継続的に検証するサイクルを運用に組み込むことが、DRSを本当に機能させる鍵となります。

DRの全体設計を深める関連記事

上流のRTO/RPO設計・Resilience Hub評価はこちら（レジリエンス/DR Vol1）

個別データのバックアップDRはこちら（AWS Backup クロスリージョンDR）

DR切替のカオステストはこちら（AWS FIS カオスエンジニアリング）

関連: マルチリージョン構成(アクティブ-アクティブ/パッシブ)