Azure Local vs VMware Cloud Foundation: Choosing the Right Enterprise Private Cloud Platform

TL;DR

Azure Local and VMware Cloud Foundation can both run enterprise virtual machines, container platforms, software-defined storage, and segmented networks. That does not make them interchangeable.

Azure Local is strongest when the organization wants Azure Resource Manager, Azure Arc, Microsoft Entra ID, Azure automation patterns, and Azure governance to become the operating model for infrastructure running in customer-owned locations. VMware Cloud Foundation is strongest when the organization wants a deeply integrated private cloud built around vSphere, vSAN, NSX, VCF Operations, VCF Automation, and established VMware operational practices.

The correct decision is rarely determined by hypervisor features alone. It depends on which control plane the organization wants to standardize, how much existing platform investment must be preserved, which networking and security controls are required, and whether the operations team is prepared to adopt the chosen platform’s lifecycle model.

Introduction

The Azure Local versus VMware Cloud Foundation debate is often reduced to Hyper-V versus ESX. That framing misses the real architectural decision.

Both platforms now extend well beyond server virtualization. Each combines compute, storage, networking, identity, automation, lifecycle management, and container services into a broader infrastructure platform. Selecting one therefore changes more than the hypervisor underneath a virtual machine. It changes how infrastructure is requested, governed, secured, updated, monitored, supported, and funded.

Azure Local places customer-owned infrastructure inside an Azure-aligned management model. Azure Arc, Azure Resource Manager, Azure role-based access control, custom locations, and Azure deployment tooling become important parts of the operating experience.

VMware Cloud Foundation creates a private cloud operating model around an integrated VMware stack. VCF Operations, vSphere, vSAN, NSX, VCF Automation, workload domains, and vSphere Kubernetes Service form a platform boundary that is designed and lifecycle-managed as a coordinated system.

The strategic question is therefore not simply, “Which platform has the better feature list?”

It is:

Which platform operating model best fits the organization’s workloads, governance requirements, skills, connectivity constraints, migration risk, and long-term infrastructure strategy?

This comparison uses Microsoft documentation aligned to the Azure Local 2606 documentation view and Broadcom documentation for VMware Cloud Foundation 9.1. Hardware compatibility, licensing, support boundaries, previews, and feature availability should be validated again before a production decision.

Why This Comparison Matters Now

Azure Local and VMware Cloud Foundation are converging around several enterprise requirements:

• Running traditional virtual machines and modern containerized applications
• Managing distributed infrastructure through a consistent control plane
• Applying policy and security controls across multiple environments
• Automating infrastructure consumption
• Coordinating platform lifecycle management
• Supporting edge, datacenter, sovereign, and disconnected scenarios
• Extending existing hardware and operational investments

The convergence can create the impression that the platforms are approaching feature parity. In practice, similar capabilities often sit inside very different architectural and operational models.

A virtual machine deployed through Azure Local VM management is represented as an Azure resource through Azure Arc. A virtual machine deployed through VCF remains part of a VMware private cloud resource and lifecycle hierarchy.

An Azure Local network security group and an NSX distributed firewall policy can both restrict traffic, but they do not automatically provide identical scope, policy constructs, enforcement behavior, operational tooling, or troubleshooting workflows.

AKS enabled by Azure Arc and vSphere Kubernetes Service can both provide Kubernetes on customer-owned infrastructure, but they align developers and operators with different ecosystems.

These differences influence staffing, governance, automation, failure handling, and migration design long after the initial deployment is complete.

Scope and Assumptions

This article compares the platforms as enterprise infrastructure foundations rather than individual hypervisor products.

The analysis assumes:

• Azure Local is being evaluated as a Microsoft distributed infrastructure platform, not merely as a replacement Hyper-V cluster.
• VMware Cloud Foundation 9.1 is being evaluated as an integrated private cloud platform, not as a collection of separately managed VMware products.
• The organization expects to run production virtual machines and may also require Kubernetes workloads.
• Networking, identity, automation, lifecycle, monitoring, support, and disaster recovery are part of the platform decision.
• No universal performance winner is assumed. Representative workloads must be tested on proposed hardware and storage configurations.
• Pricing is not compared directly because contracts, subscriptions, hardware, support terms, and existing entitlements vary significantly.
• Preview features are not treated as equivalent to generally available production capabilities.

