VMware on AWS, after Broadcom.

VMware on AWS — the original branded hybrid-cloud product — sat at the centre of VMware's cloud strategy for nearly a decade before the Broadcom acquisition reshaped how it is sold and delivered. The product itself still exists; the commercial model around it does not. Understanding what has changed, what has stayed the same, and what the practical implications are for enterprise customers is essential planning ground for any organisation running hybrid workloads or considering them.

This pillar-length article works through the full picture: the pre-acquisition baseline, the change in AWS's role, the change in Broadcom's role, the impact on existing customers, the migration paths available, the alternative cloud-VMware offerings, and the strategic implications for hybrid cloud architecture under the new commercial reality.

The baseline: VMware on AWS before Broadcom

VMware Cloud on AWS launched in 2017 as a joint go-to-market between VMware and AWS. AWS owned the underlying infrastructure — bare-metal EC2 instances in dedicated VPCs — while VMware owned the software stack running on top, plus the customer relationship. AWS sold the service; VMware engineered it; customers transacted with either party depending on commercial preference.

The product was conceptually elegant. Customers got native VMware SDDC components (vSphere, vSAN, NSX) running on AWS-provided bare metal, with full operational parity to on-premises VMware. The use cases were durable: data centre evacuation, cloud bursting, disaster recovery, application modernisation runway, and consolidation of long-tail data centre footprints.

By 2023, VMware Cloud on AWS had a meaningful installed base — particularly in the financial services, healthcare, and large public-sector segments — and was widely considered a strategic anchor of VMware's broader hybrid-cloud story.

The 2024 commercial reset

The most consequential change came in 2024, when AWS announced it would no longer sell VMware Cloud on AWS directly. Going forward, the commercial relationship for the product would be owned by Broadcom, with AWS continuing to provide the underlying infrastructure but no longer holding the customer-facing relationship.

The change had immediate, structural consequences. For existing customers, the renewal pathway moved from AWS to Broadcom. The pricing model that AWS had used — generally similar to its other EC2-based services — was replaced by Broadcom's subscription-and-VCF logic. The customer-support relationship shifted. The procurement pathway for many enterprises had to be rebuilt from scratch.

For new customers, the practical effect was that adoption slowed significantly. Customers evaluating hybrid platforms now had to engage Broadcom for the commercial and Broadcom-plus-AWS for the technical — a more complex and more expensive engagement model than the previously integrated AWS-sold offer.

What changed in the contract

Pricing structure

Under the AWS commercial model, VMware Cloud on AWS pricing was largely consumption-based with reserved-instance options. Under Broadcom, the pricing is anchored on per-core subscription with VCF-equivalent SKUs, applied to the cores running in the AWS-hosted environment. The structural shift is the same one Broadcom has applied across the VMware portfolio: from infrastructure-economic pricing to subscription-economic pricing.

The customer-facing impact for many existing VMware Cloud on AWS customers was a notable price increase at renewal — often 30% to 80% — without a change in the underlying workload footprint.

Term length

AWS had offered flexible term structures, including monthly commitment options. Broadcom's standard offer is 1-year or 3-year subscription, with 3-year being the default-and-discounted option. The flexibility customers had previously used to ramp capacity up and down is materially reduced under the new model.

Support pathway

The support model under AWS-sold VMware Cloud on AWS had a clean entry point: AWS Support owned the customer interaction and triaged to VMware for software issues. Under the Broadcom-led model, support is more layered: Broadcom owns the software support, AWS handles the underlying infrastructure, and the customer is often responsible for triaging between them.

Audit posture

This is perhaps the least-discussed but most important change. Under the AWS-sold model, the VMware Cloud on AWS hosts were not part of the customer's Broadcom audit surface in the same way as on-premises hosts. Under the new model, they are. Broadcom audits routinely now read across the customer's on-premises VMware contract, the AWS contract, and the VMware Cloud on AWS subscription, looking for entitlement gaps in any of the three.

The impact on existing customer architectures

Disaster recovery and standby

