Amazon Elastic VMware Service における VMwareワークロードのモダンネットワークの構築

2026 年 3 月 24 日に公開された “Building a modern network for your VMware workloads using Amazon Elastic VMware Service” を翻訳したものです。

組織がクラウド移行を加速させようとする中で、多くのお客様は既存の VMware ワークロードを Amazon Web Services (AWS) にリフトアンドシフトする方法を求めており、アプリケーションのリファクタリングやスタッフの再トレーニングのオーバーヘッドを避けたいと考えています。Amazon Elastic VMware service (Amazon EVS) は、VMware Cloud Foundation (VCF) を Amazon Virtual Private Cloud (VPC) 内で直接実行でき、VMware ワークロードを AWS で移行・運用するための最も迅速な方法を提供します。

VMware ワークロードを AWS に移行する際にお客様が課題として挙げるのが、クラウドでのネットワーク接続とアーキテクチャ設計です。Amazon EVS のネットワークモデルは、一般的なオンプレミスの VMware デプロイメントとはいくつかの違いがあります。本稿では、Amazon EVS のネットワークモデルを解説し、実証済みのアーキテクチャパターンをご紹介し、Amazon EVS の計画と導入を成功させるための重要な考慮事項をご説明します。

Amazon EVS ネットワークコンポーネント

Amazon EVS は、図 1 に示すように、AWS インフラストラクチャ上で VCF ワークロードをデプロイし、運用するために構築された AWS マネージド自動化フレームワークです。Amazon EVS は、VCF の Software-Defined Data Center (SDDC) スタック (vSphere, vSAN, NSX) を Amazon VPC に完全に統合し、VMware ツールと API を保持しながら、シームレスなハイブリッドクラウド運用を可能にします。Amazon EVS ネットワークは、Amazon VPC ネットワークを分離する 2 層モデルに従い、お客様が VMware NSX Software-Defined Networking を使用できるようにします。

• アンダーレイ層 (VPC infrastructure) : Amazon VPC, サブネット, ルートテーブル, およびお客様が選択したサブネット内で実行される ENI 接続 ESXi ホストで構成されます。この層はホストマネジメントトラフィック (vSphere, vSAN) を処理し、デフォルトまたはメイン VPC ルートテーブルを通じて IP 接続を実現します。
• オーバーレイ層 (NSX Software-Defined Networking) : NSX Manager はマネジメントワークロードドメイン内にデプロイされ、ロジカルスイッチ (セグメント), T0/T1 ゲートウェイ, およびサービス (NAT, Load Balancing, DHCP) をオーケストレーションします。NSX マイクロセグメンテーションとポータブルネットワークポリシーが有効化され、アンダーレイ VPC ネットワークから抽象化し、お客様のワークロードはオーバーレイセグメント上でのみ実行されます。

図 1: ルートサーバーエンドポイントを使用した Amazon EVS と Amazon VPC の統合

主要コンポーネントの詳細

• vSphere クラスター: Amazon EVS は統合された VCF アーキテクチャ (vCenter, NSX Manager, vSAN) をデプロイし、お客様が 1 つ以上のワークロードドメインを作成できるようにします。ESXi ホストは、お客様所有の VPC とサブネット内で Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス (例: i4i.metal) として起動されます。SDDC Manager と vCenter は、SDDC と vSphere クラスターコンポーネントの管理を担います。これらのコンポーネントは、管理ドメインとも呼ばれる最初の SDDC クラスター内で実行されます。さらに、3 つのクラスター化された NSX Manager が SDDC クラスター内で実行され、一元化されたネットワークポリシーオーケストレーションを可能にします。コントロールプレーンは、オーバーレイトランスポートゾーン、セグメントプロファイル、ゲートウェイファイアウォールルールを設定します。
• NSX Edge ノード: 2 つの Edge ノードが最初のクラスターまたは管理ドメイン内の Edge クラスターにデプロイされます。T0 Gateway は各 AWS アベイラビリティーゾーン (AZ) サブネット内の VPC ルートサーバーエンドポイントと eBGP ピアリングを確立し、オーバーレイ CIDR をアドバタイズします。T1 Gateway (テナント/ワークロードごとに 1 つ) はセグメントを接続し、ステートフルサービスを提供します。NSX Edge はレジリエンシーのためにアクティブ-スタンバイ構成です。
• VPC ルートサーバーエンドポイントと BGP ピアリング: Amazon EVS は Amazon VPC ルートサーバーをアンダーレイ BGP ネイバーとして使用します。各 T0 Edge は VPC ルートサーバーエンドポイントに接続し、アンダーレイ ENI 上で eBGP セッションを確立します。VPC のデフォルトまたはメインルートテーブルのみが変更されます。Amazon EVS はアウトバウンドトラフィック用に T0 ENI を指す 0.0.0.0/0 を注入し、オーバーレイプレフィックスをインバウンドに伝播します。この設計により、カスタムルートテーブルの拡散が排除され、自動化が合理化されます。

