Azure VMware Solution (AVS): Running VMware Workloads on Azure Without Replatforming
Azure VMware Solution (AVS) is Microsoft's answer to the question that every enterprise VMware customer faces when moving to Azure: do we replatform our VMware workloads to native Azure services, or do we run them as-is? AVS provides a third path — run your VMware SDDC on dedicated Azure bare-metal infrastructure, with full VMware stack compatibility, while using Azure for networking, identity, monitoring, and billing. Here is what you need to know to evaluate it correctly.
What AVS Actually Is
AVS is not a VM-level migration tool. It is a full VMware SDDC running on dedicated physical servers in Azure datacentres. The stack includes vSphere, vSAN, NSX-T, and vCenter — the same software your team runs on-premises. Microsoft manages the infrastructure layer; you manage the VMware platform exactly as you do today.
This distinction matters: your VMware administrators, runbooks, monitoring tools, and operational procedures transfer to AVS without change. There is no VMware-to-Azure skills translation required for workload operations.
SDDC Architecture on Azure
An AVS private cloud is a dedicated cluster of Azure bare-metal nodes (AV36 or AV52 series), each providing a fixed amount of CPU, memory, and vSAN storage capacity. Minimum cluster size is three nodes. vSAN provides hyperconverged storage across the nodes — no separate storage configuration is required.
NSX-T handles microsegmentation and East-West routing within the private cloud. For North-South connectivity (traffic to/from Azure VNets and on-premises), AVS connects to your Azure VNet through an ExpressRoute circuit — managed by Microsoft as part of the AVS service. From a networking perspective, AVS appears as another spoke connected to your hub VNet.
HCX Migration
VMware HCX is included with AVS and is the primary migration tool. HCX enables live vMotion migration of running VMs from on-premises VMware to AVS without downtime. It handles network extension (stretching on-premises VLANs to AVS), bulk migration of powered-off VMs, and replication-based migration with minimal cutover windows for large VMs that cannot tolerate live migration latency.
HCX is the most powerful aspect of the AVS migration story — it removes the re-IP address requirement that makes traditional VM migrations painful, and it allows teams to migrate workloads in waves at their own pace without a hard cutover date.
Cost Comparison
AVS is expensive relative to native Azure IaaS. An AV36 node costs approximately the same as running several large Azure VMs. The cost justification for AVS is not per-VM economics — it is the total cost of replatforming avoided. If replatforming a workload to native Azure services requires six months of engineering, testing, and risk management, AVS may be cheaper than replatforming when that engineering cost is factored in.
The typical AVS business case: use AVS as a stepping stone to get workloads into Azure quickly, then replatform to native services over time as capacity allows. Running on AVS permanently is usually not the cost-optimal outcome.
When AVS Is the Right Choice
- Datacentre exit deadline that cannot accommodate replatforming timelines
- VMware workloads with deep vSphere dependencies (vSphere APIs, VMware tools integrations) that are expensive to refactor
- Compliance requirements that mandate VMware-certified infrastructure
- Teams without Azure IaaS expertise who need time to upskill before replatforming
When to Go Native Azure Instead
- Greenfield workloads with no VMware dependency
- Applications already containerised or cloud-native
- Long migration timelines where replatforming investment is justified
- Cost sensitivity at scale — AVS at 50+ nodes is significantly more expensive than equivalent native Azure capacity
AVS is a powerful migration tool when used as a migration accelerator rather than a permanent hosting platform. Evaluate it against your replatforming complexity and timeline pressure, not against native Azure pricing alone.
