NSX’s evolution across VCF 9.0 and 9.1 represents the most significant architectural rethink of the platform since the original NSX-T convergence. The throughline across both releases is a shift from a Tier-0/Tier-1-centric mental model toward a VPC-native one — networking that behaves the way a public-cloud engineer expects, while still running entirely inside a private cloud fabric.
The VPC-Native Model (Introduced in 9.0, Matured in 9.1)
VCF 9.0 introduced the modern VPC (Virtual Private Cloud) construct as a first-class NSX object, rather than something implicitly built inside a Tier-1 gateway. This was a deliberate performance and manageability decision: realizing the VPC directly, instead of nesting it inside Tier-1, improves both provisioning speed and object clarity. Alongside this, Connectivity and Service Profiles let administrators define outside connectivity and service behavior in one centralized place rather than repeating configuration per VPC.
9.0 also introduced the Transit Gateway (TGW) as a central routing hub for inter-VPC and VPC-to-external traffic, in both centralized and distributed models, plus advanced DHCP configuration options that extend well beyond the basic use cases NSX previously supported inside VPCs.
VCF 9.1: Distributed Transit Gateways and the Virtual Network Appliance
The most technically significant NSX addition in 9.1 is the combination of Distributed Transit Gateways (DTGW) with a new Virtual Network Appliance (VNA) framework.
Why this matters architecturally: in the centralized model, stateful services (firewalling, NAT, load balancing) are tied to specific Edge nodes, meaning traffic between hosts has to detour to wherever that Edge instance lives — even if both VMs are on the same hypervisor. The DTGW + VNA combination decentralizes stateful services so that, where possible, traffic stays local to the hypervisor rather than hair-pinning through a centralized Edge, while still maintaining full feature parity for stateful inspection and services. In practice this means lower latency and higher throughput for east-west traffic between VPCs or tenants on the same host, without giving up the security or NAT functionality that used to require a centralized Edge hop.
The VNA itself is a new deployable unit — administrators build a VNA Cluster (with defined sizing/form factors) under the NSX UI’s Edge / Virtual Network Appliance Cluster section and associate it with the DTGW to enable stateful service injection along the distributed data path.
VPC Grouping and Policy at Scale
9.1 extends the VPC model with programmatic grouping: New-VpcGroup and New-VpcConnectivityPolicy PowerCLI cmdlets let administrators organize VPCs into logical groups and bind strict communication policies to a Transit Gateway — for example, a “community” policy enabling standard inter-VPC connectivity within a group, or a more restrictive isolated policy for tenants that shouldn’t see each other’s traffic even though they share the same TGW. New-VpcIpBlock and the AssignExternalIp network adapter parameter round this out, letting teams define IP blocks backing subnets/edge services/external IPs, and assign external IPs directly to individual network adapters, all through automation rather than click-ops.
EVPN Interoperability with Physical Fabrics
9.1 adds EVPN-based interoperability with Arista Networks switching fabrics — meaning NSX overlay networking can now interoperate directly with an EVPN/VXLAN physical underlay without a manual translation or a separate gateway device sitting in between. For customers with existing Arista-based data center fabrics, this materially simplifies the NSX-to-physical-network integration story that historically required more manual BGP/VXLAN gateway configuration.
Upgrade Sequencing Changed
Operationally, NSX’s place in the VCF upgrade sequence changed in 9.1: NSX Manager is now upgraded first, ahead of vCenter/ESX (NSX host-level bits are bundled with the ESX upgrade itself rather than handled as a separate stage), with NSX Edge clusters upgraded last. This is a reversal from pre-9.x sequencing patterns and is worth explicitly calling out in any runbook inherited from an older VCF version — automated sequencing in the VCF Operations upgrade workflow handles this correctly, but any manually-documented change-management procedure needs to be updated to match.
Security-Adjacent Capability: vDefend Integration
While vDefend itself is a separate product line (see our dedicated Frontier AI / vDefend post), it’s worth noting explicitly that vDefend’s Distributed Firewall and IDPS capabilities are built directly on top of the NSX data plane — meaning the throughput numbers discussed there (up to 75 Tbps aggregate Distributed Firewall throughput per VCF instance) are, in effect, evidence of how far the underlying NSX 9.x data plane has scaled. NSX 9.x isn’t just a networking release; it’s the substrate that makes the lateral-security story in 9.1 credible at real enterprise scale.
What to Watch Going Forward
The direction of travel across 9.0 and 9.1 is unambiguous: NSX is moving away from an appliance-and-gateway mental model toward a fully programmable, VPC-native, API-first fabric — consistent with the platform-wide API-first direction covered in our VCF 9.1 features post. For network architects planning a design today, the practical guidance is to default new deployments to the VPC/DTGW model rather than legacy VLAN-backed or Tier-0/Tier-1-centric designs wherever the workload profile allows it, since that’s clearly where ongoing feature investment — DTGW, VNA, EVPN interop, programmatic policy — is concentrated.
