If you’ve worked with NSX for a few years, you know the drill. A team needs a new network, so someone raises a ticket, the network team creates a segment, attaches it to a Tier-1, sorts out routing on the Tier-0 and updates the firewall. It works, but it’s slow, and it doesn’t feel like a cloud.
VMware Cloud Foundation 9 changes this with Virtual Private Clouds (VPCs) and Transit Gateways. These are now the default way to consume networking in VCF, and they’re available directly from the vCenter UI. VCF 9.1 and 9.1.1 then filled most of the gaps from the first release. In this post, I will explain the building blocks, the two connectivity models and what changed in 9.1.
The Building Blocks
If you know AWS VPCs, most of this will feel familiar. Under the hood it’s still NSX; VPCs are a simpler consumption layer on top of Tier-0 and Tier-1 gateways.
- Project – the tenant boundary. Each project has its own Transit Gateway, VPCs, and network and security configuration. The default project covers most enterprises; user-defined projects give true multi-tenancy.
- VPC – a group of subnets owned by an application team. Each VPC has its own VPC gateway, which runs distributed on every ESX host. Creating new subnets doesn’t touch the physical fabric.
- Transit Gateway (TGW) – connects all the VPCs in a project and provides the path to the outside world. One TGW per project keeps tenants isolated from each other.
- External Connection – defined by the provider/infra admin. It’s the abstracted path from the TGW to the physical network: centralized (via Edges) or distributed (via VLAN).
- IP Blocks and VPC Connectivity Profile – the provider defines the IP pools (external and private-TGW) and the default outbound NAT behaviour, and VPCs consume them.
Three Subnet Types
| Subnet type | Reachable from | Typical use |
|---|---|---|
| Private – VPC | Only inside the VPC (outbound via NAT) | Databases, app tiers that should stay isolated |
| Private – Transit Gateway | Other VPCs in the same project | Shared services between VPCs of one tenant |
| Public | Routed to the external network | Front-ends, anything that needs to be reached from the datacenter |
Centralized vs Distributed Transit Gateway
This is the most important design decision. It’s about how the Transit Gateway reaches the physical network.
Centralized Transit Gateway (CTGW)
The TGW runs on NSX Edge VMs alongside a Tier-0 gateway, and all north-south traffic passes through those Edges. VCF 9 includes a guided wizard that deploys the Edges and builds the Tier-0 for you. This is the full-featured model: NAT (SNAT/DNAT, 1:1 external IPs), DHCP, north-south gateway firewall, BGP to the fabric, and the L4 load balancer for Supervisor/VKS. In VCF 9.0, the Supervisor and VCF Automation All Apps required the Centralized Active/Standby model.
Distributed Transit Gateway (DTGW)
No Edge VMs and no Tier-0. The TGW maps directly onto a VLAN shared by all ESX hosts and routing happens on each hypervisor. When the physical router ARPs for a VM’s public IP, the DTGW on the host running that VM answers with the VM’s MAC. One thing to note: the default gateway for public subnets sits on your physical router, not on an NSX gateway.
That last point is a big win for brownfield environments. If you’re running classic VLAN-backed port groups today with gateways on the core switches, you can move to VPCs without redesigning your network. In VCF 9.0, the downside was that DTGW had no stateful services: no NAT and no load balancer. That’s what 9.1 fixes.
What’s New in VCF 9.1
- Virtual Network Appliance (VNA) for DTGW – stateful services such as NAT and an L4 load balancer are now available with the distributed model. The VNA is based on NSX Edge technology but works as a “bump in the wire”: normal routing stays distributed on the hosts, and only traffic that needs a stateful service is redirected to the VNA. It does not provide a north-south gateway firewall, though.
- Bigger, more flexible IP blocks – a single IP block can now hold up to 10 CIDRs or IP ranges, so you can grow a pool without changing anything for consumers.
- VPC scope – pin a VPC to specific clusters, or let it span all vCenters in the networking domain.
- Connectivity Policy – simpler control over which VPCs can talk to each other, without writing firewall rules for every case.
- Centralized model gets faster – Active-Active Tier-0 with up to eight Edge nodes for more north-south throughput.
- EVPN-VXLAN – native integration with physical fabrics (Arista, Cisco Nexus, SONiC and others), extended further in 9.1.1 with an optimized east-west datapath between transit gateways and the fabric.
- PowerCLI – the VPC module adds cmdlets such as
New-VpcTransitGatewayandNew-VpcSpan, so the whole thing can be automated.
VCF 9.1.1: VLAN-backed VPCs without TEPs
In 9.1.0, a DTGW-based VPC still needed NSX Tunnel Endpoints (TEPs) on every ESX host, which means an overlay network and a larger MTU end to end. VCF 9.1.1 adds a VLAN-backed VPC option that removes the TEP requirement completely. It still uses the DTGW and VNA, and it works with vSphere Supervisor/VKS and VCF Automation.
The trade-offs: no VPC Private subnets, no SNAT/DNAT/VPN services, and no non-IP protocols such as VRRP or multicast. For many enterprise teams that just want self-service networking and Kubernetes without touching the underlay, that’s an acceptable deal.
Which One Should You Use?
| Requirement | Centralized TGW | Distributed TGW (+VNA) | VLAN-backed VPC (9.1.1) |
|---|---|---|---|
| NSX Edge VMs / Tier-0 | Required | Not required | Not required |
| Overlay / TEPs | Yes | Yes | No |
| NAT | Yes | Yes (via VNA) | No |
| North-south gateway firewall | Yes | No | No |
| Default gateway for public subnets | NSX | Physical router | Physical router |
| Best fit | Service providers, strict multi-tenancy, full services | Enterprises wanting simplicity with some stateful services | Fastest path from VLAN port groups to VPC/VKS |
Design Tips from the Field
- Plan IP blocks before anything else. External IP blocks are routable in your datacenter; private-TGW blocks can be RFC 1918. Changing them later is painful, even with multi-CIDR blocks.
- Map projects to real tenants. In a multi-tenant or sovereign cloud, one project per tenant (or per government entity) gives clean isolation with its own TGW. Don’t create projects per application.
- Need a north-south firewall at the tenant edge? Go centralized. The VNA doesn’t provide it.
- Coming from VLAN port groups? Distributed or VLAN-backed VPCs let you keep gateways on the physical network and migrate without re-IPing or redesigning the fabric.
- Check the service matrix before committing. Supervisor, VKS, VCF Automation and Avi all have specific requirements per connectivity model and version, so validate against the 9.1.x documentation for your exact build.
Wrapping Up
VPCs are probably the biggest change in how we consume NSX since NSX-T replaced NSX-V. VCF 9.0 introduced the model, and 9.1 and 9.1.1 made it practical for real environments: stateful services without Edges, flexible IP management, EVPN integration, and a TEP-less option for teams that want to keep their network simple. If you’re planning a VCF 9 deployment, decide on your Transit Gateway model early, because it shapes everything else.
I hope this is informative for you. Thanks for reading! Be social and share it on social media if you feel worth sharing it.
References
- VPC Distributed Network Connectivity – No NSX Edge VMs – VMware Blog
- VPC Centralized Network Connectivity – With Guided Edge Deployment – VMware Blog
- Simplify Workload Connectivity and Enhance Network Scale with VCF 9.1 – VMware Blog
- VCF 9.1.1 – VKS using VLAN-backed VPCs without NSX TEPs – William Lam
- VCF 9 – NSX VPC Part 1 & 2 – evoila