Amazon EVS VCF 9.1 Automation Architecture Diagram: Underlay to NSX BGP

The July 6, 2026 how-to Deploying VCF 9.1 on Amazon EVS with End-to-End Automation, by David Piet, covers an AWS toolkit. EVS runs VMware Cloud Foundation on bare-metal EC2 in your VPC. For VCF 9 the post says Self Deployed Mode: EVS creates VLAN subnets and ESXi hosts and does not install VCF. The three phases finish the install and NSX routing.

What this Amazon EVS VCF automation architecture diagram shows

Three bands. Phase 1 is Terraform: VPC subnets, Route 53 forward and reverse zones, a Route Server with two BGP endpoints, security groups, and optional Transit Gateway, Jumpbox, and HCX. Phase 2 is Python and boto3: the EVS environment, ten VLAN subnets, three bare-metal hosts, and a 256 GB gp3 volume that stages the installer. Phase 3 runs on a jumpbox in the VPC, using the VCF Python SDK and boto3, from depot sync through bring-up, volume cleanup, two NSX edges, and an Ops Manager Connector. A manual gap sits between phase 2 and phase 3.

The problem this architecture is solving

Under VCF 5.2, the post says EVS deployed VLANs, hosts, and the full stack. For VCF 9 that stop is intentional: EVS does not install VCF. The toolkit’s claim is three CLI commands, passwords in AWS Secrets Manager, and no retyping of phase 1 outputs. The walkthrough is VCF 9.1, though the repo also supports 9.0. The built list is a VPC, three ESXi 9.1 hosts, vCenter, SDDC Manager, NSX Manager, VCF Operations, a Cloud Proxy, two edges, tier-0 and tier-1, and the connector.

Main components and trust boundaries

A two-octet cidr_prefix becomes a /16 cut into /24s on hardcoded third octets: service access, management, vMotion, vSAN, host TEP, edge TEP, VM management, HCX, NSX uplink, and two expansion VLANs. Editing those CIDRs in config.json can collide with later hardcoded IPs, including resolver and BGP addresses. Phase 1 sets the Route Server peer ASN to 65000. The edge section then says ASN 65000 on the NSX side and 65022 on the AWS side. Keep both labels.

Hosts are i4i.metal or i7i.metal-24xl, selected by flag, on ESXi 9.1. The post does not require i7i. simpleDeployment true means a three-host minimum; false means four hosts for single-rack HA and changes the NSX Manager and VCF Operations count. The picture is the three-host case, all in one Availability Zone. Quotas named: at least 3 hosts per environment, and On-Demand Standard vCPU quota of at least 256. Phase 3 needs a Broadcom depot token and the Installer OVA, placed by hand on a VMFS datastore on the EBS volume, on port group VLAN 20, using the SDDC Manager DNS address as its IP.

Phase 2 generates VCF passwords into Secrets Manager. The spec holds placeholders until phase 3. The installer admin@local password and the depot token are environment variables, not those secrets. The edge path builds a trunk port group, IP pool, uplink profile, VLAN transport zone, two large edges, a cluster, tier-0 with BGP, tier-1, neighbors, and a DRS anti-affinity rule. Overlay routes land in the VPC route tables. The connector registers VCF Operations with EVS for later steps.

Request or data path, step by step

Phase 2 reads Terraform state directly. The post times terraform apply as typically 3–5 minutes in one section and about 5–10 minutes in another. Do not average them. deploy-environment syncs config, creates the environment and hosts, waits for CREATED, writes the spec and secrets, associates the ten VLANs, and attaches the EBS volume. Separate estimates on the same page: host provisioning about 15–20 minutes, the CREATED wait about 20–40 minutes, and the phase about 30–45 minutes. They overlap. Print them separately.

Formatting VMFS, tagging VLAN 20, and deploying the OVA are the only manual stretch, about 30 minutes in the post. deploy-vcf-and-edge then checks secrets, downloads binaries (about 30–60 minutes), runs bring-up (about 2–4 hours: hosts, vCenter, NSX managers behind a VIP, SDDC Manager, VCF Operations, vSAN ESA, and the distributed switch), moves the installer disk to vSAN, deletes the EBS volume, deploys edges (about 30–50 minutes), and creates the connector (about 2–5 minutes). End-to-end is about 3.5 to 6 hours, mostly bring-up. Checks: both BGP peers Up, a test overlay segment, and that CIDR as a learned route. 172.16.1.0/24 is only the post’s example.

The diagram: labeled boxes

Keep the manual OVA between phase 2 and phase 3. The drawn path ends at BGP from the NSX edges to the VPC Route Server. There is no route-tables box after that.

• Service stop: EVS does not install VCF 9. Skipping the installer is the old VCF 5.2 path.
• One AZ: hosts and VLANs share the zone you set.
• Staging disk: after bring-up the 256 GB volume is unmounted and deleted. It is not production storage.
• BGP: peers should be Up before the overlay counts as reachable. The post says each edge VM needs about 200 GB of free vSAN.
• Idempotency: the conclusion limits that claim to phases 1 and 3. Troubleshooting says every action is idempotent. The conclusion is narrower.

What the source does not claim (preview, case study, or limits)

This July 6, 2026 how-to is not a preview or a case study. It warns of significant monthly cost for bare metal, the EVS control plane, Route Server, and optional Transit Gateway, NAT, EBS, and Route 53, and it points at the pricing page and the AWS Pricing Calculator. No dollar figure is printed. These phases do not use CloudFormation. Phase 1 is Terraform. Phases 2 and 3 are Python. Host type is a flag, not always i7i. Tear-down is deleting hosts and the environment, then terraform destroy. HCX, FSx for ONTAP, Systems Manager, and extra workload domains are a next-steps list, not steps in the three commands.

How this differs from a nearby pattern on ByteDiagram

The Oracle on EVS diagram is the workload layout: Oracle, FSx for ONTAP, and SnapMirror. This diagram stops at bring-up: underlay, hosts, the installer, and NSX BGP. The July 2026 post mentions FSx only as a later step. SnapMirror is not on this diagram.

FAQ

Does Amazon EVS install VCF 9.1 for you, according to this post?

No. VCF 9 on EVS is Self Deployed Mode. EVS creates VLAN subnets and bare-metal ESXi hosts (9.0 or 9.1) and does not install VCF. Phase 3 plus a manual installer OVA does. The post says VCF 5.2 was when the service deployed the full stack.

Which host types and how many hosts does the walkthrough use?

The example is three ESXi 9.1 hosts in one Availability Zone. The flag accepts i4i.metal or i7i.metal-24xl. simpleDeployment true is a three-host minimum; false is four hosts for HA.

How do NSX overlay routes reach the VPC route tables?

Two NSX edges, active/standby, each peer with one Route Server endpoint. The post states ASN 65000 on the NSX side and 65022 on the AWS side, after phase 1 set the peer ASN to 65000. Learned routes should appear when BGP is Up. Two sections also disagree on how long terraform apply takes.

Conclusion

Show the Terraform VPC and Route Server, EVS VLANs and three ESXi 9.1 hosts, the manual OVA, then NSX edges peering BGP. Keep the post’s paired timings, and do not add CloudFormation. The only source is Deploying VCF 9.1 on Amazon EVS. More diagrams are on the ByteDiagram blog.