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.
TermPractical MeaningWhat It Does Not Automatically ProvideTenantA consumer boundary defined by business, security, service, and ownership requirementsA specific VCF objectOrganizationA consumption and governance boundary used to group users, services, policies, and entitlementsGuaranteed physical isolationVCF Automation projectA provisioning scope for users, cloud zones, quotas, templates, and deployment policiesComplete network or administrative isolation by itselfNSX projectA delegated networking and security boundary within NSXIndependent physical infrastructureNSX VPCA tenant-consumable network environment with controlled connectivity and servicesFull lifecycle independence from the providerWorkload domainA VCF infrastructure and lifecycle boundary containing platform resourcesA one-to-one relationship with a business tenantClusterA compute and availability boundaryA complete tenant boundaryResource poolA compute entitlement and scheduling constructSecurity isolationFolderAn inventory and delegated-management constructPerformance, 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 DomainTenant QuestionProvider ControlIdentityWho can enter the tenant environment?Federation, groups, roles, privileged-access controlsAdministrationWhat can tenant administrators change?Delegated roles, organization boundaries, project permissionsComputeHow much capacity can the tenant consume?Quotas, reservations, placement policies, service classesNetworkWhat can communicate with what?Segments, VPCs, gateways, route controls, egress policySecurityWhere is policy enforced?Distributed firewall, gateway firewall, micro-segmentationStorageWhere is data placed and protected?Storage policies, encryption, replication, backup classesAutomationWhat can the tenant request?Catalog items, templates, approvals, leases, day-2 actionsOperationsWhat can the tenant observe?Dashboards, alerts, service health, scoped telemetryCostWho owns consumption?Tagging, allocation, showback, chargeback, budget controlsLifecycleWho patches or changes each layer?Responsibility model, maintenance windows, compatibility policyRecoveryHow is service restored?Backup, replication, recovery plans, test schedulesComplianceWhat 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.
CriterionShared Logical BoundaryDedicated Domain or ClusterSeparate VCF InstanceRegulatory separationModerateStrongStrongestLifecycle independenceLimitedModerate to strongStrongestCapacity efficiencyHighestModerateLowestAdministrative isolationPolicy-dependentStrongerStrongestFailure-domain separationLimitedStrongerStrongestCostLowestHigherHighestOperational complexityLowestHigherHighestCustom hardware supportLimitedStrongStrongTenant autonomyModerateHighHighestCentral governanceEasiestModerateMost 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 FailureOperational ConsequenceDefining a tenant as a VLANIdentity, administrative, storage, and lifecycle boundaries remain unresolvedTreating a folder as isolationWorkloads remain exposed to shared resource and security risksPublishing self-service before defining quotasConsumption grows faster than capacity and accountabilityGiving operators broad global rolesA routine task can affect multiple tenantsUsing one firewall policy for every tenantExceptions accumulate and application ownership becomes unclearProviding dashboards without service objectivesTeams receive metrics but cannot determine service impactAssuming all supported hardware shares one lifecycleUpgrades encounter unmanaged dependencies and support ambiguityFailing to define offboardingAbandoned resources, credentials, firewall rules, and backups remainMixing provider and tenant alertsIncident ownership becomes unclearPromising dedicated performance on shared capacityService expectations exceed enforceable controlsIgnoring cost allocationShared infrastructure becomes politically difficult to expandTreating backup as recoveryRestore 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 NotesCanonical 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 OverviewCanonical 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 ManagementCanonical 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 OrganizationsCanonical 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 FoundationCanonical 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 OperationsCanonical 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 ProjectCanonical 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 ProjectsCanonical 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 PowerFlexCanonical 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 FoundationCanonical URL: https://infohub.delltechnologies.com/en-us/l/using-dell-powerflex-with-vmware-cloud-foundation-9-0/storage-4225/
The NSX Microsegmentation Vault: Designing Distributed Firewall Policy Around Applications, Not Perimeters
TL;DR The vault image presents a useful mental model for NSX microsegmentation: every workload should occupy a controlled security compartment rather than…
The post VMware Cloud Foundation Multi-Tenancy: Designing Secure Tenant Neighborhoods on a Shared Platform appeared first on Digital Thought Disruption.