TL;DR

The underwater cloud city in the image is a useful architecture metaphor, but it should not be read as a literal bill of materials. Azure Local and VMware Cloud Foundation are separate infrastructure platforms with their own control planes, lifecycle models, security boundaries, and automation surfaces.

A resilient hybrid cloud does not force those platforms into one management product. It connects them through a shared enterprise operating model that defines identity, policy, workload placement, network connectivity, observability, security operations, data protection, service delivery, and recovery. The goal is not one pane of glass. The goal is one set of operating rules with clear platform-native execution.

Introduction

The image presents hybrid cloud as an underwater city built to survive enormous pressure. Azure Local forms one section of the habitat. VMware Cloud Foundation domains form another. Above them sit multi-tenant isolation, AI and machine learning workloads, and global connectivity. Below them are the systems that keep the environment alive: control, data services, security operations, power, and cooling.

That visual works because hybrid cloud architecture is rarely tested by the steady state. It is tested by pressure.

Pressure arrives as a failed identity provider, an expired certificate, a disconnected site, a bad lifecycle update, a compromised tenant, a saturated east-west link, a ransomware event, a GPU capacity shortage, or an application owner demanding the same service experience on two very different platforms.

The architectural question is therefore not whether Azure Local and VMware Cloud Foundation can be drawn inside the same picture. The question is whether the enterprise can operate both platforms through a coherent model without erasing the differences that make each platform useful.

The Image Is a Metaphor, Not a Supported Product Stack

The most important correction to the image is also the most useful design lesson: Azure Local is not a generic hardware substrate underneath VMware Cloud Foundation, and VCF domains do not normally run inside an Azure Local cluster.

The architecture should instead be interpreted as two adjacent platform zones inside the same enterprise cloud ecosystem.

Azure Local provides Microsoft-aligned distributed infrastructure, local compute and storage, Azure Arc integration, and Azure-consistent governance and management patterns. VMware Cloud Foundation provides a VMware private cloud model built around vSphere, vSAN, NSX, VCF Operations, VCF Automation, and VCF domain constructs.

They can share enterprise services, physical facilities, network underlay, security operations, data protection standards, and service-management processes. They should not be collapsed into a fictional single control plane.

That distinction protects the design from one of the most common multicloud mistakes: drawing integration where only coexistence exists.

Scope and Architecture Assumptions

This article uses the following assumptions:

• Azure Local refers primarily to hyperconverged deployments managed through Azure and Azure Arc.
• VMware Cloud Foundation refers to the VCF 9.1 architecture family and its fleet, instance, domain, operations, automation, networking, and storage constructs.
• The platforms coexist in the same enterprise operating model but remain separate lifecycle and failure domains.
• Shared services may include enterprise identity, DNS, IP address management, certificate services, SIEM, IT service management, backup, disaster recovery orchestration, configuration repositories, and automation pipelines.
• Global connectivity means routed, policy-controlled connectivity between sites and services. It does not imply that every workload should share a stretched Layer 2 network.
• Multi-tenancy is treated as a layered design problem involving identity, authorization, resource allocation, network policy, data separation, cost accountability, and operational evidence.

This is an operating-model architecture, not a low-level deployment reference design. Every production implementation still requires current compatibility, licensing, hardware, support, and lifecycle validation.

Pressure Reveals Whether the Architecture Is Real

A platform can look unified during normal operations because dashboards are green and network paths are available. The real architecture becomes visible when one dependency fails.

A resilient design should be able to answer questions such as:

• Can Azure Local workloads continue operating when cloud connectivity is impaired?
• Can VCF domains be patched or upgraded without coupling the Azure Local lifecycle to the same change window?
• Can the security operations team correlate alerts from both platforms without losing the native diagnostic context?
• Can a tenant administrator act only inside the intended resource, network, and data boundaries?
• Can an AI workload be moved or rebuilt without creating an uncontrolled data-export path?
• Can the enterprise recover critical services if the shared automation layer is unavailable?
• Can application owners understand which platform is responsible for an incident?

If those answers depend on a single dashboard or a single automation account, the environment is not unified. It is tightly coupled.

The pressure-resistant model is federated. It establishes common policy and evidence requirements while allowing each platform to execute through its native mechanisms.

