Amazon EVS（Amazon Elastic VMware Service）完全解説
VMware on AWS後継の本命か？競合との徹底比較 ― インフラエンジニア向け技術解説（2026年6月時点）
Amazon EVSは2025年8月5日にGAした、VCF（VMware Cloud Foundation）を顧客自身のVPC内・EC2ベアメタル上でセルフマネージドで動かすAWSネイティブサービス。東京リージョン（ap-northeast-1）はGAから対応。最小4ホスト・最大32ホスト（2026年5月に16→32に拡張）、BYOLのVCFライセンスが必須。VMC on AWS「再販終了」後の実質的な移行先だが、パッチ・アップグレード・障害ホスト交換は顧客責任という点がVMCとの最大の違い。東京4ホスト最小構成でのAWS側コストはオンデマンドで約$40,600/月（VCFライセンス別途）。
1. Amazon EVSとは
Amazon Elastic VMware Service（Amazon EVS）は、AWSがVMware Cloud Foundation（VCF）を顧客のAmazon VPC内に自動デプロイし、EC2ベアメタルインスタンス（i4i.metal等）上でそのまま動かすためのAWSネイティブサービスだ。AWSがインフラプロビジョニングとハードウェア管理を担い、顧客はESXi・vCenter・NSX・SDDC Managerへのフルルート権限を持ちながらVMwareワークロードを運用できる。
沿革を整理すると、AWS × VMware（現Broadcom）の協業は2016年に始まり、フルマネージドの「VMware Cloud on AWS（VMC）」として展開されてきた。しかし2024年2月のBroadcomによるVMware買収後のライセンス改定、2024年4月30日のAWSによるVMC再販終了を経て、2024年末のre:Invent 2024でAWSがEVSを発表。2025年6月9日にパブリックプレビュー（東京含む5リージョン）、同年8月5日に一般提供（GA）を開始した。GA対応リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（フランクフルト・アイルランド）の6リージョン。その後2025年11月にムンバイ・シドニー・カナダ中部・パリに拡張されている。
EVSはAWSが「プリミティブなサービス（ビルディングブロック）」と位置づけており、顧客がVMwareワークロードをそのままAWSで動かす最速経路として提供される。AWSには他にAWS Transform（エージェント型AI移行）、Application Migration Service（MGN）、コンテナ化（ECS/EKS）など複数の移行経路があるが、EVSは「再プラットフォーム・リファクタリング不要」の選択肢だ。
2. アーキテクチャと技術仕様
SDDC構成（Consolidated Architecture）
EVSはVCFの「Consolidated（統合）アーキテクチャ」を採用する。これは管理コンポーネントとワークロードVMを単一クラスタ上に同居させるモデルで、自動デプロイされる管理コンポーネントは以下の通りだ。
- vCenter Server（1台）
- SDDC Manager（1台）
- NSX Manager（3台クラスタ構成）
- NSX Edge（2台、Active/Standby）
- Cloud Builder（デプロイ完了後に自動削除）
これらの管理VMはvSphereリソースプールで分離されるが、ワークロードVMと同一ESXiホスト上で動作する。VCFのSeparated Architecture（管理ドメインとワークロードドメインを物理分離）はEVSでは現時点で非対応。
ネットワーク構成
EVSのネットワークは2層構造だ。外側はAmazon VPC（アンダーレイ）、内側はNSXオーバーレイ（T0/T1ゲートウェイ）。T0ゲートウェイがVPC Route Server Endpointとの間でeBGPピアリングを確立し、NSXオーバーレイのCIDRをVPCルートテーブルにアドバタイズする仕組み。EVS環境ごとに2つのVPC Route Server Endpointが必須。
構成上の制約として、T0ゲートウェイは1環境あたり1台のみ、シングルAZ構成のみ（マルチAZ非対応）という点は設計で重要な検討事項となる。オンプレミスとの接続はTransit Gateway経由のDirect Connect（Transit VIF）またはSite-to-Site VPN（TGWアタッチメント）が必要で、Direct Connect Private VIFやVGWベースVPN、VPCピアリングは非対応。
ストレージ
プライマリストレージはvSAN（ローカルNVMeインスタンスストア）。i4i.metalでは1ホストあたり約20.5 TiB rawのvSANキャパシティが使用可能（vSAN圧縮・重複排除有効時の実効容量はワークロード依存）。インスタンスストアはEphemeralであるため、VCFコマンドを経ずにEC2インスタンスを停止・終了するとデータを失う。外部ストレージとしてAmazon FSx for NetApp ONTAP（NFS/iSCSI）やPure Cloud Block Storeが対応している。
デプロイ所要時間はAWSコンソールのガイド付きワークフローまたはCLI/CloudFormationから約3時間で完了する。
VMC on AWSで利用できた vDefend Advanced Threat Protection と VMware Live Cyber Recovery はEVSでは現時点で非対応。vSphere HA/DRSはセルフマネージドでの構成が必要。EDRS（Elastic DRS）もEVSでは使用不可。
3. 最小構成・最大構成（東京リージョン）
| 項目 | i4i.metal（GA当初） | i7i.metal-24xl（追加） | 東京リージョン対応 |
|---|---|---|---|
| vCPU数 | 128 vCPU（64物理コア×HT） | 96 vCPU（48物理コア×HT） | 両タイプ対応 |
| メモリ | 1,024 GiB | 768 GiB | ― |
| ローカルNVMe | 30 TB（vSAN: 約20.5 TiB raw/host） | 約22.5 TiB raw/host | ― |
| ネットワーク | 75 Gbps | 200 Gbps超 | ― |
| CPU世代 | 第3世代 Intel Xeon (Ice Lake) 3.5 GHz | 第5世代 Intel Xeon Scalable (Emerald Rapids) | ― |
| 最小ホスト数 | 4ホスト固定（環境作成時） | 4ホスト固定（環境作成時） | 4ホスト〜（キャパシティ予約推奨） |
| 最大ホスト数 | 32ホスト（※1） | 32ホスト（※1） | クォータ引き上げリクエスト必要 |
| VCFライセンス要件 | 最低256コア（4ホスト×64物理コア） | 4ホスト×コア数分 | BYOL必須（Broadcom購入） |
（※1）2026年5月19日付けAWS What's NewにてGA当初の上限16から32へ倍増。サービスクォータ引き上げリクエストが必要。
その他の前提条件
- AWSサポートプラン：Business Support以上が必須（環境作成失敗条件）。なお2027年1月以降、Business Supportは廃止予定でBusiness Support+（$29/月〜）が実質最低基準に移行する。
- VPC：最小/22のCIDRブロック、Route Server Endpoint×2（それぞれ専用ピア）が必要。IPv6は現時点で非対応。
- 対応VCFバージョン：5.2.1、5.2.2（2026年6月時点）。VCF 9は現時点で非対応。
- デプロイ所要時間：約3時間（コンソールまたはCLI/CloudFormation）。
4. 最小構成で動くワークロードVM数の比較
インフラエンジニアがサービス選定で最も気にするポイントの一つが「最小構成でどれだけのVMを動かせるか」だ。各サービスの最小構成におけるワークロードVM稼働数の推計を以下の前提で比較する。
標準VM：2 vCPU / 8 GiB RAM / 100 GiB diskの小中規模汎用VM想定。管理コンポーネント消費分（VCF: 約24 vCPU・200 GiB、Nutanix CVM: ノードあたり12 vCPU・32 GiB等）を控除。vSphere HAの1ノード分フェイルオーバー予約（25%相当）を控除。CPUオーバーコミット比は2:1適用。VDI（1 vCPU/4 GiB）は約2倍、DBサーバー（8 vCPU/32 GiB）は約1/4が目安。
| サービス | 最小ノード数・仕様 | 総vCPU / 総RAM | 推計ワークロードVM数 | 制約要因・特記 |
|---|---|---|---|---|
| Amazon EVS | 4 × i4i.metal 128 vCPU / 1,024 GiB |
512 vCPU 4,096 GiB |
200〜400 VM | 最小4ノードのため他サービスより容量大。HAで1ノード分（1,024 GiB）確保。RAM制約が支配的。vSAN容量は十分（FTT=1で約50 TiB usable）。 |
| Azure VMware Solution | 3 × AV36 36コア / 576 GiB |
216 vCPU 1,728 GiB |
70〜150 VM | Microsoft管理コンポーネントが46 GHz CPU・171 GiB RAMを予約（3ノード中の約50%に相当）。RAM・CPUともに制約。HA1ノード分を除くと実効容量は小さい。 |
| Google GCVE | 3 × ve1-standard-72 72 vCPU / 768 GiB |
216 vCPU 2,304 GiB |
100〜200 VM | AVS AV36よりメモリ1ノードあたり192 GiB多い（768 vs 576 GiB）。フルマネージドのためHA予約がGoogle任せで透明度低め。 |
| Oracle OCVS | 3 × BM.DenseIO.E4.128 128 OCPU / 2,048 GiB |
384 OCPU 6,144 GiB |
200〜500 VM | 最大RAMを誇る構成。旧DenseIO2.52（52 OCPU/768 GiB）では80〜170 VM程度。標準shapeはOCI Block Storageを使いvSAN不要。東京リージョン（ap-tokyo-1）はOCVSの対応状況を個別確認要。 |
| NC2 on AWS （Nutanix） |
3 × i4i.metal 128 vCPU / 1,024 GiB |
384 vCPU 3,072 GiB |
150〜300 VM | CVM（Controller VM）がノードあたり12 vCPU・32 GiB消費。最小3ノード。最大28ノード（7 placement group対応リージョン）。ハイパーバイザはAHV（ESXiではない）。 |
※ 推計値。実際のVM数はVMサイズ・CPUオーバーコミット率・ワークロード特性・vSAN利用可能容量によって大きく変動する。VDI（1 vCPU/4 GiB）なら約2倍、DBサーバー（8 vCPU/32 GiB）なら約1/4が目安。
EVSは最小4ノード、他のサービスは最小3ノードという構造差がある。EVSの「200〜400 VM」はこの1ノード多い構成に起因する部分が大きい。同じ3ノードに換算すると3×i4i.metalで約150〜300 VM相当になり、NC2（AHV）と同程度の容量になる点に注意。
5. VMware Cloud on AWS（VMC）との比較
| 比較項目 | Amazon EVS | VMware Cloud on AWS（VMC） |
|---|---|---|
| サービスモデル | セルフマネージド（AWSネイティブサービス） | フルマネージド（Broadcom運営） |
| デプロイ先 | 顧客自身のVPC内 | Broadcom管理SDDC（顧客VPC外） |
| vCenter/ESXi管理権限 | フルルート権限あり（VIB導入等の自由度高い） | Broadcomが管理、顧客は限定アクセス |
| パッチ・アップグレード責任 | 顧客（またはパートナー）責任 | Broadcom責任 |
| 障害ホスト交換 | 顧客責任（AWSに連絡し交換手続き） | Broadcom責任 |
| ライセンスモデル | BYOL必須（VCFポータビリティ） | Broadcom直販サブスクリプション（ライセンス込み） |
| 最小ホスト数 | 4ホスト | 2ホスト〜（i3.metal） |
| EDRS（弾力的リソーシング） | 非対応（セルフ管理必要） | 対応 |
| vDefend ATP | 現時点で非対応 | 対応 |
| AWSからの販売 | AWSが提供（AWSアカウント直結） | 2024年4月30日にAWS再販終了・Broadcom直販のみ |
VMC→EVS移行パス：VMware HCXを使ってVMC on AWS→EVSへのvMotion/Bulk/RAV移行が公式サポートされている。VMC GovCloudのEOLなども背景にあり、VMC利用中で将来不透明感を感じている組織にとってEVSは最も自然な移行先だ。EVSデプロイ時にHCXのプライベート接続方式（Direct Connect または Public Internet）を一度選択すると変更不可な点に注意。
6. NC2 on AWS（Nutanix）との比較
NC2 on AWSとEVSは「AWSベアメタル上でオンプレの仮想化環境をそのままクラウドに持ち込む」という方向性は共通しているが、ハイパーバイザと用途が根本的に異なる。
| 比較項目 | Amazon EVS | NC2 on AWS（Nutanix） |
|---|---|---|
| ハイパーバイザ | VMware ESXi | Nutanix AHV（VMware非依存） |
| 管理ツール | vCenter / SDDC Manager / NSX | Prism Central / Prism Element |
| ストレージ | vSAN（ローカルNVMe）＋外部（FSx等） | Nutanix DSF（CVM管理）＋EBSストレージ拡張可 |
| 最小ノード | 4ノード | 3ノード（2ノードは非対応） |
| 最大ノード | 32ノード/環境 | 28ノード/クラスタ（7 placement group対応リージョン） |
| 利用可能インスタンス | i4i.metal、i7i.metal-24xl | i3.metal、i3en.metal、i4i.metal、i7ie/i7i.metal-24xl/48xl、z1d.metal等 |
| VMware移行ツール | HCX（vMotion/Bulk/RAV） | Nutanix Move（ESXi→AHV変換が必要） |
| クラスタHibernate | 非対応 | 対応（S3退避でコスト最適化可） |
| 位置づけ | VMware継続（スキル・ライセンス・ツール維持） | VMware脱却（AHVへのハイパーバイザ変換） |
判断軸：VMwareからの移行時にESXi・vCenter・NSXのスキルとライセンスを維持したければEVS。Nutanixをオンプレで採用中・採用予定であればNC2。VMwareから完全脱却してコスト削減を狙うならNC2（ただしNutanix Moveでのハイパーバイザ変換工数が発生）。
7. 競合サービス比較（AVS / GCVE / OCVS）
| 比較項目 | Amazon EVS | Azure VMware Solution（AVS） | Google Cloud VMware Engine（GCVE） | Oracle Cloud VMware Solution（OCVS） |
|---|---|---|---|---|
| 管理モデル | セルフマネージド | マネージド寄り（Microsoft管理） | フルマネージド（Google管理） | 顧客フルアクセス型（EVSに最も近い） |
| 最小ノード | 4ノード | 3ノード | 1ノード（PoC）/ 3ノード（本番） | 1ノード（dev）/ 3ノード（本番） |
| 最大ノード/クラスタ | 32ノード/環境 | 96ノード/プライベートクラウド（最大12クラスタ×最大16ノード） | 64ノード（全クラスタ合計） | 64ノード/クラスタ（最大15クラスタ） |
| マルチAZ | 非対応（シングルAZのみ） | Stretched Cluster対応（マルチAZ） | Stretched Cluster対応（マルチゾーン） | フォルトドメイン単位（シングルAD） |
| VCFライセンス | BYOL必須 | 2025年11月以降新規ノードはBYOL基本 | Google包含（ライセンス込み） | Oracle包含またはBYOL（移行フェーズ依存） |
| HCX | 対応（HCX Advanced/Enterprise） | HCX Advanced 包含 | HCX 包含 | HCX 包含 |
| 東京/日本リージョン | ap-northeast-1（東京）対応済み | Japan East（東日本）対応 | asia-northeast1（東京）対応 | ap-tokyo-1（東京）対応状況は要確認 |
| デプロイ時間 | 約3時間 | 約3〜4時間 | 約30〜60分（高速プロビジョニング） | 約2〜4時間 |
各サービスの特徴整理
- AVS（Azure）：Azureエコシステム（Azure NetApp Files、Azure Elastic SAN等）との統合が強み。Stretched Clusterでマルチ可用性ゾーンに対応できる点がEVSと異なる大きな差別化。マネージド寄りのため運用負荷は低め。
- GCVE（Google）：フルマネージドで運用負荷が最も低い。1ノードから試せる柔軟性と30〜60分の高速プロビジョニングが評価される。ve2世代（128 vCPU/2TB RAM）への世代交代が進行中。
- OCVS（Oracle）：ESXiルートアクセスでEVSに最も近い運用モデル。OCI Block Storage（外部ストレージ）との組み合わせで「コンピュートとストレージの独立スケーリング」が可能という独自性を持つ。46以上のグローバルリージョンで最大のカバレッジ。
8. コスト・ライセンス（東京リージョン試算）
AWS側料金の構成（3要素）
- EC2インスタンス料金（i4i.metal）：オンデマンド・1年/3年 Savings Plan（ISP）・予約で割引選択可
- EVSコントロールプレーン：$0.92/usage-hour（ホスト数×時間）
- VPC Route Server Endpoint：$0.20/endpoint-hour（2 endpoint必須、標準料金の73%割引適用後）
東京リージョン（4×i4i.metal、730時間/月）試算
| 料金タイプ | EC2（i4i.metal×4） | EVSコントロールプレーン | Route Server（×2） | 合計/月（AWS課金のみ） |
|---|---|---|---|---|
| オンデマンド | $12.883/hr × 4 × 730h ≒ $37,618 |
$0.92 × 4 × 730h ≒ $2,686 |
$0.20 × 2 × 730h ≒ $292 |
約 $40,600 /月 |
| 3年 ISP（推計） | ≒ $17,377 | ≒ $2,686 | ≒ $292 | 約 $20,355 /月 |
※ EC2 i4i.metalの東京オンデマンド単価はサードパーティ価格情報ベース。3年ISPは米国比から推計した参考値。正確な見積もりはAWS Pricing Calculator（ap-northeast-1）で実施のこと。VCFライセンスコスト（Broadcom別途購入）は含まず。
Broadcom VCFライセンスについて
- BYOL（ライセンスポータビリティ）必須：VCFサブスクリプション＋ポータビリティ権が必要（2023年12月13日以降購入のVCF 5.1+に付帯）。
- 最低コア要件：256コア（4×i4i.metal の初期デプロイ分）＋vSAN 110 TiB容量ライセンス。
- 課金単位：物理コア単位（16コア/CPU最小）。かつて2025年4月に追加された「72コア/インスタンス最小」の要件は後に撤回された模様（契約時に最新条件を要確認）。
- クラウドプロバイダー経由ライセンスにポータビリティ権なし：パブリッククラウドプロバイダー経由で取得したライセンスはポータビリティ対象外。
- Windows Serverライセンス：EVSを通じてVM単位での取得が可能（$0.046/vCPU-hour）。
9. 移行シナリオ（VMware from ― HCX活用）
EVSはVMware HCX（VCF Operations HCX）を公式サポートする。HCXはデフォルトではEVS環境にインストールされておらず、EVSデプロイ後に別途構成が必要。
接続方式（デプロイ時に一度のみ選択・変更不可）
- プライベート接続：Direct Connect（Transit VIF + Direct Connect Gateway + Transit Gateway）またはSite-to-Site VPN（TGW VPNアタッチメント）経由。本番・大規模移行に推奨。
- パブリックインターネット接続：IPAMで公開IP割当、隔離されたHCX用パブリックVLANサブネットが必要。帯域幅制約に注意（WAN最適化機能HCX-WOの活用を推奨）。
主な移行パターン
- オンプレVMware → EVS：HCXサイトペア設定→Service Mesh作成→vMotion/Bulk/RAV移行。IPアドレス変更不要、運用ランブック変更不要で移行可能。
- VMC on AWS → EVS：HCXプライベート接続（Transit Gateway経由）でVMC→EVS間のvMotion移行。
- DR用途（EVSをDRサイトに）：本番オンプレ/クラウド→EVSをDRターゲットとしてHCX RAVで非同期レプリケーション。
HCXの主な移行タイプ：Cold Migration、vMotion（無停止・単一VM）、Bulk Migration、Replication Assisted vMotion（RAV：並列・スケジュール・無停止）、OS Assisted Migration（非vSphere）、L2 Network Extension（IP変更不要）。
10. 強みと弱みまとめ
- VMwareスキル・ツール・ランブック維持のまま移行可能
- 顧客VPC内デプロイで200以上のAWSサービスと同一VPC内で直結
- ESXi/vCenter/NSX/SDDC Managerへのフルルート権限（VIBインストール等も可能）
- 約3時間でVCF環境が自動展開
- HCXによるIP変更不要のシームレス移行
- VCFライセンスポータビリティでBroadcom投資を活用
- Kyndryl・DXC・富士ソフト等のパートナーマネージドサービスで運用負荷を外出し可能
- 2026年5月以降、最大32ホスト/環境に拡張（当初16）
- セルフマネージド：ESXi/vSAN/NSXのパッチ・アップグレード・障害ホスト交換が顧客責任
- シングルAZのみ：マルチAZ（Stretched Cluster）非対応
- VCF 9非対応（2026年6月時点）：5.2.1/5.2.2のみ
- 最小4ホスト：競合（3ホスト〜）より参入コストが高い
- T0ゲートウェイは1環境あたり1台のみ
- vDefend Advanced Threat Protectionが現時点で非対応
- Business Support（最低）以上が必須（2027年以降はBusiness Support+以上）
- BroadcomのVCFライセンスを別途調達する必要があり、ライセンスコストが不確定
- 接続方式（プライベート/パブリック）はデプロイ時の一度きりの選択で後から変更不可
11. まとめ ― 評価・選定の推奨ステップ
Amazon EVSは「VMware資産・スキルをそのまま維持しながらAWSクラウドの恩恵を受ける」という課題に対して2025年8月にGAした現実解だ。VMC on AWSの再販終了後を睨んだ選択肢として、特に大規模なVMwareデータセンター撤退・DR強化・段階的モダナイゼーションを検討している組織に刺さるサービスといえる。
一方で、セルフマネージドゆえの運用負荷（パッチ・アップグレード）、最小4ホストという参入コスト、VCF 9非対応、シングルAZ制約という限界点も明確だ。これらを踏まえた評価フローは以下になる。
① VMwareを継続するか脱却するか → 脱却ならNC2（AHV）またはAWSネイティブ移行（MGN等）を検討
② マルチAZ（Stretched Cluster）が必須か → 必須ならAVS（Azure）またはGCVEを検討
③ 最小3ノードで十分か → 3ノードで十分ならAVS/GCVE/OCVSが有利
④ VCF 9が早期に必要か → 必要なら2026年時点でEVSは非対応のため待機またはオンプレVCFを維持
⑤ セルフマネージドの運用負荷を自社で吸収できるか → できない場合はKyndryl・DXC・富士ソフト等のパートナーマネージドを前提に検討
⑥ 3年コミットが可能なワークロードがあるか → あればSavings Planで東京でも月額$20,000台（4ホスト、AWS課金のみ）まで削減可能
・最大ホスト数：16ホスト → 32ホストに修正（2026年5月What's New確認）
・パブリックプレビュー開始：2025年6月9日（東京含む5リージョン）確認
・サポートプラン：Business Support以上（最低要件）を公式ドキュメントで確認。2027年1月以降はBusiness Support+が実質最低基準となる予定。
・EVSで現時点非対応機能（vDefend ATP、VMware Live Cyber Recovery）を追記
・NC2最大ノード数（28ノード/クラスタ）を追記
・AVSの管理コンポーネント予約（46 GHz CPU / 171.88 GiB RAM）に基づくVM数試算を追記
本記事は2026年6月時点の公開情報（AWS公式ドキュメント・What's New・各クラウドベンダー公式資料）に基づいています。料金・仕様・対応リージョンは変更されることがあるため、最新情報はAWS Pricing Calculator・各サービス公式ページで確認してください。
0 件のコメント:
コメントを投稿