ネットワークアーキテクチャの計画

Amazon EVS の導入を成功させるには、導入前のネットワーク計画が重要です。特に CIDR 割り当て、サブネット分離、DNS 解決に関する計画が必要です。Amazon EVS では、運用の安定性、スケーラビリティ、他の AWS サービスとの統合を提供するための厳格な制約があります。これらの領域での設定ミスは、導入失敗の主要な原因となっています。

CIDR の計画と制約

Amazon EVS では、インフラストラクチャとワークロードのネットワークに専用の重複しない CIDR ブロックが必要です。AWS では、この情報をまとめるためのツールをお客様に提供しています。このツールは、アカウント、VPC、CIDR、DNS の情報を含むスプレッドシートで、オンボーディング中の計画に使用し、プロビジョニング前の実現可能性を検証します。

• VCF では、図 2 に示すように、用途毎 (マネジメント, vSAN, NSX インターフェース, アプライアンスなど) に異なるサブネットを使用します。Amazon EVS では、適切なサブネットデプロイメントを提供するオーケストレーションを提供します。アンダーレイインフラストラクチャには VPC あたり最小 /24 CIDR が必要で、Amazon EVS マネジメントサブネットではお客様のワークロード (踏み台ホストや監視エージェントを含む) を起動することはできません。これらは VCF コンポーネント専用です。
• VCF 以外のサブネットは、同じ VPC 内にデプロイして使用できます。Amazon EVS VPC に他のワークロードを追加する際には、AWS Well-Architected のベストプラクティスを考慮してください。
• Amazon EVS のサブネットの最大サイズは /24 です。host-vtep ネットワークはホストあたり 2 つのアドレスを消費するため、/24 では最大 112 台のホストをホストできます。

図 2: オーバーレイネットワーク用の EVS VLAN サブネット

• オーバーレイセグメント設計と VM ネットワーク: これらはオーバーレイセグメントに階層的に CIDR を割り当てます (例：アプリケーションティアごとに /24)。成長とワークロード数の増加を想定し、ルートテーブルの効率化のために、ルート集約を検討してください。
• CIDR が重複しないこと: すべてのオーバーレイ CIDR は以下と重複してはいけません。
  • VPC プライマリ CIDR
  • オンプレミスネットワーク (AWS Direct Connect と AWS Transit Gateway 用)
  • 同じ AWS アカウント内の他の Amazon EVS ワークロードドメイン。Amazon EVS は BGP プレフィックスアドバタイズメントを使用し、重複はサイレントトラフィックブラックホールを引き起こします。
  • NSX ネットワークセグメント内での重複サブネットは、テスト目的のワークロードを隔離するのに良い方法です。

DNS

DNS 解決は Amazon EVS のデプロイメント前に設定と検証を行う必要があります。DNS 解決が適切に行われていない場合やタイプミスがある場合、Amazon EVS (VCF) のデプロイメントは失敗します。

• Amazon EVS は DNS 解決に Amazon Route 53 Resolver を使用できます。vCenter と NSX Manager アプライアンスには DNS フォワーダーが事前設定されており、Route 53 Resolver インバウンドエンドポイント (VPC にデプロイ) にクエリを送信できます。
• Amazon EVS は Microsoft DNS、Infoblox、その他のサードパーティソリューションなど、他の DNS サービスも使用できます。
• Amazon EVS の起動前に外部ホストから nslookup や dig -x でテストを行うことで、時間のかかる潜在的にコストの高いデプロイメント失敗を防ぐことができます。

前提条件

この前提条件チェックリストを参照して、デプロイメントを成功させるための情報収集と整理を行ってください。これは、前述したスプレッドシートと併用できます。適切な事前計画により、Amazon EVS ネットワークデプロイメントの問題の 90% を解決できます。このチェックリストでは、以下の項目について触れています。

• VPC CIDR
• Amazon EVS (VCF) サブネット
• Route 53 Resolver
• エンドツーエンドで検証された正引き / 逆引き DNS

一般的なネットワークパターン

このセクションでは、デプロイメントで検討すべき一般的なアーキテクチャについて説明します。

