VMware ワークロードの移行戦略 - MGN と EVS を使い分ける段階的アプローチ
VMware ワークロードを AWS へ移行する際の MGN (Application Migration Service) と EVS の使い分け、段階的移行計画の立て方、移行後の最適化を解説します。
VMware 移行の 3 つのアプローチ
VMware ワークロードを AWS へ移行する方法は大きく 3 つに分類されます。第一のリフト & シフトは、Amazon EVS を使って VMware 環境をそのまま AWS 上に移設する方法です。アプリケーションの変更は不要ですが、VMware ライセンスは引き続き必要です。第二のリプラットフォームは、AWS MGN (Application Migration Service) を使って VMware VM を EC2 インスタンスに変換する方法です。VMware ライセンスから解放されますが、OS やミドルウェアの互換性検証が必要です。第三のリファクタリングは、アプリケーションをコンテナ化して ECS や EKS で稼働させる方法です。最もクラウドネイティブな形態ですが、アプリケーションの改修工数が大きくなります。
移行アセスメントと計画策定
移行に先立ち、AWS Migration Hub で既存環境のインベントリを収集し、ワークロード間の依存関係をマッピングします。Migration Evaluator (旧 TSO Logic) を使えば、現在のオンプレミス環境の利用状況データから AWS 上での最適な構成とコスト試算を算出できます。アセスメントの結果に基づいて、各ワークロードを EVS、MGN、リファクタリングのいずれで移行するかを判定します。判定基準として、VMware 固有の機能 (vMotion、DRS、HA) への依存度が高いワークロードは EVS、標準的な Linux/Windows サーバーは MGN、マイクロサービス化が見込めるアプリケーションはリファクタリングを選択します。
MGN による EC2 移行の実践
AWS MGN は、ソースサーバーにエージェントをインストールし、ブロックレベルの継続的レプリケーションで AWS 上にレプリカを作成します。レプリケーション中もソースサーバーは稼働し続けるため、業務への影響はありません。テスト起動でレプリカの動作を検証し、問題がなければカットオーバーを実行して本番切り替えを行います。カットオーバー時のダウンタイムは、最終差分の同期時間のみ (通常数分から数十分) です。 MGN はエージェントが VMware Tools と共存できるため、 vSphere 環境のサーバーにそのままインストールできます。移行後は EC2 インスタンスとして稼働するため、 Auto Scaling や ALB との統合など AWS ネイティブの機能を活用できます。 移行プロジェクトの知見を広げたい場合はAmazon の専門書も活用できます。
移行コストの考慮
MGN の利用料金は無料で、レプリケーション用のステージングエリア (EC2 + EBS) のコストのみ発生します。EVS は専用ホスト (i4i.metal) の料金が主要なコスト要因で、最小 3 ホスト構成で月額約 15,000 ドル以上です (2026 年 8 月時点)。移行方式の選択はコストに大きく影響するため、MGN による EC2 移行 (低コスト、アプリ変更必要) と EVS による VMware 環境移設 (高コスト、変更不要) のトレードオフを慎重に評価します。Migration Evaluator で現行環境のコスト分析を行い、移行後の TCO を試算してから方式を決定します。
移行戦略の整理
クラウド移行には、いくつかのアプローチがあります。仮想マシンをほぼそのまま移す方式は、変更が少なく短期間で移行でき、まず確実に動かしたい場合に向きます。OS やミドルウェアを一部置き換えてクラウドに最適化する方式は、運用負荷の軽減と移行スピードのバランスが取れます。アプリケーションを作り直してクラウドネイティブにする方式は、手間はかかりますが、最大の効果が得られます。すべてを同じ方式で移すのではなく、アプリケーションの重要度や改修の余地に応じて方式を使い分け、段階的に進めるのが現実的な戦略です。
MGN の仕組みと特徴
Application Migration Service (MGN) は、稼働中のサーバーをほぼそのまま AWS へ移行する代表的な手段です。移行元のサーバーのデータを継続的に複製し続けることで、本番を止めずに移行の準備を進められます。切り替え前には、複製したデータからテスト用のインスタンスを起動し、移行先で正しく動くかを事前に検証できます。本番切り替えの際は、直前まで同期した状態から切り替えるため、ダウンタイムを最小限に抑えられます。既存の構成を大きく変えずに、安全かつ短い停止時間で移行できる点が、MGN を使う大きな利点です。
移行後の最適化とモダナイゼーション
サーバーをそのまま移行した後は、クラウドの利点を引き出す最適化へ進みます。実際の使用状況を計測し、過剰なスペックのインスタンスを適正なサイズに調整してコストを削減します。さらに、データベースをマネージドサービスへ移す、処理をコンテナやサーバーレスへ置き換えるといったモダナイゼーションを段階的に進めれば、運用負荷を下げ、拡張性を高められます。まず確実に移行して動かし、その後で改善を重ねるという二段構えにすることで、移行のリスクを抑えつつ、長期的にクラウドの恩恵を最大化できます。移行は最適化の出発点と捉えます。
移行プロジェクトの進め方
大規模な移行を成功させるには、技術だけでなく進め方の設計も重要です。移行先の AWS 環境を、セキュリティや権限の基盤を整えた状態で用意しておくと、各ワークロードを安全に受け入れられます。移行対象を依存関係でまとめ、優先順位を付けて段階的に進めます。最初のウェーブで得た知見を、後続の移行に反映して効率を高めます。チームがクラウドの運用に習熟するための準備も並行して進めます。一度にすべてを移そうとせず、計画・実行・検証・改善のサイクルを回しながら着実に進めることが、移行プロジェクトを成功に導きます。
まとめ - 段階的移行の推奨戦略
VMware ワークロードの AWS 移行は、単一のアプローチではなく、ワークロードの特性に応じて EVS と MGN を使い分ける段階的戦略が有効です。まず開発・テスト環境を MGN で EC2 に移行してクラウド運用のノウハウを蓄積し、本番環境は EVS でリフト & シフトした後に順次 EC2 へ転換します。移行後は Compute Optimizer でインスタンスサイズを最適化し、Savings Plans でコストを削減します。VMware ライセンスからの段階的な脱却により、長期的な運用コストの削減を実現できます。