G-gen の本間です。当記事では、 Migrate to Virtual Machines を使って、Amazon Web Services（AWS）から Google Cloud へ仮想マシンを移行する方法を解説します。 はじめに Migrate to Virtual Machines とは サポートされる環境 移行手順の概要 前提事項 AWS 側の設定 Google Cloud 側の設定 注意点 AWS 側の設定 Google Cloud 側の設定 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 はじめに Migrate to Virtual Machines とは Migrate to Virtual Machines は、オンプレミス環境や他のクラウド環境から Google Cloud の Compute Engine へ仮想マシンを移行するための Google Cloud サービスです。 このサービスでは、移行元の仮想マシンを稼働させたまま、Google Cloud 上にデータをレプリケーションできるため、移行に伴うダウンタイムを最小限に抑えられます。 参考 : Migrate to Virtual Machines のドキュメント サポートされる環境 Migrate to Virtual Machines では VMware、Amazon Web Services（以下、AWS）、Microsoft Azure が移行元としてサポートされています。ただし、それぞれの環境ごとにサポートされている OS が決まっているため、事前に確認する必要があります。 また、AWS からの移行においては、対象となる EC2 インスタンスの OS やディスクのタイプが、Migrate to Virtual Machines でサポートされているかについても事前に確認する必要があります。 なお、AWS 側からのデータ転送には、AWS のアウトバウンドデータ転送料金が発生します。移行対象のデータ量が多い場合は、コストに注意してください。 参考 : サポートされているオペレーティング システム 移行手順の概要 前提事項 当記事の解説における前提として、AWS 側では、VPC 内のパブリックサブネットに Windows Server 2025 の EC2 インスタンスを構築済みであり、インターネットゲートウェイ（IGW）経由でのルーティングおよびセキュリティグループの設定によりインターネットへのアウトバウンド通信の準備が完了しているものとします。 また、Google Cloud 側ではインスタンスを配置する対象リージョンの VPC ネットワークとサブネットの構築が完了しているものとします。移行先 VM の構築自体に特段通信要件はありませんが、移行工程でテストクローンを実施する場合、移行元 VM と移行先 VM が同時に起動する状態となります。予期しないトラブルを防止するため、移行先 VM と、移行元 VM および周辺システムが通信できないネットワーク設定とすることが推奨されます。 AWS 側の設定 AWS 側の手順では IAM ポリシーとユーザーの作成を行います。この際、アクセスキーとシークレットアクセスキーも発行します。 また、VPC や EC2 インスタンスが、前述の前提事項や後述の注意点に準拠していることを確認してください。 Google Cloud 側の設定 Google Cloud 側の大まかな手順は以下のとおりです。 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 最初に、AWS 側の VM のディスクデータを Google Cloud 側に同期します。この工程をレプリケーションと呼びます。この工程では Google Cloud 側に VM は起動せず、あくまでディスクのデータのみをコピーします。データは Migrate to Virtual Machines のマネージドなストレージに保管されます。 続いて、コピーしたデータを元にしてどのようなスペックで Google Cloud 側の VM として起動するかを定義し、その設定に基づいて実際に VM を起動します。テスト環境用に VM を起動することをテストクローンの作成、本番環境用に VM を起動することをカットオーバーといいます。 注意点 Google Cloud に移行する VM は、ブートパーティションに 128 MB 以上の空き容量が必要です。 レプリケーションは初回実施時から100日間、アクティブ状態が維持されます。100日経過後、EXPIRED 状態に移行し、レプリケーションサイクルが停止します。再びアクティブ状態にするには初回実施時から130日経過する前に存続期間を延長する必要があります。期間の延長は1回のみ可能で、追加で100日間アクティブ状態にできます。よって、VM の移行はこの期間内に完了させる必要があります。 Migrate to Virtual Machines では、レプリケーションのプロセスを通して OS 適応 というプロセスが自動的に実行されます。OS 適応は VM を Google Cloud 上で適切に動作させるために、パッケージのインストールやネットワーク設定等を行うプロセスです。このプロセスは Linux と Windows の両方で行われ、Linux VM では /root で最大640 MiB、/boot で最大128 MiB、/var で最大64 MiB、/tmp で最大32 MiB の空き容量が必要です。Windows VM では C ドライブに最大1.25 GiB の空き容量が必要です。 カットオーバー実行時は移行元の VM が停止されるため、注意してください。 参考 : 個々の VM を移行する - 前提条件 参考 : 移行中の VM のライフサイクル 参考 : Google Cloud で実行するように VM インスタンスを適応させる 参考 : VM の移行プロセス - カットオーバーフェーズ AWS 側の設定 当記事では、AWS 側の設定手順の詳細な解説は省略します。詳細は、公式ドキュメントを参照してください。 まずは AWS マネジメントコンソールにログインし、Migrate to Virtual Machines が必要とする権限を定義した IAM ポリシーを作成します。 参考 : AWS ソースを作成する - AWS IAM ポリシーを作成する 次に、作成した IAM ポリシーをアタッチした IAM ユーザーを作成します。この IAM ユーザーは、AWS リソースへのプログラムによるアクセス（API 経由でのアクセス）に使用されます。 IAM ユーザー作成後に IAM ユーザーの「セキュリティ認証情報」から、アクセスキーおよびシークレットアクセスキーを発行します。これらのキーは、Google Cloud 側の設定で使用するため、安全な場所に記録しておきます。 参考 : AWS ソースを作成する - IAM ユーザーを作成する Google Cloud 側の設定 インスタンスのレプリケーション 以下は、2026年8月現在の Google Cloud コンソール画面を前提とした手順です。 Google Cloud コンソールの上部検索ボックスに「Migrate to Virtual Machines」と入力して表示されるサジェストから「Migrate to Virtual Machines」画面へ進みます。表示された画面上部の「ソース」タブを選択し、「ソースを追加」から「AWS ソースを追加します」を選択します。 AWS ソースの作成画面から事前に発行した AWS IAM ユーザーのアクセスキーとシークレットアクセスキー、および対象の AWS リージョンを入力して、ソース環境を登録します。 このとき、AWS セキュリティグループやタグを使って対象のインスタンスをフィルタリングできます。 ソースを追加すると、指定した AWS リージョン内に存在する EC2 インスタンスのリストが自動的に取得されます。 このリストから移行対象とするインスタンスのチェックボックスにチェックを入れ、「移行を追加」プルダウンから「VM migration」を実行します。すると移行確認画面が表示されるため、「確認」を押下します。 完了後、画面上部の「VM の移行」タブを押下すると、先ほど選択したインスタンスが追加され、レプリケーションのステータスが準備完了となっていることが確認できます。続いて、対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを開始」を実行します。この処理により、AWS 上の仮想マシンデータが、Google Cloud 上に継続的にコピーされます。 ターゲットインスタンスの定義 レプリケーションが進行している間に、先行して Google Cloud 上で稼働させるインスタンスのスペック（マシンタイプ、ネットワーク設定、ディスクタイプなど）を定義します。 先ほどの画面から再び対象インスタンスのチェックボックスにチェックを入れ、「ターゲットの詳細を編集」を押下し、表示された編集画面を上から順に設定します。 なお、最下部の「Replication policy」設定でレプリケーション間隔を設定できます。デフォルトは2時間です。 テストクローンの作成と動作確認 しばらく待機し、先ほどの「VM の移行」画面から対象インスタンスのレプリケーションステータスが「有効」となっていることを確認します。この状態となっていれば初回レプリケーションは完了です。 以降は「Replication policy」で設定したレプリケーション間隔ごとに増分レプリケーションが実施されます。 参考 : VM の移行プロセス - レプリケーションフェーズ 次にテストクローンを実施します。テストクローン機能を使用すると、移行した VM のクローンを Compute Engine インスタンスとしてデプロイできます。テストクローンは省略可能ですが、本番環境へ移行する前に実施し、テスト環境で動作確認をすることが推奨されます。 参考 : VM の移行プロセス - テストクローンフェーズ 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「テストクローン」を実行します。するとテストクローン作成確認画面が表示されるため、「確認」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「クローンが完了しました」となっていることを確認します。 この状態になればテストクローン完了です。Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、インスタンスが起動していることを確認します。 ここで、必要に応じてインスタンスにログインし OS 設定を確認したり、コンソール画面から Compute Engine インスタンスの設定値を確認したりして、想定どおりにデプロイされていることを確認します。 カットオーバー テストクローンによる事前確認完了後、カットオーバーを実施します。 カットオーバーを実行すると、最後のレプリケーションが実施され、VM が Compute Engine インスタンスにデプロイされます。この際、移行元の VM は停止されるため、注意してください。 また、Compute Engine は IP アドレスやインスタンス名が同じ VM を複数作成できません。そのため、テストクローン実施時に作成したインスタンスが存在している場合は、インスタンスを削除するか、「ターゲットの詳細を編集」から別のインスタンス名を設定してください。当記事の手順では、テストインスタンスを削除してから実行します。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「カットオーバー」を実行します。するとカットオーバー確認画面が表示されるため、「確認」を押下します。 カットオーバーの状況については、先ほどの画面から対象インスタンス名を押下し、「テストクローン/カットオーバーの履歴」タブから確認できます。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「カットオーバーが完了しました」となっていることを確認します。 この状態になればカットオーバー完了です。テストクローン実施時と同様に、Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、想定どおりのインスタンスが起動していることを確認します。 レプリケーションの最終処理 カットオーバー完了後、レプリケーションの最終処理を実施します。カットオーバー完了時点で移行は完了していますが、レプリケーションの最終処理を実行するまではレプリケーションデータが保持された状態です。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを最終処理」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「レプリケーションのステータス」が「最終処理済み」となっていることを確認します。 以上で AWS から Google Cloud への VM 移行作業は完了です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

