Azure VMware Solution is one of the most misunderstood services in the cloud catalogue. To some it is a cheat code for getting out of a data centre in weeks; to others it is an expensive way to avoid making a decision. Both are right, depending on what you do with it. This is a practitioner's view of what AVS actually is, why teams reach for it, the strategic question that decides whether it pays off, the licensing reality that changed under everyone's feet in late 2025, and the security risks that do not show up on an Azure dashboard.
What AVS actually is
Azure VMware Solution runs a complete VMware private cloud on dedicated, single-tenant bare-metal hosts inside an Azure region. Not VMware-like, not a migration tool, the real stack: vSphere for compute, vSAN for storage, NSX for networking and the distributed firewall, and HCX for migration, delivered as VMware Cloud Foundation. It is a first-party Microsoft service, so it sits in your Azure subscription, bills through Azure, and connects natively to Azure networking and services.
The division of labour is the thing to internalise, because it drives both the operating model and the security model. Microsoft operates the physical hosts and the VMware software-defined data centre underneath: it patches and lifecycle-manages vSphere, vSAN and NSX, and it guarantees the infrastructure. You operate everything from vCenter upward: your virtual machines, their guest operating systems and applications, your NSX firewall policy, your templates and your access model. Crucially, you are given a CloudAdmin role in vCenter, not full administrator and not root on the hosts. So it is your VMware estate, with the undifferentiated heavy lifting of the platform handled for you, and a clear line above which everything is yours.
Generations, and the licensing change that caught people out
Two details matter in 2026 because they are recent and they change the maths. First, generations. The original AVS (now Generation 1) runs on dedicated Dell hosts, the AV36, AV36P, AV48 and AV52 node sizes, and reaches your Azure virtual network over ExpressRoute. Generation 2, generally available since September 2025, runs on general-purpose Azure hardware with the AV64 node, delivers higher throughput, and no longer requires ExpressRoute, it uses Azure networking constructs directly. The minimum cluster is three nodes either way.
Second, and more consequential, licensing. Following Broadcom's VMware licensing changes, from 1 November 2025 Microsoft no longer bundles the VMware licence into the AVS node price. You now bring a portable VMware Cloud Foundation subscription purchased directly from Broadcom. So where AVS used to be a single bill, it is now two counterparties: Microsoft sells you the host and the managed service, and Broadcom sells you the VCF licence that runs on it. The older licence-included SKUs are being retired, with the cut-off on 30 August 2027. If you are modelling AVS cost, the Broadcom subscription is a separate, significant line that is easy to forget and that Broadcom does not publish a public price for.
Why teams reach for it
The appeal is almost always about speed and risk, not technology. The clearest case is a data-centre exit on a deadline: a lease ending, a hardware refresh you do not want to fund, or a site closure. AVS lets you move the estate into Azure in weeks without re-architecting a single application, because the destination is the same VMware you already run. HCX does the heavy lifting, bulk and live migration from on-premises into AVS, at scale, with rollback, which turns what would be a risky big-bang cutover into a controlled, reversible flow.
The second driver is people and process. Your team keeps the same vCenter, the same runbooks, the same operating model and the same skills. You are not asking everyone to become cloud-native engineers overnight while also hitting a migration deadline. The third is disaster recovery: AVS is a ready DR target for an on-premises VMware estate, without standing up a second physical site. And increasingly, the fourth is simply that Broadcom's on-premises licensing has become expensive enough that a managed VMware platform in Azure is worth comparing against staying put.
The real decision: staging post, or permanent home?
This is where AVS projects succeed or quietly fail, and it is worth being even-handed because the honest answer is not a slogan. There are two legitimate ways to use AVS, and one costly mistake that looks like both.
Used well, AVS is a staging post. You exit the data centre fast, which removes the deadline that was forcing every decision, and then you modernise selectively, from a position of safety, with the estate already in Azure. Some workloads become Azure IaaS virtual machines; some are replatformed onto managed PaaS; some are retired or replaced by SaaS. The point is that modernisation becomes a deliberate, funded, per-workload choice rather than a forced march against a lease expiry. AVS buys you that optionality.
Used badly, AVS is a dead end. You lift and shift the estate, breathe a sigh of relief when the data centre is gone, and then nothing else happens. The modernisation that justified the move never gets owned or funded, "temporary" becomes permanent, and you find yourself paying premium dedicated-host prices, plus a separate Broadcom VCF subscription, to run the exact same undifferentiated virtual machines you ran before. You have not reduced technical debt; you have relocated it to a more expensive address and added a second vendor relationship.
The third use is legitimate and often confused with the dead end: some workloads genuinely belong on AVS for the long term. A stable, VMware-dependent application with no modernisation payoff, a system constrained by compliance or a vendor support matrix, something approaching end of life where refactoring would be throwing good money after bad, these can rightly stay. The error is not keeping workloads on AVS. The error is treating "staging versus refactor" as a single estate-wide decision when it is a per-workload one.
Map each workload to the six Rs and let the workload's own characteristics choose. Rehost (keep it on AVS, or move it to Azure IaaS) when it is stable, deeply VMware-dependent, compliance-bound, or simply not worth the refactor. Replatform onto managed PaaS, or repurchase as SaaS, where that removes real operational toil. Refactor only where the cloud-native payoff is real and someone owns it. Retire what no longer earns its keep.
The inputs that matter: workload stability and remaining lifecycle, depth of vSphere and NSX dependencies, modernisation appetite and whether an owner exists, data gravity and compliance, and the FinOps comparison, does the all-in cost of AVS, including the Broadcom subscription, beat the cost and risk of refactoring, over a horizon you can actually commit to?
Security: the risks that do not show on an Azure dashboard
AVS changes the shared-responsibility line in a way that catches security teams out, because it looks like Azure but behaves like a private cloud you own. Microsoft secures the physical hosts and the SDDC platform. Everything above, the guest operating systems, the applications, the identity and access model, and critically the network policy inside NSX, is yours. You hold CloudAdmin, not root, so some hardening is Microsoft's, but far more of it is yours than on a native Azure PaaS service.
The single most important thing to understand is the blind spot: native Azure security tooling does not reach inside the VMware estate. Microsoft Defender for Cloud, network security groups and VNet flow logs operate at the Azure virtual-network layer. They do not see the traffic between virtual machines inside the AVS software-defined data centre. That east-west traffic is governed only by the NSX distributed firewall, and it is visible only to in-guest agents and to the NSX, vCenter and ESXi logs you choose to forward to Microsoft Sentinel. Stand up AVS, migrate everything, and do nothing else, and you have a large estate that your Azure security posture cannot see at all. And because HCX migrates virtual machines exactly as they are, every over-permissive rule, unpatched operating system and flat network you had on-premises moves across unchanged. Your on-premises sins migrate with you.
A STRIDE threat model for AVS
The same six lenses I use in the STRIDE threat modelling project map cleanly onto an AVS deployment. Each threat below is paired with the control that addresses it.
The management plane is the whole estate. vCenter and NSX Manager sign-in, especially a CloudAdmin account with a weak, shared or reused password and no multi-factor authentication, is the first door an attacker tries. Integrate identity with Entra ID and your directory rather than relying on local SSO, enforce phishing-resistant MFA, use just-in-time privileged access, and never share the CloudAdmin credential.
A single changed NSX distributed-firewall rule, vCenter setting or VM template can open the estate quietly, and nothing in Azure will flag it. Enforce role-based access control inside vCenter and NSX, put change control around firewall and configuration changes, and monitor the SDDC configuration for drift.
vCenter, NSX and ESXi audit logs do not reach Microsoft Sentinel unless you forward them. Without that forwarding, actions inside the estate are invisible and deniable, and incident response has nothing to work with. Configure log forwarding to Log Analytics and Sentinel on day one, with retention that outlasts a slow intrusion.
Lifting flat on-premises networks into AVS brings the same east-west exposure with it, and the NSX distributed firewall, which is exactly the control that would contain it, is present but usually left wide open. The confidentiality risk is lateral movement to sensitive data and exfiltration through broad egress. Turn on micro-segmentation with the NSX DFW, keep the data path private, and inspect egress through Azure Firewall.
The management plane and the shared connectivity into Azure are single points of failure, and vSAN capacity exhaustion is a real operational risk on a fixed cluster. Plan capacity with headroom, protect any public endpoints with DDoS protection, and keep the management network off the public internet.
The escalation paths that matter are a compromised virtual machine reaching the management network and pivoting to vCenter or NSX, and a CloudAdmin role stretched further than it should be. Segment the management plane away from workload networks, restrict who can reach it and from where, apply least privilege rigorously, and monitor for privilege use that does not fit a pattern.
None of this is exotic, and that is the point. AVS security fails not because the risks are novel but because teams assume their Azure security posture covers an estate it structurally cannot see. Treat the AVS private cloud as what it is, a VMware data centre that happens to live in Azure, and secure it as you would secure any VMware estate, plus the forwarding and segmentation that make it visible to your cloud tooling.
The honest summary
Azure VMware Solution is a genuinely useful service with a narrow sweet spot and an easy failure mode. It is the fastest, lowest-risk way to get a VMware estate off its own hardware and into Azure, and a legitimate long-term home for the workloads that have no better place to be. It becomes a liability when it is used to avoid a decision rather than to buy time for one, when the modernisation it was meant to enable never gets owned, and when it is secured as if it were native Azure when it is really a private cloud you are responsible for. Model the full cost, including the Broadcom subscription that is now a separate line. Decide per workload, not per estate. And wire up the logging and segmentation before you migrate, not after, because until you do, the estate is in Azure but invisible to it.
If you are weighing an AVS move, whether it is the right destination, which workloads should pass through it and which should stay, and how to secure it properly, that is the kind of work I do through Cyber Spartans.