TL;DR
The VCF Tenant Space Station is a useful mental model for VMware Cloud Foundation 9.1 because it separates shared platform services from tenant consumption boundaries. The central station represents the provider-owned foundation, while each habitat represents an organization, project, network boundary, and service entitlement model built on shared infrastructure. The key design lesson is that VCF multi-tenancy is not one feature or one object. It is a coordinated architecture across identity, VCF Automation, NSX, resource policy, service catalogs, VCF Operations, lifecycle ownership, and external connectivity.
Introduction
Private cloud becomes difficult at the moment it stops serving one infrastructure team and starts serving many independent consumers.
Those consumers may be application teams, business units, subsidiaries, development groups, regulated environments, partners, or external customers. They want fast access to virtual machines, Kubernetes clusters, networking, data services, recovery capabilities, and increasingly AI services. The platform team still has to protect capacity, enforce security, maintain lifecycle consistency, preserve auditability, and prevent one tenant from creating problems for everyone else.
That tension is what the VCF Tenant Space Station image captures well.
The station has one foundation and one command core, but it supports multiple tenant habitats. Each habitat consumes services from the same platform while maintaining its own access, network, resource, and operational boundaries. The metaphor is strong because it shows the real architectural goal: centralize the machinery that benefits from standardization, then decentralize consumption inside explicit guardrails.
VMware Cloud Foundation 9.1 provides many of the building blocks for that model through VCF Automation, VCF Operations, NSX, vSphere, vSAN, and Kubernetes services. The platform does not remove the need for tenancy design. It gives architects a more unified place to implement it.
Why the Space Station Metaphor Works
A multi-tenant private cloud is not simply a large cluster with several folders. It is a provider-consumer system.
The provider owns the station itself. That includes platform lifecycle, identity integration, shared infrastructure, network control, service definitions, monitoring, capacity, cost policy, compliance evidence, and incident response. Tenants consume approved services without needing administrative access to the full platform.
The habitats represent bounded consumption environments. A habitat may map to a business unit, customer, application portfolio, environment tier, or regulated workload group. It can have its own users, projects, quotas, catalog entitlements, network boundaries, policies, and usage reporting while still sharing the underlying private cloud.
The important point is not the science-fiction appearance. It is the separation of responsibilities.
The following diagram translates the image into a practical VCF mental model.
What to notice is the direction of control. Tenants consume downward through approved service interfaces. Provider policy, observability, and lifecycle management operate across the platform. The shared foundation does not mean every tenant has equal visibility or control over the underlying infrastructure.
Scope and Terminology Guardrails
The station metaphor is a mental model, not a literal VCF topology diagram. Several terms need to remain precise or the design quickly becomes misleading.
TermPractical meaning in this articleWhat it does not automatically meanTenantAn independently governed consumer boundaryDedicated hardware or a dedicated VCF instanceOrganizationA high-level consumption and administration boundary in VCF AutomationComplete physical isolationProjectA narrower team, application, or environment scope with policy and resource controlsA complete security boundary by itselfNSX VPCA software-defined network boundary for tenant connectivity and policyAutomatic end-to-end zero trustWorkload domainA VCF infrastructure, lifecycle, and often control-plane boundaryA one-to-one mapping with a tenantService catalogA controlled interface for requesting approved servicesProof that every published service is operationally matureShared foundationCommon compute, storage, networking, and management capacityUnrestricted lateral access or shared administrationZero trustA security architecture based on explicit verification and least privilegeA product checkbox or default outcome
A tenant can exist entirely within shared infrastructure. Conversely, a regulated tenant may require dedicated clusters, workload domains, edge capacity, or even a separate VCF instance. The correct boundary depends on risk, lifecycle autonomy, performance isolation, and operating-model requirements.
Assumptions Behind the Model
This article uses VMware Cloud Foundation 9.1 as the version baseline and assumes that VCF Automation and VCF Operations are part of the target operating model.
It also assumes that:
NSX provides the primary software-defined networking and security control layer.
Platform teams own the provider control plane and tenant teams consume services through delegated interfaces.
Organizations and projects are used deliberately rather than as interchangeable folders.
Resource limits, catalog entitlements, identity roles, network policies, and cost attribution are defined before broad onboarding.
Shared infrastructure is acceptable unless a documented isolation requirement justifies dedicated capacity.
Database, backup, disaster recovery, observability, and AI services may require additional products, integrations, entitlements, or service-owner processes.
High availability and resilience depend on topology, capacity reserve, failure-domain design, and tested recovery procedures. They are not guaranteed by the word platform.
These assumptions matter because the image presents an idealized result. The architecture work lives in the controls that make that result credible.
The Foundation Core Is Shared Infrastructure With Provider Ownership
The left side of the image lists the VCF foundation core: compute, storage, networking, operations, automation, identity, recovery, and lifecycle management.
That is the right starting point, but a multi-tenant design needs a clear distinction between shared capability and delegated control.
Tenants should not need direct administrative access to vCenter, NSX Manager, storage administration, fleet lifecycle, or the management domain to consume a standard service. The platform team should expose service outcomes, not internal machinery.
A useful ownership model looks like this:
Platform layerProvider responsibilityTenant experiencePrimary controlComputeCluster health, placement strategy, reserve capacity, lifecycleRequest approved VM or Kubernetes capacityQuotas, policies, placement constraintsStorageCapacity, performance tiers, encryption, protection policySelect an approved storage class or profileStorage policies and service entitlementsNetworkingVPC design, routing, edge services, firewall framework, IPAMConsume approved networks and connectivityNSX VPCs, subnets, gateways, distributed policyIdentityFederation, privileged access, role design, service identitiesAccess only assigned organizations and projectsRole-based access and identity mappingsAutomationCatalog design, approvals, templates, leases, workflowsRequest repeatable servicesPolicy, entitlement, workflow, version controlOperationsMonitoring, capacity, cost, compliance, incident responseView tenant-relevant health and usageScoped dashboards, alerts, reporting, ownershipLifecyclePlatform upgrades, compatibility, certificates, component healthReceive stable service with published maintenance expectationsChange control, validation, rollback planning
The provider team still needs deep infrastructure access. The tenant should usually see a smaller and more stable interface. That separation reduces accidental coupling between application delivery and infrastructure administration.
A Tenant Habitat Is a Stack of Boundaries
One of the most common design mistakes is treating a single object as the tenant boundary.
A project is not enough. A resource pool is not enough. A VPC is not enough. A role assignment is not enough.
A credible tenant habitat is formed when several boundaries align:
The design fails when one layer is weaker than the others. A tenant may have an isolated VPC but still inherit overly broad administrative permissions. A project may have strict quotas but publish a catalog item that can connect to a shared management network. A regulated workload may have dedicated compute but send logs into an operational system where tenant scoping is not defined.
Multi-tenancy is therefore a consistency problem. Identity, resource, network, service, and operational scopes must tell the same story.
Identity Boundary
Decide whether tenants use a shared enterprise identity provider, separate identity providers, or a hybrid model. Internal business units often fit a shared identity model. Partner, customer, or regulated tenants may need stronger identity separation.
Define human users, groups, service accounts, API clients, privileged roles, access-review cadence, and break-glass procedures. Tenant administrators should not inherit provider-level authority simply because they need to manage their own projects.
Organization and Project Boundary
Use organizations for durable administrative and consumption separation. Use projects for narrower scopes such as application teams, product groups, development environments, or workload portfolios.
The hierarchy should reflect the operating model. Do not create one organization per temporary project if that produces catalog, identity, and reporting sprawl. Do not put unrelated business units into one organization merely because they share the same hardware.
Resource Boundary
Quotas, limits, reservations, placement rules, and service entitlements protect the shared foundation. They also create the basis for capacity planning and financial accountability.
A quota should answer more than how much a tenant can deploy. It should also define what happens when capacity is exhausted, who can request an increase, how temporary capacity is reclaimed, and whether burst behavior is allowed.
NSX Is the Traffic Control Layer
The image labels NSX as traffic control, and that is a practical way to think about its role.
In a shared private cloud, network isolation must be designed at several levels:
Tenant VPC and subnet boundaries
East-west microsegmentation between workloads
North-south routing and firewall policy
Provider management-plane separation
Shared service access
Internet and partner egress
Load balancing and published application access
DNS, IP address management, and certificate dependencies
Logging, flow visibility, and security evidence
The NSX design should make tenant intent visible. A network engineer should be able to identify which tenant owns a VPC, which projects may use it, which services it can reach, where inspection occurs, who owns firewall changes, and how traffic is logged.
Zero trust language should be used carefully. Microsegmentation, identity-aware access, least privilege, continuous telemetry, and explicit policy can support zero trust principles. None of those outcomes happen automatically because NSX is present. The operational process still needs policy ownership, exception handling, validation, and review.
Shared Edge or Dedicated Edge
A shared edge design can reduce cost and simplify operations, but it increases the importance of routing, NAT, firewall, load-balancer, and capacity controls. A dedicated edge design can strengthen separation and lifecycle autonomy, but it consumes more resources and adds operational overhead.
The decision should be driven by failure isolation, compliance, performance, address overlap, routing autonomy, and change ownership. It should not be driven by a desire to make the diagram look cleaner.
The Service Catalog Is the Interface, Not the Infrastructure
The service catalog sits at the bottom center of the image because it is the consumer-facing interface to the station.
A mature catalog can expose virtual machines, Kubernetes environments, networks, security policies, databases, observability, automation workflows, recovery services, and AI capabilities. The catalog should hide unnecessary implementation detail while preserving the controls needed for production operations.
Every catalog item should answer six questions:
Service questionRequired answerWhat is being delivered?A defined service outcome, not a vague infrastructure objectWho owns it?A named platform or service teamWho can request it?An explicit organization, project, role, or approval pathWhat guardrails apply?Quotas, policies, placement, network, security, and lifecycle controlsHow is success validated?Deployment checks, health signals, ownership transfer, and evidenceHow is it retired?Lease, reclamation, decommissioning, backup, data handling, and cost closure
A catalog item without an owner and a lifecycle is not a service. It is an automated support ticket waiting to happen.
The image includes databases, disaster recovery, and AI services. Those are valid private-cloud service targets, but they should not be presented as universally built-in outcomes. Each one needs its own dependency model, support boundary, security posture, availability target, capacity plan, and operational runbook.
The Command Core Is an Operating Model
The center of the station is the VCF command core. This is where the metaphor becomes especially useful.
The command core does not mean that one administrator controls everything. It means the platform has shared governance and operational services that coordinate the environment.
VCF Automation provides the consumption and automation layer. VCF Operations provides health, capacity, cost, compliance, and operational visibility. Identity services govern who can access which scope. NSX and vSphere enforce workload and infrastructure controls. Lifecycle processes keep the platform supportable.
Those capabilities need explicit ownership.
CapabilityAccountable ownerOperational responsibilityTenant onboardingPlatform product ownerIdentity mapping, organization creation, projects, quotas, catalog entitlementsNetwork onboardingNetwork platform ownerVPC, routing, firewall, shared services, external connectivityService publishingService ownerTemplate quality, dependencies, approvals, versioning, validationCapacityInfrastructure and FinOps ownersForecasting, reserve policy, expansion trigger, tenant communicationSecuritySecurity architecture and operationsControl objectives, policy review, evidence, exceptions, incident supportLifecycleVCF platform ownerCompatibility, patching, upgrades, certificates, rollbackTenant supportService desk and platform operationsTriage, escalation, ownership transfer, service-level reporting
The platform should be run like a product. That means a roadmap, service definitions, published constraints, measurable outcomes, and a feedback loop from tenant experience into platform improvement.
Orbital Operations Keep the Platform Sustainable
The image’s orbital operations panel includes health monitoring, capacity planning, cost optimization, compliance, automation workflows, and tenant lifecycle. Those are not secondary features. They are what keep multi-tenancy from turning into shared-platform chaos.
Health and Observability
Provider teams need fleet, instance, domain, cluster, network, service, and tenant-aware views. Tenants need enough visibility to understand the health of their services without exposing another tenant’s data or the provider’s privileged operational context.
Alert ownership should be explicit. A platform alert, tenant workload alert, and shared-service alert may involve different teams even when they appear in the same operations platform.
Capacity and Reserve
Raw cluster capacity is not sellable or assignable capacity.
A credible capacity model subtracts maintenance reserve, failure reserve, growth buffer, operational overhead, storage protection, network headroom, and any disaster-recovery commitments. Tenant quotas should be based on this usable capacity model, not on the total hardware installed.
Noisy-neighbor risk also needs multiple controls. CPU and memory are only part of the picture. Storage latency, network throughput, edge capacity, backup windows, Kubernetes control-plane limits, and accelerator scarcity can become the actual bottlenecks.
Cost, Showback, and Chargeback
VCF Operations can support cost and capacity management, including tenant-oriented visibility for organizations and projects. The operating model still has to define the financial rules.
Decide whether the goal is showback, chargeback, budget control, unit economics, or capacity accountability. Define which costs are included, how shared overhead is allocated, how reservations are treated, and how idle resources are reclaimed.
A cost dashboard without a decision process is only reporting. A useful FinOps model changes behavior by connecting usage to ownership, quotas, lifecycle policy, and capacity planning.
Compliance and Evidence
Compliance should be scoped to the tenant and service boundary. The provider needs evidence for platform configuration, privileged access, network policy, vulnerability management, lifecycle status, logging, backup, and recovery testing. Tenants may need their own evidence packages.
A shared platform can simplify control consistency, but it can also broaden the impact of a control failure. Central policy therefore needs strong change management, testing, and exception handling.
External Connectivity Is a Trust Boundary
The station image shows internet, partner networks, on-premises data centers, and cloud regions connected to the platform. Every one of those connections changes the threat model and operating model.
External connectivity should answer:
Which tenant or service owns the connection?
Is the path shared or dedicated?
Where are routing, firewall, inspection, and address translation enforced?
How are overlapping addresses handled?
Which identities or workloads can use the path?
How is availability monitored?
Who approves changes?
What happens when the dependency fails?
What evidence is retained?
Shared external connectivity can be efficient, but it creates common failure and security domains. Dedicated connectivity can strengthen isolation, but it increases cost, routing complexity, and lifecycle obligations.
The architecture should make those tradeoffs explicit before tenants are onboarded.
Choosing the Right Tenancy Pattern
Not every tenant needs the same degree of separation. Use the lightest pattern that satisfies risk, performance, lifecycle, and governance requirements.
Tenancy patternBest fitSeparation levelOperational impactKey warningProjects inside one organizationInternal teams with common identity and governanceLogical project, quota, and entitlement separationLowest overheadWeak fit when teams require separate administration or identitySeparate organizations on shared infrastructureBusiness units, subsidiaries, partners, or customersStronger administrative and consumption separationModerate catalog, identity, and reporting overheadStill requires deliberate network and resource isolationSeparate organizations with dedicated VPC and edge policyTenants needing stronger network autonomyAdministrative plus stronger network separationHigher network and edge complexityShared dependencies may still exist below the network layerDedicated clusters or workload domainsRegulated, performance-sensitive, or lifecycle-sensitive tenantsDedicated capacity and stronger failure isolationHigher cost and lifecycle overheadA workload domain is not automatically a complete tenant operating modelSeparate VCF instance or private cloud boundaryStrict sovereignty, independent lifecycle, or major blast-radius requirementsHighest infrastructure and management separationHighest cost, staffing, and integration overheadCentralized fleet services and identity relationships still require careful design
The decision should be documented as an architecture decision, including the requirement, selected pattern, alternatives, tradeoffs, owner, and review trigger.
An Implementation Sequence That Scales
A strong multi-tenant platform is built in layers. Starting with a large service catalog usually creates more variation than the operating model can support.
Define the Tenant Contract
Document who qualifies as a tenant, which services are available, which responsibilities stay with the provider, which responsibilities transfer to the tenant, and what isolation level is promised.
Include service levels, maintenance expectations, data handling, backup responsibilities, recovery objectives, support paths, cost policy, and exit procedures.
Build the Isolation Matrix
Map each tenant type across identity, organization, project, VPC, compute, storage, catalog, operations, cost, compliance, and recovery boundaries.
Do not accept a vague statement such as isolated by NSX. Record the actual enforcement object, owner, validation method, and exception process.
Establish the Provider Foundation
Deploy and integrate the management, automation, operations, identity, network, and lifecycle capabilities before broad self-service begins.
Validate management-plane separation, privileged access, certificate lifecycle, logging, backup, restore, upgrade sequencing, and capacity reserve.
Publish a Small Catalog
Start with a few production-ready services that have clear owners and repeatable validation. A standard VM, a Kubernetes environment, and a controlled network pattern are more valuable than twenty catalog items with unclear support.
Version service definitions and test upgrades. The catalog is part of the platform’s API to its consumers, so uncontrolled changes create downstream risk.
Instrument Operations and Cost
Create scoped dashboards, alerts, capacity views, usage reporting, and cost attribution before onboarding many tenants. Define who responds to each signal and which thresholds trigger expansion, reclamation, or escalation.
Pilot With Different Tenant Types
Use at least one cooperative internal tenant and one tenant with stricter requirements. The second tenant exposes assumptions that the first tenant may never challenge.
Test onboarding, access review, deployment, network policy, incident response, quota exhaustion, backup, restore, offboarding, and evidence collection.
Scale Through Automation and Governance
Automate repeatable onboarding and lifecycle tasks only after the design is stable. Keep approvals and exception handling visible. Use version-controlled templates and policy where possible, but retain clear human ownership for risk decisions.
Failure Modes That Break the Station
Several anti-patterns appear repeatedly in multi-tenant private cloud programs.
Treating a Project as the Entire Tenant Boundary
Projects are useful, but they do not replace identity design, VPC policy, compute isolation, catalog governance, operational scoping, or cost ownership.
Publishing Infrastructure Instead of Services
Giving tenants low-level access to raw platform constructs may feel flexible, but it transfers complexity without transferring the skills or accountability required to manage it.
Building the Catalog Before the Operating Model
Automation can make a weak process fail faster. Each service needs ownership, validation, support, lifecycle, security, and retirement before it is published broadly.
Assuming Shared Means Cheap
Shared platforms can improve utilization, but the management, security, edge, monitoring, backup, and support layers still consume capacity and labor. Strong tenancy often increases control-plane and operational costs before it produces efficiency.
Delaying Cost and Capacity Governance
Once tenants become accustomed to unlimited or unpriced consumption, introducing quotas and reclamation later becomes an organizational conflict rather than a technical change.
Calling the Platform Resilient Without Testing Failure
Resilience depends on failure domains, reserve capacity, dependency behavior, backup integrity, recovery procedures, and exercised runbooks. A green dashboard is not a recovery test.
A Practical Design Review Checklist
Before approving the design, the architecture team should be able to answer the following questions clearly:
What exactly is a tenant in this environment?
Which VCF Automation organization and project pattern represents each tenant type?
Which identity provider, groups, roles, API clients, and privileged paths apply?
Which NSX VPC, subnet, routing, firewall, load-balancing, and egress patterns apply?
Which compute, storage, edge, Kubernetes, and accelerator resources are shared or dedicated?
Which catalog services are supported, versioned, monitored, backed up, and recoverable?
Which quotas, leases, approvals, and reclamation policies apply?
How are health, cost, capacity, and compliance scoped to tenants?
Who owns provider incidents, tenant incidents, and shared-service incidents?
How is tenant offboarding performed, including data retention and access revocation?
Which requirements would force a move to dedicated clusters, workload domains, or a separate instance?
Which evidence proves the promised isolation and recovery behavior?
If the answers exist only in different teams’ heads, the station is not ready for additional habitats.
Conclusion
The VCF Tenant Space Station is more than a creative image. It is a useful way to explain the difference between a shared private cloud foundation and a governed multi-tenant operating model.
The central command core represents the capabilities that benefit from consistency: automation, operations, identity, lifecycle, security policy, capacity, and cost governance. The tenant habitats represent bounded consumption environments built from aligned organization, project, resource, network, service, and operational controls.
VMware Cloud Foundation 9.1 provides the platform constructs needed to build this model, but the quality of the result depends on architecture discipline. Organizations and projects do not replace network isolation. NSX does not replace identity governance. A catalog does not replace service ownership. VCF Operations does not replace capacity and financial decisions. Shared infrastructure does not remove the need for tested failure and recovery boundaries.
The practical path is to define the tenant contract first, choose the required separation pattern, align every control layer, publish a small set of supportable services, instrument operations and cost, then scale through automation. That is how one foundation can support many tenants without turning the private cloud into an uncontrolled collection of shared resources.
External References
Broadcom TechDocs: VMware Cloud Foundation 9.1Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
VMware: VMware Cloud Foundation AutomationCanonical URL: https://www.vmware.com/products/cloud-infrastructure/vcf-automation
Broadcom TechDocs: VCF Automation ModelsCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/vmware-cloud-foundation-concepts/vcf-automation-deployment-models.html
Broadcom TechDocs: Multi-Tenancy Consumption PatternsCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/vcf-automation-deployment-models-9-x/multi-tenancy-design-patterns.html
Broadcom TechDocs: Working with Micro-SegmentationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/infrastructure-operations/network-operationss/micro-segmentation.html
Broadcom TechDocs: Cost and Capacity ManagementCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/cost-and-capacity-management.html
Broadcom TechDocs: View Chargeback Summary, Organizations, and ProjectsCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/cost-and-capacity-management/performing-vcd-based-multitenancy-operations/viewing-vmware-chargeback-summary.html
VMware Cloud Foundation Blog: Analyst Insight Series #3: Policy-Driven Governance and Multi-Tenant ControlCanonical URL: https://blogs.vmware.com/cloud-foundation/2026/04/28/analyst-insight-series-3-policy-driven-governance-and-multi-tenant-control/
National Institute of Standards and Technology: SP 800-207, Zero Trust ArchitectureCanonical URL: https://csrc.nist.gov/pubs/sp/800/207/final
The Microsoft and VMware Architecture Forge: Building a Custom Hybrid Platform That Operates as One
TL;DR A Microsoft and VMware hybrid platform should not be designed as a loose collection of products or as an attempt to…
The post VCF Tenant Space Station: Designing a Multi-Tenant Private Cloud on One Foundation appeared first on Digital Thought Disruption.