Azure VMware Solution, licensed.

Azure VMware Solution is licensed through Microsoft, not through Broadcom directly — but the per-node pricing, the entitlement structure, and the cross-environment audit interaction with Broadcom are all things customers need to understand precisely. This article works through the AVS licensing mechanics in detail: SKUs, reservations, what the per-node price covers, what it does not, and how to negotiate the renewal.

For customers operating a hybrid VMware estate where AVS is one of the destinations, the licensing detail matters for cost certainty, audit posture, and the practical questions of when AVS is the right answer versus when an alternative would serve the workload better.

The AVS commercial structure

Azure VMware Solution is sold by Microsoft as a first-party Azure service. The customer's contractual counterparty is Microsoft, the billing flows through the Azure subscription, and the entitlement is recorded in the customer's Azure tenant. Underneath the Microsoft wrapper, Microsoft has a wholesale agreement with Broadcom that covers the VMware software components running in AVS. That wholesale relationship is invisible to the customer.

The practical effect is that AVS renewals happen through the Microsoft EA cycle, AVS support runs through Microsoft Premier or Unified Support, and AVS pricing is set by Microsoft within bounds negotiated against the wholesale Broadcom agreement. Customers who try to engage Broadcom directly on AVS pricing get redirected to Microsoft; customers who try to negotiate AVS terms outside the broader Microsoft EA conversation typically get less flexibility than they could get within it.

The node SKU model

AVS is sold in per-node units. The available SKUs map to specific hardware configurations:

AV36: 36 physical cores, 576 GB memory, 15.4 TB raw cache, 15.4 TB raw capacity. The baseline SKU, suitable for general-purpose VMware workloads.

AV36P: Higher-performance variant of AV36 with NVMe-based cache for storage-intensive workloads.

AV52: 52 physical cores, 1.5 TB memory, larger storage capacity. For memory-intensive workloads.

AV64: 64 physical cores, 1 TB memory, expanded storage. For higher core-count workloads.

Each node is a fully populated bare-metal host running ESXi, with vSAN-resident storage and NSX-managed networking. The customer's SDDC is built from a minimum of 3 nodes and scales in single-node increments.

The pricing per node is the all-in figure that includes the Azure infrastructure, the VMware software entitlement sourced via the Microsoft-Broadcom wholesale relationship, and the integrated platform components that Azure layers on top.

Reservation pricing

AVS pricing offers significant discounts for reserved-instance commitments. The structure is typical of Azure reservations: 1-year or 3-year terms, with discount levels that scale with the term length.

The 3-year reserved price is generally 35% to 45% below the pay-as-you-go price, depending on the SKU. The 1-year reserved price is generally 15% to 20% below pay-as-you-go. Pay-as-you-go is typically only used for short-term capacity additions or for proof-of-concept deployments; sustained production workloads run on reserved terms.

One important detail: AVS reservations can be paid upfront or on a monthly basis without changing the discount level. For finance teams managing cash flow, this is a useful flexibility that does not exist in some other Azure reservation programmes.

Reservations can be exchanged or cancelled within the standard Azure reservation programme rules. Microsoft has historically been reasonable about reservation cancellations where customer circumstances change materially, although the formal terms allow for cancellation fees.

What the per-node price covers

The AVS per-node price covers a defined set of components, and customers should be precise about what is in and what is out.