The comparison also assumes that an enterprise may legitimately operate both platforms. Coexistence can be a sound architecture when each platform has a clearly defined role, ownership boundary, and exit strategy. It becomes expensive when it is simply the result of avoiding a decision.

The Core Architectural Difference

The most important distinction is where the organization wants its primary infrastructure control plane to live.

The diagram is not suggesting that Azure Local lacks local tools or that VCF cannot integrate with external services. It shows the direction of architectural gravity.

Azure Local pulls the environment toward Azure resource models, Azure identity, Azure deployment patterns, and Azure governance.

VCF pulls the environment toward VMware workload domains, integrated SDDC lifecycle management, NSX policy, vSphere operational models, and private cloud automation.

That gravity matters because platform teams eventually standardize around the control plane they use every day.

Platform Capability Comparison

Control Plane and Operating Model

Azure Local

Azure Local is Microsoft’s distributed infrastructure platform for running virtual machines, containers, and selected Azure-enabled services in customer-owned environments.

Azure Arc is not merely an optional monitoring agent in this architecture. Azure Local VM management uses components such as the Azure Arc resource bridge and custom locations to project local infrastructure resources into Azure. Administrators can then work with virtual machines, disks, network interfaces, images, and logical networks through Azure-oriented management workflows.

This model can create meaningful consistency for an Azure-first enterprise. Resource groups, Azure role-based access control, deployment templates, Azure CLI, policy concepts, and existing cloud governance processes can extend into on-premises or edge locations.

That consistency has an architectural price. The organization must understand:

• Which management operations depend on Azure connectivity
• Which components require outbound endpoints
• How the Arc resource bridge is protected, monitored, backed up, and recovered
• What remains manageable during a WAN or Azure control-plane interruption
• How local administrative access is controlled
• How Azure and local support boundaries interact

Azure Local also retains local operational tools, including PowerShell and other Windows infrastructure management interfaces. The design should clearly define when engineers use Azure-based operations and when they use local break-glass or troubleshooting tools. Allowing both methods without governance can create configuration drift and unclear ownership.

VMware Cloud Foundation

VMware Cloud Foundation is designed as an integrated private cloud platform. Its architectural center remains the locally operated VMware environment, organized through management components, workload domains, cluster models, networking services, automation, and lifecycle workflows.

VCF 9.x places increasing operational importance on VCF Operations. Teams moving from older VMware architectures should not assume that established SDDC Manager or product-by-product habits remain the long-term operating model.

The major strength of VCF is the depth of integration across the VMware stack. Compute, storage, networking, monitoring, automation, identity, and lifecycle management are designed to participate in a coordinated platform architecture.

The corresponding tradeoff is that the stack must be treated as a platform. Independently upgrading components, preserving unsupported combinations, or maintaining separate ownership silos can undermine the purpose of VCF and create support risk.

VCF works best when the organization is prepared to establish a private cloud platform team rather than continuing to operate vSphere, storage, networking, automation, and monitoring as unrelated products.

Compute and Workload Placement

Azure Local and VCF are both capable enterprise virtualization platforms, but workload fit is influenced by more than virtual CPU and memory support.

Azure Local is a strong candidate when workloads align closely with:

• Microsoft infrastructure standards
• Azure governance and deployment processes
• Windows Server and Linux virtual machines managed through Azure patterns
• Azure Virtual Desktop
• AKS enabled by Azure Arc
• Distributed sites that need centralized Azure-oriented management
• Edge or regulated locations that cannot place every workload in a public Azure region

VCF is a strong candidate when workloads align closely with:

• Existing vSphere estates
• Applications already certified or operationally proven on VMware
• Advanced vMotion and VMware mobility practices
• NSX-backed networking and security
• Mature vSAN operations
• Private cloud self-service
• vSphere Kubernetes Service
• VMware-oriented disaster recovery and infrastructure operations

An application running successfully on one hypervisor may be technically portable to the other. That does not mean the complete service is portable.

The real dependency map may include backup software, replication, monitoring agents, network policies, load balancers, storage integrations, licensing controls, operational scripts, support contracts, and administrator procedures.