One Enterprise Cloud, Two Native Control Planes

The shared operating model should sit above the platform control planes, not replace them.

The top block is the enterprise contract. It defines what a compliant service must provide. The two middle paths translate that contract into platform-native controls. The lower shared services support both platforms without pretending to own their internal state.

This is the difference between governance and centralization.

Governance defines outcomes, boundaries, evidence, and accountability. Centralization tries to make every platform behave like the preferred platform. The first approach scales. The second creates brittle integrations and hidden exceptions.

Mapping the Underwater City to a Real Architecture

Image element	Real architecture meaning	Design question
Surface vessels and global connectivity	Users, cloud services, partners, remote sites, WAN, and internet dependencies	What remains available when an external path fails?
Azure Local habitat	Microsoft-aligned local infrastructure and Azure Arc-managed workloads	Which workloads benefit from local execution with Azure-consistent governance?
VMware Cloud Foundation domains	VMware private cloud capacity, lifecycle boundaries, and application-ready infrastructure	Which workloads depend on vSphere, vSAN, NSX, VCF automation, or VMware operational skills?
Multi-tenant isolation	Identity, authorization, quotas, network policy, data boundaries, and delegated operations	What prevents one tenant from affecting another tenant’s resources or evidence?
AI and machine learning workloads	GPU capacity, model services, data pipelines, registries, inference, and MLOps	Where should data, models, accelerators, and governance controls live?
Control plane	Policy decisions, orchestration, lifecycle, inventory, desired state, and change control	Which system is authoritative for each action?
Data services	Backup, replication, recovery, databases, object services, and data lifecycle	Is data protected independently of the platform that hosts it?
Security operations	Detection, response, vulnerability management, audit, and evidence retention	Can the SOC investigate across platforms without flattening platform detail?
Power and cooling	Rack design, electrical capacity, thermal limits, hardware support, and facilities operations	Can the physical environment sustain peak infrastructure and GPU demand?
Ocean depth and pressure	Failure, latency, security, compliance, scale, and operational stress	Which dependencies fail first under pressure?

The table exposes an important point: the shared architecture is not the collection of products. It is the collection of decisions that determine how those products are governed and operated.

Keep Platform-Native Responsibilities Inside Each Platform

A shared operating model does not mean shared ownership of every action. The cleanest model assigns authority at the layer where the best context exists.

Azure Local Native Responsibilities

Azure Local should remain authoritative for its cluster resources, platform lifecycle, Azure resource representation, Azure Arc-enabled workload management, and Microsoft-native governance integrations. Azure Policy, Azure Monitor, Microsoft Defender for Cloud, Azure role-based access control, Azure Resource Manager templates, Bicep, and Azure CLI can participate in that operating path where they are supported and appropriate.

The enterprise should consume the resulting inventory, compliance state, alerts, costs, and service health. It should not bypass the platform by changing low-level state through an unrelated tool simply because that tool offers a common dashboard.

VMware Cloud Foundation Native Responsibilities

VCF should remain authoritative for its fleet, instance, domain, vSphere, vSAN, NSX, VCF Operations, VCF Automation, and lifecycle workflows. A VCF domain is a meaningful infrastructure and lifecycle construct. It should not be reduced to a generic cluster label in an enterprise configuration database.

VCF Automation organizations, projects, namespaces, and associated tenancy designs can provide consumption boundaries, while VCF domains provide infrastructure organization and lifecycle boundaries. Those constructs are related, but they are not interchangeable.

The Enterprise Contract

The enterprise layer should define:

• required identity and privileged-access controls
• minimum logging and telemetry
• service-level objectives
• backup and recovery objectives
• network and data-classification policy
• encryption and certificate requirements
• vulnerability and patch evidence
• cost ownership and tagging
• change and exception workflows
• workload placement criteria
• incident escalation and communications

Each platform then proves compliance through its native implementation.

Do Not Flatten the Platform Models

A common taxonomy is useful, but a fake one-to-one mapping is dangerous.

