本稿は、2026 年 8 月 19 日に AWS Blog で公開された “Disaster Recovery for VMware Workloads on Amazon EVS” を翻訳したものです。

ビジネスクリティカルなワークロードを VMware 上で稼働させている多くの企業が、たった 1 度の障害が業務を中断し、顧客に影響を与え、収益と信頼を危険にさらし得ることを認識しています。災害復旧（DR）はその解決策であり、プライマリサイトがダウンした際に引き継ぐ準備が整ったセカンダリサイトを指します。しかし、従来その構築には多額の初期投資、長いハードウェアのリードタイム、そして本番環境との乖離が避けられない環境が必要であったため、プロジェクトは先送りにされてきました。

Amazon Elastic VMware Service（Amazon EVS）はこれらの障壁を取り除きます。AWS 上で完全な VMware 環境（VMware Cloud Foundation）をオンデマンドでデプロイでき、ハードウェアの購入もリードタイムも環境の乖離も不要です。使用した分だけ支払い、チームは既に慣れ親しんだ VMware のツールとプロセスをそのまま使い続けることができます。AWS が基盤インフラストラクチャを管理し、ワークロードは変更なしで復旧します。

この記事では、Amazon EVS を使用した災害復旧ソリューションの実装における 6 つのフェーズを解説します：戦略と目標の定義、復旧環境の作成、本番環境のミラーリング、ワークロードの保護、必要に応じた復旧、そして切り替えです。その過程で、ビジネスに適した DR 戦略を選択するためのトレードオフについても取り上げます。

図 1: Amazon EVS 上で DR ソリューションを構築するための 6 つのステップ

フェーズ 1：災害復旧の目標と戦略の定義

何かを構築する前に、一歩引いて、何を保護するのか、なぜ保護するのかを考える必要があります。

スコープ： どのワークロードがビジネスにとって重要でしょうか？いくつのワークロードに保護が必要で、それらがダウンした場合の影響はどれくらいでしょうか？これが DR 設計全体のスコープを決定します。

復旧目標： ビジネスはどれくらいの時間ダウンを許容できますか？どれくらいのデータ損失を許容できますか？これが目標復旧時間（RTO）と目標復旧時点（RPO）です。

地理： 本番環境は現在どこで稼働していますか？1 つの災害で両サイトがダウンしないよう、復旧環境はどこに配置すべきでしょうか？データ所在地とコンプライアンスの要件が、利用可能な AWS リージョンを絞り込みます。

ツール： DR サイトでワークロードを運用するために、チームはどのようなツールを必要とするでしょうか？使い慣れたツールを拡張することで、新たな学習コストや未検証の障害モードを回避できます。

環境の忠実度： アプリケーションは本番環境の完全なコピー（同じ IP、同じポリシー）で動作する必要がありますか？それとも変更を許容する柔軟性がありますか？これがネットワーキングと構成のアプローチを決定します。

予算： 予算上限はありますか？コミット型キャパシティとオンデマンドの柔軟性、どちらが適していますか？これが、災害発生前にどれだけの待機環境を維持するべきかを決定します。

事業継続： 会社に事業継続計画（BCP）はありますか？ある場合は、DR 計画をそれに合わせます。BCP が優先順位、許容可能なダウンタイム、復旧順序を設定します。

ランサムウェア対策： 復元前にワークロードがクリーンであることを検証する必要はありますか？イミュータブルストレージと隔離された復旧環境が再感染を防止します。

これらを検討し終えれば、戦略はほぼ自動的に決まります。正しい戦略とは、全体で最も低い RTO を持つものではなく、全てのワークロードがビジネスに必要なレベルの保護を受け、持続可能なコストで、チームが自信を持って実行・テストできるプロセスを備えたものです。以下の表に 4 つの一般的なアプローチを示します。

* Hot（アクティブ）：アプリケーション層では実現可能ですが、インフラストラクチャレベルでは vSAN ストレッチクラスタリングが必要です（EVS では未対応）。

** RTO は災害時に残っている復旧アクションの数に依存し、復旧アクティビティが少なく短いほど RTO は低くなります。

フェーズ 2：DR 環境の作成

復旧環境の作成は 3 つの決定に集約されます：どこにデプロイするか、何をデプロイするか、事前にどれだけ稼働させておくかです。完全なデプロイワークフローについては、 Amazon EVS のドキュメントを参照してください。

どこに： Amazon EVS を、プライマリサイトとは別の AWS リージョンまたはアベイラビリティゾーンに、自身の VPC 内にデプロイします。そこから、必要に応じて AWS 内の他のサービスやオンプレミスに接続します。

