Amazon Web Services ブログ

Amazon EVS への VCF 9.1 エンドツーエンド自動化デプロイ

本記事は 2026 年 7 月 6 日 に公開された「Deploying VCF 9.1 on Amazon EVS with End-to-End Automation」を翻訳したものです。

はじめに

Amazon Elastic VMware Service (Amazon EVS) を使用すると、Amazon VPC 内の AWS ベアメタル EC2 インスタンス上で VMware Cloud Foundation (VCF) を直接実行できます。EVS では、使い慣れた VMware スタックの運用一貫性を維持しながら、AWS クラウドサービスの弾力性、セキュリティ、豊富な機能を活用できます。

VCF 9 は VMware Cloud Foundation の最新リリースであり、以前の VCF 5.2 リリースとは根本的に異なる方法で Amazon EVS と連携します。VCF 5.2 では、EVS サービスがデプロイ全体をエンドツーエンドで処理していました。VLAN サブネットのデプロイ、ホストを含む EVS 環境、および完全な VCF スタックはすべて、サービスが自動的にプロビジョニングおよび設定していました。VCF 9 では、Amazon EVS はセルフデプロイモードと呼ばれる方式でのみ動作します。

セルフデプロイモードとは？

セルフデプロイモードでは、Amazon EVS が基盤となる AWS インフラストラクチャをプロビジョニングします。具体的には、VCF に必要な VLAN サブネットと、選択した ESXi バージョン（9.0 または 9.1）を実行するベアメタル EC2 ホストです。ただし、サービスが担うのはここまでです。EVS は VCF 自体のインストールや設定は行いません。EVS が代わりに VCF 9 をデプロイするオプションは存在しません。

つまり、EVS がホストとネットワークを提供した後は、VCF のインストールはお客様の責任となります。VMware のドキュメントに従って手動でインストールするか、自動化を使ってプログラム的に処理できます。本ブログ記事ではまさにその自動化を取り上げます。AWS が公開したエンドツーエンドの自動化ツールキットは、前提条件となる AWS インフラストラクチャと EVS 環境のプロビジョニングから、VCF のインストールおよび設定まで、ワークフロー全体を処理します。このツールキットは VCF 9.0 と 9.1 の両方に対応しています。

VCF デプロイを自動化する理由

セルフデプロイモードでは VCF 9 のインストールはお客様の責任であるため、自動化が特に効力を発揮します。VCF の手動インストールには、数十もの設定ステップ、複雑な JSON 仕様の作成、パスワード生成、そして数時間の待機が必要です。本ツールキットはそれを 3 つの CLI コマンドに集約します。

  • 再現性：リージョンやアカウントをまたいで同一環境をデプロイ可能
  • スピード：数時間かかる手動プロセスを 3 コマンドに短縮
  • 監査性：すべての設定判断がバージョン管理されたコードに記録
  • エラー削減：DNS レコード、VLAN CIDR、bringup 仕様における手動入力ミスを排除
  • セキュリティ：パスワードを自動生成して AWS Secrets Manager に保存

構築するもの

自動化ツールキットは VCF 9.0 と 9.1 の両方に対応していますが、本ブログでは VCF 9.1 のデプロイに絞って説明します。このウォークスルーを完了すると、以下が構築されます。

  • Route 53 DNS、BGP 対応 Route Server、必要なネットワーキングを備えた VPC
  • ESXi 9.1 を実行する 3 台のベアメタルホストを持つ Amazon EVS 環境
  • 完全に動作する VCF 9.1 スタック：vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、2 台の NSX Edge
  • NSX オーバーレイセグメントと VPC ルートテーブル間で動的なルート伝播を行う Tier-0 および Tier-1 ゲートウェイ
  • EVS サービス内の Ops Manager Connector

コストの考慮事項

本自動化でデプロイされるリソースには、EC2 ベアメタルコンピューティング、Amazon EVS コントロールプレーン、VPC Route Server、Transit Gateway（有効化した場合）、NAT Gateway、EBS ボリューム、Route 53 ホストゾーンなど、相当な月額費用が発生します。デプロイ前に Amazon EVS 料金ページを確認し、AWS Pricing Calculator を使って環境全体のコストを把握することをお勧めします。

アーキテクチャの概要

