Not every workload can, or should, be rebuilt for the cloud on day one.

For about two decades, VMware virtualisation has been the foundation of enterprise data centres. Thousands of organisations run business-critical applications on virtual machines managed with VMware tools. Their teams hold deep skills in these tools, their backup, monitoring and security products are built around them, and countless applications were installed and configured with VMware assumptions baked in.

When such an organisation decides to leave a data centre, the usual cloud route is to convert each virtual machine to a native cloud format, adjust networking, re-test the application and retrain the team. For hundreds or thousands of machines, that is a long and risky project, and some applications are too old, too fragile or too poorly documented to change safely.

Azure VMware Solution, often shortened to AVS, takes a different approach. It provides a private cloud made of dedicated bare-metal servers in Azure data centres, running the VMware software stack: vSphere for virtualisation, vSAN for storage and NSX for networking, managed with the familiar vCenter and NSX tools. Microsoft operates the hardware and the platform software lifecycle. You move your virtual machines across largely unchanged, keep your tools and processes, and gain direct access to Azure services next door.

It is a managed service, delivered by Microsoft and supported with Broadcom, the company that now owns VMware. That relationship, and how it affects licensing, is one of the most important things to understand, and we will return to it in its own chapter.

The main reasons organisations choose it

AVS is one of several routes to the cloud, each with its own trade-offs.

Organisations with a VMware estate generally choose among a few paths. Understanding them side by side shows when AVS is the right tool and when it is not.

flowchart TD
  A["VMware workload to move"] --> B{"Still needed?"}
  B -->|"No"| R["Retire"]
  B -->|"Yes"| C{"Must stay on premises?"}
  C -->|"Yes"| K["Retain for now"]
  C -->|"No"| D{"Simple to convert and no VMware dependency?"}
  D -->|"Yes"| N["Rehost to native Azure virtual machines"]
  D -->|"No"| E{"Large estate, tight deadline or fragile application?"}
  E -->|"Yes"| AVS["Move to Azure VMware Solution"]
  E -->|"No"| F["Consider refactoring or replacing"]
  AVS --> G["Modernise gradually using nearby Azure services"]
        

A compact vocabulary mixing VMware and Azure terms.

AVS sits between two worlds, so its vocabulary draws from both. Learning the terms once will let you follow VMware administrators and Azure architects alike.

What Microsoft runs, what you run and what sits between.

An AVS private cloud is deployed into Microsoft’s data centres on dedicated hardware that is not shared with other customers. Within it, the full VMware stack runs, and on the outside it connects to your Azure virtual networks and to your on-premises sites.

flowchart LR
  subgraph OnPrem["On-premises site"]
    OP["VMware environment"]
  end
  subgraph AVS["Azure VMware Solution private cloud"]
    VC["vCenter"]
    NSX["NSX networking and security"]
    VS["vSphere hosts"]
    VSAN["vSAN storage"]
    VMS["Your virtual machines"]
  end
  subgraph AZ["Azure"]
    VN["Virtual networks"]
    SV["Native services: storage, databases, monitoring, backup"]
  end
  OP |"ExpressRoute or VPN with HCX"| AVS
  AVS |"High-speed private connection"| VN
  VN --> SV
  VMS --> VS
  VS --> VSAN
        

Who is responsible for what

What happens between asking for a private cloud and logging in to vCenter.

Creating a private cloud is quite different from creating an ordinary Azure resource, because real physical servers must be allocated and configured. Understanding the steps explains the planning needed before you start.

Two generations of architecture

The service has evolved. In the first generation, the private cloud sits in a separate, Microsoft-managed network environment and is connected to your Azure virtual networks through ExpressRoute-based links. In the newer second generation, available on a newer host type in a growing set of regions, the hosts are attached more directly to your Azure virtual network, which simplifies connectivity and brings the private cloud closer to native services. Both generations have been described in Microsoft’s release notes, and availability, host types and features differ between them, so confirm which options exist in your target region.

Most AVS design work is network design.

An AVS private cloud must talk to three other places: your on-premises environment, your native Azure resources and the internet. Getting these connections right is the biggest part of a successful deployment.

