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 サービスを活用することができます。 著者について Victor Babasanmi Victor は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼はベストプラクティスを使用したソリューションの計画と構築に関する技術的なガイダンスをお客様に提供し, AWS 環境を運用面で健全に保つことに積極的に取り組んでいます。仕事以外では、サッカーやワークアウト、新しいことに取り組んでいます。 Craig Herring Craig Herring は AWS でシニアスペシャリストソリューションアーキテクトを務めており、インフラストラクチャの移行とモダナイゼーションを専門としています。2021 年に入社して以来、Craig は 35 年にわたる豊富な業界経験を活かして、お客様が AWS ソリューションへの移行とその効果の最大化を支援しています。仕事以外では、Craig は妻の Lindy と 8 人の子供と 3 人の大家族との時間を大切にしています。個人的な興味は友人との交流、ドライブ、アクティブなライフスタイルの維持、オーディオ機器の製作など多岐にわたります。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

こんにちは！SCSKの新沼です。 VMware環境の監視において、こんな悩みを抱えていませんか？ 「膨大な数の仮想マシンを、1つずつZabbixに手動登録するのは大変…」 「すべての仮想マシンにZabbixエージェントを入れる必要があるの？」 今回は、Zabbixの標準機能（VMwareテンプレート）を利用して、VMware ESXiホストおよび、その上で稼働する仮想マシン（以下VM）を全自動で登録・監視する手順をご紹介します。 1. VMware監視の仕組みと構成 設定に入る前に、ZabbixにおけるVMware監視の仕組みを整理します。 従来の監視手法では、仮想マシン（ゲストOS）1台ずつにZabbixエージェントをインストールするのが一般的でした。しかし、この方法には以下のような課題があります。 VMの数が多すぎて、手動でのホスト登録やエージェント導入に膨大な手間がかかる。 アプライアンス製品など、そもそもOSにエージェントをインストールできない仮想マシンが存在する。 VMが作成・削除されるたびに、Zabbix側の監視設定も手動で追加・削除しなければならない。 これらを一気に解決するのが、Zabbix標準の VMwareテンプレート と ローレベルディスカバリ（LLD） の組み合わせです。   ＜メリット＞ 完全エージェントレス : Zabbixサーバーが直接ESXi（またはvCenter）のAPIと通信し、ハイパーバイザー側から見たCPUやメモリ、ストレージの利用状況を取得します。VM側には一切手を加えません。 LLDによる自動追従 : ESXiをZabbixに1つ登録するだけで、その配下にあるVMやデータストアをZabbixが自動的に見つけ出します。今後VMが増減しても、Zabbixが自動で監視対象に追加・削除してくれます。 2. 検証環境 本記事では、以下の環境を前提として設定手順を解説します。 Zabbix Server : 構築済みのZabbixサーバ (Version 7.0) 監視対象 : 1台のESXiホスト ESXi上のVM : 以下の2台を事前に作成済み Web-Server-Test DB-Server-Test この1台のESXiをZabbixに登録し、最終的に2台の仮想マシンがZabbix上に自動登録されることを目指します。 3. 事前準備①：ESXi側でのユーザー作成 ZabbixがAPI経由でESXiにアクセスするための認証情報を用意します。 セキュリティの観点から、 root ユーザーではなく Zabbix監視用の読み取り専用（Read-only）ユーザー を新規作成します。 ESXiのWeb管理画面にログインします。 左メニューの  「ホスト」  ＞  「管理」  ＞  「セキュリティとユーザー」  ＞  「ユーザー」  タブを開きます。 「ユーザーの追加」をクリックし、ユーザー（例： zabbix-monitor ）とパスワードを設定して作成します。 次に、左メニューの  「ホスト」  を右クリックし、 「権限」  をクリックします。 「ユーザーの追加」をクリックし、先ほど作成した  zabbix-monitor  に対して  「読み取り専用 (Read-only)」 ロールを割り当てて保存します。 画像の赤枠のように、読み取り専用ロールがついたアカウントがあることを確認。 4. 事前準備②：Zabbix Server側のプロセスチューニング Zabbixのデフォルト設定では、VMware環境からデータを収集するための専用プロセスが停止しています。設定ファイルを編集してプロセスを起動させます。 Zabbix ServerにSSH等でログインし、設定ファイルを開きます。 $ sudo vi /etc/zabbix/zabbix_server.conf 以下の2つのパラメータを探し、コメントアウトを外して値を設定します。  ＃ VMwareのデータを収集するプロセス数（デフォルト0、小～中規模なら3~5程度） StartVMwareCollectors=5 ＃ APIから取得したデータを保存するキャッシュサイズ（VM数が多い場合は拡張推奨） VMwareCasheSize=64M 設定を保存後、Zabbixサーバープロセスを再起動して設定を反映させます。 $ sudo systemctl restart zabbix-server 5. Zabbixフロントエンドでのホスト登録 準備が整ったら、ZabbixのWeb管理画面からESXiを登録します。 ステップ1：ホストの作成 Zabbixの管理画面にログインし、 「データ収集」  ＞  「ホスト」  を開きます。 右上の  「ホストの作成」  をクリックします。 「ホスト」タブで以下を入力します。 ホスト名 :  ESXi-Test  （任意の名前） テンプレート :  VMware  を選択 ホストグループ :  Virtual machines  等の任意のグループ 💡 ポイント：インターフェース ZabbixのVM監視は、APIによる監視を行うのでインターフェースの設定は不要です。ここでは、エージェントを選択してデフォルトのまま設定しています。 ステップ2：マクロ（認証情報）の設定 次に、上部の「マクロ」タブを開き、「継承とホストマクロ」を選択します。VMwareテンプレートで定義されている以下の3つのマクロの「値」を入力します。 {$VMWARE.URL}  :  https://<ESXiのIPアドレス>/sdk {$VMWARE.USERNAME}  :  zabbix-monitor （先ほどESXiで作ったユーザー） {$VMWARE.PASSWORD}  : （設定したパスワード） 💡 ポイント：URLの末尾に注意 URLを設定する際、単なるIPアドレスではなく、vSphere APIのエンドポイントである /sdk を必ず末尾に付与してください。これを忘れるとAPI通信に失敗します。 入力が完了したら、画面下部の「追加」ボタンをクリックしてホストを保存します。 ※画像は、作成後のものなので、「ホストマクロ」タブになっていますが、「継承したマクロとホストマクロ」のタブで入力して「追加」をクリックしてください。 6. ディスカバリ（自動登録）の確認 ホストを追加すると、Zabbixが設定した間隔（デフォルトは1時間）でESXiと通信し、仮想マシンやデータストアの情報を自動的に取得（ディスカバリ）し始めます。 →すぐに確認したい場合は、ホスト＞ディスカバリから、すべてのディスカバリルールを選択して、「監視データ取得」をクリックしてください。 💡 ポイント：初回登録時の「取得不可」エラーについて 登録直後にホストの「ディスカバリルール」画面を見ると、ルールが赤色の「取得不可」状態になることがあります。これは設定ミスではなく、 Zabbixのバックグラウンドプロセスがデータを収集し、キャッシュに保存し終わるまでの一時的な状態 です。 焦らずに5〜10分程度待つと、自動的に緑色の「有効」状態に切り替わります。 自動登録されたホストの確認 キャッシュが溜まり、ディスカバリが正常に実行された後、 「データ収集」 ＞ 「ホスト」 の一覧画面を再度確認します。 手動で登録した ESXi-Test ホストの他に、事前準備で作成しておいた Web-Server-Test や DB-Server-Test といった仮想マシンが、別々のホストとして自動的に追加されている ことが確認できます。自動登録されたホストは、名前の横にディスカバリのリンクアイコンが表示されます。   7. 【補足】本番環境（vCenter）での運用について 今回は検証のため、「1台のESXiホスト」を直接Zabbixに登録し、その上の仮想マシンを自動検出する方針で解説しました。 しかし、実際の運用現場では複数のESXiホストを「vCenter Server」で一元管理しているケースが多いと思います。その場合、 各ESXiをZabbixに1台ずつ登録する必要はありません。 Zabbix側に「vCenter」を1つだけホストとして登録し、マクロにvCenterの認証情報を設定するだけでOKです。 ZabbixがvCenterのAPIを叩き、その配下にある 「複数のESXiホスト」も「すべての仮想マシン」も芋づる式に全自動で検出・登録してくれます。 本番環境に展開する際は、ぜひこの「vCenter起点」の構成で、劇的な監視運用の自動化を体感してください。 おわりに 以上がZabbixを利用したVMware ESXiおよび仮想マシンの自動監視設定の手順です。 VMwareテンプレートを使用することで、ハイパーバイザー自体のリソース状況をエージェントレスで取得できるだけでなく、仮想マシンが新規作成・削除された際の監視設定の追加・削除作業も全自動化されます。 仮想環境の監視運用を劇的に効率化できる強力な機能ですので、ぜひご自身の環境でも活用してみてください。   　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