本自動化は、完全な Amazon EVS 環境と VCF 9 を 3 つのステージにわたってデプロイします（1 ステージにつき 1 つのレイヤー）。最初に設定の詳細を入力するだけで、各ステージで生成されたリソース ARN などのメタデータとともに設定値が次のステージへ自動的に引き継がれます。同じ情報を 2 度入力する必要はなく、設定ミスを大幅に削減できます。各ステージの内容は次のとおりです。

  1. AWS 前提条件とアンダーレイ：VPC、サービスアクセスサブネット、Route 53（フォワードおよびリバースゾーン）、2 つの BGP エンドポイントを持つ Route Server、セキュリティグループ、オプションの Transit Gateway、オプションの Windows ジャンプボックス（踏み台サーバー）、オプションのパブリックまたはプライベート HCX 接続などを構築します。
  2. EVS レイヤー：まず、管理、vMotion、vSAN、vTEP、エッジアップリンクなどに使用する 10 個の VLAN サブネットを作成し、EVS 環境を構築します。次に、ESXi 9.1 で起動する 3 台のベアメタルホスト（ユーザーが指定する i4i.metal または i7i.metal-24xl）をプロビジョニングします。最後に、VCF Installer をステージングするデータストアとして EBS ボリュームを作成し、いずれかのホストにマウントします。
  3. VCF のインストールと NSX ルーティング：VCF Installer のデポを設定し、ターゲット VCF バージョンに基づいてバイナリのダウンロードを自動的にトリガーします。次に vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、アクティブ/スタンバイ構成の 2 台の NSX Edge をデプロイします。エッジは BGP で AWS Route Server とピアリングし、NSX セグメントルートを VPC にアドバタイズします。

3 フェーズの自動化アプローチ

本自動化は 3 つの順次フェーズで構成されており、それぞれ独自のツールと目的を持ちます。

フェーズ スタック 内容
1 Terraform VPC、Route 53、Route Server、セキュリティグループ、オプションの Transit Gateway、オプションのジャンプボックス、オプションのパブリック接続など
2 Python (boto3) EVS 環境と VLAN サブネットの作成、ESXi 9.1 を搭載したベアメタルホストのプロビジョニング、インストーラーステージング用 EBS ボリュームの作成とアタッチ
3 Python (VCF SDK + boto3) デポの設定、バイナリのダウンロード、VCF bringup、インストーラーのクリーンアップ、NSX Edge Cluster とルーティングのデプロイ、Ops Manager Connector の作成

フェーズ 1 と 2 は Mac、Linux、または Windows ワークステーションからローカルで実行します。フェーズ 3 は VPC 内のジャンプボックスから実行します（VCF Installer および NSX Manager への直接接続に必要）。唯一の手動ステップは、フェーズ 2 と 3 の間に行う 2 つの簡単な ESXi 設定と VCF Installer OVA のデプロイです。デプロイ全体の所要時間はおよそ 3.5〜6 時間で、大部分はフェーズ 3 の VCF bringup プロセスが占めます。

前提条件

AWS アカウントと権限

  • 以下を満たす AWS アカウント
    • AWS Business Support 以上
    • EVS 環境あたりのホスト数サービスクォータが 3 以上に設定済み
    • オンデマンドスタンダード（A、C、D、H、I、M、R、T、Z）インスタンスのサービスクォータが 256 以上に設定済み
  • コードリポジトリのフェーズ 1 配下にある iam_policy.json ファイルで定義された権限ポリシーを持つ IAM ユーザーまたはロール

ローカルワークステーションのツール

Broadcom デポトークン

フェーズ 3 では Broadcom デポから VCF コンポーネントのバイナリをダウンロードします。Broadcom サポートポータルの「My Dashboard」→「Quick Links」→「Generate Download Token」からダウンロードトークンを生成してください。このトークンはフェーズ 3 の実行前に VCF_DEPOT_TOKEN 環境変数として設定します。

VCF Installer OVA

Broadcom ダウンロードポータルから VCF 9.1 Installer OVA をダウンロードしてください。このアプライアンスはフェーズ 2 と 3 の間に、いずれかの ESXi ホスト上へ手動でデプロイします。

リポジトリのクローン

自動化リポジトリをクローンしてローカルワークステーションに配置してください（このコマンドは Linux と Windows の両方で使用できます）。

git clone https://github.com/aws/solutions-for-amazon-evs.git

cd solutions-for-amazon-evs/Deploy/VCF9-Phased-Deployment 

フェーズ 0：デプロイ前の入念な計画

自動化を実行する前に、設定ファイルを慎重に計画して入力する必要があります。このステップは非常に重要です。インフラストラクチャをデプロイした後は、環境全体を解体して再構築しなければ変更できない値が多数あるため、時間をかけて正確に設定してください。

自動化では、最初に 1 度だけ入力する 2 つの設定ファイルを使用します。その後のフェーズはこれらのファイルから値を読み取り、次のフェーズへ自動的に引き継ぎます。

terraform.tfvars（フェーズ 1 の入力）

このファイルは AWS インフラストラクチャの基盤を定義します。terraform.tfvars.example を terraform.tfvars にコピーして以下を設定してください（Linux）。

cd Phase_1_Base_Infrastructure

cp terraform.tfvars.example terraform.tfvars 

Windows の場合：

cd Phase_1_Base_Infrastructure

copy terraform.tfvars.example terraform.tfvars 