flowchart TD
  OP["On-premises data centre"] -->|"ExpressRoute or VPN"| HUB["Azure hub virtual network"]
  HUB -->|"Private connection"| AVS["AVS private cloud with NSX segments"]
  OP -.->|"Direct link between on-premises and AVS such as Global Reach"| AVS
  HUB --> SP["Spoke networks with native Azure workloads"]
  AVS -->|"Outbound internet via Azure or NSX"| INT["Internet"]
  AVS --> FW["NSX firewall and Azure firewall controls"]
        

The building blocks

Compute and storage do not always grow at the same speed.

Each host contains local flash disks, and vSAN combines these across the cluster into one shared datastore. This is simple and fast, and it is how virtual machine disks are stored by default. It also means that, if you need more storage, adding hosts adds storage and compute together, even if you only wanted more space.

The vSAN architecture

Recent releases have made the newer vSAN architecture the default on certain host types, which improves performance and space efficiency. The exact architecture and options depend on the host type and region, so check the current documentation for your choice.

Adding capacity without adding hosts

To avoid paying for extra hosts only for storage, AVS lets you attach external datastores that live outside the hosts. This lets storage and compute scale independently.

The tool that makes “move it unchanged” realistic.

VMware HCX is the standard migration tool for AVS. It connects your on-premises VMware environment to the private cloud and moves virtual machines across with several methods, each balancing speed, downtime and effort. It can also extend networks, so a machine keeps its address and its neighbours remain reachable while some are in the old site and some in the new.

sequenceDiagram
  participant Src as On-premises HCX
  participant Mesh as HCX service mesh
  participant Dst as AVS HCX
  participant VM as Virtual machine
  Src->>Dst: Pair environments and build service mesh
  Src->>Dst: Optionally extend the network segment
  Src->>Mesh: Start migration of virtual machine
  Mesh->>Dst: Copy disks and memory state
  alt Live migration
    Dst-->>VM: Machine continues running in AVS
  else Scheduled cutover
    Src->>VM: Short switch-over at agreed time
    Dst-->>VM: Machine starts in AVS
  end
  Dst->>Src: Confirm success and clean up source
        

Migration methods in plain terms

Preparing a migration

The most important change in how AVS is bought.

Understanding licensing is essential, because it has changed significantly and affects both cost and contracts. In the past, Microsoft sold AVS hosts with the VMware software licence included in the price, so you dealt with a single vendor. Broadcom has since moved the major cloud providers to a licence portability model. Under it, the cloud provider cannot bundle the VMware licence into its offering, and customers purchase a VMware Cloud Foundation subscription directly from Broadcom and bring it to the cloud.

What this means in practice

The long-term payoff comes from being next door to a large platform.

A private cloud inside Azure is more than a hosting location. Because it connects privately to native services, you can modernise piece by piece, reusing what Azure offers instead of rebuilding everything inside VMware.

Two layers of control: Azure on the outside, VMware on the inside.

Access to AVS is governed in two places. Azure roles control who can create, scale or delete the private cloud as an Azure resource. Inside, vCenter and NSX have their own users and roles that control who can manage virtual machines, networks and storage.

Good habits

A managed platform does not make your workloads secure by itself.

Microsoft secures the hosts and the platform, but the virtual machines, their operating systems, their network rules and their data remain your responsibility. Security therefore needs several layers.

Day-two operations are much lighter than owning hardware.

A major attraction of AVS is that the tedious platform work is handled for you. Understanding exactly what is covered, and what is not, sets realistic expectations for your operations team.

What the service takes care of

What remains with you

You need a view of the platform, the workloads and the connections between them.

Monitoring an AVS environment spans three areas: the platform health that Microsoft manages, the capacity and performance of the clusters, and the behaviour of your applications and networks.

What to watch

Plan for a failed host, a failed datacentre and a failed region.

AVS offers several layers of protection, and a complete plan uses more than one. Each layer deals with a different size of failure.

flowchart TD
  A["Failure occurs"] --> B{"What failed?"}
  B -->|"One host"| H["vSphere high availability restarts machines on other hosts and failed host is replaced"]
  B -->|"A data centre or zone"| S["Stretched cluster across zones keeps both copies of data"]
  B -->|"A whole region"| R["Disaster recovery to a second region or site"]
  B -->|"Data corruption or deletion"| K["Restore from backup"]
  R --> T["Replication tools and tested runbooks"]
        

