VMware on Azure, after Broadcom.

Azure VMware Solution — Microsoft's first-party VMware-on-hyperscaler offer — has emerged as one of the most discussed cloud destinations for enterprise VMware estates after the Broadcom acquisition reshaped the commercial landscape. The product itself is technically mature and tightly integrated into Azure. The question is what it now costs, how it is sold, and how it fits into a hybrid strategy under the new commercial reality.

This article works through the practical picture: how AVS is delivered and licensed under the Broadcom subscription model, what the renewal economics actually look like, how the cross-environment audit posture applies, and how customers should think about AVS in the context of broader hybrid and multi-cloud decisions in 2026.

The shape of Azure VMware Solution today

Azure VMware Solution sits in a structurally different commercial posture from VMware Cloud on AWS. Microsoft owns the entire customer-facing transaction: the AVS subscription, the underlying Azure infrastructure consumption, the support relationship, and the contractual paperwork. Customers pay Microsoft, not Broadcom, for the AVS-consumed VMware software running on Microsoft-provided bare metal in Azure regions.

Underneath the Microsoft commercial wrapper, however, sit Broadcom-licensed VMware software components. The vSphere, vSAN, and NSX bits that make AVS the SDDC stack it is are sourced from Broadcom on a wholesale basis. Microsoft absorbs that cost into the AVS SKU and presents a single commercial line to the customer. The wholesale Broadcom relationship is invisible to the customer but materially affects the price Microsoft is willing to negotiate.

This commercial structure has held up better than the AWS one through the Broadcom transition. Microsoft's wholesale agreement gives them pricing predictability, and customers continue to transact entirely through their existing Microsoft enterprise channels. The Microsoft account team owns the relationship; the Microsoft EA is the contractual vehicle; the renewal pathway is the same one customers use for the rest of their Microsoft estate.

How AVS is priced today

AVS pricing is delivered through the Azure EA and is structured around per-node consumption with reserved-instance options. The customer commits to a number of nodes (AV36, AV36P, AV52, AV64 SKUs depending on memory and CPU profile) for a 1-year or 3-year reserved term, with significant discounts for the longer commit. Nodes can also be consumed on a pay-as-you-go basis, but this is rare in serious deployments because of the cost differential.

What customers see on the bill is a single per-node price that includes the underlying Azure infrastructure, the Broadcom-licensed VMware software, and the integrated Azure services that AVS depends on. There is no separately listed Broadcom subscription. From a procurement perspective, this simplifies the buying experience considerably; from an audit perspective, it has more subtle implications discussed below.

The headline pricing has been broadly stable through the Broadcom transition. Microsoft has held the per-node prices reasonably steady while absorbing the upstream wholesale changes. The most common adjustment customers see at renewal is in the form of reduced discount levels rather than nominal price increases.

What changed at the contract level

The contractual changes for AVS customers under Broadcom have been less dramatic than for VMware Cloud on AWS, but they are not zero. Several specific shifts are worth noting.

Entitlement portability

Under the pre-Broadcom commercial structure, customers could often use entitlements purchased through VMware to cover workloads running in AVS, with carefully written contractual language. Under the Broadcom subscription model, this portability is more restricted. Broadcom subscriptions for on-premises use are now generally separate from the wholesale entitlement Microsoft holds for AVS, and customers cannot move entitlements freely between the two estates.

The practical effect is that customers operating a hybrid VMware estate need to license both halves separately: their own Broadcom subscription for the on-premises footprint and the Microsoft AVS subscription for the cloud footprint. Workloads that move between the two environments need entitlement on both sides.

Audit posture

The Microsoft-fronted commercial wrapper does not insulate AVS-hosted workloads from Broadcom's audit interpretation. Where the customer has any direct Broadcom subscription — for on-premises VMware, for licensed Symantec or CA products, for VCF — the Broadcom audit clause routinely reads across to AVS-hosted workloads as part of the customer's broader estate. The audit team requests deployment data covering AVS even though no direct Broadcom contract governs the AVS environment.

