VMware Cloud on AWS, licensed.
The per-core mechanics, what is included, what is separate, and how the audit posture reads cloud-hosted workloads in 2026.
VMware Cloud on AWS sits at the centre of one of the most consequential commercial transitions in enterprise software. The product is technically intact; the licensing model around it has been rebuilt by Broadcom. This article works through the licensing mechanics — what is on the SKU, how the per-core subscription applies, where the audit interpretation lands, and what the practical renewal economics look like in 2026.
If you operate VMware Cloud on AWS or are considering it as a destination for on-premises workloads, the licensing detail is where the real money sits. Understanding it precisely is the difference between a defensible renewal and an expensive surprise.
How VMware Cloud on AWS is now licensed
Following the Broadcom commercial transition, VMware Cloud on AWS is licensed through a direct Broadcom subscription. AWS provides the underlying infrastructure but does not hold the customer-facing commercial relationship for the VMware software. The customer transacts with Broadcom for the VMware subscription and with AWS for the supporting Direct Connect, VPC, and other AWS services that the SDDC integrates with.
The Broadcom-side subscription is structured around per-core entitlement. Each ESXi host in the AWS-hosted SDDC consumes a defined number of cores against the customer's VCF or per-product entitlement. The host SKUs available — i3.metal, i3en.metal, i4i.metal, and newer generations — each have a defined core count that determines the entitlement burn rate.
For new contracts in 2026, Broadcom's default offer is VCF subscription that covers both on-premises and AWS-hosted workloads under a single per-core entitlement pool. The pitch is operational simplicity; the practical effect is that customers find it harder to right-size their cloud footprint separately from their on-premises footprint.
The per-core metric in cloud context
The per-core subscription metric applies in the cloud the same way it applies on-premises, with two specific wrinkles that matter for cost planning.
First, the AWS-hosted host SKUs typically have higher core counts than typical on-premises ESXi hosts. An i4i.metal carries 64 physical cores; a comparable on-premises 2U server might carry 32 or 48 cores. This means that the per-host entitlement burn rate in the cloud is higher than customers expect when they migrate from on-premises to cloud.
Second, the cloud-hosted hosts are sized to AWS bare metal SKUs, not to the customer's workload profile. A workload that fits comfortably on a 32-core on-premises host gets allocated to a 64-core cloud host, consuming the full 64-core entitlement even if the workload uses a fraction of the capacity. The per-core metric does not adjust for utilisation.
The combined effect is that the entitlement consumption for a given workload in VMware Cloud on AWS can be 1.5x to 2x the entitlement consumption for the same workload on-premises. Many customers do not catch this in their migration economics and end up over-consuming their entitlement pool relative to plan.
What is included and what is separate
Understanding what the Broadcom subscription covers in VMware Cloud on AWS — and what it does not — is essential for accurate cost and audit planning.
Included in the VCF subscription: vSphere ESXi, vCenter, vSAN storage, NSX networking, HCX migration tooling, and the lifecycle management components that Broadcom delivers as part of the VCF stack. Standard SDDC operations and the Broadcom-provided integrations with AWS infrastructure are all covered.
Not included: Aria suite components (Aria Operations, Aria Automation, Aria Logs) are licensed separately on top of the VCF subscription. Tanzu Kubernetes components are similarly separate. Add-on networking services like NSX Advanced Threat Prevention require additional licensing. Backup and disaster recovery products from Broadcom-owned VMware Site Recovery are licensed separately.
AWS-side charges: The Broadcom subscription does not cover the AWS infrastructure charges. Data transfer between AVS and other AWS services, Direct Connect circuits, public IP addresses, and various network and storage egress charges are billed directly by AWS and can become a material cost line on their own.
Customers building cost models for VMware Cloud on AWS regularly underestimate the AWS-side charges, which can run 20% to 40% of the total cost of running the environment in scenarios with significant data movement.
Subscription term structures and pricing
Broadcom subscription terms for VMware Cloud on AWS are typically 1-year or 3-year, with 3-year being the heavily discounted default. Monthly pay-as-you-go pricing exists but at a premium that makes it impractical for serious workloads.
The discount differential between 1-year and 3-year terms is significant — often 20% to 30% lower per-core on 3-year commits — which creates a strong commercial pull toward longer commitments. The risk on the customer side is that 3-year commitments lock in pricing and entitlement structures during a period when Broadcom's commercial model is still evolving, and during a period when customer requirements are changing rapidly.
The right balance for many customers sits at 2-year terms with a structured ramp clause that allows incremental commit increases over the period. This shape captures most of the longer-term discount without surrendering the flexibility to right-size in year two if circumstances change.
The audit dimension
The licensing audit posture for VMware Cloud on AWS has tightened materially since Broadcom assumed the commercial relationship. Several specific audit patterns are worth understanding.
Per-host audit posture. Broadcom's audit team treats each ESXi host in the AWS-hosted SDDC as a fully entitled compute unit. The host's core count drives the entitlement consumption, regardless of actual workload utilisation. This is consistent with the on-premises posture but is a more aggressive interpretation than AWS historically applied when AWS sold the product.
Transient workload exposure. Workloads that ran briefly in VMware Cloud on AWS — for testing, DR drills, cloud bursting events — are surfacing in audits as compliance gaps if the customer did not have entitlement covering the period the workload ran. The audit team uses Broadcom's telemetry to identify these transient workloads.
Cross-region scrutiny. Customers who have deployed VMware Cloud on AWS in multiple AWS regions are seeing audits that read across regions and aggregate the entitlement consumption. Customers who planned their entitlement footprint on a per-region basis sometimes find themselves under-entitled in aggregate.
The defence against these patterns rests on clean operational records: documented workload deployment dates, defined entitlement allocations against specific environments, and contractual language that establishes the boundary between AWS-hosted and on-premises consumption.
Right-sizing the entitlement pool
For customers running VMware Cloud on AWS at scale, the most important cost lever is matching the entitlement pool to the actual workload demand. Over-subscription is the most common cost overrun in this space.
Three specific patterns drive over-subscription:
Cloud bursting buffer. Customers commonly provision enough cloud capacity to absorb a worst-case demand spike, leaving capacity idle most of the time. The per-core entitlement model charges for the provisioned capacity, not the consumed capacity, so the idle capacity is a paid-for asset that earns nothing. Right-sizing requires accepting some risk of bursting beyond the provisioned envelope, or accepting some pay-as-you-go pricing for true spike events.
DR-target oversizing. Standby DR targets are often sized for the worst-case failover scenario rather than the realistic one. Where the realistic recovery shape involves prioritised workloads coming up first, the standby capacity can be smaller than full-fleet sizing implies. The right DR-target sizing decision balances recovery time against entitlement cost.
Migration buffer that never gets reclaimed. Customers running a migration project commonly provision both the source and the target capacity during the migration window. The migration finishes, but the source capacity is not always promptly retired. The on-premises entitlement keeps running alongside the cloud entitlement, doubling the total bill against the actual workload.
Disciplined entitlement management requires regular reconciliation against actual workload demand, with documented decision points for ramp-up and ramp-down. The customers we see with the lowest run-rate cost have this discipline; the customers we see paying the most do not.
The renewal negotiation
For customers approaching a VMware Cloud on AWS renewal, several specific levers deserve attention.
The most important is to start the conversation early — 9 to 12 months before the renewal date — with a clear-eyed view of the alternative paths. The alternatives include staying with a renegotiated subscription, migrating to Azure VMware Solution or Google Cloud VMware Engine, re-platforming to AWS-native services, or repatriating workloads on-premises. Customers who walk into the renewal conversation with a costed view of each alternative consistently achieve materially better outcomes.
The second important lever is the entitlement portability question. Broadcom's preferred renewal shape bundles on-premises and cloud entitlement into a single VCF pool. Customers can negotiate language that preserves the right to shift entitlement between on-premises and cloud as workload demand evolves, or to split the entitlement pool by environment for clearer cost tracking. The default contractual language frequently does not include this flexibility; customers who push for it routinely get it.
The third lever is audit-credit application. Where past audits have produced settlements, the settlement amount can sometimes be applied as forward subscription credit rather than as a one-time cash payment. This conversion can produce material total-cost reductions if the audit settlement was substantial.
What to do now
If you have an existing VMware Cloud on AWS footprint
Re-baseline the economics against current pricing. Build the workload-by-workload picture of what is running where, with current entitlement consumption. Identify the workloads that are over-entitled and the ones that are under-entitled. Build the alternative-path picture for the renewal conversation.
If you are evaluating VMware Cloud on AWS as a new destination
Build the cost model carefully, including the AWS-side charges that frequently get missed. Compare against Azure VMware Solution and Google Cloud VMware Engine on equivalent workload assumptions. Compare against AWS-native re-platforming for workloads where that is feasible. Run the math on a 3-year horizon, not just year-one pricing.
If you are facing a VMware Cloud on AWS audit
The defence work starts with clean entitlement and deployment records, articulating the boundary between the AWS-hosted estate and the on-premises estate, and reading the audit clause precisely against what the audit team is asking for. Where the audit reaches across hyperscaler environments or cross-references AWS contracts, specialist support pays back quickly.
The strategic bottom line
VMware Cloud on AWS licensing under Broadcom is more expensive, more contractually layered, and more audit-exposed than it was when AWS sold the product. The product itself still works. The customers who manage the licensing and the audit posture deliberately — with discipline on entitlement consumption, with a clear-eyed view of alternatives, with active engagement at renewal time — get to keep the value of the product without paying the worst-case price for it.
The customers who treat it as a default cloud destination for VMware workloads and do not actively manage the licensing dimension consistently end up paying more than they need to. The work to do this well is real but bounded, and the payoff is durable over multi-year horizons.