Workload placement should therefore evaluate the service around the virtual machine, not just the virtual disk files.

Storage Architecture

Azure Local Storage

Azure Local’s hyperconverged architecture uses Storage Spaces Direct to aggregate local storage across cluster nodes. Microsoft has also expanded current Azure Local storage options to include supported external SAN configurations, reducing the accuracy of the older assumption that Azure Local must always use only local disks.

This creates additional design flexibility, but it also introduces more decisions:

• Hyperconverged versus disaggregated architecture
• Storage Spaces Direct versus external SAN
• Fibre Channel versus other supported protocols
• Compute and storage scaling boundaries
• Cluster Shared Volume placement
• Storage network isolation
• Multipathing and fabric design
• Backup and recovery integration
• Hardware and driver lifecycle coordination

Support status can vary by protocol and release. Architects should verify the current Azure Local compatibility documentation rather than assuming that every Windows-supported array or adapter is automatically supported.

VCF Storage

VCF commonly uses vSAN as its integrated software-defined storage platform. vSAN aligns storage policy, cluster architecture, lifecycle management, health, and capacity operations with the broader VMware environment.

This integration is valuable when the organization wants infrastructure policies to remain close to the virtual machine and cluster operating model. It also means that disk groups, fault domains, network design, capacity reserves, object policy, rebuild behavior, and upgrade sequencing become VCF design concerns.

Other storage options may be possible where supported by the applicable VCF and vSphere compatibility requirements. The key phrase is where supported. Existing array compatibility with vSphere alone should not be assumed to prove that every proposed VCF topology, lifecycle operation, or workload-domain design is supported.

The storage decision should compare failure behavior and operations, not only usable capacity.

Networking and Security

Networking is one of the areas where superficial comparisons are most dangerous.

Azure Local SDN

Azure Local supports software-defined networking through Azure Arc-enabled and locally managed approaches. Depending on the deployment and management model, the platform can use logical networks, network security groups, Network Controller capabilities, software load balancing, and gateway services.

Arc-enabled SDN allows Azure-oriented management of logical networks and NSG policies for supported Azure Local virtual machine scenarios. This is useful when teams already understand Azure NSGs and want similar policy constructs across cloud and local environments.

Current limitations still matter. For example, the scope of NSG association for AKS workloads is not identical to the scope available for Azure Local virtual machines. Architects should verify enforcement points for each workload type rather than assuming that one policy object protects every network path.

NSX in VCF

NSX provides the networking and security foundation for many VCF architectures. Its capabilities can include overlay networking, distributed routing, gateway services, distributed firewalling, segmentation, and multi-tenant network constructs.

Organizations with mature NSX designs may depend on policy models that do not have direct one-to-one Azure Local equivalents. These can include:

• Distributed east-west enforcement
• Dynamic security groups
• Application-centric policy
• Tiered routing designs
• Service insertion
• Overlay-backed tenant networks
• Advanced edge service patterns

Azure Local NSGs may satisfy a workload’s actual requirements without reproducing every NSX construct. The migration error is assuming that similar terms mean equivalent architectures.

A better process is to translate each existing policy into an intent statement:

Web servers may accept HTTPS from the application gateway, communicate with approved application services, and reach only the required management and logging endpoints.

Once the intent is documented, it can be implemented using the target platform’s native controls rather than mechanically recreating the source configuration.

Kubernetes and the Application Platform

Both platforms can run Kubernetes, but they create different developer and operator experiences.

AKS Enabled by Azure Arc

AKS enabled by Azure Arc brings an Azure-oriented Kubernetes deployment and management experience to Azure Local. Clusters run on local infrastructure while using Azure Arc for management integration.

This is attractive when the organization already uses:

• Azure Kubernetes Service
• Azure CLI and Azure Resource Manager
• Microsoft Entra ID
• Azure Policy and governance patterns
• GitOps through Azure Arc
• Azure Monitor or related Microsoft operational services
• Azure-based developer landing zones

The benefit is ecosystem consistency. The risk is assuming that AKS on Azure Local is identical to regional AKS in every capability, scale model, extension, networking option, and release cadence.

vSphere Kubernetes Service