何を： インフラストラクチャ基盤となる EC2 ベアメタルインスタンスと、ワークロードが期待するソフトウェア定義データセンターを提供する VMware Cloud Foundation のバージョンを選択します。

どれだけ： 上限と下限を把握し、その間のどこに位置するかを決定します。

• 上限：上限を算出するには、前のフェーズで作成したワークロードインベントリから、重要なワークロードが消費するリソースを合計し、VCF 管理オーバーヘッドを考慮します。これにより、全てを一度に復旧するために必要なホストの最大数が得られます。
• 下限： 一方、下限は VCF のバージョン、ストレージタイプ、フリートフットプリントに応じて Broadcom が定義します。最新の値については VCF のドキュメントを確認してください。現在、VCF 5.2 および 9.x では、Broadcom は本番環境向けに 4 ホストと vSAN ストレージによる高可用性デプロイメントを推奨しています。VCF 9 では、vSAN で 3 ホスト、または外部ストレージで 2 ホストから始められるシンプルデプロイメントも提供しており、管理プレーンの冗長性よりもコストが重要な環境に適しています。
• ティアの選択： これらの上限と下限の間で、現時点でどこに位置するかを決定します。これがコスト対速度の核心的な判断です。事前にデプロイしておくホストが多いほど復旧は速くなりますが、そのアイドル状態のキャパシティを維持するコストも増えます。何もデプロイせず災害発生時に完全に構築する方法（Cold）もあれば、小規模なフットプリントを稼働させておき必要時にスケールアウトする方法（Pilot Light または Warm Standby）もあります。また、DR サイトで日常的に非重要ワークロードを稼働させ、災害発生時にそれらをシャットダウンしてキャパシティを回収するという、一般的な手法もあります。

フェーズ 3：本番環境構成のミラーリング

Amazon EVS がデプロイされたら、ワークロードがソースサイトとまったく同じように動作するよう構成します。ネットワーキング、セキュリティ、コンピュート、ストレージ、アイデンティティです。これらが本番環境と一致していれば、ワークロードはクリーンに復旧し、プライマリサイトと同じように動作します。

図 2: 災害復旧の概要

これらの中で、ネットワーキングが最も難しく、最も重要な部分です。フェイルオーバー後に VM が期待するセグメント、ゲートウェイ、ファイアウォールルールに到達できなければ、何も機能しません。このサービスは、復旧サイトで本番ネットワークを再現するための確実な選択肢を提供します。最も一般的な 2 つのモデルを以下に示します：

コード駆動型ネットワークレプリケーション

このアプローチは、Terraform、Ansible、PowerCLI、VCF Automation などの Infrastructure as Code（IaC）ツールを使用して、本番ネットワーク構成を復旧サイトにレプリケートします。動作方法は準備する戦略によって異なります。復旧サイトがまだ存在しない場合は、本番ネットワークをコードとしてキャプチャし、サイトのデプロイ時に実行します。既に稼働している場合は、IaC パイプラインが両サイトを自動的に同期させます。いずれの場合も、DR が起動すると、VM は既に配置されているネットワークに接続します。すべてのティアで機能します。

NSX Federation

NSX Federation を使用すると、両サイトのネットワーキングを 1 つの中央拠点、NSX グローバルマネージャーから管理できます。セグメント、ファイアウォールポリシー、セキュリティグループを一度定義すれば、両方のロケーションに自動的にプッシュされます。VM が DR サイトで復旧すると、同じ IP、同じファイアウォールルール、同じセキュリティポリシーが適用されます。IP の再割り当て、再構成、乖離は不要です。

これには、両サイトにネットワーキングインフラストラクチャが既にデプロイされ稼働している DR 環境が必要です。初期セットアップが必要であり、一部のポリシーは VM が復旧サイトに登録されて初めて有効になります。それでも、両サイトを常に同期させる必要がある環境にとって、即座のネットワーク準備完了への最もクリーンなパスです。

フェーズ 4 & 5：ワークロードの保護と復旧

復旧環境が作成され、本番環境と一致するよう構成されたら、次の問題はワークロードデータをどのようにそこに移すか、そしてその時が来たときに仮想マシンをどのように復旧するかです。Amazon EVS で動作するソリューションは複数あります。以下の表は、最も重要な基準に沿って利用可能なソリューションを比較しており、続くセクションでそれぞれを詳しく解説します。

ハイパーバイザーレベルのレプリケーション