以下の値を実際の環境に合わせて更新してください。

  • region：デプロイ先の AWS リージョン（例：us-east-2）。Amazon EVS が利用可能なリージョンを指定してください。
  • availability_zone：リージョン内の特定の AZ（例：us-east-2a）。すべてのリソースは単一の AZ にデプロイされます。EC2 キャパシティ予約がある場合は、予約済みの AZ と一致させてください。
  • fqdn：環境の完全修飾ドメイン名（例：mylab.evs.aws）。Route 53 フォワードホストゾーンとなり、すべての DNS レコードに使用されます。慎重に選択してください。
  • cidr_prefix：VPC CIDR の最初の 2 オクテット（例：”10.0.”）。自動化はこのプレフィックスからすべての VLAN サブネット CIDR を導出します。Transit Gateway または Direct Connect で接続する予定のネットワークと重複しないようにしてください。
  • DNS ホスト名：各 VCF アプライアンスと ESXi ホストの短い DNS 名（esxi01_name から vcf_fleet_name まで）。
  • create_tgw：他の VPC やオンプレミスネットワークへの Transit Gateway 接続が必要な場合は true に設定してください。
  • create_jumpbox：Windows ジャンプホストを作成する場合は true に設定してください。VPC 内から実行する必要があるフェーズ 3 に必須です。このフラグを有効にすることをお勧めします。
  • enable_public_hcx：HCX インターネット接続用のパブリック IP スペースを割り当てる場合は true に設定してください。false の場合、HCX はプライベート VLAN を使用します（Direct Connect または Transit Gateway 経由の HCX に適しています）。

VPC CIDR の分割方法

cidr_prefix で最初の 2 オクテットのみ指定します（例：”10.0.”）。自動化は /16 の VPC を作成し、ハードコードされた第 3 オクテットを使って /24 の VLAN サブネットに分割します。

  • <prefix>0.0/24 — サービスアクセスサブネット
  • <prefix>10.0/24 — ホスト vmkernel 管理（vmkManagement）
  • <prefix>20.0/24 — vMotion
  • <prefix>30.0/24 — vSAN
  • <prefix>40.0/24 — Host TEP (vTep)
  • <prefix>50.0/24 — Edge TEP (edgeVTep)
  • <prefix>60.0/24 — VM 管理（vmManagement）
  • <prefix>70.0/24 — HCX
  • <prefix>80.0/24 — NSX アップリンク（nsxUplink）
  • <prefix>90.0/24 — 拡張 VLAN 1
  • <prefix>100.0/24 — 拡張 VLAN 2

config.json でこれらの VLAN サブネット CIDR を変更する場合は、NSX Edge IP、Route 53 インバウンドリゾルバーエンドポイント（<prefix>0.100 および <prefix>0.101）、BGP アップリンクアドレスなど、サブネット内に設定されるハードコードされた IP アドレスと競合しないよう注意してください。

config.json（フェーズ 2 の入力）

このファイルは EVS 環境と VCF デプロイパラメーターを定義します。config.example.json を config.json にコピーして以下を設定してください（Linux）。

cd Phase_2_evs_env/python
cp config.example.json config.json

Windows の場合：

cd Phase_2_evs_env/python
copy config.example.json config.json 

以下の値を実際の環境に合わせて更新してください。

  • environmentName：EVS 環境のわかりやすい名前。AWS コンソールに表示され、リソースのタグ付けに使用されます。
  • vcfInstallerProductVersion：VCF Installer の製品バージョン番号のみ（ビルド文字列は含めない）。例：”9.1.0.0″。正確な値は OVA ファイル名またはインストーラー UI の設定ページで確認してください。
  • simpleDeployment：単一ラック・シンプルデプロイ（最小 3 ホスト）の場合は true、単一ラック・HA デプロイ（最小 4 ホスト）の場合は false を設定してください。この設定は、デプロイされる NSX Manager と VCF Operations ノードの数に影響します。詳細は Single-Rack vSphere クラスターモデルのドキュメントを参照してください。
  • vcfSizing：vCenter（vmSize、storageSize）、NSX（nsxSize）、VCF Operations（operationsApplianceSize、operationsCollectorApplianceSize）のアプライアンスサイジング。ほとんどのデプロイでは “medium” のデフォルト値が適切です。

ヒント：FQDN、CIDR プレフィックス、ホスト名の選択は事前に十分確認してください。フェーズ 1 のデプロイ後にも検証することをお勧めします。フェーズ 1 の削除と再デプロイは数分で完了するため、この時点であれば変更は容易です。フェーズ 2 で FQDN や CIDR などの値を組み込んだ EVS 環境がデプロイされると、変更には最初から再構築が必要になります。

フェーズ 1：基盤 AWS インフラストラクチャ（Terraform）

フェーズ 1 で作成されるもの

