TL;DR
The solar-system image is a useful mental model for VMware Cloud Foundation 9.1 multitenancy because it separates two responsibilities that private-cloud programs often blur: the provider operates a shared platform, while tenants consume isolated, policy-governed environments. VCF Automation, VCF Operations, identity, vSphere, vSAN, NSX, and optional shared services form the platform core. Organizations, projects, entitlements, quotas, catalogs, NSX Virtual Private Clouds, and workload-level policies define each tenant world.
The most important design guardrail is that an NSX VPC is not the tenant by itself. It is a network abstraction and isolation construct inside a broader tenancy model. Production multitenancy also requires identity separation, resource controls, lifecycle ownership, data protection, observability, cost attribution, recovery planning, and clear limits on delegated administration.
Introduction
Enterprise private cloud becomes difficult when one infrastructure platform must serve many teams without turning every request into a ticket or every tenant into a separate hardware island. Application teams want speed and autonomy. Security wants enforceable boundaries. Finance wants accountable consumption. Operations wants consistency. The platform team wants to avoid building and maintaining a different cloud for every business unit.
That is the architectural tension represented by the VCF 9.1 multitenant solar system.
The center of the image is a shared VMware Cloud Foundation platform. Around it are tenant worlds, each with its own workloads, networks, policies, catalogs, and security boundaries. The tenants share the gravity of the platform without sharing unrestricted control of the platform. VCF Automation acts as the launch mechanism. VCF Operations provides the control-room view. NSX VPCs create network separation. Identity, policy, backup, recovery, and service management provide the guardrails that keep the environment governable.
The metaphor is useful, but only when it is translated into real platform objects, ownership boundaries, and failure domains. Otherwise, it becomes another attractive diagram that hides the hard parts.
Why the Solar-System Model Works
A well-designed multitenant private cloud has a center and an edge.
The center contains capabilities that are more efficient, consistent, and governable when operated as shared platform services. These typically include fleet operations, automation, identity integration, infrastructure lifecycle, standard workload images, network provider constructs, observability, policy, and selected protection services.
The edge contains delegated environments where consumers can act without becoming administrators of the shared foundation. A tenant may represent a business unit, application portfolio, development organization, regulated workload group, acquired company, internal platform team, or external customer. The tenant receives a controlled slice of capability rather than direct ownership of the underlying platform.
The image expresses that relationship visually:
| Image element | Practical platform meaning | Design question |
|---|---|---|
| Central sun | Shared VCF platform and provider-operated services | What must remain centralized and provider owned? |
| Tenant planet | Administrative and consumption boundary | Which users, workloads, budgets, and policies belong together? |
| Transparent shield | NSX VPC and other isolation controls | Which traffic, identities, resources, and data must be isolated? |
| Orbital path | Approved dependencies and shared-service access | Which services may each tenant reach, and through what controls? |
| Automation launchpad | Catalog-driven provisioning and Day-2 actions | What can consumers deploy or modify without a ticket? |
| Operations control room | Health, capacity, audit, telemetry, and lifecycle oversight | Who detects issues, proves compliance, and coordinates recovery? |
The central lesson is not that every tenant should orbit one physical cluster. The lesson is that each tenant should consume a consistent service contract while the provider hides unnecessary infrastructure complexity.
The Architecture Behind the Metaphor
The image shows a simple center-to-tenant relationship. The implementation is layered. The exact VCF Automation object model can vary by service path and deployment mode, but the governance hierarchy should still separate provider scope, tenant scope, network scope, and workload scope.
What the reader should notice in the following diagram is that a VPC sits inside a broader administrative model. It does not replace organizations, projects, identity, quotas, placement, or workload governance.
This layered view prevents a common design mistake: calling a subnet, VPC, namespace, workload domain, or project a tenant without defining what the tenant actually owns.
Scenario: One Enterprise, Several Tenant Worlds
Consider a large enterprise building a VCF 9.1 private-cloud service for six internal consumers:
- A digital-product engineering group needs rapid VM and Kubernetes provisioning.
- A finance application team needs strict change control, protected workloads, and auditable access.
- A data platform team needs database services and predictable east-west connectivity.
- An AI team needs GPU-capable placement, Kubernetes, and controlled access to data services.
- An acquired business needs temporary administrative separation while identity and applications are integrated.
- A shared-services team operates DNS, identity dependencies, logging collectors, artifact repositories, and security tools.
Building six independent infrastructure stacks would maximize separation but multiply lifecycle, licensing, capacity, monitoring, backup, and staffing overhead. Placing all six teams into one unrestricted environment would minimize platform duplication but create an unacceptable blast radius and weak accountability.
The multitenant model seeks a controlled middle ground. The enterprise operates shared VCF services once where appropriate, then gives each consumer a defined tenant contract. That contract specifies identity, capacity, placement, network boundaries, catalog access, service levels, data protection, cost ownership, and operational responsibilities.
Scope and Terminology Guardrails
Multitenancy discussions fail quickly when product objects and organizational terms are used as synonyms. Use the following distinctions consistently.
Private Cloud
The private cloud is the service the organization provides. It includes technology, funding, operating processes, service levels, support, governance, and consumer experience. It is broader than any single VCF object.
VCF Fleet, Instance, Domain, and Cluster
These are platform topology and lifecycle concepts. They help define management scope, deployment boundaries, lifecycle coordination, capacity, and blast radius. They are not automatically tenant boundaries.
A workload domain may align with a tenant when hard lifecycle or isolation requirements justify it, but one tenant does not always need one workload domain. Likewise, several tenants may consume resources from shared workload domains when the isolation and change model support it.
Organization and Project
These are consumption and governance constructs used to group consumers, entitlements, resources, placement options, policies, and catalog access. They help define who may request what and where it may be placed.
Do not create projects as arbitrary folders. Each project should correspond to an operationally meaningful scope such as a team, environment, application portfolio, cost center, or security zone.
NSX Virtual Private Cloud
An NSX VPC provides a self-contained networking abstraction for workloads, including tenant-facing control over relevant networking services. It is one of the strongest building blocks in the multitenant model because it separates tenant network intent from the underlying provider network.
It is still only one dimension of isolation. A VPC does not automatically create separate identity administration, storage ownership, backup policy, cost accountability, observability, or application governance.
vSphere Namespace and Kubernetes Boundary
Namespaces are useful workload and service-consumption boundaries, especially for Kubernetes-oriented services. A namespace can exist inside a tenant design, but it should not be treated as the complete tenancy model unless identity, policy, quotas, network behavior, logging, backup, and lifecycle responsibilities are also defined.
Assumptions Behind the Model
This article assumes the environment is using VMware Cloud Foundation 9.1 as the target platform baseline and that VCF Automation is part of the consumption model. It also assumes the platform team has a supported identity integration, a deliberate IP addressing and routing plan, adequate capacity, and named owners for operations, networking, security, automation, and recovery.
The model also assumes that consumers receive delegated access through supported VCF and NSX constructs rather than direct administrative access to shared management components.
The image includes capabilities such as backup, recovery, load balancing, databases, security, and catalog services. Treat these as service categories, not a universal base-license promise. Availability can depend on the deployed VCF components, enabled services, add-ons, integrations, support matrix, and licensing. Specific VCF 9.1 networking functions can also carry add-on requirements. Validate the exact bill of materials and entitlements before turning an architecture concept into a service catalog.
Decision Criteria for Tenant Boundaries
The right tenancy boundary is not determined by organization charts alone. It should be selected using operational criteria.
| Criterion | Question to answer | Design consequence |
|---|---|---|
| Identity | Must administrators, users, or service identities be separated? | Separate role assignments, groups, organizations, or stronger platform boundaries |
| Network isolation | Can workloads communicate by default, or must access be explicitly approved? | VPC design, connectivity policy, firewalling, shared-services routing |
| Lifecycle independence | Do tenants need independent maintenance and upgrade windows? | Separate domains, clusters, instances, or fleets may be justified |
| Blast radius | What failures or operator mistakes may affect multiple tenants? | Stronger separation and fewer shared dependencies |
| Regulatory scope | Must evidence, data, or administration remain isolated? | Dedicated control, logging, encryption, or platform boundaries |
| Resource governance | Who owns quotas, reservations, placement, and capacity growth? | Project, zone, quota, and chargeback model |
| Recovery | Do tenants have different recovery time and recovery point objectives? | Separate protection policies, recovery workflows, and testing schedules |
| Autonomy | Which Day-2 changes can consumers perform safely? | Catalog design, approvals, RBAC, and automation policy |
| Economics | Is shared capacity acceptable, and can consumption be attributed? | Metering, tagging, showback, chargeback, and reclamation |
These criteria often produce several tenant archetypes rather than one universal model. A development tenant may share more infrastructure and receive broader self-service. A regulated tenant may require stronger administrative separation, narrower catalogs, dedicated recovery controls, and independent change windows.
The Shared Platform Core
The shared platform is the sun in the image, but it should not become an all-powerful monolith. Each central capability needs a named service owner, a defined scope, a recovery plan, and a clear consumer contract.
VCF Automation as the Consumption Layer
VCF Automation is where provider-defined infrastructure becomes a consumable service. It can organize access, expose catalogs, apply placement and policy, delegate approved actions, and support repeatable provisioning. This is the launchpad in the image.
A strong service catalog does more than present icons. Each item should define:
- Who may request it.
- Which organization or project receives it.
- Which zones, VPCs, images, and policies are eligible.
- What quotas and lease rules apply.
- Which approvals are required.
- Which Day-2 actions are delegated.
- What protection, monitoring, and ownership metadata are attached.
- What successful deployment and handoff look like.
- How the resource is reclaimed or retired.
Self-service without those controls is simply faster sprawl.
VCF Operations as the Provider Control Room
VCF Operations provides the shared operating view needed to manage a platform that spans multiple tenants and infrastructure scopes. The practical objective is not to give every tenant the same dashboard. It is to provide role-appropriate visibility while preserving a provider view of capacity, health, risk, service quality, and lifecycle.
Provider dashboards should answer questions such as:
- Which tenant services are degraded?
- Is the issue inside a workload, VPC, domain, instance, or shared platform service?
- Which capacity pool or quota is approaching exhaustion?
- Are policy violations or configuration drift increasing?
- Which tenant is affected by a planned change?
- Is the problem a workload failure, a control-plane failure, or a shared dependency failure?
Tenant-facing visibility should be scoped to the services and resources the tenant owns. Shared visibility without proper scoping can expose data, topology, or operational details across tenant boundaries.
Identity and Policy as the Gravitational Rules
Identity determines who can enter a tenant world. Policy determines what they can do once they arrive.
The provider should define a role model for platform administrators, organization administrators, project owners, catalog consumers, network administrators, security operators, auditors, and automation identities. Human and non-human identities should follow the same least-privilege principles, with clear ownership, credential rotation, auditability, and revocation.
Multi-factor authentication is commonly enforced through the integrated identity provider rather than assumed from the infrastructure platform alone. The architecture should document where authentication occurs, where authorization is evaluated, which groups drive access, and how emergency access is controlled.
NSX VPCs as Tenant Network Worlds
NSX VPCs provide the clearest visual connection to the planets in the image. Each VPC can offer a tenant-oriented network abstraction with subnets, addressing, routing, NAT, and relevant network services while the provider retains control of the underlying fabric and external connectivity.
VCF 9.1 expands the network services available to VPC consumers and introduces additional ways to control connectivity. That does not remove the need for architecture decisions. The provider must still define:
- How IP space is allocated and prevented from overlapping.
- Which VPCs may reach shared services.
- Which north-south paths are allowed.
- Whether inter-VPC traffic is open, grouped, isolated, or firewall controlled.
- Where NAT, VPN, load balancing, and inspection are implemented.
- Who owns DNS, certificates, public addressing, and route advertisement.
- How network telemetry is retained and exposed.
- Which functions require additional services or licensing.
The VPC should simplify the consumer experience, not hide unresolved provider responsibilities.
vSphere and vSAN as the Shared Substrate
Tenant autonomy still depends on provider-managed compute and storage. The platform team owns cluster design, hardware compatibility, lifecycle, capacity headroom, failure-domain placement, storage policy, encryption posture, and remediation.
Consumers should request service outcomes such as a protected production VM, a Kubernetes cluster, or a database service. They should not need to select physical hosts, datastore internals, or low-level network constructs unless the service contract explicitly requires that level of control.
A Tenant Is a Multidimensional Contract
A production tenant boundary should be documented as a contract across several control planes.
| Control dimension | Provider responsibility | Tenant responsibility |
|---|---|---|
| Identity | Integrate identity sources, define roles, audit privileged access | Maintain correct group membership and application identities |
| Compute and placement | Define zones, clusters, capacity pools, quotas, and placement guardrails | Select approved service classes and manage workload demand |
| Network | Operate NSX fabric, external connectivity, IP pools, shared services | Manage delegated VPC networks and approved security controls |
| Storage and data | Provide storage policies, encryption, capacity, and platform protection | Classify data and select the correct service policy |
| Catalog and automation | Publish tested services, workflows, approvals, and Day-2 actions | Use supported patterns and maintain application configuration |
| Observability | Operate platform telemetry, alerts, retention, and escalation | Own workload-level health, application logs, and response |
| Recovery | Provide supported backup and recovery services and test the platform | Define workload recovery requirements and validate application recovery |
| Cost and lifecycle | Meter usage, enforce quotas, reclaim resources, report consumption | Own budget, tagging quality, renewal, and decommission decisions |
This is why the phrase “one VPC per tenant” is incomplete. It answers part of the network question and leaves the rest of the operating model undefined.
The Tenant Launch Flow
The strongest part of the image is the automation launchpad because it shows tenancy as a repeatable lifecycle rather than a one-time network configuration.
What the reader should notice in the next diagram is that provisioning starts with identity and policy, not with a VM. Protection and telemetry are attached before handoff, not added after the workload becomes important.
A mature implementation makes each transition observable. Failed policy checks should produce an actionable explanation. Provisioning should be idempotent where practical. Ownership metadata should be mandatory. The handoff should state who supports the platform, who supports the guest or application, and how incidents are escalated.
Shared Services Need Explicit Connectivity
The orbital paths in the image imply that tenant worlds can consume shared services such as identity, DNS, logging, backup, artifact repositories, databases, or security tools. That can improve economics and consistency, but shared services are also cross-tenant dependencies.
Do not create a single unrestricted shared-services network and connect every tenant to it. Instead, define each dependency as a service path:
- Named producer and owner.
- Approved consumers.
- Required ports and protocols.
- Authentication method.
- Data classification.
- Availability objective.
- Logging and audit requirements.
- Failure behavior.
- Recovery and change process.
A shared DNS service and a shared database service should not inherit the same connectivity policy merely because both are centralized. The sensitivity, trust model, state, and recovery consequences are different.
Isolation Must Match the Risk
There is no single multitenancy pattern that fits every enterprise.
Shared Fleet and Shared Workload Infrastructure
This model offers the lowest operational overhead and highest utilization. It fits internal teams with a common governance boundary, compatible maintenance windows, and moderate isolation requirements. Organizations, projects, VPCs, namespaces, quotas, policies, and catalog controls carry most of the tenancy design.
The tradeoff is greater shared dependency. Fleet-service changes, provider mistakes, capacity pressure, and common infrastructure incidents may affect multiple tenants.
Shared Fleet with Stronger Domain Separation
This model keeps fleet services centralized while using workload domains, clusters, or other infrastructure boundaries to separate regulated, high-risk, or operationally distinct tenants. It improves lifecycle and blast-radius control without duplicating the full fleet layer.
The tradeoff is additional capacity fragmentation, lifecycle coordination, and provider complexity.
Multiple Fleets or Separate Private-Cloud Programs
This model is appropriate when identity, regulatory, administrative, regional, or business separation is too strong for a shared fleet. It can reduce shared control-plane blast radius and support independent change calendars.
The tradeoff is duplicated management services, higher staffing and lifecycle overhead, more complex cross-fleet governance, and reduced resource pooling. A separate fleet should be a risk and operating-model decision, not a reaction to weak project or VPC design.
Operating Model and Ownership
The platform will not operate cleanly if every team assumes someone else owns the shared core.
| Role | Primary accountability |
|---|---|
| VCF platform owner | Fleet services, platform standards, capacity model, lifecycle, and service reliability |
| Automation owner | Organizations, projects, catalogs, blueprints, approvals, entitlements, and Day-2 actions |
| NSX and network owner | VPC provider design, IPAM, routing, gateways, connectivity, and network troubleshooting |
| Identity and security owner | Identity integration, role governance, privileged access, audit, and compliance controls |
| Observability owner | Telemetry standards, retention, dashboards, alert routing, and service-level evidence |
| Protection owner | Backup, recovery, replication, restore testing, and cyber-recovery integration |
| Tenant owner | Workload lifecycle, application health, consumption, data classification, and budget |
| Service owner | End-to-end reliability and support for each catalog service |
The clean ownership sentence is:
The platform team owns the shared foundation. Automation owns consumption. Network and security teams own the boundaries. Operations owns signal quality and response. Tenants own their workloads and demand.
That sentence should appear in the operating model, not only in an architecture presentation.
Resilience and Blast Radius
A shared platform creates efficiency by centralizing services. It also creates shared dependencies.
A failure in VCF Automation may prevent new requests or Day-2 actions while existing workloads continue running. A failure in a shared identity dependency may block administrative access without immediately stopping applications. A VCF Operations outage may reduce visibility and coordinated lifecycle workflows while workload data paths remain available. A shared network, DNS, IPAM, backup, or certificate dependency can create a much broader impact if it is not designed and tested as a platform service.
The provider should document failure behavior at four levels:
- Shared fleet service failure.
- VCF instance or management-domain failure.
- Workload-domain or cluster failure.
- Tenant-specific workload or VPC failure.
For each level, define detection, affected consumers, degraded functions, escalation, recovery sequence, and evidence that the recovery process has been tested. The solar-system model is only credible when the center can fail gracefully and the tenants know what that failure means.
Common Multitenancy Anti-Patterns
Treating the VPC as the Entire Tenant
This leaves identity, quotas, catalogs, placement, data protection, monitoring, and lifecycle ownership undefined.
Giving Consumers Direct Access to Shared Control Planes
Delegation should occur through supported organization, project, VPC, namespace, catalog, and role constructs. Shared administrator access weakens separation and increases the chance of cross-tenant impact.
Creating a Catalog Without a Service Contract
An icon that deploys a VM is not a private-cloud service. The catalog item needs policy, ownership, support, protection, validation, expiration, and Day-2 behavior.
Centralizing Services Without Designing Their Failure Domains
Shared services reduce duplication, but they also concentrate dependency. Availability and recovery must match the number and criticality of the tenants that depend on them.
Using One Tenant Model for Every Consumer
Development, production, regulated, AI, data, and acquired-business environments often require different autonomy, isolation, and recovery profiles. Standardize archetypes, not exceptions.
Measuring Infrastructure but Not Tenant Experience
Host and cluster health are necessary but insufficient. The provider must know whether tenants can request services, resolve names, reach approved dependencies, complete Day-2 actions, and recover workloads.
Ignoring Entitlement and Add-On Boundaries
Architecture diagrams often show every possible platform service as if it is universally available. Verify licensing, enabled components, add-ons, support, and version compatibility before publishing a catalog commitment.
A Practical Adoption Sequence
The safest path is to build the multitenant operating model before scaling the number of tenants.
Define Tenant Archetypes
Document common tenant profiles such as developer, production, regulated, data, AI, and acquired-business tenants. For each archetype, define identity, isolation, catalog, quota, connectivity, protection, observability, and recovery expectations.
Build the Provider Baseline
Standardize naming, tags, identity groups, IP allocation, VPC patterns, placement zones, images, storage policies, catalog templates, logging, backup, and lifecycle ownership. The provider baseline should be testable and version controlled.
Pilot a Low-Risk Tenant
Use a tenant that is representative enough to expose integration problems but not so critical that every issue becomes an emergency. Validate provisioning, access, policy rejection, Day-2 actions, monitoring, backup, restore, cost reporting, and decommissioning.
Prove Shared-Service Paths
Test DNS, identity, logging, repositories, backup, databases, and other shared dependencies as explicit service paths. Confirm that one tenant cannot discover or reach another tenant through a shared-service shortcut.
Test Failure and Recovery
Disable or isolate selected control-plane and shared-service dependencies in a controlled exercise. Confirm what continues running, what becomes unavailable, how alerts are routed, and how the provider communicates impact.
Scale Through Templates, Not Manual Exceptions
Promote successful patterns into reusable organization, project, VPC, catalog, policy, and operational templates. Require architecture review when a tenant cannot fit a standard archetype. Do not let one-off exceptions silently become the platform.
When to Build Another Solar System
A single shared VCF platform is not always the right answer.
Consider a separate fleet, instance strategy, or private-cloud program when tenants require independent identity administration, incompatible maintenance schedules, strong regulatory separation, different regional control, materially different lifecycle cadence, dedicated operational teams, or a blast radius that cannot be accepted at shared fleet scope.
The decision should compare the cost of duplicated platform services with the cost of shared risk. If the organization cannot clearly state which shared failures are acceptable, it is not ready to decide that every tenant belongs under one platform core.
Conclusion
The VCF 9.1 multitenant solar system is a strong mental model because it shows the correct relationship between centralized platform capability and delegated tenant autonomy. The platform core provides operations, automation, identity, compute, storage, networking, policy, and selected shared services. Tenant worlds consume those capabilities through defined administrative, resource, network, and service boundaries.
The model becomes dangerous when the planet is reduced to an NSX VPC or when the central sun is treated as a feature bundle with no ownership or failure analysis. A production tenant is a multidimensional contract. It includes identity, placement, quota, network, data, protection, observability, cost, lifecycle, and support.
The practical goal is not maximum centralization or maximum separation. It is controlled autonomy. Keep shared services at the center when that improves consistency and economics. Push decisions to tenant teams when they can act safely inside enforceable guardrails. Build another fleet or platform boundary when the risk, identity, recovery, or change model cannot tolerate shared dependency.
That is how one VCF 9.1 foundation can support many tenant worlds without turning the private cloud into either a ticket queue or an uncontrolled universe.
External References
- Broadcom TechDocs: VMware Cloud Foundation 9.1 Release Notes
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes.html - Broadcom TechDocs: What Is VMware Cloud Foundation?
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/overview-of-vmware-cloud-foundation-9/what-is-vmware-cloud-foundation-and-vmware-vsphere-foundation.html - Broadcom TechDocs: Managing Organizations in VMware Cloud Foundation Automation
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/managing-organizations-for-all-apps-in-vcf-automation.html - Broadcom TechDocs: Create a VCF Automation Organization for All Applications
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/provider-management/managing-organizations/create-an-organization.html - Broadcom TechDocs: Create a Connectivity Profile in VCF Automation
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/adding-and-managing-virtual-private-clouds/create-a-connectivity-profile.html - VMware Cloud Foundation Blog: Accelerate, Streamline, and Control Your Self-Service Private Cloud with VMware Cloud Foundation 9.1
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/accelerate-streamline-and-control-your-self-service-private-cloud-with-vcf-9-1/ - VMware Cloud Foundation Blog: VMware Virtual Private Cloud in VMware Cloud Foundation 9.0: A New Era of Private Cloud Networking
Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/07/02/vmware-virtual-private-cloud/ - VMware Cloud Foundation Blog: VCF 9.1 Networking: Exploring Network Services for Virtual Private Clouds
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/15/vcf-networking-9-1-exploring-network-services-for-virtual-private-clouds/ - VMware Cloud Foundation Blog: VCF 9.1 Networking: Simpler VPC Connectivity Control
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/15/vcf-networking-9-1-simpler-vpc-connectivity-control/
TL;DR The image presents VMware Cloud Foundation 9.1 as a massive engine that accepts business requirements and produces governed digital worlds. That...