4.5 VCF 9.0 Virtual Private Clouds (VPCs) & Transit Gateway Connectivity
Key Takeaways
- VCF 9.0 introduces a networking consumption model built on Virtual Private Clouds and Transit Gateways that is natively multi-tenant and consumable from NSX, vCenter, VCF Automation, and VCF Operations.
- A VPC belongs to an NSX Project, which is the tenant grouping construct that carries delegated administration and quotas.
- VPC subnets use three access modes: Public, which is externally advertised without NAT; Private-VPC, which is isolated to the VPC; and Private-Transit Gateway, which is reachable across VPCs attached to the same Transit Gateway.
- A Centralized Transit Gateway routes through an NSX Edge cluster and Tier-0 gateway, while a Distributed Transit Gateway uses distributed hypervisor routing and requires no Edge nodes.
- External IP Blocks supply the externally routable addresses used by Public subnets and NAT services such as SNAT for outbound access and 1:1 NAT for inbound reachability.
4.5 VCF 9.0 Virtual Private Clouds (VPCs) & Transit Gateway Connectivity
Exam Focus: This is the single largest networking change between VCF 5.x and VCF 9.0. Earlier sections in this chapter covered the NSX building blocks — transport nodes, Tier-0 and Tier-1 gateways, Geneve, and distributed services. VCF 9.0 layers a consumption model on top of those primitives so that application teams request networks without touching them. Community material written for VCF 5.x does not cover this, and the 2V0-17.25 exam is scoped to 9.0.
What Changed: From Building Blocks to a Consumption Model
In VCF 5.x, giving an application team a network meant a network administrator creating segments, attaching Tier-1 gateways, and configuring routing and firewall rules by hand. The primitives were powerful but the consumption experience was a ticket queue.
VCF 9.0 provides a consistent networking consumption model based on Virtual Private Clouds (VPCs) and Transit Gateways (TGW). Two properties define it:
- It is natively multi-tenant, so isolation is structural rather than something an administrator remembers to configure.
- It is consumable not only from NSX, but also from vCenter, from VCF Automation, and monitored from VCF Operations — the same object appears wherever the relevant persona works.
The VPC: An Isolated Network Environment
A VPC is a secure, isolated multi-tenant network environment hosted inside the broader VCF private cloud. It lets a team define its own IP addressing, routing, and security policy without coordinating with anyone else's addressing.
A VPC belongs to an NSX Project. The Project is the tenant grouping construct — it carries delegated administrative rights and quotas, so a Project Admin manages VPCs and resources within the boundary an enterprise administrator set. Inside a VPC, a VPC Admin configures networking within that governance envelope.
Subnet Access Modes
VPCs contain subnets to which VM network adapters attach with no physical network configuration. The access mode chosen at subnet creation determines reachability, and this is prime exam material:
| Access mode | Reachability | NAT required? |
|---|---|---|
| Public | Advertised externally, directly reachable | No — addresses come from an External IP Block |
| Private-VPC | Isolated within the owning VPC | Yes, via External IP for anything outside the VPC |
| Private-Transit Gateway | Routable to other VPCs attached to the same Transit Gateway | No, for traffic that stays within the TGW domain |
Subnet size sets the total address count, and some addresses in every subnet are reserved for network operations rather than being available to workloads.
The Transit Gateway: New in VCF 9.0
The Transit Gateway is a construct introduced in VCF 9.0. It performs two jobs:
- Interconnects multiple VPCs, so shared services can be reached without full-mesh peering between every pair.
- Aggregates north-south traffic heading to networks outside the private cloud.
Two connectivity architectures exist, and choosing between them is a design decision with real consequences:
| Centralized Transit Gateway (CTGW) | Distributed Transit Gateway (DTGW) | |
|---|---|---|
| Path | Through an NSX Edge cluster, via a Tier-0 gateway | Distributed across vSphere hypervisor routing |
| Edge nodes | Required | Not required — an "edgeless" design |
| Strength | Centralised stateful services and advanced routing at a controlled peering point | Fewer hops, higher throughput, lower latency; physical and virtual topologies align, which simplifies troubleshooting |
| Typical use | Environments needing centralised NAT, gateway firewalling, and BGP peering control | VLAN-backed fabrics where hosts connect directly and edge deployment is unwarranted |
[!IMPORTANT] The edgeless option is the headline. In VCF 5.x, external connectivity effectively required deploying Edge nodes and configuring routing. The Distributed Transit Gateway removes that requirement for suitable topologies, and it is fully compatible with existing vSphere VDS VLAN-based networking. If a scenario stresses "no Edge nodes to deploy" or "reduce the number of hops", it is pointing at the distributed model.
External Connectivity, IP Blocks, and NAT
Enterprise administrators define External IP Blocks — ranges of externally routable addresses. These supply:
- The addresses assigned to VMs on Public subnets.
- The addresses consumed by NAT services.
Two NAT patterns cover most requirements:
- Source NAT (SNAT) gives workloads on private subnets outbound access while hiding their internal addresses.
- 1:1 NAT maps an external address to a specific workload so external systems can reach it inbound.
Alongside external blocks, IP address management tracks private-VPC and private-TGW blocks, with quota enforcement so one tenant cannot exhaust the pool.
Services Available Inside a VPC
A VPC is not merely address space. Core services are available on demand:
- On-demand segment creation, DHCP, distributed and static routing, NAT, and a Gateway Firewall.
Advanced services can be layered on:
- vDefend Distributed Firewall for micro-segmentation and enhanced threat prevention.
- NSX Advanced Load Balancer (Avi) for application delivery.
Who Consumes a VPC
The same object serves several personas, which is what makes the model coherent:
| Persona | Interface | Typical action |
|---|---|---|
| VI administrator | vCenter | Attach a VM to a VPC subnet |
| Network / security administrator | NSX UI | Configure gateways, routing, firewall policy, advanced services |
| Application team | VCF Automation self-service catalog | Consume networking as part of a deployment |
| DevOps engineer | REST API / IaC tooling | Declare networking as code |
Exam Watch: Key Scenarios and Candidate Traps
[!WARNING] Public subnet does not mean internet-facing by default. It means the addresses come from an External IP Block and are advertised without NAT. Whether they are reachable from the internet depends on the physical network and firewall policy beyond the VPC.
[!TIP] Read the requirement for the Edge signal. "Must not deploy Edge nodes", "minimise hops", or "align physical and virtual topology" all point to a Distributed Transit Gateway. "Centralised stateful services" or "controlled BGP peering point" point to a Centralized one.
A design requires connectivity between workloads and the physical network with the fewest possible hops, no deployment of NSX Edge nodes, and compatibility with the existing vSphere VDS VLAN-based fabric. Which VCF 9.0 construct satisfies these requirements?
An application team requests a subnet inside their VPC whose workloads must be directly reachable from outside the VPC without address translation. Which subnet access mode should be selected?
Within the VCF 9.0 networking model, what is the relationship between a VPC and an NSX Project?
An enterprise administrator must supply the externally routable addresses that VPC Public subnets and 1:1 NAT rules will consume. Which construct do they define?