フェーズ 1 は、EVS が必要とする AWS ネットワークおよびサポートリソースをすべてプロビジョニングします。terraform apply が完了すると（通常 3〜5 分）、以下が構成されます。

  • VCF アプライアンスと ESXi ホスト用の Route 53 プライベートホストゾーン
    • フォワードホストゾーン（A レコード）
    • リバースホストゾーン（PTR レコード）
    • 2 つの IP を持つインバウンドリゾルバーエンドポイント
  • Amazon VPC
    • 専用サービスアクセスルートテーブルに関連付けられたプライベートサービスアクセスサブネット
    • 専用パブリックアクセスルートテーブルに関連付けられたパブリックアクセスサブネット
    • Elastic IP を持つ NAT Gateway
    • Internet Gateway
    • FQDN、Route 53 インバウンドリゾルバー IP、NTP（169.254.169.123：AWS NTP サーバー）を設定した DHCP オプションセット
    • VPC CIDR からの受信を許可する専用 EVS サービスアクセスセキュリティグループ
  • VPC Route Server
    • VPC に関連付け済み
    • それぞれピア IP、ピア ASN（65000）、BGP キープアライブを設定した 2 つの Route Server エンドポイント
    • サービスアクセスルートテーブルとパブリックアクセスルートテーブルへの 2 つの Route Server 伝播
  • EVS ホスト用の EC2 キーペア
  • （オプション）アンダーレイ VPC への VPC アタッチメントを持つ Transit Gateway
  • （オプション）VPC 内の Windows ジャンプホスト
    • ジャンプホスト用の VPC パブリックサブネット
    • Internet Gateway へのルートを持つジャンプホスト用専用ルートテーブル
    • 専用ルートテーブルへの Route Server 伝播
    • VPC CIDR と EVS サービスアクセスセキュリティグループからのすべてのトラフィックを許可するジャンプホスト用専用セキュリティグループ
    • 50 GB 暗号化 gp3 ルートボリュームとパブリック IPv4 アドレスを持つ、Windows Server 2025 を実行する t3.2xlarge EC2 インスタンス
    • ジャンプホスト用専用 EC2 キーペア
      • 注：このキーペアは “Jumpbox-KeyPair” という名前です。同名のキーペアが既に存在する場合、このコードは失敗します。その場合はコード内でキーペア名を変更してください。
  • （オプション）パブリック HCX 接続
    • IPv4 IPAM プール
    • 連続したパブリック IP スペースの /28
    • VPC CIDR へのパブリック /28 の追加

デプロイの実行（Linux）：

export AWS_PROFILE=your-profile-name 
 
terraform init 
terraform plan 
terraform apply 

Windows の場合：

$env:AWS_PROFILE = "your-profile-name" 

terraform init
terraform plan
terraform apply

Terraform は VPC ID、サブネット ID、Route Server エンドポイント IP、セキュリティグループ ID などの値を出力します。フェーズ 2 はこれらを terraform.tfstate ファイルから直接読み取ります。フェーズ 1 のデプロイはおよそ 5〜10 分で完了します。

インフラストラクチャの検証

フェーズ 1 の完了後、AWS コンソールで以下を確認してください。

  • 期待される CIDR で VPC が作成されていること
  • Route 53 ホストゾーンに、すべての VCF アプライアンスと ESXi ホストの A レコードおよび PTR レコードが含まれていること
  • Route Server の 2 つのエンドポイントが “Available” 状態であること
  • ジャンプボックスを使用する場合：インスタンスが実行中でパブリック IP を持つこと

ジャンプボックスをデプロイした場合は、以下の手順で RDP アクセスを確立してください。

  • Jumpbox-SG セキュリティグループに、自分の IP アドレスからの RDP（TCP 3389）を許可するインバウンドルールを追加する
  • EC2 キーペアを取得して Windows Administrator パスワードを復号する。PEM ファイルをダウンロードする（Linux）：
KEY_PAIR_ID=$(terraform output -raw jumpbox_key_pair_id) 
aws ssm get-parameter --name /ec2/keypair/$KEY_PAIR_ID --with-decryption \ 
  --region us-east-2 --query 'Parameter.Value' --output text > jumpbox.pem 
chmod 400 jumpbox.pem
  • Windows の場合：
