This chapter covers Azure VMware Solution (AVS), a dedicated VMware environment running on Azure bare-metal infrastructure. For the AZ-104 exam, AVS appears in the Compute domain under objective 3.1, typically accounting for 5-10% of questions. Understanding AVS is critical because it bridges on-premises VMware environments with Azure, enabling migration without refactoring. The exam tests your ability to plan, deploy, and manage AVS, including networking, identity, and integration with native Azure services.
Jump to a section
Imagine a company that has a fleet of specialized trucks (VMware-based workloads) operating on their own private road network (on-premises data center). They want to expand into a new city (Azure) without buying new trucks or retraining drivers. Azure VMware Solution (AVS) is like building a dedicated, fully compatible private road network inside Azure's existing highway system. Azure provides the land (bare-metal servers), the road signs (networking), and the traffic control (integration with Azure services), but the company still uses their own trucks (VMware VMs), drivers (vSphere administrators), and dispatching software (vCenter). The company can seamlessly drive their trucks from their private roads onto Azure's private roads via a secure tunnel (ExpressRoute or VPN). They can even use Azure's roadside assistance (native Azure services like Azure Backup, Azure Monitor) to maintain their fleet. AVS ensures the trucks experience the same environment as on-premises, so no modifications are needed. The key is that AVS is not a cloud-native service; it's a dedicated VMware environment running on Azure infrastructure, managed by Microsoft but controlled by the customer.
What is Azure VMware Solution?
Azure VMware Solution (AVS) is a Microsoft-managed VMware environment that runs on Azure dedicated bare-metal infrastructure. It provides vSphere, vCenter, vSAN, and NSX-T Data Center, allowing customers to migrate VMware workloads from on-premises to Azure without rearchitecting applications or changing management tools. AVS is an IaaS offering where Microsoft manages the hypervisor, storage, and networking fabric, while customers retain full administrative access to vCenter and NSX.
Why AVS Exists
Many enterprises have significant investments in VMware-based virtualization. Migrating these workloads to Azure natively would require converting VMs to Azure VMs (using Azure Migrate), refactoring applications, and retraining staff. AVS eliminates these barriers by providing a familiar VMware environment in Azure, enabling lift-and-shift migration with minimal disruption. It also extends on-premises datacenters into Azure for disaster recovery, burst capacity, or application modernization.
How AVS Works Internally
AVS is deployed in an Azure subscription within a specific region. Microsoft allocates dedicated bare-metal servers (e.g., Dell EMC PowerEdge) that are pre-configured with VMware ESXi hypervisor, vSAN for storage, and NSX-T for networking. These servers form a cluster that hosts the VMware management plane (vCenter, NSX Manager) and customer workloads. The cluster is connected to an Azure Virtual Network (VNet) via Azure ExpressRoute (recommended) or VPN. Customers access vCenter and NSX Manager through the Azure portal or directly via a jump box in the same VNet.
Key Components
SDDC (Software-Defined Data Center): The core unit of AVS, consisting of a cluster of ESXi hosts, vCenter, vSAN, and NSX-T. Each SDDC is deployed in an Azure region and can contain multiple clusters.
Cluster: A group of ESXi hosts (minimum 3, maximum 16 per cluster) that share compute and storage via vSAN. Each host has a specific SKU (e.g., AV36, AV36P, AV64) with defined CPU, RAM, and NVMe cache.
vCenter: The management interface for VMware VMs. Customers have full admin rights to create VMs, apply templates, and manage permissions. vCenter is accessed via the Azure portal or directly.
NSX-T Data Center: Provides software-defined networking, including logical switches, routers, firewalls, and VPN. Customers manage NSX-T through the NSX Manager interface.
vSAN: Provides hyper-converged storage across cluster hosts. Storage policies control availability, mirroring, and encryption.
ExpressRoute: The recommended connectivity method between AVS and on-premises or Azure VNets. ExpressRoute provides low-latency, high-bandwidth private connection.
Azure VMware Solution Private Cloud: A managed vSphere environment within a customer's Azure subscription.
Configuration and Verification
Deploying AVS requires: 1. A valid Azure subscription with sufficient quota for the desired host SKU. 2. A resource group and region. 3. A dedicated /22 CIDR range for the AVS management network (e.g., 10.0.0.0/22). This range cannot overlap with Azure VNets or on-premises networks. 4. ExpressRoute gateway or VPN gateway in the same VNet.
After deployment, verify the environment:
From Azure portal: Check AVS resource status, cluster health, and connectivity.
From vCenter: View hosts, datastores, and networks.
Use Azure CLI:
az vmware private-cloud list --resource-group myAVSResourceGroup
az vmware private-cloud show --resource-group myAVSResourceGroup --name myPrivateCloud
az vmware cluster list --resource-group myAVSResourceGroup --private-cloud myPrivateCloudInteraction with Related Technologies
AVS integrates with: - Azure Active Directory: For identity management, vCenter can be configured to use Azure AD as an identity source. - Azure Backup: Backup VMs in AVS using Azure Backup Server or third-party backup solutions. - Azure Site Recovery: For disaster recovery, replicate AVS VMs to another region. - Azure Monitor: Collect logs and metrics from AVS via diagnostic settings. - Azure NetApp Files: Use as external NFS datastore for AVS clusters. - Azure VMware Solution HCX: For advanced migration and mobility features between on-premises and AVS.
Defaults and Timers
Host SKUs: AV36 (36 cores, 576 GB RAM, 15.36 TB NVMe), AV36P (36 cores, 768 GB RAM, 19.2 TB NVMe), AV64 (64 cores, 1024 GB RAM, 30.72 TB NVMe).
Minimum cluster size: 3 hosts for vSAN fault tolerance (RAID-1 mirroring).
Maximum cluster size: 16 hosts.
vCenter retention: 30 days after deletion.
ExpressRoute bandwidth: Up to 10 Gbps.
Exam Tips
Remember that AVS is a dedicated VMware environment, not a native Azure service. You manage VMs via vCenter, not Azure portal.
The management CIDR /22 is critical — it must not overlap with any connected networks.
AVS supports both ExpressRoute and VPN, but ExpressRoute is preferred for production.
You can integrate AVS with Azure AD for authentication, but vCenter still uses its own permissions model.
AVS does not support nested virtualization or certain advanced VMware features like vMotion across SDDCs without HCX.
Plan AVS Deployment
Assess your on-premises VMware environment: inventory VMs, resource usage, and network topology. Determine the required cluster size based on VM needs (CPU, RAM, storage). Ensure you have a non-overlapping /22 CIDR for AVS management. Choose a region close to on-premises for low latency. Verify Azure subscription quota for the desired host SKU (e.g., AV36). Plan connectivity: ExpressRoute or VPN gateway in the same VNet.
Deploy AVS Private Cloud
In Azure portal, navigate to Azure VMware Solution and click 'Create'. Provide subscription, resource group, region, private cloud name, and management CIDR. Select host SKU and initial cluster size (minimum 3). Review and create. Deployment takes 2-4 hours. After deployment, note the vCenter and NSX Manager IP addresses and credentials (provided in the portal).
Configure Network Connectivity
Create an ExpressRoute circuit or VPN gateway in the same VNet as AVS. Authorize the AVS private cloud to use the ExpressRoute. In AVS, configure NSX-T to create logical segments for workloads. Connect these segments to the Azure VNet via the ExpressRoute. Verify connectivity by pinging from an Azure VM to an AVS workload VM.
Configure Identity and Access
Optionally integrate vCenter with Azure AD for identity. In vCenter, add an identity source pointing to Azure AD domain. Assign roles (e.g., CloudAdmin) to Azure AD users. Alternatively, use the default cloudadmin account. For NSX-T, configure role-based access control similarly. Ensure that the proper permissions are set for administrators and end users.
Migrate Workloads to AVS
Use Azure Migrate for discovery and assessment, then migrate VMs using HCX (Hybrid Cloud Extension) or Azure Site Recovery. Install HCX connector on-premises and in AVS. Create a service mesh and migrate VMs with minimal downtime. Alternatively, use vMotion if you have a direct ExpressRoute connection. After migration, verify VM functionality and network connectivity.
Enterprise Scenario 1: Data Center Exit
A large financial institution wants to close an on-premises datacenter but has hundreds of VMware VMs running legacy applications that cannot be refactored for Azure IaaS. They deploy AVS in an East US region with 10 hosts (AV36). They use ExpressRoute for low-latency connectivity to their remaining on-premises systems. They migrate VMs using HCX bulk migration over a weekend. Post-migration, they continue to manage VMs via vCenter, and they enable Azure Backup for VM snapshots. A common misconfiguration is using overlapping CIDR ranges for the AVS management network, causing routing issues. They also learned that AVS hosts are dedicated — they cannot be shared with other customers.
Enterprise Scenario 2: Disaster Recovery
A healthcare provider uses on-premises VMware for critical patient data systems. They deploy AVS in a secondary Azure region as a DR site. They replicate VMs using Azure Site Recovery (ASR) with AVS as the target. ASR continuously replicates changes to AVS vSAN storage. In a disaster, they failover VMs to AVS and access them via ExpressRoute. They test DR quarterly. The key challenge is ensuring the AVS cluster has sufficient capacity to run all VMs during failover. They also configured Azure AD authentication for vCenter to avoid managing separate credentials.
Scenario 3: Burst Capacity
A retail company experiences seasonal spikes in demand for their e-commerce platform. They have a baseline on-premises VMware environment but need extra compute during holidays. They deploy AVS with 3 hosts and use HCX to extend their on-premises network into AVS. During peak season, they vMotion additional VMs to AVS. After the season, they move VMs back. They discovered that AVS does not support auto-scaling — they must manually add or remove hosts. They also had to ensure their NSX-T network segments matched on-premises VLANs to avoid IP conflicts.
AZ-104 Exam Focus on AVS
The exam tests your understanding of AVS as a migration path for VMware workloads. Key objectives include:
Plan and deploy AVS (Objective 3.1)
Configure networking for AVS (ExpressRoute, VPN, NSX-T segments)
Integrate with Azure AD
Understand licensing and billing (AVS hosts are billed per hour)
Common Wrong Answers
'AVS VMs are managed in Azure portal' — Wrong. AVS VMs are managed via vCenter, not Azure portal. The Azure portal only shows the AVS private cloud resource.
'AVS supports any VMware version' — Wrong. AVS runs a specific, validated version of VMware software (e.g., vSphere 7.0 U3). Not all features are supported.
'AVS is a shared multi-tenant environment' — Wrong. AVS provides dedicated hosts per customer; no multi-tenancy.
'AVS can be deployed without a VNet' — Wrong. AVS requires an Azure VNet for connectivity; you cannot deploy it standalone.
Specific Exam Numbers
Management CIDR: /22 (must not overlap)
Minimum hosts per cluster: 3
Maximum hosts per cluster: 16
Host SKUs: AV36, AV36P, AV64
ExpressRoute bandwidth: up to 10 Gbps
Edge Cases
If you delete the AVS private cloud, vCenter is retained for 30 days.
AVS cannot be directly peered with Azure VNets; it requires an ExpressRoute or VPN gateway.
AVS does not support Azure DNS; you must configure DNS manually in NSX-T.
Eliminating Wrong Answers
Understand the underlying mechanism: AVS is a dedicated VMware environment. If a question asks about managing VMs, the answer should involve vCenter, not Azure portal. If a question asks about networking, think about NSX-T and ExpressRoute. Remember that AVS is not native Azure compute; it's a bridge for existing VMware.
AVS provides a dedicated VMware environment on Azure bare-metal infrastructure.
Minimum cluster size is 3 hosts; maximum is 16 hosts per cluster.
Management CIDR must be /22 and not overlap with connected networks.
Connectivity to Azure VNets requires ExpressRoute or VPN gateway.
VMs are managed via vCenter, not Azure portal.
AVS supports integration with Azure AD for identity.
AVS hosts are billed per hour; you can stop billing by deleting hosts.
HCX enables advanced migration and mobility features.
These come up on the exam all the time. Here's how to tell them apart.
Azure VMware Solution (AVS)
Runs VMware vSphere, vCenter, vSAN, NSX-T
Managed via vCenter, not Azure portal
Lift-and-shift migration without refactoring
Dedicated bare-metal hosts per customer
Billed per host per hour
Native Azure VMs
Runs Hyper-V based Azure compute
Managed via Azure portal, CLI, or PowerShell
Requires refactoring or conversion for VMware VMs
Multi-tenant shared infrastructure
Billed per VM per hour (or reserved instances)
Mistake
AVS VMs appear in Azure portal as virtual machines.
Correct
AVS VMs are managed exclusively through VMware vCenter. The Azure portal only shows the AVS private cloud resource and its clusters.
Mistake
AVS is a multi-tenant service like Azure VMs.
Correct
AVS provides dedicated bare-metal hosts per customer. No other tenant shares your hosts.
Mistake
You can use any VMware version and features in AVS.
Correct
AVS runs a specific, validated VMware version (e.g., vSphere 7.0 U3). Some advanced features like vMotion across SDDCs require HCX.
Mistake
AVS integrates directly with Azure VNets without additional gateways.
Correct
AVS requires an ExpressRoute or VPN gateway in the same VNet to connect to Azure VNets.
Mistake
AVS supports auto-scaling of hosts based on demand.
Correct
AVS does not auto-scale. You must manually add or remove hosts via the Azure portal or CLI.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AVS is a Microsoft-managed VMware environment running on Azure dedicated bare-metal servers. It provides vSphere, vCenter, vSAN, and NSX-T, allowing you to migrate on-premises VMware workloads to Azure without refactoring. You manage VMs through vCenter, and AVS integrates with Azure services like ExpressRoute, Azure AD, and Azure Backup.
Use Azure ExpressRoute for a private, high-bandwidth, low-latency connection. Alternatively, use a site-to-site VPN. Both require an ExpressRoute or VPN gateway in the same Azure VNet as AVS. You must also configure NSX-T to route traffic between on-premises and AVS segments.
No. AVS VMs are managed exclusively through VMware vCenter, which you access via a web browser or VMware tools. The Azure portal only shows the AVS private cloud resource, cluster health, and connectivity status.
The main SKUs are AV36 (36 cores, 576 GB RAM, 15.36 TB NVMe), AV36P (36 cores, 768 GB RAM, 19.2 TB NVMe), and AV64 (64 cores, 1024 GB RAM, 30.72 TB NVMe). Choose based on workload requirements.
Minimum 3 hosts for vSAN fault tolerance. Maximum 16 hosts per cluster. You can have multiple clusters in a single AVS private cloud.
Yes. You can use Azure Site Recovery (ASR) to replicate on-premises VMware VMs to AVS for disaster recovery. ASR installs the Mobility service on VMs and replicates changes to AVS vSAN storage.
The management CIDR is a /22 IP range used for AVS internal management (vCenter, NSX, etc.). It must not overlap with any connected Azure VNets or on-premises networks. Overlap causes routing conflicts and deployment failure.
You've just covered Azure VMware Solution (AVS) — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?