vSphere Kubernetes Service integrates Kubernetes with the vSphere and VCF environment. It is attractive when infrastructure teams want Kubernetes consumption to remain close to vSphere capacity, storage policies, networking, identity, and private cloud operations.

VCF can provide a cohesive platform for traditional virtual machines and Kubernetes clusters, particularly where the organization already has mature VMware infrastructure processes.

The Kubernetes decision should consider:

• Cluster creation workflow
• Supported Kubernetes versions
• Upgrade ownership
• Identity integration
• Load balancing
• Persistent storage
• Network policy
• Observability
• Registry access
• Backup and recovery
• Developer self-service
• Air-gapped or restricted network requirements

Kubernetes conformance alone does not make two platforms operationally equivalent.

Lifecycle, Automation, and Observability

Azure Local Operations

Azure Local supports Azure portal, Azure CLI, PowerShell, Azure Resource Manager templates, Bicep-based deployments, and local Windows infrastructure tools.

This gives Azure-oriented teams several familiar automation paths. It can also create overlapping methods for modifying the same environment.

A production operating model should define:

• The authoritative infrastructure-as-code repository
• Which changes require pull requests
• Which portal operations are permitted
• How configuration drift is detected
• How emergency local changes are reconciled
• How update readiness is validated
• How hardware, firmware, drivers, and platform software are coordinated
• How Azure and local telemetry are retained during connectivity failures

VCF Operations

VCF Operations provides operational and lifecycle capabilities across the VCF platform. VCF Automation adds self-service, organization, tenancy, and infrastructure-consumption workflows, while APIs and PowerCLI support programmatic operations.

VCF’s coordinated lifecycle model can reduce unsupported version drift across integrated components. It can also create stricter sequencing and dependency requirements than teams accustomed to independently upgrading vCenter, NSX, vSAN, and management products may expect.

A VCF team must understand:

• Platform bill of materials
• Upgrade prechecks
• Repository and binary management
• Workload-domain sequencing
• Component compatibility
• Certificate and password lifecycle
• Backup prerequisites
• Rollback boundaries
• Support-bundle collection
• Post-upgrade validation

Neither platform eliminates lifecycle work. Each platform attempts to coordinate it through a different control model.

Connectivity, Sovereignty, and Disconnected Operations

It is no longer accurate to describe Azure Local simply as a platform that always requires uninterrupted connectivity to the Azure public cloud. Microsoft now documents disconnected operations for Azure Local, using a local control plane for selected Azure Arc-enabled services.

It is equally inaccurate to assume that disconnected mode makes every Azure Local capability identical to the standard connected experience.

Architects evaluating disconnected or sovereign deployments must validate:

• Which services are available locally
• Which features remain dependent on external endpoints
• How updates and extensions are imported
• Where identity is hosted
• How certificates are issued and rotated
• Which telemetry leaves the site
• How licensing and support validation occur
• How the local control plane is recovered
• Whether developers receive the same APIs in connected and disconnected locations

VCF is locally operated by design, although repositories, support systems, identity providers, integrations, and operational processes may still create external dependencies.

The real requirement should not be written as “must be on-premises.” It should specify the permitted dependencies and failure behavior.

For example:

Production workloads must continue operating, administrators must retain emergency control, and security policy must remain enforced during a 24-hour loss of external connectivity.

That statement can be tested on either platform.

Translating VMware Concepts to Azure Local

A migration from VMware to Azure Local should not be approached as a direct product replacement exercise.

The most important column is the translation warning. The target architecture should preserve required outcomes, not recreate every source object.

Migration and Coexistence Strategy

Microsoft currently documents Azure Migrate-based VMware migration to Azure Local as generally available. That reduces some mechanical migration effort, but it does not remove the architecture work surrounding the virtual machines.

A responsible transition should use phased adoption.

Discover the Real Dependency Graph

Inventory more than processors, memory, disks, and operating systems. Capture:

• Application communication paths
• DNS and identity dependencies
• Firewall and microsegmentation policies
• Load balancers
• Backup products
• Replication and disaster recovery
• Storage performance
• Monitoring and logging
• Automation scripts
• Licensing controls
• Support certifications
• Recovery procedures

Build the Platform Before Moving Workloads