Architecture concern	Azure Local expression	VCF expression	Shared enterprise contract
Administrative scope	Tenant, subscription, resource group, role assignment, cluster, custom location	Private cloud, fleet, instance, domain, organization, project, namespace	Named owner, approved role, separation of duties, review cadence
Infrastructure lifecycle	Azure Local lifecycle and update workflows	VCF component and domain lifecycle workflows	Maintenance policy, readiness gate, rollback evidence, business approval
Resource governance	Azure Resource Manager, policy, quotas, tags, Arc resource model	VCF Automation policies, quotas, projects, blueprints, placement	Standard service classes, cost centers, limits, exception process
Network isolation	Physical network design, logical networks, platform and workload controls	NSX segments, gateways, distributed security, VPC and domain design	Addressing, routing, egress, segmentation, inspection, ownership
Observability	Azure Monitor, platform health, Defender integrations, logs and metrics	VCF Operations, platform logs, NSX telemetry, domain health	Common severity, retention, correlation, ticket routing, evidence
Workload automation	ARM, Bicep, Azure CLI, APIs, Arc-enabled workflows	VCF Automation, APIs, Terraform providers, PowerCLI and platform workflows	Git control, approval gates, secrets, artifact versioning, rollback
Recovery	Workload backup, replication, Azure-integrated recovery options, application recovery	VMware and partner backup, replication, recovery, application recovery	RPO, RTO, recovery owner, test frequency, recovery evidence

The shared contract should normalize intent and evidence, not erase platform semantics.

Shared Services Need Contracts, Not Forced Consolidation

Identity and Privileged Access

The enterprise identity model should provide consistent user lifecycle, multifactor authentication, privileged-access control, break-glass procedures, and access reviews. Platform roles still need to be designed separately because equivalent role names do not guarantee equivalent permissions.

A global cloud administrator role is usually too broad. Delegation should be aligned to platform scope, service ownership, and incident responsibility. Service accounts and automation identities need the same rigor as human administrators, including credential rotation, least privilege, ownership, and termination procedures.

Policy and Governance

Policy should begin as an enterprise statement such as: production workloads must use approved images, encrypted storage, protected management paths, current vulnerability baselines, named owners, tested recovery, and retained audit evidence.

That policy is then translated into Azure and VCF implementations. Some controls can be prevented at deployment. Others can only be detected and remediated. The operating model must distinguish prevention, detection, response, and exception handling.

A policy dashboard without an exception owner is only a reporting system.

Observability and Security Operations

A central SIEM or observability platform can aggregate events from Azure Local, Azure services, VCF, NSX, guest operating systems, identity providers, and network devices. Aggregation is not the same as diagnosis.

The shared telemetry model should preserve:

• platform and resource identity
• tenant and service ownership
• event time and source
• severity and confidence
• change correlation
• network and identity context
• lifecycle status
• ticket and incident linkage
• evidence retention requirements

The SOC should be able to correlate events across platforms, then hand the investigation to an operator who still has native platform context.

Data Protection and Recovery

Data services in the image sit beneath both platforms because data outlives infrastructure. That is the correct mental model.

Backup policies, immutability, replication, retention, recovery orchestration, and restore testing should be governed independently from the platform that hosts the workload. A platform snapshot may support operational recovery, but it is not automatically a complete cyber-recovery strategy.

Recovery design should begin with the application dependency chain. Infrastructure recovery without identity, DNS, secrets, databases, queues, and external integrations can produce a technically running but functionally unusable application.

Network Connectivity

Global connectivity should use explicit routed boundaries, address-management discipline, DNS authority, egress control, and documented failure behavior. Stretching networks across platforms and sites can simplify a migration, but it can also extend failure domains and hide application dependencies.

The default goal should be application reachability, not universal Layer 2 adjacency.

Service Catalog and Automation

A shared service catalog can present a consistent request experience while dispatching work to different platform adapters. The request should contain intent: workload class, data classification, availability target, recovery target, network zone, owner, cost center, and approved software pattern.

The adapter should translate that intent into Azure Local or VCF resources. The catalog should not assume that both platforms expose identical objects or lifecycle behavior.

Multi-Tenant Isolation Is a Layered System

The image places multi-tenant isolation above the infrastructure because tenancy is an end-to-end property. It cannot be delivered by a VLAN, a resource group, a VCF domain, or a project alone.