これらのソリューションは、ハイパーバイザーレベルで仮想マシンのディスクへの変更をインターセプトし、復旧サイトに転送することでレプリケーションを行います。通常、データの管理と移動のために両サイトにアプライアンス VM をデプロイします。このアプローチは最もタイトな RPO を提供し、復旧環境が既に稼働していることを必要とします。保護と復旧は同じサービス内で処理されます。

図 3: ハイパーバイザーベースのレプリケーション — 仮想アプライアンスを通じた DR オーケストレーションとデータレプリケーション

VCF Protection and Recovery

これは VCF における統合 DR プラットフォームであり、2 つのワークフローを持ちます：1 つは運用継続に焦点を当て、もう 1 つはサイバー攻撃後の安全な復旧のために設計されています。Disaster Recovery Orchestration：従来型の DR を処理します。各サイトにアプライアンスをデプロイし、vSphere Replication、vSAN Data Protection、またはストレージアレイでレプリケーションを行います。復旧計画が残り、つまり IP の変更、ネットワークマッピング、起動順序を処理します。RPO はレプリケーション方式に依存します：vSphere Replication で約 5 分、vSAN DP では設定したスケジュール、同期アレイではほぼゼロです。DR サイトが既に稼働していれば、RTO は通常わずか数分です。Cyber Recovery はランサムウェアからの復旧のための隔離された場所を提供します。小さなコネクターが重複排除された VM スナップショットをイミュータブルなクラウドファイルシステムに送信します。問題が発生した場合、隔離された復旧環境を起動し、Live Mount を使用してクリーンなスナップショットを即座に起動します。完全な復元は不要であり、DR サイトを 24 時間 365 日稼働させる必要もありません。

パートナーソリューション

複数のパートナー製品が Amazon EVS で動作します。Veeam は最も一般的なものの 1 つであり、単一のサービスで複数のティアにわたる保護と復旧の両方を処理します。保護については 3 つのモードを提供します：Amazon S3 へのスケジュールバックアップ（RPO は数時間）、スタンバイ VM へのほぼ継続的なレプリケーション（RPO は数分）、そしてハイパーバイザーレベルですべての書き込みをキャプチャする Continuous Data Protection（RPO は約 2 秒）。復旧については、フェイルオーバー計画がブートシーケンスと IP 再割り当てルールを自動的に処理し、Instant VM Recovery はフルリストアがバックグラウンドで完了する間にバックアップから直接マシンを起動できます。バックアップモードは事前の DR 環境を必要としません。レプリケーションと CDP モードは DR 環境を必要とします。粒度は VM 単位。複雑さは中程度で、1 つのコンソールですべてを管理しますが、3 つのモードすべてを同時に運用するには計画が必要となります。イミュータブルバックアップがランサムウェアから復旧ポイントを保護します。ライセンスは VM 単位です。

ストレージレベルのレプリケーション

ストレージベースのレプリケーションはブロックレベルで動作し、両サイトに同じストレージサブシステムが必要です。Amazon FSx for NetApp ONTAP は 1 つの選択肢であり、EverPure などのパートナーからも同等のソリューションが利用可能です。

図 4: ストレージレベルのレプリケーション — 本番環境と復旧ストレージアレイ間のブロックレベル同期

Amazon FSx for NetApp ONTAP

このソリューションは両サイトに FSx for NetApp ONTAP が必要であり、保護と復旧の両方を処理します。保護については、SnapMirror がブロックレベルでストレージボリュームを 5 分ごとにレプリケートし、VM に対して完全に透過的で、ゲストレベルのオーバーヘッドはありません。完全な EVS 環境は復旧時のみ必要です。 復旧については BlueXP がフェイルオーバーをオーケストレートします：SnapMirror の関係を切断し、レプリカボリュームを書き込み可能にし、DR サイトにデータストアとしてマウントし、vCenter に VM を登録し、定義した順序で電源を入れます。プロセス全体がワンクリックまたは API 駆動です。粒度はボリューム単位で、通常は VM のグループを意味します。複雑さは低〜中程度。価格は GB 単位の従量課金で、大規模ではコスト効率が高いです。既に NetApp ONTAP を使用しており、最小限の運用オーバーヘッドでストレージ効率の高いレプリケーションを求める組織に最適です。

スケジュールバックアップ

最もシンプルかつ安価な保護形態で、耐久性のある外部ストレージに保存される定期的なスナップショットです。RPO はバックアップ頻度に応じて数時間から数日です。事前に DR 環境を稼働させておく必要はありません。

図 5: バックアップとリストア — リモートリポジトリへのスケジュールスナップショットとオンデマンド復旧

AWS Backup

