TL;DR · Key Takeaways
- In NSX 9, Projects and VPCs are first-class multi-tenancy constructs, not an afterthought. A Project is the tenant boundary; VPCs are the self-service network spaces inside it.
- The Transit Gateway changed VPC routing. VPCs no longer attach straight to a Tier-0. They connect through the Project’s Transit Gateway, which handles inter-VPC routing and the path to the outside. One Transit Gateway per Project.
- External connectivity comes in two flavours: centralized (Transit Gateway to a Tier-0 on Edge VMs) and distributed (Transit Gateway straight to physical via an external VLAN, no Edge VMs in the data path). The choice is a real design fork with throughput and service trade-offs.
- Subnets are typed: public (routable externally), private (VPC scope), and private with Transit Gateway scope. Pick the type per workload, because it decides reachability.
- RBAC and quotas at the Project and VPC level are what make this safe to hand to tenants. Without the guardrails, self-service becomes self-harm.
For years, giving a business unit its own slice of NSX meant one of two unhappy choices: stand up a whole separate NSX instance per tenant, or carefully hand-build isolation with naming conventions, RBAC scopes, and a lot of hope. Neither scaled. The first was expensive, the second was fragile. NSX 9 finally fixes this with Projects and VPCs as built-in tenancy primitives, and it changes how I design shared platforms. The first time a client asked me to give forty internal teams “their own AWS-style VPC, on-prem, today,” this is the model I reached for.
Projects are tenants, VPCs are their networks
Get the hierarchy straight first, because everything else hangs off it. At the top sits the Provider: the platform team that owns the NSX deployment, the Edge clusters, and the external connectivity. Below that, a Project is a tenant. It is an isolated space where a tenant configures their own networking and security objects without seeing or touching anyone else’s, and the Provider sets quotas so one tenant cannot consume the whole platform. Inside a Project live one or more VPCs, each a self-contained network with its own subnets, its own routing, and its own distributed firewall scope. A workload lands in a subnet, in a VPC, in a Project. That nesting is the isolation.
What makes this genuinely multi-tenant rather than cosmetic is the RBAC. A Project has its own role bindings, so a tenant admin gets full self-service inside their Project and zero visibility outside it. Combine that with per-Project quotas and you can hand a team the keys to build segments, VPCs, and firewall rules without a platform engineer in the loop, which is the entire promise of cloud-like on-prem networking.
The Transit Gateway changed VPC routing
If you carry an NSX-T mental model into NSX 9, this is the part that will trip you. In the old world, tenant networks hung off Tier-1 gateways that connected up to a Tier-0. In NSX 9, VPCs do not attach directly to a Tier-0. Each Project gets a Transit Gateway, and the VPCs connect through it. The Transit Gateway is the central routing element: it lets multiple VPCs in the same Project reach each other over private transit networks while staying isolated from anyone outside the Project, and it owns the path to the outside world. The rule to memorize is simple: one Transit Gateway per Project. That single constraint shapes the whole tenant topology, because all inter-VPC and north-south routing for a tenant funnels through it.
This is the same Transit Gateway and VPC model I introduced from the platform side back in NSX in VCF 9 explained, but here we care about how a tenant actually consumes it, and the design fork it forces on you for external connectivity.
Centralized connectivity
In centralized mode, the Transit Gateway forwards north-south traffic to a Tier-0 gateway, with the service router instantiated on NSX Edge VMs. This is the familiar path: traffic that needs to leave the Project rides through the Edge cluster, where you also get the stateful services that live on the Edge. The cost is that your tenant north-south throughput is now bounded by Edge capacity, and the Edge cluster sizing from Part 7 becomes a shared resource across every tenant that uses this mode.
Distributed connectivity
In distributed mode, the Transit Gateway connects to physical infrastructure directly through an external VLAN network, without an Edge VM in the forwarding path. Traffic is routed in a distributed fashion across the hosts rather than hairpinning through an Edge. The upside is obvious: you remove the Edge as a north-south bottleneck and a single point of contention, which matters a lot for high-throughput tenants. The trade is that you give up the centralized stateful services that only the Edge can provide, and you take on a tighter coupling to the physical VLAN and routing design. I reach for distributed when a tenant’s north-south demand is high and their service needs are simple, and centralized when they need the Edge’s stateful features more than they need raw throughput.
| Dimension | Centralized | Distributed |
|---|---|---|
| Data path | Transit GW to T0 on Edge VMs | Transit GW to physical via external VLAN |
| Edge in the path | Yes | No |
| North-south ceiling | Bounded by Edge capacity | Distributed across hosts |
| Edge stateful services | Available | Not on this path |
| Best for | Service-heavy tenants | High-throughput, simple-service tenants |
Subnet types decide who can reach what
Inside a VPC, a subnet is not just an address range, it has a type, and the type decides reachability. There are three to know. A public subnet is routable externally and provides outside connectivity, so it needs the external routing the Transit Gateway provides. A private subnet with VPC scope is reachable only within its VPC, the right default for a tier that should never be seen outside its application. A private subnet with Transit Gateway scope is reachable across the VPCs in the Project but not from outside it, which is how you let a shared service in one VPC serve other VPCs in the same tenant without exposing it publicly.
Choosing the subnet type is a security decision dressed as a networking one. A database that only its app should reach belongs on a VPC-scoped private subnet. A tenant-wide logging collector belongs on a Transit-Gateway-scoped subnet. Only the things that truly must face outward belong on a public subnet. Get sloppy here and you have published reachability you did not intend, which no distributed firewall rule should have to clean up after.
Worked example
A SaaS tenant runs two apps in one Project: a customer portal in VPC-1 and a billing engine in VPC-2, sharing a central logging service. Design: portal web front end on a public subnet in VPC-1; portal database on a VPC-scoped private subnet; billing entirely on VPC-scoped private subnets in VPC-2; the logging collector on a Transit-Gateway-scoped subnet so both VPCs reach it without anyone reaching it from outside. One Project, one Transit Gateway, three subnet types, and the only thing exposed to the internet is a single web tier. That is the model working as designed.
My Take
Projects and VPCs are the most genuinely new thing in NSX 9, and the feature most worth restructuring a design around. If you are building a shared platform for internal business units or external customers, this is how you stop cloning NSX instances and hand-rolling isolation. Start by drawing the Project boundary around the isolation and external-connectivity requirement, not the org chart, because the one-Transit-Gateway-per-Project rule will bite teams that drew it around reporting lines. Pick centralized or distributed connectivity per tenant based on whether they need Edge services or raw throughput. Default every subnet to the narrowest scope that works. Then lean on per-Project RBAC and quotas so self-service does not become a way for one tenant to hurt the platform or each other. Used well, this is the closest on-prem NSX has come to feeling like a public cloud VPC. Used carelessly, it is a faster way to build a mess. Is your tenancy boundary a Project, or are you still cloning instances?
RBAC and quota are what make self-service safe
Projects give a tenant their own space, but space without guardrails is a liability rather than a feature. Per-Project role-based access control scopes a tenant admin to their own Project and nothing else, so they get genuine self-service inside their boundary and zero visibility into anyone else. Quotas cap how much a tenant can consume, the address space, the object counts, the capacity, so one enthusiastic team cannot exhaust the resources the whole platform shares. Together, RBAC and quota are precisely what let you hand the keys to a business unit without also handing them a way to damage the platform or their neighbours.
Without both, self-service quietly becomes self-harm. RBAC without quota lets a runaway tenant starve everyone else of shared resources; quota without RBAC lets a tenant see and touch things that are not theirs. Design the two together, set the quotas from realistic expected consumption with headroom for growth, and revisit them as tenants scale. These guardrails are not bureaucracy bolted on after the fact; they are the mechanism that makes the cloud-like, delegated model safe enough to actually use. A platform team that trusts its RBAC and quota can say yes to self-service; one that does not ends up back in the ticket queue brokering every change by hand.
Draw the Project boundary around isolation, not the org chart
The most common VPC design mistake is drawing Project boundaries to mirror the reporting structure, one Project per team because that is how the org is shaped. The boundary that actually matters is isolation and external connectivity, and the reason is the one-Transit-Gateway-per-Project rule: everything inside a Project shares a single external-connectivity domain through that one Transit Gateway. If two parts of an organization genuinely need separate external connectivity, or hard isolation from each other, that is two Projects, no matter how closely they sit on the org chart.
So design from the requirement, not the hierarchy. Group workloads that share an isolation and connectivity model into one Project, and split workloads that need different models into separate Projects. Get this right and the single-Transit-Gateway constraint never bites you, because you never asked one Project to be two connectivity domains. Get it wrong by following the org chart and you discover the limit late, when re-homing a tenant into a new Project is an expensive migration rather than a planning decision. The org chart is reorganized every couple of years; the isolation and connectivity requirement is stable, so anchor the design to the stable thing and let the boundaries follow the network reality.
Subnet scope is a security decision, restated
It is worth closing the loop on subnet types because they are where a tidy tenancy design quietly leaks reachability. Every subnet in a VPC has a scope, public and routable, private within the VPC, or private across the Project through the Transit Gateway, and that scope decides who can reach the workloads on it. Choosing the scope is therefore a security decision wearing networking clothes, and the safe default is always the narrowest scope that still meets the requirement.
In practice that means a database belongs on a VPC-scoped private subnet, a tenant-wide shared service on a Transit-Gateway-scoped subnet, and only the handful of things that genuinely must face outward on a public subnet. Get sloppy and put a workload on a wider scope than it needs and you have published reachability you did not intend, which no firewall rule should have to compensate for after the fact. Pick the scope deliberately per subnet, default to the smallest, and the VPC design stays as tight as the segmentation work that sits on top of it.
References
- Broadcom TechDocs: Virtual Private Cloud in NSX
- Broadcom TechDocs: Transit Gateways
- evoila: VCF 9 NSX VPC, Centralized Transit Gateway
About The Author