One of the most common deployment patterns for VMware Cloud on AWS was as a DR target — keeping the on-premises production environment, with the AWS-hosted VMware environment as the standby site. Under the new commercial model, this pattern has become significantly more expensive, because the standby footprint is now licensed under subscription rather than reserved-instance economics.

Customers who built their DR strategy around VMware Cloud on AWS are revisiting it. Some are accepting the higher cost and continuing. Some are migrating the DR target to a hyperscaler-native architecture (replicating to AWS-native services rather than to VMware on AWS). A smaller group is moving the entire workload off VMware and onto an alternative platform.

Data centre evacuation

The "exit the data centre" use case — moving on-premises VMware workloads into VMware Cloud on AWS to allow the physical site to be decommissioned — was historically a key narrative for the product. Under the new economics, the calculus has changed: the costs of running the workload in VMware Cloud on AWS over a 5-year horizon are higher than they used to be, and the per-host pricing parity between on-premises VCF and VMware on AWS subscription removes the previous arbitrage.

Customers who have already executed this migration are not, in most cases, reversing it — the work to move workloads back on-premises is substantial. But few customers are starting net-new data-centre-evacuation projects with VMware Cloud on AWS as the destination.

Cloud bursting and elastic capacity

The use case where VMware Cloud on AWS has held up best is true cloud bursting — running a baseline on-premises capacity and spilling spikes into the AWS-hosted environment. Customers with predictable spike patterns continue to find this architecturally valuable, although the new pricing model has reduced the cost-effectiveness of small or infrequent bursts.

The migration paths customers are taking

Path one: stay on VMware Cloud on AWS, renegotiate harder

For customers with deep integration into VMware-on-AWS — particularly those running NSX-heavy networking or vSAN-anchored storage architectures — the cost of leaving is high enough that the practical answer is to stay and negotiate. The lever here is the customer's strategic value to Broadcom (in the strategic 2,000) plus the credible threat of migration to a hyperscaler-native model.

Path two: re-platform onto Azure VMware Solution or Google Cloud VMware Engine

Some customers, particularly those with significant Microsoft or Google relationships, have evaluated migrating from VMware Cloud on AWS to Azure VMware Solution or Google Cloud VMware Engine. The economics depend heavily on the customer's other commitments to those hyperscalers; in some cases, EA bundling and credit programmes from Microsoft or Google make a meaningful difference.

However, the underlying Broadcom subscription terms apply to all three hyperscaler-VMware offerings now, and the pricing differentials at the VMware layer are smaller than they used to be. The economic case for moving between hyperscalers is therefore weaker than it was 18 months ago.

Path three: migrate to hyperscaler-native

The strategically most attractive path — and the most expensive in upfront engineering — is to migrate workloads from VMware on AWS to AWS-native services: EC2 with native networking, EBS or S3 storage, native AWS load balancing, and either ECS, EKS, or Lambda for the application layer. This removes the VMware layer entirely from the cloud architecture.

The upside is that the long-term run-rate cost is typically lower (no Broadcom subscription on the cloud footprint) and the strategic optionality is higher. The downside is real engineering work: re-platforming workloads, re-validating compliance, retraining operations teams, and managing the migration risk.

For workloads with manageable dependencies — especially newer applications or those already containerised — this path is increasingly the preferred answer for net-new cloud capacity decisions.

Path four: hybrid retain on-premises, exit the cloud-VMware portion

For some customers, the cleanest answer is to keep VMware running where it works well (on-premises, particularly for large legacy workloads) and exit the cloud-VMware footprint specifically. The workloads previously running in VMware Cloud on AWS are migrated either back on-premises or onto AWS-native services. The on-premises VCF subscription is retained and right-sized.

This is a common landing point for customers who are not philosophically opposed to VMware but cannot make the cloud-VMware economics work under the new commercial model.

Strategic implications for hybrid cloud architecture

The shift in VMware Cloud on AWS economics has broader implications for hybrid cloud architecture decisions, beyond the specific product.

The hybrid VMware narrative is weaker

The strategic promise of VMware Cloud on AWS — that customers could extend their VMware operational model into the cloud without learning a new platform — was always going to be somewhat expensive. Under Broadcom, it is meaningfully more expensive. For new architecture decisions, the question of whether to extend VMware into the cloud or learn a hyperscaler-native model has shifted in favour of the latter for many use cases.

Multi-cloud parity matters less

One historical attraction of the VMware-on-hyperscaler model was that the same operational model worked across AWS, Azure, and GCP. That narrative is intact under Broadcom, but the economic gap between VMware-on-hyperscaler and native services on each platform has widened. For customers committed to a multi-cloud strategy, the rational architecture is increasingly multi-cloud-native (using each hyperscaler's services) rather than multi-cloud-VMware.

The audit surface in the cloud matters more

The expansion of Broadcom audit interpretation to include hyperscaler-hosted VMware workloads means that hybrid customers need to manage entitlement reconciliation across on-premises, AWS, Azure, and any other VMware-bearing environments. This is more work than the historical on-premises-only audit posture required, and it requires tooling and process discipline that not every IT shop has built.

Disaster recovery design is being reopened

The DR use case in particular is being reopened across many enterprises. Designs that depended on a low-cost VMware-on-AWS DR target are being re-engineered, either toward AWS-native DR architectures, toward in-region DR within the on-premises VMware estate, or toward a third-party DR-as-a-service approach.

The technical architecture: what actually runs in VMware Cloud on AWS

To understand the commercial change, it helps to be precise about the technical architecture that sits underneath. VMware Cloud on AWS is not the same thing as "VMware running on Amazon EC2". The product is a software-defined data centre stack — vSphere, vSAN, NSX — provisioned and managed by VMware (now Broadcom) on top of bare-metal EC2 instances that AWS dedicates to the customer's tenancy.

The customer interacts primarily with the SDDC, not with AWS. vCenter looks like vCenter; ESXi hosts look like ESXi hosts; vSAN datastores look like vSAN datastores. The AWS layer is essentially invisible except where customers explicitly extend into AWS-native services (S3, Lambda, RDS, etc.) through the VPC connectivity that ships with the SDDC.

This architecture is what made the product strategically attractive: it preserved the on-premises VMware operational model in a cloud environment without forcing customers to learn AWS-native operating patterns. It is also what makes the commercial change consequential. The same architectural choice that gave customers operational continuity also locked them into the VMware (now Broadcom) commercial stack on top of AWS infrastructure. When that commercial stack changes, the technical architecture is unchanged but the economics around it move significantly.

The pre-Broadcom value proposition in detail

The historical value proposition rested on five pillars worth restating, because each pillar's strength has changed under the new commercial model.

Operational continuity. The same vCenter, vSphere, NSX, and vSAN operations that worked on-premises worked in the cloud. Training, tooling, and operational runbooks transferred directly. This pillar is technically intact under Broadcom — the product still works the same way — but the value of operational continuity is diminished if the cost of preserving it is materially higher.

Workload portability. VMs could move between on-premises VMware and VMware Cloud on AWS using existing vMotion and HCX tooling. Bidirectional movement was a real differentiator. This pillar is also technically intact, with the caveat that the licensing implications of moving workloads have become more complex under the new entitlement and audit posture.

Infrastructure flexibility. The cloud-hosted environment could scale up or down faster than on-premises infrastructure could be provisioned. This pillar has been weakened by the move to longer-term subscription commits, which reduces the practical ability to flex capacity downward.

Joint go-to-market. AWS sold the product, AWS Support handled the relationship, and AWS account teams owned the customer engagement. This pillar is fundamentally broken. The commercial relationship is now Broadcom-owned, and the customer experience reflects that.

Investment durability. The strategic message to customers was that VMware Cloud on AWS represented a stable long-term commitment from both companies. This pillar has been the most damaged. Whatever the future of the product looks like, the customer experience of the past 18 months has reset the baseline assumption about commercial stability.

The audit dimension in detail

The audit posture change deserves expanded treatment because it is the area where most existing customers are least prepared.

Under the AWS-sold commercial model, the contract structure for VMware Cloud on AWS treated the AWS-hosted environment as commercially distinct from the customer's on-premises VMware estate. Audit clauses in the on-premises VMware contract did not extend cleanly into the AWS environment, and AWS's standard terms did not include VMware-style audit rights. The practical effect was an audit shadow: hosts in VMware Cloud on AWS were less audit-exposed than on-premises hosts.

Under the Broadcom-led commercial model, the on-premises and cloud-hosted environments are now treated as a single customer commercial estate. The audit clause in the headline Broadcom subscription agreement applies across both. Usage data requests cover both. Settlement findings span both.

This shift has produced several specific patterns we now see in audits:

Cross-environment entitlement reconciliation. Broadcom audits frequently request a unified view of entitlements and deployment across on-premises VMware, VMware Cloud on AWS, Azure VMware Solution, and Google Cloud VMware Engine. The audit team reads across all of them to assess compliance.

Transient cloud usage findings. Workloads that ran briefly in VMware Cloud on AWS — for testing, for DR validation, for cloud-bursting events — are surfacing as audit findings against the per-core subscription metric. Where these workloads were not separately entitled, they appear as compliance gaps.

Hyperscaler-contract cross-reference. Broadcom audits now read the customer's AWS, Azure, and GCP agreements alongside the Broadcom subscription, looking for inconsistencies in entitlement assertions. This is unusual in the software industry and customers rarely expect it.

The defence response to these patterns has evolved. We now run cross-environment entitlement reconciliations as a routine first step in any audit defence engagement where the customer has any cloud-hosted VMware footprint. The reconciliation typically surfaces both real exposure (which needs to be settled) and Broadcom over-counting (which can be challenged).

Designing for the new commercial reality

For enterprises designing cloud architecture in 2026, the new commercial reality changes the right answer to several common architectural questions.

Where should DR live?

Historically: VMware Cloud on AWS was a natural DR target for on-premises VMware estates. Native VMware tooling, light-touch operational model, modest pricing.

Now: the licensing economics of running a substantial standby footprint in VMware Cloud on AWS are challenging. The right DR architecture often shifts toward AWS-native (replicating to S3 with EC2-based recovery), or toward in-region on-premises DR, or toward a DR-as-a-service provider that handles the licensing layer.

Where should cloud bursts go?

Historically: VMware Cloud on AWS supported true on-demand spillover from on-premises capacity into cloud, with minimal architectural change.

Now: bursting into VMware Cloud on AWS still works technically but is more expensive economically. Bursting into AWS-native compute (with appropriate workload re-architecture) is cheaper but requires more engineering. Bursting into Azure VMware Solution may be marginally cheaper depending on the customer's Microsoft relationship, but the operational cost of managing two hyperscaler environments often outweighs the saving.

Where should new cloud-based workloads land?

Historically: VMware Cloud on AWS provided a low-friction landing zone for cloud-resident workloads that needed VMware-style operational continuity.

Now: for net-new workloads, the architectural default has shifted decisively toward hyperscaler-native, container-based, or Kubernetes-based platforms. VMware Cloud on AWS as a net-new landing zone is becoming the exception rather than the default.

What is the right hybrid posture?

Historically: a substantial fraction of the enterprise estate in VMware Cloud on AWS, with on-premises VMware as the anchor and AWS-native as the modernisation runway.

Now: a leaner cloud-VMware footprint, an on-premises VMware estate that is right-sized and hard-negotiated, and a growing hyperscaler-native footprint that absorbs net-new workloads and selected migrations.

The migration mechanics

For customers actively migrating workloads off VMware Cloud on AWS, several specific mechanical considerations matter.

Workload assessment

The first job is a workload-by-workload assessment of fit for the destination platform. Not every workload that runs well in VMware Cloud on AWS will run well as-is on EC2-native. Workloads with high NSX dependency, complex storage requirements, or VM-specific HA configurations need careful handling.

An effective assessment categorises workloads into three buckets: lift-and-shift candidates (can move with minimal change), refactor candidates (require some application-level change), and replace candidates (right answer is a SaaS or hyperscaler-native equivalent rather than direct migration).

Data movement

The data layer is usually the largest single component of migration effort. Moving VMs out of VMware Cloud on AWS into EC2-native, or back on-premises, or onto a different hyperscaler, requires moving the underlying vSAN-resident data. Tools like AWS DataSync, S3 Snowball, and various third-party migration platforms have different cost and time profiles depending on data volume and bandwidth availability.

Network re-architecture

The network architecture around VMware Cloud on AWS — NSX overlays, transit gateways, direct connect — often does not translate directly to native AWS networking. Re-architecting the network layer is frequently the most underestimated migration cost.

Security and compliance recertification

Moving regulated workloads requires recertifying the new environment against the relevant compliance frameworks. The recertification effort is real and non-negotiable for workloads under PCI, HIPAA, SOC 2, or sector-specific regimes.

Operational handover

The operations team needs to absorb the new platform's operational model. Where the migration target is hyperscaler-native, this typically means a significant investment in skills, tooling, and process redesign that should be planned for, not bolted on at the end of the migration.

The Broadcom negotiating posture on cloud workloads

Customers approaching renewal of a VMware Cloud on AWS subscription should expect a structured Broadcom negotiating posture with predictable elements.

Broadcom's preferred deal shape for cloud customers is a multi-year VCF subscription that bundles on-premises and cloud-hosted entitlement on a single commercial structure. The pitch is operational simplicity and pricing predictability; the reality is that this structure produces the maximum ACV for Broadcom and the minimum customer flexibility.

Lever points where customers have real negotiating room include: term length (1-year terms are available but expensive; the right balance often sits at 2 years), commit volume (over-committing locks in pricing but reduces flexibility; under-committing produces overage exposure), audit-credit application (where past audit findings can be applied as forward subscription credit), and contractual portability (where the entitlement should be usable on-premises and on any of the three hyperscaler-VMware offerings without separate licensing).

Customers who walk into the renewal conversation with these levers explicit, supported by data, and tied to a credible alternative path consistently achieve materially better outcomes than customers who treat the renewal as a procurement task.

What good looks like

For the customers we have seen navigate the VMware-on-AWS transition most successfully, the pattern has been remarkably consistent.

They started early. The work began 9 to 12 months before the renewal date, not in the last quarter.

They built a real number on the alternative paths — not theoretical, but priced and time-bounded.

They retained specialist advisory support. The Broadcom-specific contract knowledge required to negotiate effectively in this domain is not standard procurement skill, and the customers who recognised that achieved better outcomes.

They prepared the audit posture in parallel. Negotiating a renewal while simultaneously running an audit risk reconciliation is more work, but it removes audit pressure as a renewal lever Broadcom can use.

They kept the workload-by-workload economics visible. The decision was never "migrate everything" or "stay with everything". It was "for each workload, what does the math say".

They communicated internally. CFO, CIO, head of architecture, head of operations, head of legal, head of procurement — all aligned on the strategic question before the negotiation began.

None of this is exotic. It is the operating model of mature vendor management applied with discipline to a specific high-stakes commercial relationship. The customers we see achieve the best outcomes are not necessarily the largest or most sophisticated — they are the ones who treat this work seriously and start it early.

Risks of the path forward

Several specific risks deserve attention in any go-forward plan.

Lock-in to the new commercial model. Signing a 3-year VCF subscription with cloud entitlement creates a 3-year window during which the customer is committed to Broadcom's commercial template. If circumstances change — pricing, products, or strategic direction — the customer has limited mid-term recourse.

Underestimated migration cost. Migration projects routinely run 30% to 60% over initial cost estimates, particularly on network and security work. Plans built on optimistic numbers expose the customer to a worse outcome than the stay-and-negotiate alternative.

Hyperscaler-native commitment risk. Moving from VMware Cloud on AWS to AWS-native services creates exposure to a different commercial counterparty with its own pricing trajectory. The strategic optionality is real, but it should not be confused with cost certainty.

Audit settlement timing. If the renewal conversation is happening in parallel with an open audit, the customer's negotiating posture is materially weaker. Resolving any open audit before entering serious renewal negotiation is almost always the right sequence.

Skills and operational risk. Operating a hyperscaler-native environment at enterprise scale is a different discipline from operating a VMware-based one. Underestimating the skills-and-operations transition is a common and expensive mistake.

Final perspective

VMware on AWS sits at a particularly visible intersection of the broader Broadcom story. The product is technically excellent. The commercial reality has changed in ways that materially affect the value proposition. Customers are responding rationally, with a mix of staying, leaving, and rebalancing the hybrid posture.

The right read in 2026 is that the hybrid VMware story is not over but is meaningfully smaller in scope than it was three years ago. The customers who manage that transition well — workload-by-workload, with discipline on both the commercial and the technical side — will end up with hybrid architectures that work commercially and operationally for the next five years. The customers who manage it poorly — through either reactive defence of the status quo or unconsidered migration — will end up with higher cost, more operational risk, or both.

The good news is that the decision is genuinely within the customer's control. None of the variables that matter most — workload portfolio, alternative-path readiness, audit posture, renewal preparation — depend on Broadcom changing direction. The work is the customer's to do, and the customers doing it well are achieving outcomes that the headlines do not capture.

A note on the broader hyperscaler-VMware landscape

Although this article focuses on VMware on AWS, the dynamics described apply with regional variation to Azure VMware Solution and Google Cloud VMware Engine. Each has its own contract structure, its own commercial posture, and its own integration with native hyperscaler services, but the underlying Broadcom subscription overlay applies consistently across all three.

For customers running on more than one hyperscaler-VMware service, the cross-environment audit and entitlement reconciliation is more complex still. Broadcom's audit team can and does read across all three hyperscaler agreements and the on-premises VMware contract simultaneously. Customers operating across that landscape need a unified entitlement view; otherwise the exposure surface compounds in ways that no individual environment owner can see.

The strategic lesson is that hybrid VMware in 2026 is best treated as a single relationship with multiple operational venues, not as separate relationships per venue. That framing produces better contract negotiation, better audit posture, and better architectural decisions than the alternative.

What to do now

Re-baseline the economics

If you have a meaningful VMware Cloud on AWS footprint and have not re-baselined the economics in the last 12 months, that is the first job. The numbers have moved enough that prior business cases are likely no longer valid. Re-baseline against the current Broadcom subscription pricing, the current AWS infrastructure pricing, and the current alternative options. The output of that re-baselining should be a clear, time-bounded position on which workloads stay and which move.

Treat the renewal as a strategic event

If your VMware Cloud on AWS renewal is approaching, treat it as a strategic decision, not a procurement task. The decision to renew is a multi-year commitment to a particular architecture under a particular commercial model. Get the right stakeholders engaged — enterprise architecture, FinOps, security, applications — and run a full options analysis before the renewal date forces a default outcome.

Build the audit-posture muscle

The expansion of Broadcom audit reach into cloud-hosted VMware workloads means that entitlement management is now a cross-environment discipline. Customers without a single, authoritative view of entitlement versus deployment across on-premises and hyperscaler environments are exposed. The fix is process, tooling, and ownership — and it pays back the first time an audit notice arrives.

Don't over-react

VMware Cloud on AWS still works. The product still solves the problems it was designed to solve. The change is commercial, not technical. For workloads where the use case is clearly fit and the migration alternatives are expensive, the right answer is often to stay and negotiate hard. The mistake is letting the negative noise around the Broadcom commercial model push you into an unnecessarily expensive migration.

The strategic bottom line

VMware on AWS after Broadcom is a fundamentally different commercial proposition than it was before. The product is intact; the economics are not. For some customers the new economics still work; for many they do not. The right response is workload-by-workload analysis under the new pricing, not a wholesale stay-or-leave decision.

The bigger lesson is that the era of VMware as a comfortable, low-friction extension of on-premises infrastructure into the public cloud is over. Hybrid VMware will continue to exist; it will simply be more expensive, more contractually layered, and more audit-exposed than it was. Customers who treat that fact as a planning constraint — rather than wishing it away — will architect hybrid environments that hold up commercially and operationally over the next five years.

For most enterprises, the right shape of hybrid in 2026 is leaner on cloud-VMware and richer in hyperscaler-native, with a thoughtful retained on-premises VMware estate and a defensive posture against the unified Broadcom audit programme. That is not a romantic answer, but it is the one that maps best to the commercial reality.