$KEY_PAIR_ID = terraform output -raw jumpbox_key_pair_id
aws ssm get-parameter --name "/ec2/keypair/$KEY_PAIR_ID" --with-decryption ` --region us-east-2 --query 'Parameter.Value' --output text | Out-File -Encoding ascii jumpbox.pem
icacls jumpbox.pem /inheritance:r /grant:r "$($env:USERNAME):(R)"

この PEM ファイルを EC2 コンソール（Connect > Get Windows Password）で使用して Administrator パスワードを復号してください。

最後に、VCF Installer OVA をジャンプホストにダウンロードまたはコピーしてください。フェーズ 2 と 3 の間の手動作業ステップで必要になります。

フェーズ 2：EVS 環境のデプロイ（Python）

フェーズ 2 の処理内容

フェーズ 2 は Python CLI で、AWS API 経由で EVS デプロイを調整し、SDDC bringup 仕様と NSX デプロイ仕様を構築します。単一の CLI コマンドで、以下の 6 つのサブステップを順番に実行します。

  1. pre-evs-sync-config：フェーズ 1 の Terraform ステートを読み取り、VCF bringup 仕様とエッジクラスター仕様の初期版を生成
  2. create-environment-and-hosts：AWS API を呼び出して EVS 環境を作成し、完了後にベアメタルホストをプロビジョニング（15〜20 分）
  3. すべてのホストが CREATED ステータスになるまで待機（20〜40 分）
  4. post-evs-sync-config：環境とホスト ID から派生した名前で SDDC 仕様を確定し、対応する VCF パスワードを Secrets Manager にプロビジョニング
  5. associate-vlan-subnets：10 個の EVS VLAN サブネットをすべてサービスアクセスルートテーブルに関連付け
  6. create-and-attach-ebs：256 GB の gp3 EBS ボリュームを作成し、VCF Installer VMFS 用として 1 台のホストにアタッチ

deploy-environment の実行

Python 環境をセットアップし、単一コマンドでフェーズ 2 のパイプライン全体を実行します（Linux）。

python -m venv .venv 
source .venv/bin/activate 
pip install -r requirements.txt 

python -m src.main deploy-environment \ 
  --profile your-aws-profile \ 
  --config config.json \ 
  --tfstate ../../Phase_1_Base_Infrastructure/terraform.tfstate \ 
  --instance-type <INSTANCE_TYPE>  # 'i4i.metal' or 'i7i.metal-24xl'

Windows の場合：

py -m venv .venv 
.venv\Scripts\Activate.ps1 
pip install -r requirements.txt  

python -m src.main deploy-environment ` 
--profile your-aws-profile ` 
--config config.json ` 
--tfstate ..\..\Phase_1_Base_Infrastructure\terraform.tfstate ` 
--instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl'

このコマンドは 6 つのサブステップを自動的に連結して実行します。合計所要時間はおよそ 30〜45 分で、大部分はベアメタルホストがプロビジョニングされて CREATED ステータスになるまでの待機時間が占めます。デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを強く推奨します。

Secrets Manager によるパスワード管理

フェーズ 2 の構築中、post-evs-sync-config サブステップがすべての VCF アプライアンス用の複雑なパスワードを自動生成し、AWS Secrets Manager に保存します。命名パターンは evs-<environment-id>_<role> です。

VCF のアカウントには vcenterRoot、vcenterSso、nsxRoot、nsxAdmin、nsxAudit、sddcManagerRoot、sddcManagerSsh、sddcManagerLocal、operationsAdmin、operationsMaster、operationsCollector、edgeAppliance が含まれます。

bringup 仕様はプレースホルダートークンを通じてこれらのパスワードを参照します。フェーズ 3 は実行時に Secrets Manager からパスワードを解決するため、平文パスワードがディスクに書き込まれることはありません。

手動による事前作業：ESXi 設定とインストーラー OVA

フェーズ 2 と 3 の間に、いくつかの簡単な手順を手動で実施する必要があります。デプロイ全体を通じて唯一の非自動化部分であり、所要時間はおよそ 30 分です。以下の手順はすべて、フェーズ 2 で EBS ボリュームを受け取った 1 台の ESXi ホスト上で実施します。

EBS ボリュームへの VMFS データストアの作成

フェーズ 2 でいずれかの ESXi ホストに 256 GB の EBS ボリュームをアタッチしました。フェーズ 2 のコンソール出力で、どのホストがボリュームを受け取ったか確認できます。VCF Installer アプライアンスをホストするために、VMFS データストアとしてフォーマットする必要があります。

  1. ESXi ホスト UI（https://<esxi-host-ip>）に root としてログインします。root パスワードは AWS Secrets Manager から取得してください（シークレット名は evs-<environment-id>_<role> のパターンです）。
  2. Storage に移動し、New Datastore を選択する
  3. NVMe デバイス（256 GB EBS ボリューム）を選択して VMFS データストアを作成する

VM Network ポートグループへの VLAN タグ付け

EBS ボリュームを持つ ESXi ホストで、デフォルトの “VM Network” ポートグループに VLAN ID 20 をタグ付けし、VCF Installer が VM 管理ネットワークで通信できるようにします。

  1. ESXi UI で Networking に移動し、Port groups を選択する
  2. “VM Network” ポートグループを編集する
  3. VLAN ID を 20 に設定する

VCF Installer OVA のデプロイ

VMFS データストアを持つホスト上に VCF Installer アプライアンスをデプロイします。

  1. ESXi UI で Virtual Machines > Create/Register VM > Deploy OVF template に移動する
  2. VCF 9.1 Installer OVA ファイルをアップロードする
  3. 上記で作成した 256 GB VMFS データストアに配置する
  4. “VM Network” ポートグループにアタッチする
  5. 管理 IP を DNS 設定の SDDC Manager IP アドレスに設定する
  6. ネットマスクを 255.255.255.0 に設定する
  7. admin@local パスワードを設定する。手動で選択する唯一のパスワードです。独自のパスワードを作成するか、Secrets Manager に生成済みのパスワードを使用することもできます。フェーズ 3 で必要になるためパスワードを控えておいてください。
  8. アプライアンスの電源を入れ、起動を待つ（https://<sddcm_name>.<your-fqdn> でアクセスを確認）

フェーズ 3：VCF Bringup と NSX Edge Cluster（Python）

フェーズ 3 の処理内容

フェーズ 3 は EVS 環境をホストする VPC 内のジャンプホストから実行する必要があります。公式 VMware VCF Python SDK（vcf-installer、vcf-nsx）と vCenter 操作用 pyvmomi、および対応する AWS 操作用 boto3 ライブラリを使用します。単一の CLI コマンドで、以下の 7 つのサブステップを順番に実行します。

  1. Secrets Manager 事前確認：開始前に必要なすべての Secrets Manager シークレットが存在することを確認。不足している場合、不足している VCF アカウントを明示したエラーでパイプラインを即座に終了。
  2. prepare-depot：Broadcom ダウンロードトークンをインストーラーに設定し、デポカタログを同期して必要なすべてのコンポーネントバイナリをダウンロード（約 30〜60 分）
  3. start-bringup --wait：bringup 仕様を VCF Installer に送信し、ワークフローが完了するまでポーリング。vCenter、NSX Manager、SDDC Manager、VCF Operations をデプロイ（約 2〜4 時間）
  4. remove-installer-datastore：手動で作成した 256 GB VMFS データストア上の VM を vSAN にストレージ vMotion し、データストアをアンマウント（約 5〜10 分）
  5. destroy-ebs-volume：AWS 側からアンマウント済み VMFS データストアをホストしていた EBS ボリュームをデタッチして削除（約 30 秒）
  6. deploy-edge-cluster：2 台の NSX Edge アプライアンスをデプロイし、エッジクラスターを作成し、Tier-0/Tier-1 ルーティングを設定し、AWS Route Server との BGP ピアリングを確立（約 30〜50 分）
  7. create-connector：VCF Operations Manager コネクターを CreateEnvironmentConnector 経由で EVS に登録。ACTIVE になるまでポーリング（約 2〜5 分）

以下のサブセクションでは、フェーズ 3 の内部処理をより詳細に段階的に説明します。deploy-vcf-and-edge の実行と題したセクションに、フェーズ 3 のワークフロー全体を実行する単一コマンドが記載されています。

デポとバンドルの管理

prepare-depot サブステップは、VCF Installer UI にログインして Broadcom デポを設定する手動プロセスを自動化します。具体的には以下を実行します。

  1. VCF SDK 経由でデポトークンをインストーラーに保存
  2. メタデータ同期をトリガーしてバンドルカタログを更新
  3. ターゲットバージョンに一致するすべての INSTALL タイプバンドルを特定
  4. 必要なすべてのコンポーネントバイナリ（vCenter、NSX、SDDC Manager、VCF Operations、ESXi）をダウンロード
  5. すべてのダウンロードが完了するまでポーリングし、その後 bringup に進む

ヒント：デポの問題をデバッグする必要がある場合、list-bundles、get-depot-settings、sync-depot などの個別アクションをスタンドアロン CLI コマンドとして実行できます。

VCF bringup ワークフロー

start-bringup アクションは型付きの SddcSpec を VCF Installer に送信し、ワークフローを監視します。bringup 中にインストーラーは以下を実行します。

  1. ESXi ホストを VCF 管理ドメインにコミッション
  2. vCenter Server をデプロイして設定
  3. NSX Manager をデプロイして仮想 IP アドレスでクラスター化
  4. SDDC Manager をデプロイ
  5. VCF Operations をデプロイ
  6. すべてのホストで vSAN ESA を設定
  7. 必要なすべてのポートグループを持つ分散仮想スイッチを作成

ヒント：CLI は 10 分ごとにインストーラーをポーリングして進捗を報告します。bringup が失敗した場合は、https://<sddcm_name>.<your-fqdn> のインストーラー UI でタスクごとの詳細なエラー情報を確認してください。

インストーラーのクリーンアップ

bringup が正常に完了した後、自動化は 2 つのクリーンアップステップを実行します。

  1. remove-installer-datastore：ローカル VMFS データストアに配置された VM を vSAN にストレージ vMotion し、データストアをホストからアンマウントします。これにより EBS ボリュームが削除可能になります。
  2. destroy-ebs-volume：EC2 インスタンスから EBS ボリュームをデタッチして削除します。ボリュームは ManagedBy タグと EnvironmentId タグで識別され、他のボリュームを誤って削除しないよう保護されています。

NSX Edge Cluster のデプロイ

次のサブステップは NSX Manager と vCenter API を直接使用して NSX Edge Cluster をデプロイします。7 つのステージで実行されます。

  1. prep-edge-cluster：DVS TRUNK ポートグループ、IP プール、アップリンクプロファイル、VLAN トランスポートゾーンを作成
  2. deploy-edge-nodes：2 台のラージフォームファクター エッジトランスポートノードを作成（OVA デプロイをトリガー）
  3. create-edge-cluster：両方のトランスポートノードをグループ化するエッジクラスターを作成
  4. create-tier0：ロケールサービスと BGP を有効にした Tier-0 ゲートウェイを作成
  5. create-tier1：Tier-0 とエッジクラスターにアタッチした Tier-1 ゲートウェイを作成
  6. configure-routing：アップリンクセグメント、インターフェース、BGP ネイバー、プレフィックスリスト、スタティックルート、再配布を設定
  7. create-anti-affinity：エッジ VM 用の vCenter DRS アンチアフィニティルールを作成

各エッジアプライアンスは ASN 65000（NSX 側）と 65022（AWS 側）を使って 1 つの AWS Route Server エンドポイントと BGP ピアリングします。ピアリングが確立されると、NSX オーバーレイセグメントが VPC ルートテーブルにルートとして自動的にアドバタイズされます。

Ops Manager Connector

最後のサブステップは VCF Operations Manager コネクターを Amazon EVS に登録します。これは仮想マシンの Windows Server ライセンスエンタイトルメントの作成など、後続のアクションに使用されます。

環境変数の設定

フェーズ 3 では Secrets Manager に保存されていない 2 つのシークレットが必要です。手動手順で設定した VCF_INSTALLER_PASSWORD と、Broadcom ポータルから取得した VCF_DEPOT_TOKEN です。以下のコマンドで環境変数として設定します（Linux）。

# The admin@local password you set when deploying the installer OVA: 
read -rs VCF_INSTALLER_PASSWORD ; export VCF_INSTALLER_PASSWORD 

# Your Broadcom depot download token: 
read -rs VCF_DEPOT_TOKEN ; export VCF_DEPOT_TOKEN

Windows の場合：

# The admin@local password you set when deploying the installer OVA: 
$env:VCF_INSTALLER_PASSWORD = Read-Host -MaskInput "VCF Installer Password" 
 
# Your Broadcom depot download token: 
$env:VCF_DEPOT_TOKEN = Read-Host -MaskInput "VCF Depot Token"

他のパスワード（vCenter、NSX、SDDC Manager など）はすべて Secrets Manager から自動的に解決されます。

deploy-vcf-and-edge の実行

Python 環境を作成し、単一の CLI コマンドでフェーズ 3 のパイプライン全体をエンドツーエンドで実行します（Linux）。

cd Phase_3_VCF9/python 
python -m venv .venv 
source .venv/bin/activate 
pip install -r requirements.txt 

python -m src.main deploy-vcf-and-edge \ 
  --installer-host sddcm.<your-fqdn> \ 
  --target-version 9.1.0 \ 
  --nsx-manager-host nsx.<your-fqdn> \ 
  --vcenter-host vc.<your-fqdn> \ 
  --aws-profile your-aws-profile

Windows の場合：

cd Phase_3_VCF9\python 
python -m venv .venv 
.venv\Scripts\Activate.ps1 
pip install -r requirements.txt 

python -m src.main deploy-vcf-and-edge ` 
--installer-host sddcm.<your-fqdn> ` 
--target-version 9.1.0 ` 
--nsx-manager-host nsx.<your-fqdn> ` 
--vcenter-host vc.<your-fqdn> ` 
--aws-profile your-aws-profile

デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを強く推奨します。

検証と次のステップ

deploy-vcf-and-edge が正常に返ったら、以下でエンドツーエンドの接続性を確認してください。

Route Server BGP ピアの確認

AWS コンソールで VPC > Route Servers > Peers に移動してください。両方の BGP ピアの BGP ステータスが “Up” になっているはずです。”学習済みルート” タブには NSX から発信された CIDR が表示されます（後で作成したセグメントも自動的にここに表示されます）。

テスト用 NSX セグメントの作成

NSX Manager（https://nsx.<your-fqdn>）にログインし、Tier-1 ゲートウェイにアタッチした新しいオーバーレイセグメントを作成します。

  1. Networking > Segments > Add Segment に移動する
  2. セグメント名を test-segment とする
  3. 作成した Tier-1 ゲートウェイにセグメントをアタッチする
  4. サブネットを設定する（例：ゲートウェイ 172.16.1.1 の 172.16.1.0/24）
  5. このセグメントにテスト VM をデプロイし、IP アドレスを受け取ることを確認する

オーバーレイからアンダーレイへの接続確認

NSX セグメント上のテスト VM から以下を実行します。

  1. パブリックサブネット内のジャンプボックスに Ping する（デプロイ済みの場合）
  2. サービスアクセスサブネット内の EC2 インスタンスに Ping する
  3. セグメント CIDR（172.16.1.0/24）が VPC ルートテーブルに学習済みルートとして表示されることを確認する

