TL;DR
Do not create a VMware Cloud Foundation workload domain every time a tenant, business unit, application, or security team asks for separation.
In VCF 9.1, the correct design is usually to choose the smallest boundary that satisfies the strongest verified requirement. A subnet or segment separates network attachment. An NSX VPC separates application networking, routing, addressing, and delegated policy. An NSX project creates a broader tenant and administrative scope for quotas, shared services, and multiple VPCs. A dedicated cluster creates a physical compute, maintenance, capacity, and failure boundary. A workload domain creates a separate vCenter-centered inventory and lifecycle boundary, with NSX either shared or dedicated according to the control-plane requirement.
A separate workload domain is justified when the requirement is truly about independent vCenter administration, lifecycle cadence, backup and recovery of the management plane, support ownership, identity scope, or control-plane blast radius. It is usually excessive when the requirement is only logical network isolation, overlapping private IP space, delegated security policy, or dedicated compute capacity.
Introduction
One of the easiest ways to make a VMware Cloud Foundation design unmanageable is to confuse separation with a workload domain.
The conversation often starts innocently. A business unit asks for isolation. A regulated application asks for a dedicated zone. A service-provider tenant asks for overlapping IP addresses. A development team asks for independent administration. Someone translates every request into the same answer: another workload domain.
The result can be dozens, or even hundreds, of vCenter instances, duplicated NSX management planes, fragmented clusters, stranded capacity, multiplied lifecycle operations, and a support model that becomes harder to explain than the original security requirement.
The Broadcom community discussion that inspired this article described a design considering more than 100 workload domains. The most important question raised in that discussion was not how to scale the number of domains. It was why each customer supposedly required one. Was the requirement physical resource separation, security separation, or something else? [13]
That is the right architecture question.
The official VCF Networking overview is the product-level starting point for the integrated NSX capabilities in VCF. This article focuses on how those networking capabilities relate to VCF topology and operational boundaries. [4]
VCF 9.1 provides several isolation boundaries. They are not interchangeable, and they do not solve the same problem. The design task is to translate vague words such as dedicated, isolated, tenant, secure, and independent into specific failure, security, lifecycle, administrative, routing, addressing, and compliance requirements.
The Design Principle: Use the Smallest Boundary That Satisfies the Requirement
The practical rule is simple:
Start with the smallest isolation boundary. Escalate only when a documented requirement cannot be met at that layer.
This avoids two common mistakes. The first is under-isolation, where a network segment is treated as sufficient even though the tenant needs independent administration, quotas, routing, and overlapping address space. The second is over-isolation, where a complete workload domain is created for a requirement that an NSX project, VPC, or dedicated cluster could satisfy.
Broadcom describes a VCF domain as a logical unit of application-ready infrastructure. Creating a workload domain adds a logical pool of compute, network, and storage infrastructure, and a workload domain maps to a vCenter-centered management boundary. Existing vCenter environments are also imported into VCF as workload domains at the vCenter level, not cluster by cluster. [1]-[3], [11]
That makes the workload domain a significant architectural commitment. It is not merely a tenant folder with stronger branding.
Scenario: The Enterprise That Proposed 120 Workload Domains
Consider a global enterprise planning a new VCF 9.1 platform. The first proposal contains 120 workload domains:
- one for each business unit
- one for each regulated application
- one for each development environment
- one for each external customer
- several more for shared services and regional teams
The stated reason is separation.
The architecture team pauses the design and asks each requester to classify the requirement using six boundary questions:
- What must not fail together?
- What must not be administered by the same people?
- What must not share physical hosts, storage, or network devices?
- What must be upgraded or restored on a different schedule?
- What addressing and routing behavior must be independent?
- What regulation, contract, or assessor finding explicitly requires dedicated infrastructure?
The answers reveal that most requests do not require separate vCenter instances or separate workload-domain lifecycle.
An illustrative translation might look like this:
| Original request | Actual requirement | Better default boundary |
|---|---|---|
| 60 application domains | Isolated application networks, delegated subnet creation, separate firewall policy | 60 VPCs grouped into projects |
| 20 business-unit domains | Administrative delegation, quotas, shared services, chargeback | 20 NSX projects with multiple VPCs |
| 20 development domains | Noisy-neighbor control, faster change cadence, lower assurance | Shared development clusters plus projects and VPCs |
| 12 regulated domains | Dedicated hosts and storage policy, restricted administration | A small number of dedicated clusters grouped by control regime |
| 6 customer domains | Overlapping private IP space and tenant-level policy | Per-customer projects and VPCs, with dedicated clusters only where contracted |
| 2 sovereign zones | Independent administrators, identity, lifecycle, recovery, and external connectivity | Separate workload domains or VCF instances |
The revised platform may need four or six workload domains, not 120. It can still contain dozens of projects, hundreds of VPCs, many clusters, and strong tenant isolation. The exact numbers are illustrative, but the reasoning pattern is reusable.
Scope, Assumptions, and Terminology Guardrails
This article assumes VMware Cloud Foundation 9.1 and uses current VCF terminology, including VCF Networking, NSX projects, VPCs, VPC gateways, Transit Gateways, VPC subnets, workload domains, VCF instances, and fleets.
The article focuses on infrastructure and network isolation boundaries. It does not attempt to replace a formal compliance assessment, legal interpretation, or detailed application threat model.
Several guardrails matter:
- Logical isolation is not physical isolation. A VPC can strongly isolate networking while workloads still share hosts, storage systems, racks, and management appliances.
- A dedicated cluster is not a dedicated control plane. It can isolate compute placement and maintenance without providing a separate vCenter or NSX Manager.
- A workload domain is not automatically an air gap. It may still share identity, physical switching, DNS, backup infrastructure, storage arrays, or an NSX control plane.
- A separate NSX Manager does not automatically require separate physical infrastructure. It changes the networking management and control-plane boundary, not necessarily the hardware boundary.
- Configuration maximums are not design targets. A platform can be technically supported and still be operationally unreasonable.
The most important terminology distinction is between a tenant boundary and a platform lifecycle boundary. Projects and VPCs are designed to create tenant and application isolation inside a shared private-cloud platform. Workload domains are used when the infrastructure management and lifecycle boundary itself must be separated.
The Isolation Boundary Ladder
The diagram below shows the hierarchy from the smallest logical boundary to the broadest platform boundary. The key point is that each step adds cost, operational overhead, and a larger degree of independence.
A segment or subnet is inexpensive and narrow. A VPC adds routing, addressing, security, and self-service. A project adds tenant administration and quotas. A cluster adds physical resource and maintenance separation. A workload domain adds a vCenter-centered lifecycle boundary. A separate VCF instance adds an independent management domain and broader operational autonomy.
What Each VCF Boundary Actually Isolates
Network Segment or VPC Subnet
A network segment or VPC subnet is primarily a workload connectivity boundary.
In the traditional NSX policy model, a segment provides Layer 2 connectivity and attaches workloads to a routing topology, commonly through a Tier-1 gateway. In the VPC model, the tenant-facing construct is a VPC subnet with an access mode that determines its routing scope.
Use a segment or subnet when the requirement is limited to:
- separating application tiers
- controlling broadcast and address scope
- attaching workloads to a specific network
- applying network security policy to a defined workload group
- creating a distinct routing prefix inside an existing tenant boundary
A segment alone is usually not enough when a tenant needs its own delegated administration, quotas, routing policy, or overlapping private address space.
NSX VPC
A VPC is the default application or tenant network boundary in the VCF 9.x consumption model.
Broadcom describes a VPC as a logically isolated, multi-tenant network environment with custom IP addressing, routing, and security policies. Each VPC owns a VPC gateway, and VPC administrators can create and manage subnets within their assigned quota. [5], [6]
Use a VPC when the requirement includes:
- per-application or per-tenant networking
- delegated subnet creation
- isolated routing within the VPC
- private IP address space that may overlap with another VPC
- VPC-scoped firewall and gateway policy
- controlled north-south access using public subnets, external IPs, or NAT
- self-service through vCenter, NSX, or VCF Automation
VCF 9.1 also allows the architecture team to control VPC network span. A VPC can be restricted to selected clusters or extended across vCenters in the same networking domain when the design requires it. [10]
That feature is especially important because it breaks the assumption that an application needs a new workload domain merely to control where its network can exist.
NSX Project
An NSX project is the broader tenant-administration boundary above one or more VPCs.
The enterprise administrator creates projects, assigns resources and quotas, and retains infrastructure-level authority. A project administrator can then allocate project resources to VPCs. VPC administrators operate within the delegated VPC scope without receiving access to the underlying physical or provider network. [5]
Use a project when the requirement includes:
- one administrative boundary for a business unit or customer
- multiple VPCs for separate applications or environments
- tenant-level quotas and consumption controls
- a shared Transit Gateway or shared-services routing scope
- delegation to a project administrator
- policy guardrails enforced above individual VPC administrators
- reporting and chargeback aligned to a tenant or organizational unit
A useful model is one project per durable tenant or business unit, with multiple VPCs beneath it for applications, environments, or product teams.
Cluster
A vSphere cluster is the first major physical-resource and failure boundary in this decision model.
A dedicated cluster can isolate:
- ESX host placement
- CPU and memory capacity
- hardware generation or accelerator type
- vSphere HA and DRS behavior
- host maintenance and evacuation
- cluster image and host remediation cadence
- storage presentation and policy choices
- licensing or application affinity constraints
- noisy-neighbor risk
A cluster is often the correct answer when a customer asks for dedicated hardware but does not require a dedicated vCenter or NSX control plane.
However, a cluster does not isolate every dependency. Multiple clusters in the same workload domain still share vCenter. They may share NSX Manager, edge infrastructure, physical storage, identity, monitoring, and lifecycle orchestration. The design must state which shared dependencies are acceptable.
Workload Domain
A workload domain is justified when the infrastructure management boundary itself must be independent.
In VCF 9.1, the workload domain is closely associated with a vCenter inventory and lifecycle scope. Broadcom’s import workflow reinforces this model: infrastructure is added to VCF at the vCenter level, and the entire vCenter inventory is imported as a workload domain. [3], [11]
A separate workload domain can provide:
- a separate vCenter inventory and API endpoint
- independent vCenter administration and backup scope
- a distinct lifecycle and change-management boundary
- separate cluster groups under that vCenter
- a clearer support and ownership boundary
- separate identity or SSO design where required
- a separate NSX management plane when the domain uses dedicated NSX
- reduced vCenter-specific blast radius across domains
A workload domain is not automatically necessary for every cluster, business unit, application, or security zone. It is appropriate when the organization can explain why a separate vCenter and lifecycle boundary are required.
VCF Instance or Separate Site
A separate VCF instance creates a broader platform boundary with its own management domain. This is usually reserved for requirements such as:
- independent regional or sovereign operations
- separate management-domain failure scope
- disconnected or tightly controlled network zones
- different release or maintenance governance
- separate operations teams and support ownership
- mergers, divestitures, or provider boundaries
- site-level recovery or disaster-isolation requirements
Even this boundary is not automatically an air gap. Shared identity, DNS, depot access, monitoring, backup, or physical network services can reconnect the environments operationally.
Physical Separation Versus Logical Multitenancy
The architecture must state whether separation means policy isolation or exclusive infrastructure.
| Requirement | VPC or project | Dedicated cluster | Workload domain | Separate VCF instance |
|---|---|---|---|---|
| Separate routing and private IP space | Strong fit | Not required | Usually excessive | Excessive |
| Delegated tenant network administration | Strong fit | Not required | Usually excessive | Excessive |
| Dedicated hosts | No | Strong fit | Optional | Optional |
| Independent vCenter administration | No | No | Strong fit | Strong fit |
| Independent NSX management plane | No | No | Possible with dedicated NSX | Strong fit |
| Independent lifecycle cadence | Limited | Cluster image only | Strong fit | Strongest fit |
| Independent management-domain failure scope | No | No | No | Strong fit |
| Air-gap requirement | No | No | Insufficient by itself | Possible only with full dependency separation |
Logical multitenancy is not a weaker version of architecture. It is the correct architecture when the requirement is policy, routing, addressing, and administrative isolation on shared infrastructure.
Physical separation becomes necessary when the requirement concerns host exclusivity, performance determinism, hardware certification, data-remanence risk, contractual tenancy, or a control that cannot be demonstrated on shared compute.
Tier-0, Tier-1, Transit Gateway, VPC Gateway, and Segment Responsibilities
VCF 9.1 supports both traditional NSX routing models and the newer VPC consumption model. The two should not be mixed casually because they expose different administrative abstractions.
| Component | Primary responsibility | Appropriate owner | What it is not |
|---|---|---|---|
| Tier-0 gateway | Provider and external routing, physical network connectivity, BGP or static routing, centralized service placement | Enterprise network team | A tenant or workload-domain boundary by itself |
| Tier-1 gateway | Application or tenant routing and centralized services in the traditional NSX policy model | Network or platform team | A complete multitenancy and quota model |
| Transit Gateway | Project-level connectivity among VPC gateways and attachment to external connectivity | Enterprise or project design authority | A replacement for a workload domain |
| VPC gateway | Routing among subnets inside one VPC and enforcement of VPC-scoped network behavior | Platform-provided, VPC-admin consumed | A separately managed appliance per tenant |
| VPC subnet | Workload attachment, IP allocation, and routing scope through its access mode | VPC administrator | An administrative or lifecycle boundary |
| NSX segment | Layer 2 workload network in the traditional policy model | Network or platform team | A full tenant construct with delegated quotas |
Every VPC owns a VPC gateway. Within a project, a Transit Gateway links VPC gateways. With centralized external connectivity, the Transit Gateway reaches the physical network through a Tier-0 gateway running on NSX Edge nodes. With distributed connectivity, the design can avoid NSX Edge nodes and Tier-0 gateways, subject to the required Layer 2 physical-network topology and service constraints. [8], [9]
Tier-1 gateways remain relevant for traditional NSX designs and specific centralized service patterns. They should not be created automatically for every new VPC tenant when the VPC gateway and Transit Gateway model already provides the required abstraction.
Tenant Address Spaces and Overlapping IP Requirements
Overlapping IP address requirements are a classic reason organizations overbuild workload domains.
They usually do not need to.
VCF VPC subnet access modes create different routing scopes: [5], [7]
- Private-VPC: The subnet is visible only inside its VPC. Its CIDR can overlap with private CIDRs used by other VPCs because those routes are not advertised beyond the local VPC gateway.
- Private-Transit-Gateway: The subnet is reachable across VPCs attached to the same Transit Gateway. Addresses come from a shared project-level pool and must remain non-overlapping within that routing scope.
- Public: The subnet is reachable from the wider data-center network. The address space must be unique and routable within the external network design.
This distinction matters. A service provider can use overlapping Private-VPC address space for isolated tenant applications without deploying a separate workload domain per customer. When tenants must exchange traffic with shared services, external networks, or each other, the design must resolve address conflicts using non-overlapping project pools, NAT, separate routing scopes, or a more advanced external routing design.
The requirement should therefore be written precisely:
Tenant private address spaces may overlap while isolated inside each VPC. Any address advertised to a shared Transit Gateway or the external network must be unique within that routing domain.
That statement is much more useful than saying each tenant needs its own domain because IP addresses may overlap.
Security Policy Delegation
VCF multitenancy works when policy ownership is layered rather than transferred wholesale.
A practical delegation model is:
- Enterprise administrator: Owns external connectivity, projects, shared IP blocks, provider-level routing, global guardrails, service insertion, and policies that tenants cannot override.
- Project administrator: Owns tenant allocation, project-level quotas, Transit Gateway design, shared services, and the distribution of resources among VPCs.
- VPC administrator: Owns VPC subnets and permitted VPC-scoped networking and security configuration within quota and enterprise guardrails.
- Application owner: Consumes approved networks and declares application intent without receiving provider-network privileges.
The design should answer four questions before delegating access:
- Which policies are inherited and non-overridable?
- Which objects can the tenant create, modify, and delete?
- Which logs and flow records can the tenant see?
- Who approves connectivity that crosses VPC, project, or external boundaries?
A new workload domain is not required merely because a security team wants local policy autonomy. It becomes relevant when the security administrators must also have independent control of vCenter, NSX Manager, backup, lifecycle, privileged access, and incident response.
Dedicated Versus Shared NSX Manager Designs
The decision to share or dedicate NSX Manager should be evaluated separately from the decision to create a workload domain.
| Design | Advantages | Tradeoffs | Best fit |
|---|---|---|---|
| Shared NSX management plane | Fewer appliances, consistent enterprise policy, shared operational tooling, easier common services, VPCs across a shared networking domain | Larger control-plane and change blast radius, shared administrative authority, version and maintenance coordination, shared capacity limits | Multiple workload domains under one network operating model |
| Dedicated NSX management plane | Independent network administration, backup and restore, change windows, routing design, troubleshooting, and policy ownership | More appliances, more certificates and backups, duplicated edge and service infrastructure, more lifecycle work, higher capacity fragmentation | Sovereign, provider, regulated, or organizational zones requiring control-plane independence |
A shared NSX design is often appropriate when the enterprise network team owns the routing fabric, security guardrails, and lifecycle across multiple workload domains. VCF 9.1 can also span VPCs across vCenters within a networking domain, which increases the usefulness of a shared network control plane. [10]
A dedicated NSX design is justified when a failure, administrative error, backup restore, upgrade, certificate event, or security compromise in one NSX management plane must not affect another zone. That is a control-plane requirement, not merely a desire for separate firewall rules.
The operating model must also consider case ownership. Shared NSX means one networking incident can involve several vCenters and workload domains. Dedicated NSX narrows that scope but increases the number of systems that must be monitored, patched, backed up, and supported.
Routing and Service Insertion Considerations
Network-service requirements often determine the topology more strongly than tenant count.
The VCF 9.1 distributed VPC connectivity model removes the need for NSX Edge nodes and Tier-0 gateways, but it depends on all participating ESX hosts having the required common Layer 2 connectivity. The centralized model uses NSX Edge nodes and a Tier-0 gateway and supports the broadest set of stateful services, including VPN. [9]
Use the following questions:
- Does the tenant require BGP or static routing to the physical network?
- Is VPN required?
- Is north-south gateway firewalling required?
- Must traffic pass through a third-party firewall, intrusion-prevention platform, proxy, or network virtual appliance?
- Is load balancing required, and where will the service run?
- Is NAT needed to resolve overlapping addresses or control exposure?
- Must traffic be inspected differently by tenant, application, or regulatory zone?
- Does the design require deterministic service placement and failure behavior?
These requirements may justify a dedicated edge cluster, a dedicated external connection, a separate Transit Gateway, or a dedicated NSX instance. They do not automatically justify a separate workload domain.
A good design separates the decisions:
- Compute placement: cluster and workload-domain design
- Tenant routing: project, VPC, and Transit Gateway design
- External connectivity: Tier-0 and physical fabric design
- Stateful services: edge, VNA, load-balancer, firewall, or appliance design
- Administrative ownership: project, NSX Manager, vCenter, and VCF instance design
Blast Radius and Upgrade-Domain Differences
Isolation boundaries should be selected by asking what can fail or change together.
| Event | Segment or VPC | Project | Cluster | Workload domain | VCF instance |
|---|---|---|---|---|---|
| Incorrect tenant firewall rule | Usually VPC-scoped | May affect project services | No additional isolation | No additional isolation | No additional isolation |
| Host failure | No isolation | No isolation | Cluster HA boundary | Limited to clusters using failed resources | Limited to instance resources |
| Cluster image remediation | No isolation | No isolation | Cluster scope | Coordinated within domain lifecycle | Coordinated within instance operations |
| vCenter outage or restore | No isolation | No isolation | All clusters in that vCenter affected operationally | Domain-level management impact | Other instances can remain independent |
| NSX Manager outage or bad change | VPCs on that NSX affected operationally | Projects on that NSX affected | Clusters using that NSX affected | Depends on shared or dedicated NSX design | Other NSX instances can remain independent |
| Management-domain outage | No isolation | No isolation | No isolation | Workload data planes may continue, but instance management is constrained | Other VCF instances can remain independent |
The table also exposes a common design error: adding a workload domain does not reduce the NSX blast radius if the new domain attaches to the same shared NSX management plane. Likewise, adding a dedicated NSX Manager does not isolate a shared vCenter outage.
The boundary must match the failure being controlled.
Capacity Fragmentation Caused by Too Many Workload Domains
Every hard boundary reduces the scheduler’s ability to use spare capacity elsewhere.
A small workload domain needs enough hosts to satisfy availability, maintenance, and failure-reserve requirements. If dozens of small domains each retain their own N+1 headroom, capacity becomes stranded across isolated pools. The same problem appears in dedicated clusters, but workload domains add management and lifecycle overhead on top of compute fragmentation.
Over-segmentation creates several costs:
- spare host capacity repeated in every small domain
- uneven CPU and memory utilization
- stranded storage capacity or incompatible storage policies
- duplicated edge and network-service capacity
- more management appliances and backup targets
- additional DNS names, certificates, service accounts, and firewall rules
- more prechecks, upgrade plans, maintenance windows, and rollback plans
- more compatibility matrices and vendor-support evidence
- smaller failure pools that are harder to evacuate during maintenance
Projects and VPCs preserve logical separation while allowing workloads to share larger compute pools. Dedicated clusters can then be introduced only where physical tenancy, hardware type, performance, or maintenance independence requires them.
The objective is not maximum consolidation. It is controlled consolidation with explicit reserves and measurable blast radius.
Operational and Lifecycle Implications
A workload-domain decision is also an operating-model decision.
For each additional domain, the platform team should account for:
- vCenter configuration, backup, restore testing, certificates, and privileged access
- NSX Manager operations if dedicated
- lifecycle planning and compatibility validation
- monitoring, logging, alert routing, and capacity management
- identity integration and access reviews
- audit evidence and change records
- incident triage and vendor case ownership
- automation endpoints, credentials, inventories, and drift control
- disaster-recovery dependencies and recovery runbooks
- documentation and known-good configuration baselines
A design with 100 workload domains is not merely 100 logical containers. It is potentially 100 vCenter-centered operating units, plus the NSX, identity, certificate, backup, monitoring, and lifecycle relationships attached to them.
The platform team should require an operating-cost estimate for every requested workload domain. That estimate does not need to be a perfect financial model. It must at least count the management systems, lifecycle actions, backup targets, monitoring objects, certificates, identities, and reserved capacity introduced by the boundary.
Compliance Cases That Genuinely Require Dedicated Infrastructure
Compliance is often cited as the reason for a dedicated workload domain, but the actual requirement may be narrower.
NIST guidance for virtualized environments recognizes network segmentation, firewall traffic control, path resilience, and monitoring as important protection mechanisms. It does not imply that every security zone requires its own physical virtualization stack. [14]
A dedicated cluster, workload domain, NSX instance, or VCF instance becomes appropriate when a regulation, contract, assessor decision, or risk treatment explicitly requires one or more of the following:
- exclusive physical hosts or racks
- separate cryptographic key ownership or hardware security modules
- independent privileged administrators
- separate management-plane credentials and recovery
- a distinct patch or release cadence that cannot be coordinated with other tenants
- evidence that shared control-plane administrators cannot access the regulated zone
- independent audit logging and retention under separate custody
- separate external connectivity and inspection infrastructure
- a disconnected, sovereign, or air-gapped operating environment
- contractually dedicated capacity and failure reserves
- separate incident response, support, and legal ownership
A common middle ground is a dedicated cluster inside a shared workload domain, combined with a dedicated project and VPC. This can provide host exclusivity and logical network isolation while retaining a common vCenter and NSX operating model.
The compliance team should document the exact control objective and the evidence required. The architecture team can then choose the least expensive boundary that produces that evidence.
When a Separate vCenter or Workload Domain Is Justified
A separate workload domain is usually justified when several of these statements are true:
- The environment requires an independent vCenter inventory and administrator group.
- vCenter backup, restore, certificate, or outage events must be isolated.
- The tenant requires an independent lifecycle and maintenance calendar.
- The environment needs a dedicated NSX management plane because shared control-plane risk is unacceptable.
- The domain has a distinct support owner, managed-service provider, or contractual service boundary.
- Identity and privileged access must be separated beyond project-level delegation.
- The environment requires a different platform configuration baseline or hardware lifecycle.
- Recovery must be performed independently without coordinating with other tenants in the same vCenter.
- The environment will be transferred, divested, or operated as a separately governed platform unit.
A separate workload domain is usually not justified when the only requirement is:
- separate VLANs or subnets
- separate distributed firewall rules
- overlapping private IP space
- a business-unit chargeback label
- a dedicated resource quota
- application-level routing
- development versus production labeling
- a dedicated host cluster under the same administrators and lifecycle
The decision should be recorded as an architecture decision record, including the requirement, chosen boundary, alternatives rejected, operational cost, blast radius, and review trigger.
A Practical Isolation Decision Tree
Use the decision path below from top to bottom. Stop at the first boundary that satisfies every mandatory requirement.
Some designs legitimately combine layers. A regulated customer may receive a project, multiple VPCs, and a dedicated cluster inside a shared workload domain. A sovereign region may receive its own VCF instance, several workload domains, and many projects and VPCs. The decision tree identifies the highest required boundary, not the only boundary in the design.
Decision Matrix by Common Enterprise Scenario
| Scenario | Recommended default | Escalate to dedicated cluster when | Escalate to workload domain when | Escalate to separate VCF instance when |
|---|---|---|---|---|
| Business unit | NSX project with VPCs per application or environment | It needs exclusive hosts, hardware, capacity, or maintenance | It needs independent vCenter administration, lifecycle, recovery, or NSX control plane | It has independent regional, legal, sovereign, or management-domain requirements |
| Application | VPC, with subnets for tiers | Performance, licensing, GPU, hardware, or noisy-neighbor controls require dedicated hosts | The application platform has a distinct vCenter lifecycle and support model | The application is operated as an independent platform or disconnected site |
| Regulated zone | Project and VPC plus strong enterprise guardrails | The control requires physical host exclusivity or dedicated storage presentation | The control requires independent privileged administration, lifecycle, backup, and control plane | The zone requires a sovereign, disconnected, or separately recovered platform |
| Development environment | Shared development project, VPCs, and shared clusters | Rapid remediation, destructive testing, or noisy-neighbor risk warrants a separate cluster | Tooling or release cadence requires a separate vCenter and lifecycle | Development is managed by an independent site or organization |
| Service-provider tenant | Project per tenant, VPCs per service or application | Contract requires dedicated hosts or guaranteed reserved capacity | Contract delegates vCenter or NSX control-plane ownership and independent lifecycle | Tenant receives a fully independent private-cloud instance or sovereign service |
| Shared services | Dedicated shared-services VPC or project-level service VPC | Services need dedicated performance or appliance hosts | Services require independent vCenter recovery or lifecycle | Services operate as a separate regional platform dependency |
This matrix is a starting point, not a substitute for requirements. The word regulated does not automatically select a workload domain, and the word tenant does not automatically select a VPC. The deciding factor is the strongest boundary the organization can defend with evidence.
The Redesigned 120-Domain Scenario
After translating the original requests, the enterprise replaces its proposed 120 workload domains with a layered design:
- two VCF instances aligned to major regional and sovereignty boundaries
- four to six workload domains aligned to independent vCenter, lifecycle, and support models
- shared NSX management planes where enterprise networking and lifecycle are common
- dedicated NSX management planes only for zones requiring independent control-plane administration or recovery
- dedicated clusters for regulated, hardware-specific, and contractually reserved compute
- NSX projects for durable business-unit and customer tenancy
- VPCs for applications, products, and environments
- VPC subnets for application tiers and routing scopes
This design is not less isolated. It is more precise.
It also improves capacity efficiency because many logical tenants can share larger clusters. It reduces the number of vCenter and NSX systems that require backup, certificates, monitoring, and upgrades. It creates a clearer support model because the architecture can identify which boundary owns a failure.
Most importantly, it makes future growth predictable. Adding a new application normally creates a VPC. Adding a new business unit normally creates a project and a set of VPCs. Adding a new hardware class normally creates a cluster. Adding a new workload domain becomes an exception that requires architectural approval.
Supported Limits Must Be Verified, Not Remembered
The community scenario referenced a version-specific workload-domain maximum from an earlier release. That number should not be carried into a VCF 9.1 design as if it were timeless.
Broadcom’s Configuration Maximums tool is the source of truth for release-specific supported limits. Architects should verify the exact VCF 9.1 limits for SDDC Manager, vCenter, NSX, projects, VPCs, gateways, edge nodes, and related objects during design signoff, and confirm version-sensitive behavior against the VCF 9.1 release notes. [12], [15]
Use three rules:
- Validate limits against the exact installed release and appliance sizing.
- Treat a maximum as a support guardrail, not a recommended operating target.
- Include operational thresholds below the product maximum for upgrade duration, backup time, fault isolation, and human manageability.
A design that fits under a documented maximum can still be the wrong design if every maintenance event requires coordinating dozens of control planes.
Governance Controls That Keep the Model Consistent
The architecture will drift unless boundary creation is governed.
Create a standard intake record with these fields:
- requested tenant, application, or zone
- data classification and compliance obligations
- administrative owner
- network and address-space requirements
- physical resource requirements
- lifecycle and maintenance requirements
- failure and recovery requirements
- service insertion and external connectivity
- capacity reservation and chargeback model
- proposed isolation boundary
- evidence that a smaller boundary is insufficient
- architecture review date and approval owner
Then establish default provisioning patterns:
- Application pattern: existing project plus new VPC
- Business-unit pattern: project plus multiple VPCs
- Regulated shared-platform pattern: project plus VPC plus dedicated cluster
- Independent platform pattern: separate workload domain with explicit NSX choice
- Sovereign platform pattern: separate VCF instance with dependency-separation checklist
Automation should reinforce these patterns. Catalog items, infrastructure-as-code modules, naming standards, tags, quotas, IP blocks, and policy templates should make the recommended boundary the easiest path to consume.
Common Architecture Mistakes
Treating Every Security Zone as a Workload Domain
Security zones are often routing and policy constructs. Start with projects, VPCs, firewall guardrails, and dedicated clusters where physical separation is required.
Treating a Dedicated Cluster as Full Tenant Independence
A cluster can isolate hosts and maintenance, but shared vCenter and NSX control planes remain common dependencies. Document them.
Sharing NSX Without Accepting the Shared Blast Radius
Shared NSX is efficient, but the design must account for common upgrades, certificate events, configuration errors, backup restores, and administrative privileges.
Dedicating NSX Without Funding Operations
A separate NSX management plane adds backups, certificates, monitoring, edge design, upgrades, troubleshooting, and support ownership. It should be treated as a service, not a checkbox.
Solving Overlapping IP Space with More vCenters
Private-VPC subnets can use overlapping address space when the routes remain inside each VPC. Solve routing scope at the network layer before multiplying control planes.
Designing to the Published Maximum
Maximums describe support boundaries. They do not define an efficient or supportable operating model.
Conclusion
The right isolation boundary in VCF 9.1 is not the largest boundary the platform can provide. It is the smallest boundary that satisfies the strongest verified requirement.
Use VPC subnets for workload-network scope. Use VPCs for application or tenant routing, addressing, security, and self-service. Use NSX projects for durable tenancy, delegation, quotas, and shared services. Use dedicated clusters for physical compute, hardware, capacity, maintenance, and failure separation. Use workload domains when independent vCenter, lifecycle, recovery, identity, support, or NSX control-plane boundaries are required. Use separate VCF instances when the management domain, region, sovereignty model, or site operations must also be independent.
This layered model prevents control-plane sprawl without weakening isolation. It also gives architecture teams a defensible answer when someone asks for 100 workload domains: describe the failure, security, lifecycle, administrative, addressing, routing, and compliance boundaries first. Then build only the platform boundaries those requirements actually demand.