Microsoft's wholesale agreement with Broadcom handles the AVS-side compliance from Broadcom's perspective, but the customer's broader compliance posture is still scrutinised. We have seen audit findings that effectively double-count AVS workloads — claiming them under both the wholesale agreement and the customer's direct Broadcom subscription — which is a defensible challenge but requires a clear contractual position to make.

Support escalation paths

Support for AVS runs through Microsoft. For pure infrastructure or AVS-platform issues, Microsoft handles the entire interaction. For deeper VMware software issues, Microsoft can escalate to Broadcom through the wholesale relationship, but the customer remains downstream of that escalation rather than party to it. In practice this works well for most issues; the friction shows up in edge cases where the root cause requires direct VMware-Broadcom engagement.

Why customers are choosing AVS in 2026

For customers evaluating cloud destinations for VMware workloads, AVS has become a more attractive option relative to VMware Cloud on AWS for several specific reasons.

Commercial continuity. The fact that the AVS commercial relationship is owned by Microsoft, not by Broadcom directly, gives customers a buffer from the more aggressive elements of the Broadcom commercial playbook. Renewal negotiations happen with Microsoft account teams under EA dynamics, which most enterprises find easier to navigate.

Azure-native integration. AVS is tightly integrated into the broader Azure platform. Identity, networking, monitoring, storage, and security services that are part of the standard Azure estate extend cleanly into AVS-hosted workloads. For customers already running a substantial Azure footprint, this integration is genuinely valuable and reduces the operational complexity of running a hybrid estate.

Microsoft commercial leverage. Customers with large Microsoft enterprise agreements can use existing EA dynamics — bundling, credit programmes, Azure consumption commitments — to negotiate AVS terms more aggressively than they could negotiate a comparable Broadcom subscription directly. The lever is the broader Microsoft relationship, not the AVS line item itself.

Predictable economics. The Microsoft-set per-node pricing has been notably more stable than the Broadcom-set subscription pricing has been for direct customers. For finance teams trying to budget cloud spend over multi-year horizons, this predictability is valuable.

Where AVS is the wrong answer

AVS is not the right destination for every workload. Several specific patterns make it a poor fit.

Pure modernisation candidates. Workloads that could be re-platformed to Azure-native services (App Service, AKS, Azure Functions, Azure SQL) generally should be. Running modernisable workloads in AVS preserves the operational continuity at a cost premium that is hard to justify when the alternative is genuine cloud-native architecture.

Small footprints. AVS has a minimum node commitment that makes small VMware footprints uneconomic. Customers with a few dozen VMs are usually better served by either consolidating onto on-premises infrastructure or migrating to Azure IaaS directly, rather than standing up an AVS node cluster sized for a much larger workload.

Strict data sovereignty. AVS is available in many Azure regions but not all. Customers with data sovereignty requirements that align poorly with Microsoft's regional footprint may need to consider Google Cloud VMware Engine or an on-premises VCF model instead.

Non-Microsoft-centric estates. The commercial advantages of AVS depend on the customer having a meaningful Microsoft relationship to leverage. Customers without a substantial Azure or Microsoft 365 EA do not get the same negotiating dynamic and may find direct Broadcom pricing on-premises more attractive.

The negotiating posture on AVS renewals

Customers approaching an AVS renewal have several specific lever points to consider.

Bundle into the Azure EA cycle. The single most powerful lever is to negotiate AVS as part of the broader Microsoft EA renewal rather than as a standalone item. Microsoft account teams have more flexibility on AVS pricing when it is part of a larger commercial conversation about Azure consumption commitments, M365 licensing, and EA discounts.

Use the alternative path credibly. The credible threat of migrating workloads out of AVS — to on-premises VCF, to Google Cloud VMware Engine, or to Azure-native services — is a real lever. Customers who can demonstrate they have a costed migration plan get materially better outcomes than customers who present the renewal as a routine procurement task.

Right-size the node commit. Over-committing on nodes locks in a multi-year cost that is difficult to unwind. Under-committing creates pay-as-you-go exposure at unfavourable rates. Getting the commit size right against a clear-eyed workload forecast is essential, and many customers should commit to less than the salesperson recommends.