Included: Bare-metal host infrastructure, ESXi software, vCenter, vSAN storage (using the node's local NVMe), NSX networking (including the standard NSX-T edge nodes that AVS provisions), HCX for migration, and the Azure-integrated platform services that AVS depends on for identity, monitoring, and lifecycle.

Not included: Aria Operations, Aria Automation, and other Aria suite components are licensed separately. Tanzu Kubernetes Grid is a separate licence. NSX Advanced Threat Prevention and other premium networking add-ons require separate licensing. VMware Site Recovery Manager is separate.

Azure-side charges: Data egress from AVS to other Azure regions or to the public internet incurs standard Azure data transfer charges. ExpressRoute or VPN connectivity from on-premises to AVS is billed separately. Storage beyond the included vSAN capacity (Azure NetApp Files, Azure Storage) is billed at standard Azure rates. Azure-side IP addresses, Azure Bastion, and other Azure services that customers commonly use alongside AVS are all separately billed.

For most production AVS deployments, the Azure-side charges add 15% to 25% to the per-node cost on a steady-state basis, with significant variability depending on workload patterns.

How the audit posture works

Because AVS is licensed through Microsoft's wholesale relationship with Broadcom, AVS-hosted workloads are commercially covered without the customer needing to hold direct Broadcom entitlement for them. This is the key audit-posture distinction.

In a Broadcom audit of a customer's broader VMware estate, the customer can articulate a defensible position that AVS-hosted workloads are covered by the Microsoft wholesale agreement and should not be counted as exposure against the customer's direct Broadcom subscription. Broadcom's audit team frequently includes AVS workloads in their initial findings; the challenge is straightforward to make if the customer has clean documentation of which workloads ran where.

The documentation that supports this defence includes Azure billing records showing AVS node consumption during the audit period, deployment records identifying which workloads ran on AVS versus on-premises, and clear contractual language in the on-premises Broadcom subscription that limits the entitlement scope.

Customers without clean documentation often find AVS workloads bundled into the on-premises exposure calculation, materially inflating the audit claim. The fix is process and tooling, established before the audit notice arrives.

The renewal economics

AVS renewals tend to be more predictable than direct Broadcom subscription renewals, because Microsoft sets the AVS pricing within bounds set by the wholesale agreement and has generally held those bounds steady. The most common adjustment customers see at renewal is in the form of reduced discounting on EA bundling, not in the form of nominal price increases on the AVS line.

The most important renewal lever is bundling. Customers who negotiate AVS as part of the broader Microsoft EA renewal — alongside Azure consumption commitments, M365 licensing, and other Microsoft estate — get materially better outcomes than customers who negotiate AVS as a standalone line item.

The second lever is the credible alternative path. Customers who can demonstrate a costed plan to migrate workloads out of AVS — to on-premises VCF, to Google Cloud VMware Engine, or to Azure-native services — get better outcomes than customers who present AVS as an immutable commitment.

The third lever is right-sizing the reservation. Microsoft's reservation programme allows for some flexibility in cancellation and exchange, but the practical work is in not over-committing in the first place. Reservations should be sized to the realistic node demand, not to the optimistic forecast.

Common AVS licensing pitfalls

Several specific licensing patterns regularly produce unexpected cost or audit exposure.

Over-provisioning for elasticity. AVS reservations charge for the committed node count, not for the consumed capacity. Customers provisioning capacity for worst-case demand spikes pay for the headroom whether or not it is consumed. The right balance is to size reservations for the baseline and accept some pay-as-you-go pricing for true spike events.

Aria suite assumption. Customers commonly assume that Aria Operations or Aria Automation comes with AVS because they came with on-premises VMware. They do not; they are separate licences. Customers who deploy Aria on AVS without confirming entitlement are technically out of compliance.

HCX licence creep. HCX is included in AVS for migration purposes, but the Enterprise tier of HCX (with advanced features) sometimes requires separate licensing. Customers running long-term active-active replication between on-premises and AVS occasionally find this out at audit time.

Cross-tenant deployments. Customers running AVS workloads on behalf of subsidiaries or affiliates need to be precise about whose Azure tenant the AVS subscription sits in and which legal entity is the contracting party. Cross-entity AVS use without clean contractual structure can produce unexpected audit findings.

Where AVS sits in the hybrid architecture

For customers building a hybrid VMware architecture in 2026, AVS earns its place in the design where specific conditions hold: a substantial Microsoft enterprise relationship that gives meaningful EA leverage, defined VMware-on-cloud use cases that justify the per-node cost (typically DR, data centre evacuation, or Azure adjacency), and operational capacity to manage a multi-environment VMware estate.

It does not earn its place where workloads could reasonably be re-platformed to Azure-native services, where the VMware footprint is too small to make the minimum node commitment economic, or where the broader Microsoft relationship does not provide enough negotiating leverage to make the EA dynamic work.

The right shape of AVS adoption in most enterprises is targeted: a defined slice of workloads in AVS for specific reasons, with the rest of the estate distributed across on-premises VMware, Azure-native services, and other cloud destinations as appropriate.

What to do now

Audit your AVS entitlement against actual deployment

Periodically reconcile your reserved node count against actual node deployment. Over-committed reservations are wasted spend; under-committed reservations create pay-as-you-go exposure. The reconciliation should happen quarterly at minimum, and more often if the workload profile is changing.

Document the boundary between AVS and on-premises clearly

For audit defence purposes, you need to be able to articulate cleanly which workloads ran in AVS versus on-premises during any given period. Azure billing records are the authoritative source; deployment tooling should align with the billing record so there are no discrepancies that can be exploited in an audit.

Use the Microsoft EA cycle as the renewal lever

Do not negotiate AVS renewals as standalone line items. Engage the broader Microsoft account team and bundle AVS into the EA conversation. The leverage you have on the EA dynamic does not exist on the AVS line in isolation.

The strategic bottom line

Azure VMware Solution licensing is one of the cleaner stories in the post-Broadcom VMware landscape. Microsoft's wholesale agreement with Broadcom buffers customers from the most aggressive elements of direct Broadcom pricing, the Azure EA dynamic provides real negotiating leverage, and the per-node SKU model is easier to budget against than the per-core subscription model that applies on-premises.

The work to manage AVS licensing well is bounded but real: right-sized reservations, clean entitlement documentation, audit-defence preparation, and disciplined integration with the broader Microsoft renewal cycle. Customers who do this work consistently get good outcomes from AVS; customers who do not consistently pay more than they should and carry more audit exposure than they need to.

For the right workload profile and the right customer shape, AVS is a credible long-term destination for VMware workloads. For the wrong profile, it is an expensive way to run workloads that should have been re-platformed to Azure-native services or kept on-premises under a tight VCF subscription. The decision is workload-by-workload, not platform-by-platform.