Principles for a sound plan

Dedicated hardware means you pay for capacity, not for each virtual machine.

Unlike native Azure virtual machines, which are billed individually, AVS is billed by the host. A private cloud has a minimum starting size, commonly three hosts, and each additional host adds a fixed hourly amount. The skill is to fill those hosts efficiently with virtual machines, while leaving headroom for failures and growth.

How the cost is built up

Ways to keep it efficient

Shapes that work, and shortcuts that hurt later.

Patterns worth adopting

Anti-patterns to avoid

Habits that separate calm migrations from heroic ones.

Best practices

• Assess before you size. Use discovery data to estimate hosts, and revisit after migration with real measurements.
• Settle licensing first. Confirm the VMware subscription route and costs with both vendors before committing.
• Prepare the landing zone. Identity, networking, governance, monitoring and backup must exist before machines move.
• Plan the network carefully. Address ranges, DNS, routing and firewalls need a documented design.
• Pilot with HCX. Test throughput and procedures with a small wave before moving critical systems.
• Keep failure headroom. Size clusters so that a host loss does not overload the rest.
• Segment and secure. Use NSX to control east-west traffic and keep guests patched.
• Back up and rehearse recovery. Keep independent backups and test restores and failover regularly.
• Modernise continuously. Treat AVS as a platform to move off from, one workload at a time, where it makes sense.
• Follow release notes. Platform versions, licensing rules and available features change, so assign someone to track them.

Common mistakes

How different organisations put a data centre inside Azure.

The following scenarios are typical patterns rather than descriptions of specific companies. They show how the same building blocks combine for very different needs.

Quick answers to questions that come up again and again.

A managed service that runs the VMware software stack, including vSphere, vSAN and NSX, on dedicated bare-metal hosts in Azure data centres, so you can move VMware workloads to the cloud with little change.

No. It is a separate VMware environment on dedicated hardware, managed with vCenter and NSX, rather than Azure’s native virtual machine service.

Microsoft manages hardware and the platform software lifecycle. You manage virtual machines, guest operating systems, network design inside the private cloud, security of your workloads and licences.

Mostly with VMware HCX, which offers live, bulk, cold and other migration methods and can extend networks so addresses stay the same during the move. Azure Migrate can assist with assessment.

Under Broadcom’s portability model, new AVS deployments require a portable VMware Cloud Foundation subscription purchased directly from Broadcom, instead of a licence bundled by Microsoft. Transition arrangements for older licence-included hosts have been described with an end date of 31 October 2026, so confirm your position with Microsoft and Broadcom.

The newer generation connects the VMware hosts more directly to Azure virtual networks and uses a newer host type, simplifying connectivity. It is available in selected regions, so check availability and features for your target.

Yes. External datastores such as Azure NetApp Files and Azure Elastic SAN, and some partner options, can be attached so storage scales independently of compute.

A private cloud has a minimum starting size, commonly three hosts. Use assessment data to estimate your real requirement, and confirm the current minimums in the documentation.

Yes. The private cloud connects privately to Azure virtual networks, so workloads can use native monitoring, backup, databases, storage and other services.

Combine vSphere high availability for host failures, stretched clusters where available for zone failures, replication to another region or site for regional disasters, and independent backups with tested restores.

It can be, but many organisations use it as a fast landing place and then modernise or move selected workloads to native services over time, based on cost and value.

Azure VMware Solution is your familiar data centre rebuilt inside Azure. It gives you dedicated bare-metal hosts running vSphere, vSAN and NSX, managed by Microsoft at the hardware and platform level, so you can move virtual machines with HCX with little change, keep your skills and tools, and then modernise at your own pace using nearby Azure services. Success depends on careful planning of networking and address ranges, sizing from real data with headroom for failures, deliberate use of external storage, layered security with micro-segmentation, tested backup and disaster recovery, and above all a clear understanding of licensing. The VMware subscription is now purchased separately from Broadcom, which makes honest cost comparison with other paths essential. Because architecture generations, host types, regions and licensing terms are all changing, always confirm current details in official documentation and with both vendors.