本稿は、2026 年 3 月 9 日に AWS migration-and-modernization Blog で公開された Microsoft and VMware workloads on AWS: Your complete AWS re:Invent 2025 playlist を翻訳したものです。 AWS 上で Microsoft および VMware ワークロードを移行およびモダナイズするには、適切な戦略、ツール、実際の検証が必要です。このプレイリストは、AWS re:Invent 2025 のトップセッションをまとめたもので、 AWS Transform によるエージェント型 AI を活用した自動化、AWS 上でのネイティブな VMware の実行、大規模に実施した顧客からの教訓を取り上げ、クラウドジャーニーのあらゆる段階における実践的なガイダンスを提供します。 大規模な移行とモダナイゼーションのためのエージェンティック AI AWS Transform は、大規模な移行のために特別に構築された初のエージェント型 AI サービスです。これは、検出、依存関係マッピング、ウェーブプランニング、サーバー移行といった、以前は数か月の手作業を必要としたタスクを自動化します。これらのセッションでは、VMware と .NET モダナイゼーションの両方のシナリオで AWS Transform がどのように機能するかを示します。 AWS Transform for VMware によるエージェンティック AI を使用した VMware 移行 | MAM202 | Level: 200 Amazon EC2 への大規模な VMware 移行のための初のエージェンティック AI サービスである AWS Transform をご紹介します。アプリケーション検出、依存関係マッピング、ネットワーク変換、ウェーブプランニング、最適化された EC2 インスタンス選択によるサーバー移行を自動化する方法のライブデモをご覧ください。ライセンスの課題とベンダーロックインを克服しながら、VMware インフラストラクチャをクラウドネイティブアーキテクチャにモダナイズし、より迅速で確実な移行を可能にする方法を学びます。 AWS 移行ジャーニー: Microsoft ワークロードのための 2025 年の旅程 | MAM309 | Level: 300 Active Directory およびファイルサーバーの移行戦略、インフラストラクチャの変革、SQL Server データベースの移行手法、.NET アプリケーションモダナイゼーションアプローチを含む、Microsoft エコシステム専用に設計された画期的な移行ツールをご紹介します。これらのサービスとソリューションが複雑な移行を合理化し、手作業を削減し、移行ジャーニーを加速する方法を直接学びます。 AWS 上でネイティブに VMware ワークロードを実行 Amazon Elastic VMware Service (Amazon EVS) を使用すると、リプラットフォームやリファクタリングなしで VMware ワークロードを AWS に移行できます。既存の VMware ツール、スキル、投資を維持しながら、AWS インフラストラクチャ、スケール、サービスを利用できます。これらのセッションでは、開始方法から高度なアーキテクチャパターンまですべてをカバーします。 Amazon EVS の完全ガイド: VMware ワークロードのための AWS スケールを解放 | MAM201 | Level: 200 Amazon EVS は、リプラットフォームやリファクタリングの手間なく、VMware ワークロードを AWS に移行するシームレスな方法を提供します。このサービスを使用すると、既存の VMware への投資と専門知識を保護しながら、AWS の堅牢なインフラストラクチャを活用できます。自己管理を選択するか、AWS パートナーと協力するかにかかわらず、Amazon EVS は、統合されたストレージ、バックアップ、ディザスタリカバリ機能を備えた仮想環境をカスタマイズするための柔軟なオプションを提供します。プラットフォームの直感的なデプロイプロセスと継続的なイノベーションにより、クラウドジャーニーを最適化するために必要なツールと柔軟性が確保されます。 FSx for ONTAP による Amazon EVS のストレージコスト最適化 (NetApp 提供) | MAM101 | Level: 100 Amazon EVS は、リプラットフォームなしで VMware ワークロードを AWS にシームレスに移行できるようにします。 Amazon FSx for NetApp ONTAP と組み合わせると、高い TCO や複雑なデータ操作などの一般的な移行の課題に対処します。この統合により、オンプレミスソリューションで通常見られるエンタープライズ機能である、シームレスなデータ移行、自律的なランサムウェア保護、ストレージ利用率の最適化など、エンタープライズグレードのデータ管理機能が提供されます。AWS パートナーの NetApp によるプレゼンテーションです。 お客様の成功事例 これらのセッションでは、大規模な移行とモダナイゼーションを完了した顧客が、結果を推進した戦略、ツール、教訓を共有します。 VMware ワークロード – 移行とモダナイゼーションの実現 AWS への VMware マイグレーション: 成功方法、ロードマップと戦略 | MAM203 | Level: 200 VMware 環境を AWS へ成功裡に移行した IT リーダーが、クラウドジャーニーの経験を共有します。移行の計画と実行中に使用された実証済みのツール、戦略、学んだ教訓から学びます。これらのグローバル組織は、モダナイゼーションのロードマップとイノベーション戦略に関する洞察を共有し、開始したばかりでも課題をナビゲートしている場合でも、独自のクラウド変革のための貴重なガイダンスを提供します。 エージェンティック AI による改革の先駆け: CSL VMware および SAP モダナイゼーション | MAM346 | Level: 300 CSL Behring が、 AWS Transform for VMware のエージェンティック AI を使用して 4,000 台を超える VMware サーバーを移行し、SAP システムを統合することでインフラストラクチャを変革した方法を紹介します。彼らの戦略は、技術的負債とライセンスコストを削減しながら、検出とプランニングプロセスを 10 倍高速化しました。 RISE with SAP on AWS を通じて ERP ランドスケープを統合し、エンタープライズ全体のデータ標準を確立した方法を学びます。このケーススタディは、組織の変革ジャーニーに適用できる技術的ガイダンスと実践的な洞察を提供します。 Microsoft ワークロード – 移行とモダナイゼーションの実現 AWS Transform による DMV システムのモダナイズ: Idemia の .NET 成功事例 | MAM410 | Level: 400 米国全土の 48 の DMV (車両管理局) にサービスを提供している Idemia が、 AWS Transform を使用してレガシー .NET Framework アプリケーションをモダナイズし、25 年間の技術的負債に対処した方法を学びます。カスタマイズされたモダナイゼーションのためのコンポーザブル変換、パートナーツールのシームレスな統合、変革中のビジネス継続性を維持するための戦略を探ります Grupo Tress Internacional の AWS Transform による .NET モダナイゼーション | MAM320 | Level: 300 Grupo Tress Internacional が、 AWS Transform for .NET を使用して .NET Framework から .NET 8 に移行しながら、モダナイゼーションの労力を 70% 削減した方法をご紹介します。 Amazon Elastic Container Service (Amazon ECS) および AWS Fargate を使用したコンテナ化、 AWS Lambda を使用したサーバーレス実装、.NET アプリケーションのための DevOps 方法論、生成 AI ツールによる開発者のエンパワーメントに関する実践的な戦略について学びます。 EC2 から EKS へ: Tipalti の AWS 上の Windows コンテナへの変革 | MAM339 | Level: 300 Tipalti が従来の Windows アプリケーションをモダンなコンテナ化されたソリューションに変革し、50% のパフォーマンス向上を達成したジャーニーをたどります。プロセス管理の課題の克服、Windows ワークロードのオートスケーリングの実装、Windows コンテナのベストプラクティス、Windows アプリケーションのモダナイズのための実践的な知識について学びます。 Thomson Reuters のエージェンティック AI によるスケールモダナイゼーション | MAM334 | Level: 300 Thomson Reuters が AWS Transform for .NET を活用して月間 500 万行のコードをモダナイズし、開発速度を 4 倍加速した方法を学びます。このセッションでは、アプリケーション変革を数か月から単一のスプリントに短縮し、運用コストを 30% 削減し、大規模な並列モダナイゼーションを実装した方法を紹介します。また、AI を活用したエージェントが、セキュリティとパフォーマンスを維持しながら技術的負債を削減した方法も紹介します。 ライセンスとコスト最適化 ソフトウェアライセンスの管理は、Microsoft および VMware ワークロードを AWS に移行する際の最も複雑な側面の 1 つです。このセッションでは、適切なサイジング、ライセンスコストの削減、AWS ツールを使用したコンプライアンスの維持とクラウド投資の最大化のための戦略を取り上げます。 AWS におけるエンタープライズソフトウェアライセンスと最適化 | MAM315 | Level: 300 このセッションでは、Microsoft ワークロードとコスト最適化戦略に焦点を当てて、AWS における商用ソフトウェアライセンスについて詳しく説明します。 Microsoft Optimization and Licensing Assessment (OLA) スペシャリストが、クラウドライセンスの複雑さの管理に関する専門的な洞察を共有します。このセッションでは、新しいセルフサービス AWS Transform Assessments を含む、さまざまなデプロイシナリオのための完全に無償の OLA オファリングを取り上げます。これらのツールが、クラウド投資効果を最大化するために AWS サービス全体で重要となる最適なサイジングの推奨事項をどのように提供するかをご覧ください。 チョークトーク re:Invent 2025 の以下のチョークトークは、移行計画、.NET モダナイゼーション、SQL Server、ライセンス、Amazon EVS アーキテクチャに関するインタラクティブで詳細なコンテンツを提供します。 スライドはこちらでご覧いただけます。 エージェンティック AI による AWS 上の SQL Server モダナイゼーションの加速 | MAM304 | Level: 300 AWS におけるライセンス管理と最適化 | MAM321 | Level: 300 .NET クラウドジャーニー: 移行とモダイゼーション戦略 | MAM317 | Level: 300 突然 SQL Server データ管理者になった人のための AWS 基礎 | MAM308 | Level: 300 VMware から AWS への準備: 移行前の基本的な決定事項 | MAM357 | Level: 300 Amazon EVS ディーブダイブ: 高度なネットワークとストレージアーキテクチャ | MAM401 | Level: 400 Amazon EVS ディープダイブ: 戦略的な移行計画 | MAM305 | Level: 300 まとめ AWS re:Invent 2025 は 1 つのことを明確にしました。Microsoft および VMware ワークロードをクラウドに移行することは、これまで以上に現実的になっています。エージェンティック AI により、.NET モダナイゼーションと VMware 移行の手作業が数か月から数週間に短縮されます。専用に設計構築されたインフラストラクチャオプションにより、リプラットフォームの障壁が取り除かれ、適切なライセンス戦略を導入することで、コストを管理しながらより迅速に移行できます。 Thomson Reuters から CSL まで、多くのお客様が、適切なツールと明確な移行戦略を組み合わせ、結果を達成しています。セッションをご覧になり、チョークトークのスライドを確認し、AWS での移行の計画を開始してください。 全ての移行とモダナイゼーションのプレイリストは、 YouTube の全プレイリスト をご覧ください。 <!-- '"` --> Suhail Fouzan Suhail Fouzan は、IT 業界で 15 年以上の経験を持つ Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトです。Microsoft ワークロード、移行サービス、AWS Systems Manager による運用管理を専門とし、Suhail はお客様がインフラストラクチャを AWS に正常に移行できるよう支援しています。仕事以外では、Suhail はクリケットをプレーしたり、家族と過ごしたりすることを楽しんでいます。 Bianca Velasco Bianca Velasco は、AWS 上の VMware ベースのワークロードの移行と変革に焦点を当てた AWS のプロダクトマーケティングマネージャーです。マーケティングとテクノロジーで 7 年以上の経験があり、複雑なテクノロジーを意味があり親しみやすいものにするナラティブを作成することに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 この投稿の翻訳は Solutions Architect の田澤が担当させていただきました。原文記事は こちら です。