パターン 1: Transit Gateway と AWS Cloud WAN を使用した Amazon EVS VPC から他の VPC およびオンプレミスネットワークへの接続

図 3: Transit Gateway を使用した Amazon EVS VPC から他のネットワークへの接続

図 3 に示すこのパターンは、Amazon EVS オーバーレイセグメントから複数の VPC、オンプレミス/外部ネットワーク、および他の AWS リージョンへの一貫性のあるスケーラブルな接続が必要な場合に使用します。

このパターンでは以下の点が重要です:

• 本稿の執筆時点 (2026/3) では、VPC ピアリングはサポートされていません。Amazon EVS VPC から他の VPC への接続には Transit Gateway や AWS Cloud WAN が必要です。
• Transit VIF を使用した Direct Connect や AWS Site-to-Site VPN は、Amazon EVS アンダーレイ VPC ではなく、Transit Gateway / AWS Cloud WAN で終端する必要があります。Amazon EVS は Private VIF や VGW ベースの Site-to-Site VPN をサポートしていません。
• NSX オーバーレイプレフィックスは BGP を通じて VPC ルートサーバーによって学習され、VPC ルートテーブルに伝播されますが、Transit Gateway と AWS Cloud WAN はこれらのルートを自動的にインポートしません。そのため、各 NSX オーバーレイ CIDR 範囲について、Amazon EVS VPC アタッチメントを指す静的ルートを Transit Gateway/AWS Cloud WAN ルートテーブルに追加する必要があります (図 3 参照)。AWS Cloud WAN の場合、これらの静的ルートはコアネットワークポリシーで設定します。
• より多くの AWS リージョンに拡張する際は、モダンなポリシー駆動型のグローバルネットワークを提供するAWS Cloud WAN を検討してください。これにより、手動での Transit Gateway ピアリングが不要になり、AWS リージョンと VPC 間の動的ルーティングが可能になります。

パターン 2: AWS PrivateLink を使用した Amazon EVS から AWS および非 AWS サービスへのプライベート接続

図 4: Amazon EVS VPC から AWS および非 AWS サービスへのプライベート接続

NSX オーバーレイセグメント上のワークロードが、インターネットを経由することなく、AWS サービス (Amazon Simple Storage Service (Amazon S3) や Amazon DynamoDB など)、お客様が管理するサービス、またはサードパーティ ISV サービスをプライベートに利用する必要があるパターンです。

インターフェースエンドポイント: AWS サービスへの接続には、インターフェース VPC エンドポイントを使用します。インターフェースエンドポイントは、Amazon EVS VPC 内の非 Amazon EVS サブネットに配置するか、Transit Gateway / AWS Cloud WAN 経由でアクセス可能な別の共有サービス VPC に配置します。Amazon EVS オーバーレイから T0 を通じてエンドポイントへトラフィックをルーティングします。2026/3 時点では、S3 ゲートウェイエンドポイントは Amazon EVS でサポートされていません。Amazon EVS ワークロードからの Amazon S3 アクセスには、インターフェースエンドポイントを使用する必要があります。

プライベート DNS: VPC DNS 属性を有効にする必要があります。プライベート DNS でインターフェースエンドポイントを使用する場合は、スプリットホライズン DNS シナリオに対して適切な Route 53 Resolver 転送ルールを設定します。

サービスネットワークエンドポイントとリソースエンドポイント: サービス間またはリソース接続でゼロトラストな接続に VPC Lattice を使用したい場合は、サービスネットワークエンドポイントまたはリソースエンドポイントを使用できます。Lattice サービスネットワークエンドポイントとリソースエンドポイントは、T0 を通じて VPC への NSX オーバーレイネットワークからアクセスできます。2026/3 時点では、Lattice サービスネットワーク関連付けは Amazon EVS でサポートされておらず、接続にはエンドポイントの使用が必要です。

ベストプラクティス: Amazon EVS 専用の VPC

Amazon EVS VPC は Amazon EVS リソース専用とすることを検討してください。共有サービスやその他の Amazon EVS 以外のワークロードは、Transit Gateway または AWS Cloud WAN を通じて接続された VPC に配置します。このアプローチにより、より明確な障害範囲の境界、より良いコスト配分とチャージバック、コンプライアンスとセキュリティ監査が提供されます。

セキュリティポリシーの適用

Amazon EVS におけるセキュリティには多層防御アプローチが必要で、複数のレイヤーでポリシーを適用します。

NSX Distributed Firewall (DFW)

vDefend の DFW は、ハイパーバイザーカーネル内の VM のネットワークインターフェースに直接適用される L2 – L7 ファイアウォール機能を提供します。また、DFW はマイクロセグメンテーションを可能にし、以下のような機能を持っています。