このオプションは保護のみを処理します。VM のスケジュールスナップショットを取得し、Amazon S3 に保存します。オプションの Vault Lock によるイミュータビリティにより、ランサムウェアを含め誰も復旧ポイントを削除または変更することができません。復旧は完全に手動です。オペレーターが仮想マシンを復元し、ネットワーキングを構成し、ブート順序を設定し、検証します。オーケストレートされたフェイルオーバーはありません。そのため、復旧時間が重要なワークロードには単独では不向きですが、他のアプローチの下にあるベースライン保護およびコンプライアンス層としては上手く機能します。ポリシー駆動、エージェント不要で、すべての操作が CloudTrail にログとして記録されます。粒度は VM 単位で、複雑さは最小限です。

フェーズ 6: 切り替えとテスト

最終フェーズは 2 つのことに関するものです：ユーザーを復旧サイトに切り替えること、そして実際の災害が発生した際にプロセスがまだ機能することを確認するために、十分な頻度でテストすることです。

切り替えの実行

切り替えとは、シンプルに DNS を更新して、ユーザーとシステムがプライマリサイトへの参照を停止し、復旧サイトへの参照を開始することです。Route 53 のヘルスチェックとフェイルオーバールーティング、加重レコード、またはオーケストレーションツールによってトリガーされる DNS 更新を使用します。重要なレコードの TTL は低く保ちます（60 秒以下）。長い TTL は、レプリケーションツールが提供する値をはるかに超えて実効 RTO を延ばす可能性があります。また、ランブックには外部依存関係への対応も記載して下さい。パートナー連携や、ハードコードされた IP を持つアプリケーション、管理外のサードパーティ DNS ゾーンなどです。

DR 計画のテスト

テストされていない DR 計画は単なる推測に過ぎません。実際の復旧が失敗する最も一般的な理由は乖離です。レプリケーションから漏れたアプリケーション、本番環境でのみ変更されたファイアウォールルール、数ヶ月前にリネームされたものを参照しているスクリプトなどです。ほとんどのレプリケーションツールは、隔離ネットワークやサンドボックス環境を通じた非破壊テストをサポートしているため、スケジュールに従って使用します。重要ワークロードは毎月、その他は四半期毎。実際の RTO を目標と比較して追跡し、テストごとの想定外の事象の数を記録します。想定外の事象の傾向こそが、DR 成熟度の真の指標になります。ランブックの実行者をローテーションし、壊れた自動化が宣言時ではなく訓練時に発見されるようにします。

本番環境へのフェイルバック

実際のフェイルオーバー後、プライマリサイトが復旧したら、最終的にワークロードを本番環境に戻す必要があります。保護に使用したのと同じレプリケーションツールが逆方向に機能します：DR 環境を本番環境にレプリケートし、整合性を検証してから、トラフィックを切り戻します。フェイルバックは最初から計画しテストして下さい。テストされていないフェイルバックは、テストされていないフェイルオーバーと同じリスクを伴います。

結論

Amazon EVS 上の災害復旧は、単一のツールや単一の決定ではありません。6 つのフェーズにわたる一連の選択であり、それぞれが RTO、RPO、コスト制約、運用の現実によって形作られます。復旧環境をどこにどのようにデプロイするか、本番環境をどれだけ忠実にミラーリングするか、データをどのように移すか、ワークロードをどのようにオンラインに戻すか、そしてすべてが機能することをどのように証明するかを選択します。良いニュースは、Amazon EVS が小さく始めて成長する柔軟性を提供することです。優先度の低いワークロードには最小限のフットプリントとスケジュールバックアップから始め、ダウンタイムを許容できないワークロードには継続的レプリケーションとフルオーケストレーションを段階的に追加できます。すべてを一度に解決する必要はなく、すべてのキャパシティを一度にコミットする必要もありません。唯一省略できないのはテストです。ドキュメントの中にしか存在しない DR 戦略は負債です。テストを実行し、想定外の事象を追跡し、ギャップを埋め、繰り返します。目標は初日から完璧であることではありません。検証済みの復旧を1回ずつ積み重ねて信頼を築いていくことです。

Amazon EVS を始める

AWS 上の VMware ワークロードのための災害復旧を構築する準備はできましたか。Amazon EVS を探索し、今日から復旧戦略の計画を始めましょう。

Amazon EVS のオファリングを Amazon EVS 製品ページで確認してください。

技術的な詳細を Amazon EVS ドキュメントで掘り下げましょう。

最初の EVS 環境を Amazon EVS コンソールからデプロイしましょう。

この投稿の翻訳は Solutions Architect の有岡が担当いたしました。原文記事はこちらです。