A credible tenant boundary includes at least four layers:

• Administrative isolation: distinct identities, delegated roles, approval boundaries, and privileged-access controls.
• Resource isolation: quotas, placement, capacity reservations, noisy-neighbor protections, and lifecycle scope.
• Network and data isolation: segmentation, routing, egress, encryption, secrets, storage access, and backup boundaries.
• Operational isolation: separate alerts, costs, logs, tickets, evidence, change calendars, and incident ownership.

The provisioning path should enforce those layers before resources are created.

The request is not complete when the virtual machine or cluster exists. It is complete when ownership, policy, telemetry, protection, cost, and recovery evidence also exist.

AI and Machine Learning Workloads Increase the Pressure

The AI and machine learning label in the image is not just another workload category. Accelerated workloads can amplify every weakness in the operating model.

GPU resources are scarce and expensive. Model artifacts may have licensing and provenance requirements. Training and inference pipelines move sensitive data. Vector stores and model endpoints create new access paths. High-throughput traffic can expose network bottlenecks. Teams often request broad permissions because experimentation moves faster than governance.

Both Azure Local and the VCF ecosystem can support accelerated workload patterns, but the placement decision should not begin with GPU availability alone.

The enterprise should evaluate:

• where the source data is created and governed
• whether data may leave the site or security zone
• latency and availability requirements
• GPU type, memory, partitioning, and scheduling needs
• VM, Kubernetes, or platform-service preference
• model registry and artifact provenance
• secrets, service identities, and network egress
• monitoring, prompt and inference logging, and retention
• recovery expectations for data, pipelines, and model services
• skills and support ownership
• cost allocation and capacity reservation

AI infrastructure is not resilient when the accelerator is available but the data path, identity path, or model supply chain is uncontrolled.

Workload Placement Should Be a Decision, Not a Habit

The right platform is the one that best satisfies the workload’s requirements under the enterprise operating model.

Decision criterion	Questions to ask
Application dependency	Does the workload rely on VMware-specific operations, Microsoft-native services, Kubernetes patterns, licensing, or existing automation?
Data gravity and sovereignty	Where is the data created, who owns it, and which locations or services may process it?
Latency and connectivity	Can the workload tolerate cloud-control-plane latency, site isolation, or WAN failure?
Isolation requirement	Does the workload need dedicated infrastructure, a shared tenant model, specialized network policy, or strict administrative separation?
Lifecycle fit	Which platform can patch, upgrade, and support the workload without unacceptable coupling?
Automation fit	Which native API, template, pipeline, and skills model can deliver the service reliably?
Resilience and recovery	Which platform and recovery design can meet the application RPO and RTO?
Observability and security	Can the platform produce the telemetry and control evidence required by operations and risk teams?
Cost and capacity	How are licensing, hardware, GPU capacity, storage growth, support, and operational labor allocated?
Reversibility	Can the workload be rebuilt, exported, migrated, or retired without creating a permanent dependency trap?

A placement decision should be recorded with assumptions and review triggers. The answer can change when the application, platform release, connectivity model, cost profile, or regulatory requirement changes.

Build the Shared Operating Model in Deliberate Phases

Establish Authority Before Integration

Identify the authoritative system for identity, inventory, network addressing, DNS, certificates, secrets, vulnerability state, backup policy, cost ownership, service requests, and incident records.

Two tools can display the same data. Only one should own the decision.

Normalize Service Intent and Evidence

Define common service classes and evidence requirements before creating a universal portal. A production service might require a named owner, support tier, data classification, network zone, recovery tier, logging profile, patch window, and cost center.

The platforms can implement those requirements differently, but they should return evidence in a form the enterprise can evaluate.

Federate Identity, Telemetry, and Service Management

Connect platforms to enterprise identity, SIEM, observability, IT service management, and configuration repositories. Preserve native identifiers so incidents and changes can be traced back to the correct platform object.

Build Platform Adapters and Golden Paths

Create separate automation modules for Azure Local and VCF. Reuse enterprise policy, request schemas, naming conventions, metadata, tests, and approval logic. Do not reuse low-level platform actions merely to create visual consistency.

Test Failure and Recovery