The destination should have validated identity, networking, storage, monitoring, backup, lifecycle, security, and operational ownership before the first production migration wave.

Moving virtual machines into an unfinished platform simply relocates technical debt.

Pilot Representative Services

The pilot should include more than an easy standalone server. Select workloads that exercise:

• Multi-tier network communication
• Persistent storage
• Backup and restore
• Monitoring
• Identity
• Scheduled automation
• High availability
• Patch management
• Operational escalation

Migrate in Reversible Waves

Each wave should have:

• Entry criteria
• Application owner approval
• Dependency validation
• Performance baseline
• Migration window
• Rollback point
• Functional testing
• Security validation
• Operational acceptance
• Legacy decommission criteria

Preserve Coexistence Only Where It Has a Purpose

A dual-platform model can be effective when it creates a deliberate boundary, such as:

• Azure Local for distributed Microsoft-aligned sites
• VCF for consolidated enterprise datacenters
• Azure Local for Azure Virtual Desktop and edge applications
• VCF for existing NSX-dependent application estates
• Separate platforms for different regulatory or connectivity zones

Coexistence becomes wasteful when every tool, skill, backup product, monitoring system, automation pipeline, and support process must be duplicated indefinitely.

The TCO Question Is Primarily Operational

Vendor pricing matters, but it is only one part of the financial model.

Azure Local may reduce friction for an Azure-skilled organization by reusing Azure governance, identity, automation, and deployment knowledge. It may increase cost if the enterprise must add Azure connectivity, Arc expertise, new operational tooling, and extensive VMware migration work.

VCF may reduce transition risk for a large VMware estate by preserving platform familiarity, application compatibility, automation, and operational processes. It may increase cost if the organization retains a complex stack that exceeds its workload requirements or fails to consolidate overlapping management products.

The correct TCO model should normalize:

• Equivalent workload capacity
• Resilience level
• Storage usable capacity
• Network and security scope
• Backup retention
• Disaster recovery objectives
• Support level
• Staff coverage
• Migration horizon
• Expected growth
• Hardware refresh timing

A platform that appears less expensive on a subscription quote can become more expensive after migration, staffing, tooling, and operational risk are included.

Where Azure Local Fits Best

Azure Local deserves strong consideration when:

• Azure is the enterprise’s strategic cloud and governance platform.
• Infrastructure teams already use Azure Resource Manager, Azure CLI, PowerShell, Bicep, Azure RBAC, and Microsoft Entra ID.
• The organization needs infrastructure across datacenters, factories, retail sites, branch locations, or other distributed environments.
• Azure-consistent VM and Kubernetes management is more important than preserving VMware-specific constructs.
• Windows Server, Azure Virtual Desktop, AKS, and Microsoft-aligned workloads make up a significant portion of the estate.
• The organization is prepared to engineer Azure connectivity, Arc dependencies, local break-glass access, and support processes.
• Existing VMware network and automation dependencies can be translated without unacceptable risk.

Azure Local should not be selected merely because the organization owns Microsoft licenses or operates Azure subscriptions. It should be selected because the Azure operating model improves the full infrastructure lifecycle.

Where VMware Cloud Foundation Fits Best

VCF deserves strong consideration when:

• The organization operates a large and mature vSphere estate.
• Applications, operational procedures, and support agreements are deeply aligned with VMware.
• NSX networking and distributed security are strategic requirements.
• vSAN is an established storage platform.
• The enterprise requires mature private cloud resource organization and workload-domain patterns.
• Teams already have strong vSphere, NSX, vSAN, VCF Operations, and PowerCLI skills.
• Migration risk is more significant than the potential benefit of changing control planes.
• Local private cloud control is a stronger requirement than Azure-native management consistency.
• The organization is prepared to adopt VCF as an integrated lifecycle and operating model.

VCF should not be selected simply because vSphere has always been present. The organization must still prove that the complete platform aligns with future workload, cost, automation, and skills requirements.

Common Misunderstandings

Azure Local Is Azure Running Inside the Datacenter

Azure Local extends Azure management and selected Azure capabilities into customer-owned infrastructure. It is not a locally hosted copy of every Azure regional service.