Negotiate the conversion mechanism. Microsoft's EA structure allows for various forms of credit conversion between Azure consumption, M365 licensing, and AVS nodes. Skilled procurement teams can use this flexibility to optimise the commitment shape across multiple Microsoft product lines.

The cross-environment audit defence

Because AVS-hosted workloads frequently appear in Broadcom audits even though the AVS commercial relationship is with Microsoft, customers need a clear contractual position on how AVS workloads are treated.

The defensible position rests on the wholesale agreement between Microsoft and Broadcom: AVS-consumed VMware entitlement is sourced through that agreement, and the customer's direct Broadcom contract does not extend to AVS-hosted workloads. Articulating this position cleanly in audit responses requires that the customer can demonstrate which workloads ran in AVS versus on-premises during the audit period, and that the AVS-hosted workloads are documented in the AVS billing record.

Customers who do not maintain this clean separation often see audit findings that include AVS workloads in the on-premises Broadcom exposure calculation, inflating the claim materially. The fix is process and documentation: ensure AVS deployments are tracked separately from on-premises deployments, and ensure billing records can serve as the authoritative source of truth for AVS-hosted entitlement during an audit.

Architectural implications for hybrid design

For enterprises with a meaningful Microsoft relationship and a substantial VMware estate, AVS deserves serious consideration as part of the hybrid architecture. The specific patterns where it adds clear value include disaster recovery for on-premises VMware estates, data centre evacuation projects with a defined end-state, cloud bursting for workloads with predictable spike patterns, and Azure adjacency for VMware-resident workloads that need close integration with Azure-native services.

The patterns where AVS adds less value include net-new application development (where Azure-native is almost always the right answer), short-lived or unpredictable workloads (where the per-node commitment model is a poor fit), and small or fragmented VMware estates (where the minimum node commit is uneconomic).

For most enterprises, the right shape of AVS adoption is targeted rather than wholesale: a defined slice of the VMware estate moves into AVS for specific use cases, with the rest of the estate staying on-premises and a separate strategy in place for net-new cloud-native workloads. The temptation to use AVS as a one-size-fits-all cloud destination should be resisted; the economics do not support that posture under Broadcom subscription pricing.

What to do now

If you are evaluating AVS as a new destination

Build the business case against the right alternatives. AVS competes against on-premises VCF, against Azure-native re-platforming, against VMware Cloud on AWS, and against Google Cloud VMware Engine. The right destination depends on workload portfolio, existing Microsoft relationship, data sovereignty requirements, and the alternative-path readiness of the operations team. None of these can be assessed without a structured analysis.

If you have an existing AVS footprint approaching renewal

Start the renewal conversation 9 to 12 months before the renewal date. Engage the broader Microsoft account team, not just the AVS specialist. Build the workload-by-workload picture of where AVS is the right answer versus where the workload should be re-platformed or repatriated. Use the alternative paths as negotiating leverage even if you do not intend to execute them.

If you are facing a Broadcom audit that touches AVS workloads

The AVS workloads should be carved out of the on-premises Broadcom exposure on the basis of the Microsoft wholesale agreement. The challenge requires clean documentation of which workloads ran where during the audit period, and a clear contractual articulation of the wholesale-versus-direct distinction. This is exactly the kind of defence work where specialist support is high-leverage.

The strategic bottom line

Azure VMware Solution has emerged from the Broadcom transition in a stronger relative position than VMware Cloud on AWS, primarily because of the Microsoft commercial wrapper that buffers customers from direct Broadcom pricing pressure. For customers with the right shape — meaningful Microsoft relationship, defined VMware-on-Azure use cases, disciplined approach to workload placement — AVS is a credible long-term cloud destination for VMware workloads.

It is not, however, a cheap or simple answer. The per-node economics are real, the contractual integration with the broader Microsoft estate matters, and the cross-environment audit posture requires active management. Customers who treat AVS as a strategic decision and manage it accordingly get good outcomes; customers who treat it as a default cloud destination for VMware workloads consistently end up paying more than they need to for workloads that often should have been re-platformed instead.

The right shape of AVS in any enterprise architecture is a deliberate one. The work of getting there pays back in both lower run-rate cost and stronger negotiating posture at every renewal cycle.