3 つの確認がすべて成功すれば、NSX オーバーレイと AWS アンダーレイ間の動的なルート伝播が確立された、完全に動作する EVS 環境の構築完了です。

次のステップ：

  • VMware HCX やその他の移行ツールを使用してオンプレミスからワークロードを移行する
  • データセンターへのハイブリッド接続のために AWS Transit Gateway を設定する（フェーズ 1 でオプションとして作成しなかった場合）
  • 補足ストレージとして Amazon FSx for NetApp ONTAP をセットアップする
  • 運用監視のために AWS Systems Manager を統合する
  • SDDC Manager 経由で追加のワークロードドメインをデプロイする

トラブルシューティング

よくある障害パターンと解決策を以下にまとめます。

フェーズ 1 および 2：AWS リソースエラー

  • 対象リソースの AWS コンソールを確認してください。Terraform または boto3 のエラーテキストは通常、正しくプロビジョニングされなかった特定のリソース（AZ の誤り、サブネットの欠落、API コールのスロットリング）を指しています。
  • サービス制限を確認してください：EVS サービスクォータ、Dedicated Host の割り当て、VPC Route Server クォータ、EBS ボリューム制限。
  • ホストの実現がタイムアウトした場合（90 分超）、コンソールで EVS 環境のステータスを確認してください。FAILED 状態はキャパシティまたは設定の問題を示します。