Service availability, scaling, connectivity, networking, and lifecycle behavior must be evaluated specifically for Azure Local.

VCF Is Just a vSphere Bundle

VCF is an integrated private cloud operating model. Treating its components as independently managed products defeats much of its lifecycle, governance, and support value.

Azure Local NSGs Are a Direct Replacement for Every NSX Policy

Both can enforce network access controls, but policy scope, dynamic grouping, service insertion, routing integration, and operational depth can differ substantially.

Security requirements must be translated control by control.

Migrating the Virtual Machine Completes the Migration

The virtual machine is only one component of an application service. Networks, identities, monitoring, backup, automation, certificates, DNS, recovery, and support processes must also move or be redesigned.

One Platform Must Serve Every Workload

A governed dual-platform strategy can be valid. The platforms should have explicit placement rules, ownership, cost accountability, and lifecycle plans.

A Practical Decision Framework

The final decision should be supported by a weighted scorecard. Suggested criteria include:

The weights should be adjusted before scoring either platform. Changing weights after reviewing results converts the framework into a justification exercise.

What to Prove Before Committing

A production decision should not be made from demonstrations or feature matrices alone.

The proof of concept should validate:

• Automated platform deployment
• Representative VM provisioning
• Network segmentation
• Routing and load balancing
• Identity and role assignment
• Kubernetes cluster deployment, when required
• Storage performance and failure recovery
• Backup and application-consistent restore
• Node maintenance
• Platform upgrade workflow
• Monitoring and alert routing
• Loss of management-plane connectivity
• Break-glass administration
• Disaster recovery
• Infrastructure-as-code workflows
• Support escalation and diagnostic collection
• Measured operational effort

The final output should be an architecture decision record with evidence, assumptions, unresolved risks, ownership, and conditions that would cause the decision to be revisited.

Conclusion

Azure Local and VMware Cloud Foundation are not simply competing hypervisors. They represent different answers to the question of how enterprise infrastructure should be controlled and operated.

Azure Local is the stronger strategic fit when Azure is expected to become the common control plane across cloud, datacenter, edge, identity, governance, and application platforms. Its value increases when the organization can reuse Azure skills and processes while accepting the engineering responsibilities introduced by Arc, connectivity, and Azure-aligned lifecycle management.

VMware Cloud Foundation is the stronger fit when the organization requires a mature, integrated private cloud built around vSphere, vSAN, NSX, VCF Operations, automation, and VMware operational knowledge. Its value increases when preserving workload compatibility, network policy depth, established processes, and migration stability outweighs the benefit of changing control planes.

The worst decision is to choose from a feature checklist without addressing the future operating model. The best decision is the platform that the organization can secure, automate, update, recover, support, and financially sustain after the implementation team has moved on.

External References

• Microsoft: What Is Azure Local? Overview and Key Benefits
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/overview?view=azloc-2606
• Microsoft: Overview of Hyperconverged Deployments for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/overview/hyperconverged-overview?view=azloc-2606
• Microsoft: What Is Azure Local VM Management
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/azure-arc-vm-management-overview?view=azloc-2606
• Microsoft: Software Defined Networking Enabled by Azure Arc on Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/sdn-overview?view=azloc-2606
• Microsoft: External Storage Support for Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/concepts/external-storage-support?view=azloc-2606
• Microsoft: What Is AKS Enabled by Azure Arc
  Canonical URL: https://learn.microsoft.com/en-us/azure/aks/aksarc/aks-overview
• Microsoft: Disconnected Operations for Azure Local Overview
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview?view=azloc-2606
• Microsoft: What’s New in Hyperconverged Deployments of Azure Local
  Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/whats-new?view=azloc-2606
• Broadcom TechDocs: VMware Cloud Foundation 9.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
• 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: Lifecycle Management in VMware Cloud Foundation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/lifecycle-management/lifecycle-management-in-vmware-cloud-foundation.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: vSphere Kubernetes Service Architecture and Components
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsphere-supervisor-installation-and-configuration/vsphere-supervisor-concepts/tanzu-kubernetes-grid-architecture-and-components.html

The post Azure Local vs VMware Cloud Foundation: Choosing the Right Enterprise Private Cloud Platform appeared first on Digital Thought Disruption.