Run exercises that remove dependencies:

• disconnect a site from external management services
• revoke or expire an automation credential
• simulate loss of a shared DNS or certificate dependency
• fail a network path
• restore a protected workload into an alternate recovery zone
• isolate a tenant after a suspected compromise
• pause a lifecycle operation and validate rollback
• recover the service catalog from source control and documented state

The design is complete only when the operating model survives the failure of its convenience layers.

A Practical Ownership Model

Capability	Enterprise authority	Platform execution	Required evidence
Identity and privileged access	Identity and security teams	Azure and VCF role models	Access review, role assignment, break-glass test
Network and IP services	Network architecture	Azure Local networking and NSX	Address ownership, route state, policy, flow evidence
Platform lifecycle	Platform governance	Azure Local lifecycle and VCF lifecycle	Compatibility check, readiness gate, change record, rollback plan
Workload provisioning	Cloud platform team	Azure and VCF automation adapters	Request, approval, code version, deployment result
Security monitoring	SOC	Native platform telemetry and controls	Alert, owner, response record, retained logs
Data protection	Data protection team	Platform and backup integrations	Policy, immutable copy, restore test, recovery result
Cost and capacity	FinOps and platform owners	Native usage and capacity data	Allocation, forecast, exception, reclamation action
Incident response	Incident command	Platform specialists and service owners	Timeline, containment, recovery, post-incident actions

This model creates shared accountability without pretending that every team should operate every platform.

Measure the Operating Model, Not the Diagram

The environment should be measured by outcomes that reveal whether the shared model works:

• percentage of services with a named owner and recovery tier
• percentage of privileged roles reviewed on schedule
• policy compliance before and after deployment
• mean time to identify the correct platform and service owner
• mean time to contain a tenant or workload
• successful restore and recovery-test rate
• lifecycle changes completed without cross-platform incident
• percentage of resources deployed through approved automation
• configuration drift age
• telemetry coverage and evidence retention
• capacity forecast accuracy
• orphaned resource and unused reservation rate
• AI workloads with approved data, model, identity, and egress controls

These measures expose whether the architecture is operationally coherent. A visually unified dashboard does not.

Conclusion

The underwater city is a strong metaphor for hybrid cloud because it makes pressure visible. The habitat survives only when every boundary, control path, life-support dependency, and recovery mechanism has been designed before the emergency.

Azure Local and VMware Cloud Foundation should not be treated as one merged product stack. They should be treated as distinct platform zones connected by a shared enterprise operating model. Each platform keeps authority over its native lifecycle, resources, networking, automation, and diagnostics. The enterprise defines the common contract for identity, policy, observability, security operations, data protection, connectivity, cost, service delivery, and recovery.

That approach produces something more valuable than one pane of glass. It produces one accountable way of operating across multiple control planes.

The architecture succeeds when a workload can be placed deliberately, governed consistently, operated by the right team, isolated under pressure, and recovered with evidence. That is the pressure hull beneath a resilient hybrid cloud.

External References

• Microsoft Learn: What is Azure Local?
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/overview?view=azloc-2606
• Microsoft Learn: Azure Local baseline reference architecture
  Canonical URL: https://learn.microsoft.com/en-us/azure/architecture/hybrid/azure-local-baseline
• Microsoft Learn: Azure Local security book overview
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/security-book/overview?view=azloc-2606
• Microsoft Learn: Prepare GPUs for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/gpu-preparation?view=azloc-2606
• Broadcom TechDocs: Architectural Options in VMware Cloud Foundation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/vmware-cloud-foundation-concepts.html
• Broadcom TechDocs: Managing VCF Domains in VMware Cloud Foundation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/building-your-private-cloud-infrastructure/working-with-workload-domains.html
• Broadcom TechDocs: Shared Workload Domain for Multiple Organizations in a VCF Instance
  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: 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: VMware Private AI Foundation with NVIDIA 9.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-1.html
• NIST: Zero Trust Architecture
  Canonical URL: https://csrc.nist.gov/pubs/sp/800/207/final

The post Azure Local and VMware Cloud Foundation: The Shared Operating Model Beneath a Resilient Hybrid Cloud appeared first on Digital Thought Disruption.