You read an AZ-305 migration scenario, and the source estate runs on VMware. Azure VMware Solution is one of the options, and so are plain Azure VMs. The word VMware in the stem is not the decision. The decision is the target operating model. If the scenario must keep vCenter, NSX, and HCX operations, or it carries fragile IP dependencies or a hard relocation deadline, Azure VMware Solution is the right answer. If the workloads can run on Azure VMs or a managed PaaS service, those are the better targets.
This boundary is what the exam tests. Microsoft's AZ-305 study guide, with skills measured as of April 17, 2026, lists Design migrations under Design infrastructure solutions, 30-35% of the exam. The task statements include evaluating a migration solution with the Cloud Adoption Framework, assessing on-premises servers, data, and applications for migration, and recommending a solution for moving workloads to IaaS and PaaS (AZ-305 study guide). The English AZ-305 exam was updated on April 17, 2026 (AZ-305 exam page). In that domain, AVS is one target among several, and the scenario's constraints select the answer.
The cues that point to each target
Microsoft's Cloud Adoption Framework guidance for Azure VMware Solution, last updated October 1, 2026, states the rule directly. AVS "is often the right choice when the business value of moving to Azure is clear, and the cost, risk, or time required to redesign applications aren't acceptable" (Azure VMware Solution adoption guidance).
Choose Azure VMware Solution when the scenario says:
- the organization must retire infrastructure, exit a colocation facility, or leave another cloud provider, and the path must work with minimal application change;
- business-critical applications rely on operating systems, middleware, or vendor-supported configurations that are not validated on Azure virtual machines;
- the team's VMware expertise, monitoring, backup, and automation are part of what must survive the move;
- workloads need low-latency access to Azure services such as databases, backup, security, or monitoring while staying on VMware;
- the plan uses HCX for migration or L2 network extension, or AVS is the recovery target for an on-premises or other-cloud estate.
Choose Azure VMs or a PaaS target instead when the scenario says:
- the team plans to modernize or refactor the applications in the near term;
- the workloads run well on Azure VMs without VMware dependencies;
- the VMware footprint is small enough to migrate directly to Azure-native services;
- the primary goal is long-term cloud optimization rather than VMware continuity;
- the workloads are new and can be designed cloud-native from the start.
For those last five cases, the same guidance says moving directly to IaaS or PaaS "often provides greater cloud-native benefits and can reduce long-term platform costs."
What an AVS private cloud actually is
An AVS private cloud is the full VMware stack, vSphere, vSAN, and NSX with vCenter Server to manage it, running on dedicated bare-metal Azure infrastructure. Microsoft documents that AVS "provides private clouds that contain VMware vSphere clusters built from dedicated bare-metal Azure infrastructure," and that every provisioned private cloud includes vCenter Server, vSAN, vSphere, and NSX, on a minimum of three hosts, up to 16 per cluster (What is Azure VMware Solution?).
The split of responsibility is part of the design. Microsoft operates and maintains the Azure infrastructure and the VMware platform: it racks and powers the bare-metal hosts, deploys, patches, and upgrades ESXi, vCenter, NSX, and vSAN, and handles health monitoring and corrective actions such as replacing failed hosts. You keep the operational layer above it: NSX network segments and firewall, the vCenter VM lifecycle, OS and application work, and the HCX configuration for migration (responsibility matrix).
The economics run per host. You are billed by the number and size of hosts, not by the number of VMs on them, and you bring VMware Cloud Foundation licenses from Broadcom under a bring-your-own-license model that must cover all the physical cores in the private cloud (CAF AVS plan-readiness guidance). That is why a small server set rarely justifies AVS, and why a scenario that leans on cost optimization is pointing elsewhere.
For new deployments, the current guidance recommends Generation 2, whose hosts attach directly to an Azure Virtual Network. Keep Generation 1, which uses a Microsoft-managed ExpressRoute model, only when an existing deployment or a technical dependency requires it. Moving between generations requires workload migration, so the generation choice is an early design decision.
The practical exam distinction:
- Azure VM migration converts or relocates workloads into Azure IaaS VMs, agent-based or agentless.
- PaaS migration changes the runtime target to App Service, AKS, Container Apps, or a managed database.
- AVS migration moves the workloads into a VMware private cloud in Azure, with HCX as the documented method.
The decision path from on-premises discovery to placement:
The readiness details that confirm an AVS design
AVS questions often hide the deciding fact in the prerequisites. The exam draws on these:
A /22 management address space. A private network /22 address space is required to deploy an AVS private cloud, and it must not overlap with other virtual networks in the subscription or with on-premises networks (AVS FAQ). When a scenario asks how much address space to reserve for the AVS management network, the answer is /22.
ExpressRoute in two flavors. Connectivity from an AVS private cloud to an Azure virtual network runs over an internal ExpressRoute circuit, which Microsoft documents as free of cost regardless of region. On-premises to AVS traffic runs through an Azure virtual network or ExpressRoute Global Reach, because the ExpressRoute Gateway does not provide transitive routing between its circuits (AVS FAQ).
HCX is the migration path. vSphere-to-AVS migration is documented as "possible and recommended via VMware HCX," and HCX Enterprise is "available on Azure VMware Solution at no other cost and is enabled by default" (AVS FAQ). A scenario that names HCX, live vMotion, or content library sync is describing an AVS migration. If it wants AVS as the recovery target for an on-premises estate, the documented DR path commonly uses solutions such as Azure Site Recovery, Jetstream, or Zerto.
Host quota and licensing are planning items. Provisioning requires approved host quota in the target region, and approval can take up to five business days; the subscription must use an eligible plan such as an Enterprise Agreement or a Microsoft Customer Agreement. The Broadcom VCF licenses are part of the deployment request, not an afterthought (CAF AVS plan-readiness guidance).
The assessment targets both VMs and AVS. Azure Migrate, a free service (About Azure Migrate), discovers a VMware environment, maps the dependencies between on-premises servers so you can identify groups of servers to migrate together, and assesses the environment "for moving to Azure Virtual Machines or to the managed Azure VMware Solution offering" (Start here to migrate from VMware to Azure). An answer that skips the assessment and jumps to moving VMs is skipping the architect step.
The platform boundary. AVS VMs are not Azure IaaS objects. Azure Load Balancer internal supports only IaaS VMs, and Azure Bastion cannot connect to AVS VMs directly (AVS FAQ). The adoption guidance diagrams the AVS private cloud as a dedicated workload landing zone inside the Azure landing zone, alongside the other workload landing zones in the estate.
Worked example: a datacenter exit with a VMware estate
Scenario:
A company must leave a leased datacenter in nine months. Most business applications run on VMware vSphere. The operations team depends on vCenter, NSX firewall rules, and existing backup tooling, and several applications have fragile IP dependencies. A few public web apps can modernize later, but the first requirement is to reduce datacenter risk without rewriting the estate. The architecture team also wants a path to Azure-native services after the move.
Exam reasoning:
- The hard requirement is timing and continuity, not immediate modernization.
- The dependency language is VMware-specific: vSphere, vCenter, NSX, backup tooling, and IP-sensitive workloads.
- Azure Migrate still assesses the estate, but the target for most workloads is a VMware-consistent private cloud, and HCX is the documented migration path.
- The landing zone, the /22 management space, and the ExpressRoute path come before the migration wave.
- Modernizing the few web apps is a later phase, not the first answer.
Strong answer:
Assess the estate, group the dependencies, prepare the AVS landing zone and connectivity, migrate the suitable workloads with HCX, and plan the later move of the web apps to Azure-native services.
Weak answer:
Convert every server directly to Azure VMs because VMs are the IaaS migration service. That ignores the fragile IP dependencies, the NSX firewall rules, and the nine-month deadline the scenario sets.
Another weak answer:
Refactor every application into PaaS before the datacenter deadline. Refactoring is the right long-term direction for some of these workloads, but it does not meet the near-term constraint of a working estate in nine months.
When AVS is the wrong answer
AVS is usually the wrong target when the scenario asks for one of these:
- a simple rehost of a small server set with no VMware-operational requirement;
- a web app that moves directly to App Service;
- containerized services that belong on AKS or Container Apps;
- a database migration whose durable target is Azure SQL, SQL Managed Instance, or another managed data service;
- a cost-optimization answer, where paying for dedicated AVS hosts would be disproportionate;
- a mandate to retire VMware operations immediately.
The current CAF guidance lists the same cases from the other side: modernizing in the near term, workloads that run well on Azure VMs without VMware dependencies, a small VMware footprint, a primary goal of long-term cloud optimization rather than VMware continuity, and workloads that are new and cloud-native by design. In those scenarios, moving directly to IaaS or PaaS often provides greater cloud-native benefits and can reduce long-term platform costs.
The presence of VMware in the source environment is not enough. AVS preserves the VMware operating model when that solves a real constraint in the scenario. It is not the destination for every workload that currently runs on VMware.
What a wrong AVS answer reveals
If you pick AVS too often, you are weighting the source platform. Ask what the target operating model should be. Does the business want to keep VMware skills and tools during migration, or is it trying to simplify operations?
If you never pick AVS, you are weighting modernization. Look for the cues the earlier sections list: deadlines, fragile dependencies, a /22 management space, HCX, NSX, vCenter, and datacenter-exit language.
If you confuse AVS with Azure VMs, you are missing the platform boundary. State the target clearly. Azure VMs are Azure IaaS. AVS is a VMware private cloud on Azure infrastructure, and its VMs are not IaaS objects.
If you skip the assessment, you are skipping the architect step. Azure Migrate discovery, dependency grouping, and assessment come before the migration wave, for any target.
Put the rule to work on your migration misses
If a scenario still reads as a tie, ask which constraint is hard. A deadline, an unsupported dependency on VMware tooling, or fragile IPs points to AVS. A cost or simplicity goal with no VMware dependency points to a native target.
Take the free AZ-305 assessment. It is free, needs no credit card, and returns a Readiness Report with your top gaps. After it returns, label each migration miss by its cause: VMware continuity, timing, readiness prerequisites, or the wrong native target. Then fix the boundary behind the most common one against the rule above.