本稿は、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 つの一般的なアプローチを示します。 Cold (オンデマンド) Pilot Light (最小構成) Warm Standby (部分構成) Hot (アクティブ)* 事前デプロイされるもの なし (EVS は災害時にデプロイ) 最小限の EVS 環境 (2 〜 4 ホスト) 縮小クラスター (重要ワークロード向け) フルクラスター (本番同等の容量) コスト $ $$ $$$ $$$$ RTO** 最も高い(8 時間以上) 中‑高(~ 4 時間以上) 中-低(~ 2 時間以上) 低 (~ 15 分以上) RPO 数時間〜数日（最終バックアップ） 数分（最終レプリケーション） 数分（最終レプリケーション） ほぼゼロ（継続的同期） 復旧アクション* EVS デプロイ → 本番ミラーリング → VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え テストの信頼性 低（災害時まで未テスト） 中（クラスター検証済み） 高（部分的フェイルオーバーテスト） 非常に高（継続的検証） 最適な用途 RTO に余裕のある非重要ワークロード 標準的な本番ワークロード 厳格な SLA を持つ重要アプリケーション ゼロダウンタイムのミッションクリティカル * 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 が復旧サイトに登録されて初めて有効になります。それでも、両サイトを常に同期させる必要がある環境にとって、即座のネットワーク準備完了への最もクリーンなパスです。 NSX Federation コード駆動型ネットワークレプリケーション ネットワーク同期 自動、リアルタイム 手動または IaC 駆動、定期的 フェイルオーバー時の IP 再割り当て なし（同じセグメントがストレッチ） あり得る（マッピングに依存） インフラストラクチャオーバーヘッド 高い（両サイトにグローバルマネージャー + Edge） 低い（クロスサイト NSX インフラ不要） 乖離リスク なし（グローバルマネージャーが強制） 自動化されていなければ存在する 最適な用途 Warm Standby、Hot — 頻繁な変更、IP 再割り当てゼロ Cold、Pilot Light、Warm Standby — 安定したネットワーク、IaC の成熟度 フェーズ 4 & 5：ワークロードの保護と復旧 復旧環境が作成され、本番環境と一致するよう構成されたら、次の問題はワークロードデータをどのようにそこに移すか、そしてその時が来たときに仮想マシンをどのように復旧するかです。Amazon EVS で動作するソリューションは複数あります。以下の表は、最も重要な基準に沿って利用可能なソリューションを比較しており、続くセクションでそれぞれを詳しく解説します。 VMware Live Recovery Veeam FSx for NetApp ONTAP AWS Backup カバー範囲 保護 + 復旧 保護 + 復旧 保護 + 復旧 保護のみ レプリケーション層 ハイパーバイザー(vSphere Replication) ハイパーバイザー(I/O フィルタ + プロキシ) ストレージ(SnapMirror、ブロックレベル) スケジュール(S3 へのスナップショット) RPO 5 分 – 24 時間 ~2 秒 (CDP)、 分 (レプリケーション)、時間 (バックアップ) 5 分 数時間〜数日 自動化 高 (復旧計画、スクリプト、再 IP) 高 (切替計画, 即時 VM 復旧) 中-高 (BlueXP でワンクリック) 最小 (スケジュールバックアップ、手動復旧) テスト 非破壊、隔離ネットワーク 非破壊切替テスト FlexClone ゼロスペースコピー 組み込みテスト無し 粒度 VM 単位 VM 単位 ストレージボリューム単位 VM 単位 DR サイト必要？ Yes Yes (CDP/Replication)、No (Backup) Yes No 複雑さ 低 中 低 – 中 最低 ライセンス VM – VCF アドオン VM GB 単位の従量課金 GB 単位の従量課金 最適な用途 統合ソリューションを求める VMware チーム すべてのティアで 1 つのサービスを求めるチーム 既に NetApp ONTAP を使用している組織 ベースライン保護とコンプライアンス層 ハイパーバイザーレベルのレプリケーション これらのソリューションは、ハイパーバイザーレベルで仮想マシンのディスクへの変更をインターセプトし、復旧サイトに転送することでレプリケーションを行います。通常、データの管理と移動のために両サイトにアプライアンス 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 の有岡が担当いたしました。原文記事は こちら です。 Akshay Joshi AWS の Worldwide Public Sector チームのシニアソリューションアーキテクトであり、政府および教育機関の顧客が VMware 環境をモダナイズするのを支援しています。IT インフラストラクチャ（サーバー、ネットワーキング、ストレージ）で 15 年以上の経験があり、VMware を専門とし、そのキャリアの最後の 5 年間を AWS で過ごしてきました。公共セクターチームと協力し、既存の VMware 投資をスケーラブルでセキュアな AWS アーキテクチャに引き継ぐ支援を行っています。 Erick Meneses AWS の移行とモダナイゼーションに特化したスペシャリストソリューションアーキテクトです。大規模な変革プログラムのリードで 20 年以上の経験を持ち、EMEA 全域のエンタープライズ顧客がクラウドジャーニーを進め、成功した成果の達成を支援しています。 Ben Lipman 仮想化、ストレージ、ネットワークを管理する IT インフラストラクチャエンジニアリングで 25 年のバックグラウンドを持ち、あらゆる規模のエンタープライズを担当してきました。AWS で過去 10 年間を過ごし、現在はワールドワイド VMware テクニカルリーダーを務めています。

