Stop Renting Their VM Layer: The Case for Hybrid Multicloud Infrastructure
8 min read
Updated October 2026: corrected the GO-EUC performance figures and chart, and tightened the DORA scope.
If you have read the earlier posts in this series, on yesterday’s silicon, the CPU lottery and its AMD edition, you already know the problem from two angles. You are paying full price for hardware that was amortized years ago, and the VM you get assigned is drawn from a lottery of CPU generations spanning a decade. Both of those problems share a root cause: you are consuming a managed VM layer over which you have no control.
Most organizations frame cloud strategy as a choice between providers. AWS or Azure. Single cloud or multicloud. The more useful question is whether you should be running on their VM layer at all.
The managed VM layer is the constraint
When you deploy workloads onto standard cloud VM SKUs, you inherit every decision the hyperscaler made about sizing ratios, CPU scheduling, NUMA topology, and hardware assignment. As modelled in the CPU lottery post, a Standard_D4s_v3 on Azure gives you roughly a 73% chance of landing on a CPU from 2019 or earlier. Worth being precise about what that number is: Microsoft publishes the per-host VM densities the calculation rests on, 17 D4s_v3 on a Broadwell host, 20 on Skylake, 21 on Cascade Lake and 24 on Ice Lake, but it does not publish the fleet mix. The 73% is therefore a modelled scenario for a mature region, not a measurement. Model a newer region where 60% of hosts are Ice Lake or better and it drops to roughly 36%. The point survives either way: you cannot see which draw you got without asking the VM. You cannot negotiate that. You cannot observe it without running diagnostics. You definitely cannot move off it without re-provisioning.
The same dynamic applies on AWS and GCP wherever an instance family spans more than one CPU generation. None of the three providers publishes its fleet mix, so you cannot tell how much capacity still runs on 2019-era Cascade Lake or EPYC Rome hosts. Your only view is from inside the VM. The VM layer abstracts it all away, which sounds convenient until you realize that abstraction is actively working against your interests.
Bare metal breaks the cycle
Bare-metal capacity exists on all three major clouds, but not on equal terms, and that distinction matters more than the vendor decks suggest. AWS sells .metal sizes across most instance families as ordinary, orderable SKUs. Azure’s BareMetal Infrastructure is scoped to specific workload families rather than offered as general-purpose capacity. Google’s Bare Metal Solution is moving to an allowlist-only model, but Compute Engine sells bare metal machine types (the -metal sizes) on selected machine series as ordinary instances. In practice the route to a bring-your-own-hypervisor estate on AWS and Azure runs through the dedicated-node offerings the virtualization vendors have built on top of those instances, rather than through raw bare metal you rent yourself.
That changes the calculus completely. Instead of accepting whatever CPU-to-memory ratio comes with a managed SKU, you define it. Instead of sharing a host whose packing and oversubscription you cannot see, you size the host and decide what runs on it. Instead of getting whatever generation of hardware the scheduler assigns, you pick the instance family that maps to current-generation silicon and explicitly provision against it.
For EUC workloads, the generation gap is measurable. GO-EUC’s Azure CPU Showdown tested it with OBUX, an open benchmark whose system score combines CPU-intensive calculations, disk IO and application start times. Moving from v5 to v6 raised the OBUX system score by 26.4% on Intel (D2s v5 to D2s v6 on Emerald Rapids) and 16.1% on AMD (D2as v5 to D2as v6 on Genoa). You can capture that gain on the managed tier too, by moving to a family pinned to one CPU generation such as Dsv6, Dasv6 or Dasv7. What the managed tier will not give you is control over when the next generation arrives, how hosts are packed, or a way to leave without rebuilding. Bare metal gives you all three.
Hybrid multicloud is an exit strategy, not just a deployment model
Running the same virtualization stack across AWS, Azure, and on-premises hardware is not new. HCI platforms have supported this for several years. What has changed is the regulatory pressure that makes it a compliance requirement rather than an engineering preference.
DORA has applied to EU financial entities since 17 January 2025. Article 28(8) requires an exit strategy for every ICT service that supports a critical or important function, so you can leave a provider without disrupting the business, breaking regulatory compliance or degrading service to clients. Not theoretical portability. A documented exit plan that you test and review. In November 2025 the European Supervisory Authorities also designated the first critical ICT providers, which now fall under their direct oversight.
That is a hard requirement to meet if your workloads are built on managed VM tiers with provider-specific storage backends, proprietary networking overlays, and snapshot formats that do not travel. If your disaster recovery documentation references Azure Site Recovery or AWS DRS as the sole mechanism for workload portability, your compliance posture is weaker than it looks.
A unified virtualization layer that runs identically on bare metal in AWS, on bare metal in Azure, and on commodity hardware in your own data center makes the exit requirement far easier to evidence than provider-native VM migration tools do. You are not migrating between two different environments. You are relocating a workload between identical environments that happen to be running in different locations.
What this actually looks like in practice
The operational model is closer to what on-premises teams have run for years than to a traditional cloud migration. Your hypervisor, your storage fabric, your networking stack. Deployed on bare metal in whichever cloud makes sense for latency, pricing, or data sovereignty at a given point in time.
License portability matters here. If your virtualization software ties licenses to specific infrastructure or to a single cloud provider, the exit strategy falls apart at the commercial layer even if the technical layer supports it. The platforms worth evaluating are those where a license is a license, regardless of whether it runs on hardware in your cage or on a bare-metal instance billed to your cloud account.
The flexibility is not just about avoiding lock-in. When AWS bare-metal pricing is more competitive for a specific workload class, you move it there. When regulatory requirements demand on-premises residency for a dataset, you extend the same cluster into your own data center. When a cloud provider raises prices on managed VM SKUs, you are not captive to it.
Visibility first, then portability
The same principle that applies to CPU generation transparency applies to infrastructure portability. You cannot manage what you cannot see. If you do not know which cloud provider your workloads depend on at the storage and networking levels, you do not have an exit strategy; you have hope.
The audit is the starting point. Map your workloads against managed services, proprietary storage tiers, and provider-specific networking constructs. Identify which ones would survive a provider migration intact and which ones would require re-architecture. That gap is your actual lock-in exposure, and it is almost certainly larger than your cloud strategy documents acknowledge.
Once you have that map, bare metal multicloud stops being a theoretical architecture and becomes a concrete migration path. The workloads that are portable move to a unified virtualization layer running on bare metal. The ones that are not become intentional technical debt with a remediation plan attached.
That is a more honest infrastructure strategy than most organizations are operating with today.
The Bottom Line
The abstraction is the product.
Cloud providers frame the managed VM layer as convenience. What it actually delivers is the removal of your control over CPU generation, storage topology, and network primitives, and of your ability to leave cleanly when the contract changes, the price increases, or a regulator asks for documented evidence of a workable exit strategy.
Bare metal with a BYO hypervisor is not a step back from the cloud. It is a move to a layer below the one the provider controls. The same physical infrastructure and the same cloud bill, without the provider’s VM layer on top. You run one virtualization stack that behaves identically on your own hardware, on an AWS bare metal instance, or on an Azure bare metal node.
The compliance requirement is not coming. It is already here. DORA has applied since 17 January 2025. An exit strategy that depends on provider-native migration tools is not a strategy; it is a dependency dressed up in documentation. A unified virtualization layer running on bare metal makes that exit testable because the environment is portable, not because the migration tooling is good enough.
Start with the audit. Map your workloads against managed services, proprietary storage, and provider-specific networking constructs. The gap between what is portable today and what would survive an unplanned provider exit is your real lock-in exposure. Most organizations find it is significantly larger than their cloud strategy documents acknowledge. Closing it starts with knowing where it is.
Are you running workloads on managed VM tiers with no documented exit strategy? Is the hybrid multicloud conversation happening in your organization? Drop a comment below or find me on X at @kbaggerman.
Kees Baggerman
Latest posts by Kees Baggerman (see all)
- Stop Renting Their VM Layer: The Case for Hybrid Multicloud Infrastructure - October 28, 2026
- The Cloud Desktop CPU Lottery, AMD Edition: Which Zen Are You Actually Running On? - October 23, 2026
- Citrix MCSIO on Nutanix AHV: A Solution to a Problem That Doesn’t Exist - June 10, 2026
- The Cloud Desktop CPU Lottery: What Are You Actually Running On? - June 2, 2026
- Your Cloud Desktop Is Running on Yesterday’s Silicon - May 21, 2026
