Dr. Pranay Jha

A platform owner asked me last year to “give each business unit its own NSX.” Eight business units, one VCF instance, and a hard rule that the storage team must never see the trading team’s firewall rules. The instinct in the room was to build eight NSX Managers. That would have been a budget fire and an operational nightmare. NSX 9 already solves this with multi-tenancy built into the Policy data model, but only if you pick the right layer for each tenant. Get that choice wrong and you either strangle a developer team with infra-grade controls or hand an infra team a consumption model that cannot do what they need.

Two layers of tenancy, and why the distinction matters

NSX 9 isolates tenants inside a single deployment through the Policy hierarchy, not through separate appliances. There are two nested constructs. Projects came first (API-only in NSX 4.0.1, full UI in 4.1), and VPCs landed in 4.1.1 and have matured into a first-class capability in VCF 9. By NSX 9 this is not an edge feature you bolt on. It is how the data model is shaped.

What a Project actually is

A Project is a tenant that wants to do networking. Inside a Project, a Project Admin can create Tier-1 gateways, segments, groups, DFW and gateway firewall policies, DHCP, and VPN on the project Tier-1s. The objects live under /orgs/default/projects/<project-id>/infra and are invisible to other projects. This is the right fit when the tenant is itself a technical team that understands routing and wants to define its own topology. Think of an internal platform team, a managed-service customer, or a security zone with its own admins.

What a VPC actually is

A VPC is a self-contained private network inside a Project, built for people who do not want to think about NSX at all. Subnets, basic services, and a Transit Gateway uplink, consumed the way you would consume a VPC in AWS. The application owner asks for a subnet and gets one. They never touch a Tier-1, a BGP neighbor, or a transport zone. VPCs live under /orgs/default/projects/<project-id>/vpcs/<vpc-id> and can only exist inside a Project. You cannot create a VPC in the default space.

Who owns what: the provider and tenant split

This is the line that decides your whole design, so be precise about it. Tier-0 gateways and Edge clusters are always owned by the default space. You cannot create a Tier-0 or an Edge cluster inside a Project, full stop. What you can do is allocate an existing Tier-0 to a Project so the tenant’s Tier-1s and VPCs can hang off it for north-south. Several projects can share the same Tier-0 or a Tier-0 VRF, which is exactly why route filtering inside projects exists: to keep one tenant’s routes from leaking into another’s through the shared uplink.

A Project can own Tier-1 gateways, and it must, because a Project cannot borrow a Tier-1 from the default space. A VPC goes a step further and hides routing behind the Transit Gateway, so the VPC consumer never creates a gateway object at all. The provider keeps the parts that carry blast radius (the Edge, the BGP peering, the physical uplinks) and tenants get the parts that are safe to self-serve.

The Transit Gateway decision: centralized vs distributed

The Transit Gateway (TGW) is the hub that connects VPCs to each other and to the outside world. In VCF 9 you choose how it is realized, and this is the single most consequential VPC design decision because it changes where packets are switched and how many Edge VMs you need.

Centralized Transit Gateway

The centralized model realizes the TGW on the Edge cluster. Every inter-VPC flow and every flow needing stateful services rides through the Edge. It is the simpler model to reason about and the one you want when you need centralized services on that traffic. The cost is real: east-west between two VPCs on the same hosts hairpins out to an Edge VM and back, and that Edge throughput becomes your inter-VPC ceiling. Size for it.

Distributed Transit Gateway

The distributed model, added in VCF 9.0, routes inter-VPC traffic directly in the hypervisor data plane with no Edge VM in the east-west path. Two workloads in different VPCs on the same host talk through the local forwarding stack. You still need an Edge for north-south and for stateful services like the gateway firewall, but the inter-VPC volume no longer lands on it. For dense multi-VPC environments this is the difference between a two-node Edge cluster and a much larger one.

VPC connectivity profiles and the IP planning that bites

VPCs are configured through a Connectivity Profile, which is where the provider centralizes the address space and outbound behavior so tenants do not have to. There are three IP pools you need to keep straight, and mixing them up is where new VPC deployments go wrong.

Private subnets are routed only within the VPC and never reachable from outside. The private Transit Gateway IP blocks are scoped to the TGW within its project and are not advertised to the northbound router. The external IP block is your public, routable space, and public subnets are carved from it, must not overlap, and must be routed on your physical fabric. Here is the part people miss: when Default Outbound NAT is set in the Connectivity Profile, NSX automatically reserves a subnet from the public block and pulls one outbound NAT IP for every VPC. Spin up 50 VPCs and you have silently consumed 50 public IPs before a single workload is exposed.

The limits that change the design

Two constraints reshape architectures, so surface them early.

The second is quotas. Each Project can have quotas that cap how many objects of a given type its users create, segments, Tier-1s, NAT rules, and so on. This is your guardrail against one noisy tenant exhausting shared scale. Project users can monitor quota status and see alarms as they approach a limit. Set quotas when you create the Project, because retrofitting them after a tenant has sprawled is a negotiation, not a config change.

One more operational note that follows from NSX 9 removing the Manager API: everything tenant-facing is Policy API and hierarchical API. The hierarchical API lets you push an entire Project intent, gateways, segments, groups, and firewall rules, in a single tree-structured call, which is how you should be templating tenant onboarding. The Terraform provider exposes the same model through resources like nsxt_policy_project, so a new tenant becomes a module, not a runbook.

# Create a Project with the Policy hierarchical API (conceptual)
PATCH https://<nsx-mgr>/policy/api/v1/orgs/default/projects/trading
{
  "resource_type": "Project",
  "id": "trading",
  "tier_0s": [ "/infra/tier-0s/edge-t0-a" ],
  "site_infos": [ ... ]
}

# Then a VPC under that Project
PATCH .../orgs/default/projects/trading/vpcs/payments-app

How I decide: Project, VPC, or both

My default pattern for a real tenant is a Project that owns its Tier-1s and DFW, with VPCs created inside it for the application teams who just want subnets. That gives the tenant’s network owner real control at the Project level and gives their developers a cloud-like experience at the VPC level, all under one set of quotas and one shared, provider-owned Tier-0. Read the NSX in VCF 9 overview for how this slots into the wider platform, and the VKS networking part for how Kubernetes consumes these VPCs. The tenant isolation itself is enforced by the distributed firewall, which each Project controls within its own scope.

What I’d Do

Start by sorting your tenants into two buckets: teams that will manage networking, and teams that just want to ship apps. The first bucket gets Projects, the second gets VPCs inside a shared or per-team Project. Keep the Tier-0 and Edge firmly with the provider, default to a distributed Transit Gateway unless you have a specific reason to centralize, size the external IP block for your worst-case VPC count, and decide the Federation question before anyone draws a topology. Do that and NSX 9 multi-tenancy holds up under real load instead of becoming the thing you quietly work around. Next up in the series: NSX Federation and multi-site, which is the path you take when tenancy is not your problem but geography is.

NSX Series navigation:
← Previous: Part 21: NSX 9 Micro-segmentation Design
→ Next: Part 23: NSX Federation and Multi-Site (coming soon)
↑ Series hub: NSX Complete Guide

References

Broadcom TechDocs: NSX Projects (VCF 9.0)
Broadcom TechDocs: Virtual Private Cloud in NSX
VCF Blog: VPC Distributed Network Connectivity, No NSX Edge VMs

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts