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.

Why the Enterprise Cloud City Metaphor Works

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.

Where the Metaphor Needs Guardrails

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.

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: VCF Automation Overview
  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/vcf-automation-overview.html
• Broadcom TechDocs: Organization Management
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management.html
• Broadcom TechDocs: Tenancy Deployment Model with a Shared Workload Domain for Multiple Organizations
  Canonical 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/tenancy-deployment-models-with-vmware-cloud-foundation/model-3.html
• Broadcom TechDocs: Workload Domains in 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/workload-domains-in-vmware-cloud-foundation.html
• Broadcom TechDocs: Managing Your Private Cloud in VCF Operations
  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/vcf-operations-overview/managing-your-private-cloud-in-vcf-operations.html
• Broadcom TechDocs: Add an NSX Project
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/advanced-network-management/nsx-multi-tenancy/nsx-projects/add-an-nsx-project.html
• Broadcom TechDocs: Secure VPC Projects
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/vdefend-firewall/9-1/secure-vpc-projects.html
• Dell Technologies: VMware Cloud Foundation Components with Dell PowerFlex
  Canonical URL: https://infohub.delltechnologies.com/en-us/l/using-dell-powerflex-with-vmware-cloud-foundation-9-0/vmware-cloud-foundation-141/
• Dell Technologies: Storage Design for Dell PowerFlex with VMware Cloud Foundation
  Canonical URL: https://infohub.delltechnologies.com/en-us/l/using-dell-powerflex-with-vmware-cloud-foundation-9-0/storage-4225/

The post VMware Cloud Foundation Multi-Tenancy: Designing Secure Tenant Neighborhoods on a Shared Platform appeared first on Digital Thought Disruption.