フェーズ 3：デポの同期問題

  • Broadcom デポトークンが有効で有効期限が切れていないことを確認してください
  • インストーラーアプライアンスが depot.broadcom.com へのアウトバウンドインターネットアクセス（ポート 443）を持つことを確認してください
  • ダウンロードが止まった場合、自動化は指数バックオフで再試行し、5 回失敗後にエラーを報告します。その場合は download-all-product-binaries --wait で手動再試行できます

フェーズ 3：Bringup の失敗

  • VCF Installer UI（https://<sddcm_name>.<your-fqdn>）はタスクごとの進捗と詳細なエラーメッセージを提供しており、API エラー本文よりも参考になります。
  • スタックトレースについてはインストーラーアプライアンスの /var/log/vmware/vcf/domainmanager/domainmanager.log を確認してください。
  • bringup が “VMwareProductVersion can not be null or empty” で失敗した場合、デポに必要なバイナリがキャッシュされていません。prepare-depot を再実行して再試行してください。

フェーズ 3：Edge Cluster のデプロイ

  • vSAN データストアに十分な空き容量がない場合、エッジノードのデプロイが失敗することがあります（各エッジ VM には約 200 GB が必要）
  • BGP ピアリングの問題：エッジクラスター仕様の Route Server エンドポイント IP がフェーズ 1 の Terraform 出力と一致することを確認してください
  • configure-routing が失敗した場合、クラスターが作成される前に両方のエッジノードが Success 状態に達していることを確認してください

ヒント：自動化の各アクションはべき等です。ステップが失敗した場合は、根本的な問題を修正して同じコマンドを安全に再実行できます。副作用は発生しません。

クリーンアップ

構築した環境を解体する場合は、以下の順序で実施してください。

  1. EVS 内の仮想マシンを保持したい場合は、まず別の場所に移行してください。
  2. AWS コンソールから EVS ホストを 1 台ずつ削除してください。
  3. AWS コンソールから EVS 環境を削除してください。
  4. フェーズ 1 を実行した元のワークステーションから Phase_1_Base_Infrastructure ディレクトリに移動し、terraform destroy を実行してください。Terraform は既存の状態ファイルを使用してすべてのフェーズ 1 リソースを特定して削除します。

まとめ

本ウォークスルーでは、3 フェーズの自動化ツールキットを使って VMware Cloud Foundation 9.1 を Amazon EVS にデプロイしました。空の AWS アカウントから出発し、Terraform で前提条件となる AWS インフラストラクチャをすべてプロビジョニングし、AWS API 経由の Python CLI で EVS 環境とベアメタルホストをデプロイし、公式 VCF Python SDK を使って NSX Edge Cluster ルーティングを含む完全な VCF スタックを立ち上げました。

terraform apply から BGP ピアリングの確認まで、デプロイ全体でおよそ 3.5〜6 時間かかります。自動化により、作業は 3 つの CLI コマンドと ESXi 設定・OVA デプロイに必要な約 30 分の手作業のみに削減されます。

このアプローチの主な利点：

  • Infrastructure as Code：すべてのリソースが Terraform または Python 自動化で定義されています
  • デフォルトセキュア：すべての VCF パスワードが厳格な複雑性要件に従って生成され、AWS Secrets Manager に保存されます
  • 安全な再実行：フェーズ 1 と 3 は完全にべき等であり、デバッグや復旧のためにどのステップも副作用なく安全に再実行できます
  • SDK 駆動：フェーズ 3 は公式 VMware VCF Python SDK を使用し、手動による REST ペイロードの構築を排除します
  • モジュラー設計：1 つのコマンドでパイプライン全体を実行するか、デバッグや部分的な再実行のために個別ステップを実行できます

開発環境のセットアップ、本番環境のデプロイ、顧客デモ用の再現可能なラボなど、あらゆるユースケースに対応できる堅牢な基盤として、バージョン管理・カスタマイズ・拡張が可能です。

著者について

David Piet

David Piet

Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、VMware ベースのワークロードを持つエンタープライズのお客様が AWS へ移行し、モダナイズするための支援を担っています。2018 年にパートナーソリューションアーキテクトとして AWS に入社し、VMware Cloud on AWS を専門としてきました。以来、AWS 最大規模のエンタープライズ顧客を数多くサポートし、VMware ベースのワークロードのクラウド移行と最適化戦略を牽引してきました。長年にわたり、AWS での VMware ビジネスの成長とともに担当範囲を広げ、現在もお客様のモダナイゼーションジャーニーの支援に深く関わっています。ノースウェスタン大学で博士号を取得しており、応用数学とエンジニアリングを専門としています。AWS 入社前はシリコンバレーのストレージスタートアップでソフトウェアデベロッパーとして勤務していました。

翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文はこちらです。