> ## Content Index > Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt > Use this file to discover other available public pages before exploring further. # Same Stack Underneath, Different Deal About Who Does the Work - URL: https://www.mohammadsiddiqui.com/same-stack-underneath-different-deal-about-who-does-the-work/ - Published: 2026-10-14T11:50:22.000Z - Updated: 2026-10-14T21:05:21.000Z - Description: Licensing now costs the same wherever you run it, which takes one variable out of every comparison. What separates the four hyperscaler VMware services is who operates the stack, not what is underneath it. - Author: Mohammad Siddiqui - Tags: architecture, operations Now that licensing costs the same wherever you run it, comparing the hyperscaler VMware services has got a lot simpler. Not easier necessarily, but simpler, because one of the variables that used to muddy every spreadsheet has been taken out of it. So here's how I'd run that decision now, and where I think each of the four lands. One thing to be straight about I know the AWS service best, because I went through its documentation properly for a separate piece. What follows on the other three is accurate to what their own documentation says, but it isn't the same depth. Treat this as a framework with my read attached rather than a verdict, and check anything that matters against the provider. ## Start with the thing that actually separates them It isn't price. It isn't feature parity either, because underneath they're all running the same VCF stack, which is rather the point of the arrangement. What separates them is **who operates it**. Azure VMware Solution and Google Cloud VMware Engine: managed Microsoft describes AVS as a fully managed VCF private cloud, with Microsoft-managed infrastructure and host management including patching and upgrades. GCVE follows the same shape. You get the environment, they keep the platform underneath it current. If your team is small, or stretched, or you're moving partly to stop doing lifecycle work, that's the attraction and it's a real one. Oracle Cloud VMware Solution: full administrative control Oracle positions OCVS around full administrative control and host-level lifecycle management on dedicated infrastructure, with deep OCI integration as the differentiator. Closer to running your own environment, in somebody else's data centre. Suits teams who want the control and have the people to use it. Amazon EVS: you operate it EVS deploys VCF onto EC2 bare metal inside your own VPC. You hold the licences, you run vCenter and NSX, you do the lifecycle. AWS provides the hardware, the automation to stand it up, and support that engages Broadcom when needed. Most control, most work. That axis should drive the decision more than anything else, and it's the one people discuss least. Everyone wants to talk about price per node. Almost nobody opens with whether their operations team actually wants to keep patching hosts. ## The dimensions worth scoring Same method as any platform evaluation. Weight these before you look at any option, not after, or you'll end up justifying a decision you already made. Operational model Do you want lifecycle handed over or kept? There's no universal right answer but there's a right answer for your team. A managed service that removes work you're good at and enjoy is a downgrade. A self-operated environment handed to a team already behind on patching is worse. Ecosystem gravity Where does the rest of your estate already live? Identity, data platforms, the tooling your applications call. This matters more than anything on the infrastructure sheet and it's the reasoning that survives licensing changes. If your identity estate is in Entra, that's a genuine argument for Azure and it has nothing to do with VMware. Networking and integration How the VMware environment reaches everything else, which is where the real design differences sit. On EVS you're working with a VPC underlay plus NSX overlay, and there are specific unsupported connectivity options worth knowing before you draw anything. The managed services abstract more of this, which is convenient right up until you need something they don't expose. Region and sovereignty Which regions each service runs in, and whether that satisfies your residency obligations. For anyone under APRA, DORA or equivalent this is a gate rather than a scoring line. Check current availability directly, because it moves. Migration path How workloads actually get there and what the tooling supports. None of these require re-platforming, which is the shared benefit and the whole reason this category exists. The differences are in the detail of what's supported and how much help there is. Exit cost The one nobody scores. How hard is it to leave whichever you pick, and where would you go next? Licence portability helps more than people realise here, because the entitlement travels with you. The data and the network design are the sticky parts. ## Where I think each one fits Broad strokes, and your estate may contradict all of it. A managed service, when lifecycle is the problem If your honest reason for moving is that keeping the platform current is eating the team, AVS or GCVE answers that directly. You're buying back time. The trade is less control over when things change, which bothers some organisations a great deal and others not at all. OCVS, when Oracle is the centre of gravity If your databases and applications are already deep in OCI, the integration argument does the work on its own. The full administrative control model also suits teams who went to cloud for capacity rather than to hand over operations. EVS, when you want cloud hardware and your own operating model Your VPC, your licences, your stack. Strongest fit for a data centre exit with a date attached, where the team is competent and wants to carry on operating the way it does, just on somebody else's metal. Also the obvious one if AWS is already where everything else lives. And genuinely consider staying where you are If none of the above describes a problem you actually have, your own data centre might be the right answer. Each of these makes most sense when there's a specific reason to move. Moving because everyone else is has a poor track record. ## Questions I'd want answered before committing What are we actually trying to fix? Lifecycle burden, a lease ending, capacity, or something else Does our operations team want to keep operating, and do we have the people either way Where does the rest of our estate live, and how much does that integration matter in practice Which regions do we need, and does the service run there today What does the network design look like end to end, including what isn't supported How do workloads get there, and who has done it before What would leaving look like in three years, and what would it cost Have we scored doing nothing properly, or did we skip it ## What I'd avoid Comparing on node price alone. It's the most available number and the least useful one, because it tells you nothing about the operating model you're signing up to or what the surrounding services will cost once you actually use them. And picking based on a relationship. Vendor relationships are genuinely valuable and they're also the thing most likely to survive a decision that turns out wrong, which means they're not evidence. ## The honest summary These services are more similar than the marketing suggests and more different than the architecture diagrams suggest. Same stack underneath, quite different propositions about who does the work. Work out which of those propositions you want, and most of the rest of the decision follows. ## Sources - [VCF License Portability: certified cloud providers](https://www.vmware.com/docs/vmware-cloud-foundation-license-portability-list-of-certified-cloud-providers?ref=mohammadsiddiqui.com), Broadcom. - [Broadcom VMware licensing changes: what AVS partners need to know](https://techcommunity.microsoft.com/blog/partnernews/broadcom-vmware-licensing-changes-what-azure-vmware-solution-partners-need-to-kn/4452173?ref=mohammadsiddiqui.com), Microsoft: the managed service description and BYOL position. - [Azure VMware Solution portable VCF](https://www.broadcom.com/how-to-buy/software-partners/hyperscalers/azure-vmware?ref=mohammadsiddiqui.com), Broadcom. - [Evolving Oracle Cloud VMware Solution for Broadcom's BYOL model](https://blogs.oracle.com/cloud-infrastructure/ocvs-vcf-byol-guidance?ref=mohammadsiddiqui.com), Oracle: administrative control and lifecycle positioning. - [Amazon EVS architecture](https://docs.aws.amazon.com/evs/latest/userguide/architecture.html?ref=mohammadsiddiqui.com), AWS: the VPC and consolidated domain model. - [Azure VMware Solution licensing changes](https://www.cloudcomputing-news.net/news/azure-vmware-solution-licensing-changes/?ref=mohammadsiddiqui.com): the GCVE dates and quota changes. *Service capabilities, regions and terms change regularly across all four. Verify anything decision-critical with the provider rather than relying on a comparison written at a point in time.* *Views expressed here are my own.*