本記事は 2026 年 8 月 27 日 に公開された「 A year of expanding choice for VMware customers on AWS 」を翻訳したものです。 Amazon EVS が一般提供 (GA) を開始してから 1 年以上が経ちました。人材やツール、運用ワークフローへの既存の投資を維持しながらクラウドでより多くの選択肢を求めていた VMware ワークロードのお客様にとって、Amazon EVS の GA 開始は大きな節目でした。Amazon EVS を使用すると、AWS 環境と統合された Amazon EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を実行できます。チームは VMware のソリューションを継続して使用しながら、AWS の機能とグローバルな展開力を活用できます。 この 1 年間で新しい VCF バージョンのサポートを追加し、デプロイの自動化機能をリリースし、新しい EC2 インスタンスへの対応も拡大してきました。VCF 9 の Memory Tiering や NSX Federation の設定に関するガイダンスも公開し、新しい Windows Server ライセンスの権利オプションも導入しました。これらの機能追加により AWS で稼働する VMware ワークロードのデプロイ、運用、スケーリング、保護をお客様がより細かく制御できるように取り組んでいます。 ここからは最初の 1 年間でお届けした内容を詳しく紹介します。 VCF 9 を思い通りにデプロイ 今年に入って Amazon EVS での VCF 9.0 および 9.1 のサポート を発表しました。VCF 9 では Amazon EVS が VPC 内に EC2 ベアメタルインフラストラクチャをプロビジョニングし、アーキテクチャや設定はネイティブの VCF Installer でお客様自身が管理します。この制御レベルは VCF のライフサイクル全体に及ぶため、オンプレミスと同じ VCF の機能を Amazon EVS でも利用できます。 自動インストールを好むチーム向けには Solutions for Amazon EVS GitHub リポジトリ で Amazon EVS Deployment Orchestrator を公開しました。Amazon EVS Deployment Orchestrator には Amazon EVS 上に完全に構成された VCF 9 環境をデプロイするためのエンドツーエンドの自動化が含まれています。今後も計画、デプロイ、移行、運用のための新しいソリューションを追加していきます。 新しい i7i.metal-48xl、AWS リージョンの拡大、より大規模な環境でスケール 4 月には i7i.metal-24xl のサポート を追加して EC2 インスタンスの選択肢を拡大し、本日 i7i.metal-48xl のサポート を発表します。この新しいインスタンスは物理コア 96 個、メモリ 1.5 TB、ローカル NVMe ストレージ 45 TB を備え、負荷の高い VMware ワークロードに対応する大きなキャパシティを提供します。 第 5 世代 Intel Xeon Scalable プロセッサーを搭載した i7i インスタンスは、i4i インスタンスと比べてコンピューティング性能が最大 23% 向上し、料金性能比も 10% 以上向上しています。i7i.metal-48xl はコア数とメモリ容量が増えているため、ホストあたりでより多くの VM を実行でき、少ないホスト数でも環境を拡張できます。 また Amazon EVS の対応リージョンを 22 の AWS リージョンに拡大し、エンドユーザーの近くにワークロードを配置したり、ビジネス目標やデータ主権の要件に合わせたデプロイができるようになりました。さらに環境の最大サイズを 16 ホストから 32 ホストに増やしました。1 つの環境内で大規模な単一クラスターを構築することも、複数の小規模クラスターに分けることも、要件に合わせて自由に組み合わせることもできます。 Memory Tiering でクラスター密度を向上 VCF 9 は、ホストがローカル NVMe ストレージを追加メモリとして利用できる Memory Tiering を導入しました。同じホスト数でもクラスターが実質的に最大 2 倍のメモリを扱えるようになり、VM の密度を高めながらハードウェアとライセンスのコストを削減できます。Memory Tiering は i4i および i7i の両インスタンスファミリーに対応しています。 Memory Tiering の詳細解説 ではこの機能の仕組みや、Amazon EVS でのサイジングと有効化について説明しています。 Windows Server のライセンスをシンプルに Windows Server のライセンスは VMware の移行を計画する際に障壁となることがあります。 Amazon EVS Windows Server Licensing では Windows VM を実行するための 2 つの選択肢を用意しています。対象となる Windows Server ライセンスと移行権を持つお客様は、そのライセンスをそのまま Amazon EVS に持ち込めます。移行権のない VM については、Amazon EVS で Windows Server ライセンスの権利を追加し、使用した分だけ vCPU 時間単位で料金を支払えます。権利は環境の変化に応じて追加・削除できるため、個々の VM 単位でライセンスを付与し、ホスト全体にライセンスを付与するコストを回避できます。 Amazon EVS で VMware ワークロードを保護・復旧 Amazon EVS を使うと、チームが既に使い慣れた VMware のツールとプロセスのまま、AWS 上で VMware ワークロードを柔軟に保護・復旧できます。オンデマンドで復旧環境をデプロイし、ワークロードを変更せずに稼働させ、復旧目標に合わせてキャパシティをスケールできます。 Amazon EVS における VMware ワークロードの災害復旧ガイド では復旧方法と保護オプションを比較しており、ワークロードごとに復旧時間、復旧時点、コスト、運用要件のバランスを取れます。 サイト間でネットワークとセキュリティを拡張 またオンプレミスの NSX 環境と Amazon EVS 環境を単一のコントロールプレーンで管理できる NSX Federation のサポートも発表しました。NSX Federation により拠点をまたいでネットワークセグメントとセキュリティポリシーを拡張し、データセンターと AWS の間で統一されたネットワーキング基盤を構築できます。大規模なレイヤー 2 拡張、統一された Distributed Firewall ポリシー、簡素化された災害復旧のフェイルオーバーを必要とするお客様にとって、NSX Federation は HCX の移行ワークフローを補完する長期的なネットワーキングと復旧の基盤となります。 NSX Federation の詳細解説 では両方の技術がどのように連携し、それぞれがどのような場面に適しているかを説明しています。 より広い選択肢を提供した 1 年間 今年リリースしたすべての機能はチームが使い慣れた VMware のツールと運用ワークフローを維持しながら、Amazon EVS でより多くの制御、選択肢、柔軟性を提供するという目標を支えるものです。VMware を利用している組織であれば、Amazon EVS を VMware ベースのワークロードを実行する世界最高の場所にしたいと考えています。 次のステップ: VMware Explore 2026 で Amazon EVS をご覧ください 最新の取り組みを実際にご覧になりたい方は、8 月 31 日から 9 月 3 日までラスベガスの The Venetian で開催される VMware Explore 2026 にぜひお越しください。 今すぐセッションをスケジュールに追加してください 。 ブレイクアウトセッション [CLOB2172LVS] Amazon EVS with VCF 9: Expanding choice and flexibility for VMware on AWS – 9 月 2 日(水) | 午後 3:15 – 午後 4:00 | Level 3, San Polo 3505 20 分間シアターセッション [CLOQT2319LVS] 20-minute guide to running VMware Cloud Foundation 9 on Amazon EVS – 8 月 31 日(月) | 午後 5:30 – 午後 5:50 | The Hub Theater VMware Explore にご参加の有無を問わず、皆様が取り組んでいる内容についてぜひお聞かせください。 Amazon EVS の製品ページ にアクセスして利用を開始するか、AWS のアカウントチームに連絡して次のステップを検討してください。 著者について Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とトランスフォーメーションを担当しています。マーケティングとテクノロジー分野で7年以上の経験を持ち、複雑な技術を分かりやすく伝えるストーリーづくりに情熱を注いでいます。AWS の業務以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーとして、VMware、SAP、Red Hat OpenShift のワークロードを担当するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアの分野で25年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis AWS のシニアテクニカルプロダクトマネージャーとして、インフラストラクチャの移行と Amazon Elastic VMware Service を担当しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS のサービスを活用してお客様がビジネス成果を達成することを支援することに情熱を注いでいます。プライベートでは、旅行を通じて様々な場所や人々、文化に触れることを楽しんでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。