• NSX 論理セグメント間の East-West トラフィック制御
• タグベースの動的セキュリティグループ
• vDefend を通じた IDS/IPS 機能や、アプリケーション対応フィルタリングなどのその他のセキュリティ機能

現在の VCF NSX ライセンスオプションについては、Broadcom VMware アカウントチームにご相談ください。

AWS セキュリティコントロール

AWS セキュリティグループは Amazon EVS VLAN サブネット上の Amazon EVS ENI には適用されません。ただし、セキュリティグループを使用して、インターフェースエンドポイントや Amazon EVS 以外のサブネット内の他のワークロードへのトラフィックを制御できます。

Amazon EVS VLAN サブネット上でアンダーレイのアクセス制御においては Network ACL (NACL) を使用して、DNS, SSH, オンプレミスへのハイブリッド接続用の Hybrid Cloud Extension (HCX), VPC ルートサーバーピアリング用の BGP などのプロトコルのトラフィックを許可することができます。

以下の用途で、VPC の Ingress / Egress ポイントに AWS Network Firewall またはパートナーファイアウォールソリューション (Gateway Load Balancer 経由) の導入を検討してください。

• North-South トラフィックの検査・制御
• Amazon EVS 環境に出入りするトラフィックの IDS/IPS
• URL フィルタリング, 脅威インテリジェンス, コンプライアンス・監査ログなどのセキュリティ機能

モニタリング

VPC Flow logs などの AWS モニタリングサービスは、Amazon EVS ENI のアンダーレイトラフィックのみを確認でき、NSX オーバーレイトラフィックは確認できません。オーバーレイのモニタリングは、Aria operations for Networks、NSX Traceflow などの VMware ツールを使用してください。

考慮事項

• NSX トランスポート MTU 設定が Amazon EC2/VPC アンダーレイ機能と一致していることを確認してください。現世代の EC2 インスタンスは最大 9001 バイトのジャンボフレームをサポートし、Transit Gateway は最大 8500 バイト、Direct Connect は Transit VIF で最大 8500 バイトをサポートします。NSX 内の MTU 制限を考慮してください。
• NSX Edge T0 ゲートウェイは、サイズが不十分な場合にスループットのボトルネックになる可能性があります。NSX Edge データパスメトリクスを監視し、Edge のサイジングとチューニングに関する VMware のパフォーマンスガイダンスに従ってください。
• Amazon EVS では、同一アベイラビリティーゾーン内でのレジリエンシーのために 2 つの VPC ルートサーバーエンドポイントが必要です。2 つの NSX Edge T0 ノードは Active/Standby モードで動作し、各エッジは 1 つの VPC ルートサーバーエンドポイントとピアリングします。
• アクティブな T0 エッジがすべての North-South トラフィックを処理します。フェイルオーバー時間を監視し、障害シナリオをテストして、アプリケーションが Edge ノードフェイルオーバーイベントに対応できることを確認してください。
• Amazon EVS は IPv4 のみをサポートします。執筆時点 (2026/3) では IPv6 は利用できません。
• Amazon EVS は、ピアの生存確認にデフォルトの BGP キープアライブメカニズムをサポートします。Multi-hop Bidirectional Forwarding Detection (BFD) はサポートされていません。
• 作成時、VLAN サブネットは VPC のメインルートテーブルに暗黙的に関連付けられます。デプロイ後、Amazon EVS VLAN サブネットをカスタムルートテーブルに明示的に関連付けることができます。NSX 接続用にカスタムルートテーブルを作成することをお勧めします。
• セキュリティグループは Amazon EVS ENI には適用されません。アンダーレイのアクセス制御には NACL を使用してください。Amazon EVS ワークロードにステートフルなセキュリティポリシーを提供するために、より多くの NSX セキュリティオプションを検討してください。
• 本稿の情報は、今後の Amazon EVS サービスのアップデートにより変更される可能性があります。

まとめ

Amazon Elastic VMware Service (Amazon EVS) は、VMware Cloud Foundation スタックを VPC 内に直接配置し、AWS での VMware テクノロジーの制御と柔軟性を提供します。デプロイメントを成功させるには、事前に十分な計画を立て、適切なルーティングパターンを選択し、適切なレイヤーでセキュリティを実装してください。これらの原則に従うことで、VMware ワークロードを AWS インフラストラクチャ上で実行し、確立されたネットワーク、セキュリティ、運用パターンを適用し、モダナイゼーションとイノベーションのための幅広い AWS サービスを活用することができます。

著者について