TL;DR
The city shown in the image is a useful mental model for VMware Cloud Foundation multi-tenancy, but it should not be mistaken for a literal reference architecture. A tenant neighborhood is not simply a VLAN, resource pool, folder, or colored segment. It is a coordinated bundle of identity boundaries, resource entitlements, network controls, security policies, storage policies, service catalogs, observability, lifecycle ownership, and cost accountability.
VCF provides the layers needed to build these neighborhoods, including VCF Automation, VCF Operations, NSX, vSphere, vSAN, and supported external infrastructure. The architecture succeeds only when those products are connected through an explicit provider and tenant operating model.
Introduction
The supplied image presents VMware Cloud Foundation as a futuristic enterprise city. Finance, healthcare, retail, manufacturing, and research operate in separate neighborhoods. NSX acts as the transportation and security system, vSphere and storage provide the resource grid, VCF Automation and VCF Operations run the city, and the physical infrastructure supports everything beneath it.
That metaphor is valuable because it shifts the discussion away from individual products. VMware Cloud Foundation is not merely a collection of virtualization, networking, storage, automation, and monitoring tools. It is a platform operating model that coordinates those capabilities around repeatable infrastructure services.
The image also creates a risk. A clean visual can make multi-tenancy appear easier than it is. Real tenant isolation is not created by drawing boundaries around workloads. It emerges from coordinated decisions across identity, administration, compute, networking, storage, automation, observability, capacity, security, and lifecycle management.
This article translates the city metaphor into a practical VCF multi-tenancy model. It explains what the image gets right, where the metaphor needs guardrails, and what architects should decide before onboarding the first tenant.
Traditional infrastructure diagrams tend to organize components by product. vSphere sits in one box, NSX sits in another, storage appears beneath them, and an operations platform is placed somewhere to the side.
That view is useful for installation planning, but it does not explain how the platform is consumed.
The city metaphor starts from the opposite direction. It begins with the consumers:
- Finance needs controlled access to regulated applications and data.
- Healthcare needs strict privacy, auditability, and segmentation.
- Retail may prioritize elasticity, seasonal capacity, and application availability.
- Manufacturing may require low latency, predictable operations, and isolated operational technology integrations.
- Research and development may need faster provisioning, temporary environments, and broader experimentation rights.
These groups may share the same physical estate without sharing the same administrative permissions, policies, risk profiles, or service expectations.
That is the central idea behind the image: shared infrastructure does not require shared control.
A successful private cloud allows infrastructure to be pooled where pooling creates efficiency, while preserving separation where identity, security, lifecycle, performance, or regulatory requirements demand it.
Scope and Assumptions
This mental model assumes an enterprise VCF environment serving multiple internal organizations, business units, application teams, or regulated workload groups.
It also assumes:
- VMware Cloud Foundation 9.1 terminology and platform direction.
- A platform team provides standardized infrastructure services.
- Some services and physical capacity may be shared.
- Tenants require different levels of isolation.
- VCF Automation provides controlled service consumption and provisioning.
- VCF Operations provides health, capacity, optimization, and operational visibility.
- NSX supplies network virtualization and distributed security controls.
- vSphere supplies compute virtualization and resource governance.
- Storage may be provided by vSAN or supported external platforms, depending on the design.
- Hardware compatibility, vendor support, and lifecycle integration are validated separately.
This is not a hosting-provider reference architecture. It is an enterprise mental model for designing internal cloud services on a shared VCF platform.
Terminology Guardrails
VCF multi-tenancy discussions become confusing when several different objects are all called a tenant. These terms should not be treated as interchangeable.
| Term | Practical Meaning | What It Does Not Automatically Provide |
|---|---|---|
| Tenant | A consumer boundary defined by business, security, service, and ownership requirements | A specific VCF object |
| Organization | A consumption and governance boundary used to group users, services, policies, and entitlements | Guaranteed physical isolation |
| VCF Automation project | A provisioning scope for users, cloud zones, quotas, templates, and deployment policies | Complete network or administrative isolation by itself |
| NSX project | A delegated networking and security boundary within NSX | Independent physical infrastructure |
| NSX VPC | A tenant-consumable network environment with controlled connectivity and services | Full lifecycle independence from the provider |
| Workload domain | A VCF infrastructure and lifecycle boundary containing platform resources | A one-to-one relationship with a business tenant |
| Cluster | A compute and availability boundary | A complete tenant boundary |
| Resource pool | A compute entitlement and scheduling construct | Security isolation |
| Folder | An inventory and delegated-management construct | Performance, network, or storage isolation |
The word tenant should therefore describe the business and operational boundary. VCF objects are the technical mechanisms used to implement that boundary.
The VCF Stack as a Layered Operating Model
The image organizes VCF into understandable layers. The same layering can be translated into a practical architecture.
The important point is not the product order. It is the dependency direction.
A tenant consumes a service. That service is governed by automation and operations controls. It is implemented through networking, security, compute, and storage policies. Those policies eventually consume physical capacity.
Every promise made at the tenant layer must therefore be supportable by the layers beneath it.
Physical Infrastructure Is the Foundation
The image places Dell servers, switching, and storage at the base of the city. This is more than visual branding. Physical architecture defines the limits of every service exposed above it.
Tenant-facing promises depend on:
- Processor and memory capacity
- Network throughput and oversubscription
- Storage latency and availability
- Failure-domain design
- Hardware compatibility
- Firmware and driver lifecycle
- Rack, power, and cooling resilience
- Replacement and expansion lead times
A self-service catalog may allow a tenant to request a large database cluster in minutes, but automation cannot manufacture physical capacity. Catalog design and capacity planning must operate as one system.
External storage also introduces an important ownership distinction. A storage platform may be fully supported with VCF while retaining its own management, upgrade, monitoring, and support workflows. Architects must not assume that every supported infrastructure component is automatically absorbed into the same lifecycle boundary.
vSphere and Storage Form the Resource Grid
vSphere supplies the compute substrate, placement controls, availability constructs, and resource governance used by tenant workloads. Storage services provide capacity, performance, data protection characteristics, and policy-based placement.
At this layer, tenant separation may include:
- Dedicated or shared clusters
- Resource pools and reservations
- Limits and shares
- Host affinity or anti-affinity rules
- Storage policies
- Datastore or storage-pool placement
- Backup and replication policies
- Encryption requirements
- Availability and recovery objectives
A resource pool can protect capacity, but it does not create a security boundary. A datastore can separate placement, but it does not define application access. Each mechanism solves a particular part of the tenancy problem.
NSX Is More Than the Transportation System
The image calls NSX the transportation system. That is partly correct. NSX supplies routing, gateways, load balancing, and connectivity between workloads and external networks.
Its more important role in a multi-tenant design is policy enforcement.
NSX can provide:
- Tenant-specific network segments
- Distributed firewall enforcement
- Micro-segmentation
- Gateway policy
- North-south connectivity
- NAT
- Load-balancing services
- Controlled egress
- Delegated administration
- NSX Projects
- Tenant-facing VPC constructs
- Logging and security telemetry
Roads explain how traffic moves. They do not explain who is allowed to travel, what can cross a boundary, how an exception is approved, or how suspicious behavior is investigated.
A stronger metaphor is that NSX combines the roads, border controls, traffic rules, inspection points, and zoning enforcement of the cloud city.
VCF Automation Provides the Service-Consumption Plane
VCF Automation translates platform capabilities into repeatable services.
Instead of asking an infrastructure administrator to manually assemble compute, network, storage, and security objects, a tenant can request a governed service through a catalog, API, or approved workflow.
A production service definition may include:
- Approved machine sizes
- Operating-system images
- Network placement
- Security groups
- Storage policies
- Backup classes
- Lease or expiration policies
- Approval requirements
- Naming and tagging standards
- Day-2 actions
- Quotas
- Cost information
- Ownership metadata
The value is not provisioning speed alone. The greater value is reducing architectural variation.
A controlled catalog can make the compliant path easier than an improvised one. Poorly designed self-service does the opposite. It accelerates inconsistency, cost growth, and security drift.
VCF Operations Provides the Operational Control Plane
The city cannot be operated only through deployment workflows. Once services exist, they must be observed, maintained, optimized, and repaired.
VCF Operations supports the platform team by bringing together areas such as:
- Infrastructure health
- Performance analysis
- Capacity planning
- Rightsizing
- Alerting
- Operational dashboards
- Remediation workflows
- Cost and consumption visibility
- Inventory relationships
- Troubleshooting context
Tenant-facing monitoring should not simply expose every underlying metric. The platform team must translate infrastructure telemetry into service-level information.
A tenant generally needs to know whether its service is healthy, constrained, unavailable, or violating an agreed objective. The platform provider still needs deeper visibility into clusters, hosts, storage, networks, gateways, certificates, and dependencies.
These are related views, but they are not the same view.
A Tenant Neighborhood Is a Policy Bundle
The colored districts in the image appear visually separate. In a production environment, those boundaries are created by multiple coordinated policies.
| Design Domain | Tenant Question | Provider Control |
|---|---|---|
| Identity | Who can enter the tenant environment? | Federation, groups, roles, privileged-access controls |
| Administration | What can tenant administrators change? | Delegated roles, organization boundaries, project permissions |
| Compute | How much capacity can the tenant consume? | Quotas, reservations, placement policies, service classes |
| Network | What can communicate with what? | Segments, VPCs, gateways, route controls, egress policy |
| Security | Where is policy enforced? | Distributed firewall, gateway firewall, micro-segmentation |
| Storage | Where is data placed and protected? | Storage policies, encryption, replication, backup classes |
| Automation | What can the tenant request? | Catalog items, templates, approvals, leases, day-2 actions |
| Operations | What can the tenant observe? | Dashboards, alerts, service health, scoped telemetry |
| Cost | Who owns consumption? | Tagging, allocation, showback, chargeback, budget controls |
| Lifecycle | Who patches or changes each layer? | Responsibility model, maintenance windows, compatibility policy |
| Recovery | How is service restored? | Backup, replication, recovery plans, test schedules |
| Compliance | What evidence must be retained? | Logs, policy history, approval records, audit exports |
No single row creates a tenant. The tenant exists when these controls tell a consistent story.
For example, a healthcare organization is not isolated merely because its virtual machines occupy a dedicated segment. Its users, administrators, automation projects, firewall rules, storage placement, encryption, logs, backups, recovery workflows, and operational access must also align with the same boundary.
Choosing the Right Tenancy Pattern
Not every tenant requires the same degree of separation. VCF supports different design patterns, and the correct choice should follow risk and operating requirements rather than organizational politics.
Shared Infrastructure with Logical Separation
In this model, multiple tenants share clusters and major platform services. Isolation is created through organizations, projects, quotas, network constructs, distributed security, storage policies, and delegated access.
Best fit
- Internal business units
- Development and test teams
- Workloads with similar lifecycle requirements
- Environments prioritizing consolidation and utilization
- Tenants that trust a common platform-operations team
Advantages
- Better infrastructure utilization
- Lower platform overhead
- Faster onboarding
- Easier capacity pooling
- Fewer duplicated management components
Tradeoffs
- Greater noisy-neighbor risk
- More complicated quota and policy design
- Shared maintenance windows
- Larger potential administrative blast radius
- Strong dependence on correct role and policy implementation
Shared Workload Domain with Stronger Tenant Segmentation
Multiple organizations may share a workload domain while receiving distinct consumption, network, security, and governance boundaries.
This pattern can provide a practical middle ground. The infrastructure remains pooled, but tenant access and network administration are more explicitly separated.
Best fit
- Multiple internal organizations
- Managed private-cloud services
- Business units needing delegated control
- Environments requiring stronger network separation without dedicated hardware
Advantages
- Efficient shared infrastructure
- Clearer tenant administration
- Reusable platform services
- Centralized lifecycle management
- Improved policy consistency
Tradeoffs
- The workload domain remains a shared lifecycle and failure boundary
- Cross-tenant governance requires careful design
- Capacity contention remains possible
- Provider-side roles can still span multiple tenants
- Troubleshooting must preserve tenant data and administrative separation
Dedicated Workload Domain or Infrastructure Boundary
A tenant receives a dedicated workload domain, cluster set, storage boundary, network edge, or other infrastructure allocation.
Best fit
- Strict regulatory separation
- Independent maintenance requirements
- High-value or high-risk workloads
- Predictable dedicated performance
- Specialized hardware requirements
- Different upgrade or compatibility timelines
Advantages
- Stronger lifecycle separation
- Clearer capacity ownership
- Reduced contention
- Smaller operational blast radius
- Easier alignment to dedicated service objectives
Tradeoffs
- Higher infrastructure cost
- Lower utilization
- More lifecycle work
- More capacity stranded within individual boundaries
- Potential duplication of network, storage, and operational services
Separate VCF Instance
A separate VCF instance provides the strongest platform-level separation but also creates the greatest operational overhead.
This pattern should be selected because the tenant requires an independent trust, lifecycle, administrative, or failure boundary. It should not be the default answer to every internal ownership dispute.
Decision Criteria for Tenant Isolation
The isolation decision should be based on explicit criteria.
| Criterion | Shared Logical Boundary | Dedicated Domain or Cluster | Separate VCF Instance |
|---|---|---|---|
| Regulatory separation | Moderate | Strong | Strongest |
| Lifecycle independence | Limited | Moderate to strong | Strongest |
| Capacity efficiency | Highest | Moderate | Lowest |
| Administrative isolation | Policy-dependent | Stronger | Strongest |
| Failure-domain separation | Limited | Stronger | Strongest |
| Cost | Lowest | Higher | Highest |
| Operational complexity | Lowest | Higher | Highest |
| Custom hardware support | Limited | Strong | Strong |
| Tenant autonomy | Moderate | High | Highest |
| Central governance | Easiest | Moderate | Most distributed |
The table is not a scoring system. A single hard requirement, such as independent administrative trust or incompatible lifecycle timing, may outweigh several efficiency benefits.
What the Image Gets Right
The image communicates several important VCF principles effectively.
The Platform Is Layered
Tenant services depend on management, networking, compute, storage, and physical infrastructure. A failure or capacity constraint at a lower layer eventually affects the consumer experience above it.
Networking and Security Are Foundational
NSX is not an optional decorative component in the city. Segmentation, routing, gateway services, load balancing, and policy enforcement are central to creating secure tenant boundaries.
Operations and Automation Are Different Capabilities
Automation provisions and changes services. Operations observes, analyzes, optimizes, and helps remediate them. Combining both capabilities creates a lifecycle, not merely a deployment portal.
Tenants Need More Than Applications
The tenant layer includes applications, services, data, identity, policy, and security. This is a stronger model than treating the tenant as a collection of virtual machines.
Physical Architecture Still Matters
Private cloud remains dependent on servers, networks, storage, power, cooling, firmware, and facilities. Software-defined infrastructure changes how resources are consumed; it does not remove their physical limits.
A Unified Platform Can Produce Different Experiences
Finance and research may consume the same underlying platform through different catalogs, quotas, policies, network boundaries, and operational views. Standardization at the infrastructure layer does not require every tenant to receive an identical service.
A strong mental model should clarify architecture without hiding its operational complexity.
Dedicated Resources Are a Design Choice
The image suggests that every tenant has dedicated resources. Some tenants may require dedicated clusters, storage, or gateways, but many enterprise designs use shared infrastructure with logical separation.
The service catalog must state what is dedicated, what is reserved, what is shared, and what remains best effort.
Colored Boundaries Do Not Equal Security Boundaries
A tenant cannot be declared secure because its workloads use a separate network segment. Identity, roles, firewall policy, automation permissions, logging, storage access, backups, and support access must follow the same boundary.
Automation Does Not Create Governance Automatically
Self-service can enforce good policy, but only after architects define service classes, ownership, approvals, quotas, expiration, exceptions, and remediation.
A catalog without governance is simply a faster request mechanism.
Unified Does Not Mean One Administrative Role
A unified platform should provide a consistent operating model. It should not require every operator to receive broad access to every tenant and every layer.
Infrastructure, network, security, automation, operations, and tenant teams may need different responsibilities and restricted views.
Supported External Infrastructure May Retain Separate Lifecycle Ownership
The image shows several possible Dell infrastructure platforms. The architecture should distinguish platform integration from lifecycle integration.
An external storage or network system may be supported and observable without being upgraded, remediated, or governed by the same VCF workflow. Those boundaries must be documented before production adoption.
Aria Terminology Requires Translation
The image includes the Aria Suite name. In current VCF documentation, major capabilities are presented through names such as VCF Automation and VCF Operations.
Teams migrating from earlier VMware environments may continue using Aria terminology conversationally. Architecture documents should map historical and current names explicitly so that operational responsibilities are not lost during the naming transition.
The Provider and Tenant Operating Model
The image emphasizes technology layers, but a production private cloud also needs ownership layers.
The platform team is not the owner of every workload decision. The tenant team is not the owner of every infrastructure control.
A practical responsibility model should answer:
- Who approves a new tenant?
- Who creates organizations and projects?
- Who defines identity groups?
- Who owns network-address allocation?
- Who creates baseline firewall policy?
- Who approves security exceptions?
- Who manages quotas?
- Who responds to capacity pressure?
- Who handles tenant-visible incidents?
- Who controls backup and recovery policies?
- Who approves upgrades that affect multiple tenants?
- Who communicates maintenance windows?
- Who pays for idle or abandoned resources?
- Who removes access when ownership changes?
Without these answers, the platform may be technically integrated while remaining operationally fragmented.
Building Tenant Neighborhoods in a Practical Sequence
Tenant onboarding should be treated as a design and validation process, not a portal configuration task.
Define the Service Classes
Start with the services tenants are allowed to consume.
Examples may include:
- General-purpose virtual machine
- High-memory application server
- Regulated workload service
- Isolated application environment
- Short-lived development environment
- High-availability database platform
- Recovery-enabled production service
Each class should define compute, storage, network, security, backup, observability, availability, lifecycle, and cost characteristics.
Select the Tenancy Pattern
Determine whether the tenant will use:
- Shared clusters with logical separation
- A shared workload domain with stronger organizational boundaries
- Dedicated clusters
- A dedicated workload domain
- A separate VCF instance
Record why the boundary was selected and what would cause it to change.
Establish Identity and Administrative Boundaries
Map enterprise groups to platform roles. Avoid assigning individual users directly wherever group-based access is practical.
Separate:
- Tenant users
- Tenant administrators
- Platform operators
- Network administrators
- Security administrators
- Automation administrators
- Operations users
- Break-glass administrators
Test both intended access and denied access. A role model is not validated until prohibited actions have also been tested.
Design Capacity and Storage Entitlements
Define:
- Initial quotas
- Growth thresholds
- Reservations
- Burst behavior
- Storage classes
- Backup policies
- Performance expectations
- Expansion approval
- Capacity exhaustion behavior
A tenant should know what happens when it reaches a limit. Silent overcommitment and last-minute hardware procurement are not capacity strategies.
Build the Network and Security Boundary
Implement the required NSX constructs, such as projects, VPCs, segments, gateways, routing, distributed firewall policy, egress controls, and logging.
Start with a default-deny or tightly controlled baseline where the workload permits it. Add approved flows based on application requirements rather than broad network location.
Connect Operations and Telemetry
Create both provider and tenant views.
The provider view may include:
- Infrastructure health
- Cluster capacity
- Datastore and storage-system health
- NSX services
- Certificate state
- Tenant consumption
- Cross-platform dependencies
The tenant view may include:
- Service health
- Workload availability
- Quota consumption
- Active alerts
- Capacity trends
- Cost or showback
- Request and deployment status
Expose Governed Automation
Publish catalog items only after the underlying service has been validated manually and operationally.
A published service should include:
- Ownership metadata
- Version control
- Approval logic
- Quota enforcement
- Network and security policy
- Day-2 actions
- Expiration or lease behavior
- Logging
- Failure handling
- Support instructions
- Rollback expectations
Validate the Boundary
Test more than successful provisioning.
Validation should include:
- Cross-tenant access attempts
- Privilege-escalation attempts
- Quota enforcement
- Noisy-neighbor behavior
- Network-policy enforcement
- Backup restoration
- Tenant offboarding
- Platform-component failure
- Capacity exhaustion
- Automation rollback
- Log and audit visibility
- Provider break-glass access
- Tenant data exposure during troubleshooting
The tenant is ready when the provider can prove both service delivery and boundary enforcement.
Common Design Failures
| Design Failure | Operational Consequence |
|---|---|
| Defining a tenant as a VLAN | Identity, administrative, storage, and lifecycle boundaries remain unresolved |
| Treating a folder as isolation | Workloads remain exposed to shared resource and security risks |
| Publishing self-service before defining quotas | Consumption grows faster than capacity and accountability |
| Giving operators broad global roles | A routine task can affect multiple tenants |
| Using one firewall policy for every tenant | Exceptions accumulate and application ownership becomes unclear |
| Providing dashboards without service objectives | Teams receive metrics but cannot determine service impact |
| Assuming all supported hardware shares one lifecycle | Upgrades encounter unmanaged dependencies and support ambiguity |
| Failing to define offboarding | Abandoned resources, credentials, firewall rules, and backups remain |
| Mixing provider and tenant alerts | Incident ownership becomes unclear |
| Promising dedicated performance on shared capacity | Service expectations exceed enforceable controls |
| Ignoring cost allocation | Shared infrastructure becomes politically difficult to expand |
| Treating backup as recovery | Restore order, dependencies, and application validation remain untested |
These failures usually come from implementing visible product objects before defining the operating model they are meant to enforce.
Design Questions Before Onboarding the First Tenant
The following questions should be resolved before production onboarding:
- What constitutes a tenant in this environment?
- Which resources are shared, reserved, or dedicated?
- What is the required administrative trust boundary?
- Does the tenant need an independent lifecycle window?
- Which VCF, automation, and NSX objects implement the boundary?
- How are identities created, reviewed, and removed?
- Who owns firewall policy and exceptions?
- How are quotas established and increased?
- Which storage, backup, and recovery classes are available?
- What service-level objectives are offered?
- What telemetry can the tenant see?
- How is tenant consumption measured?
- How are failed deployments cleaned up?
- What happens when shared capacity is exhausted?
- How is cross-tenant exposure tested?
- Which external systems retain separate lifecycle ownership?
- How is a tenant migrated to a stronger isolation model later?
- What evidence demonstrates that offboarding is complete?
These questions turn a conceptual neighborhood into a supportable service boundary.
Conclusion
The enterprise cloud city is a powerful way to explain VMware Cloud Foundation because it begins with the consumer experience rather than the product inventory. Tenants consume governed services, not individual hypervisors, switches, datastores, and monitoring tools.
The metaphor becomes operationally useful only when each neighborhood is defined as a coordinated policy bundle. Identity, administration, compute, network, security, storage, automation, operations, cost, recovery, and lifecycle must reinforce the same boundary.
VCF Automation, VCF Operations, NSX, vSphere, vSAN, and supported external infrastructure provide the technical mechanisms. The platform team still has to decide how those mechanisms are assembled, who owns them, how the boundaries are tested, and which promises can be supported by the physical foundation.
The best VCF multi-tenant architecture is not the design with the most dedicated infrastructure. It is the design that applies the correct degree of separation, makes shared dependencies visible, preserves operational accountability, and gives every tenant a service experience that the provider can repeatedly deliver.
