Most enterprises are already multi-cloud by accident
Very few organisations chose to run across two or three cloud providers. It happened through acquisition, through a team that preferred a particular managed service, or through a data-residency requirement that only one provider met in a given region. The result is a working estate that nobody designed.
The cost of accidental multi-cloud is not primarily infrastructure spend. It is that identity, networking, deployment and monitoring are solved differently in each place, so every engineer carries three mental models and every incident starts with working out which runbook applies.
Decide what has to be consistent
The instinct is to abstract everything behind a common layer. Resist it. Abstractions that span cloud providers tend to give you the lowest common denominator of each, and you end up maintaining a platform team whose entire job is compensating for the abstraction.
A more durable line is to make four things consistent and let everything else vary: identity and access, network topology and naming, deployment pipeline, and observability. Those are the four that hurt during an incident. Managed databases, queueing and serverless runtimes can differ per provider without much pain, because a team working in one of them rarely needs to reason about the others simultaneously.
Where hybrid genuinely earns its place
On-premise is not legacy by default. Predictable, high-throughput workloads with steady utilisation are often cheaper to run on owned hardware, and data-gravity arguments are real: if two terabytes a day are generated in a factory, processing them at the edge and shipping aggregates is simply better engineering than shipping everything to a region.
The pattern that works is a clean boundary with a documented contract — an event stream or an API — rather than a network extension that makes on-premise systems look like they are in the cloud. Stretched layer-two networks between a data centre and a VPC create failure modes that are extremely unpleasant to debug at three in the morning.
The FinOps piece
In every multi-cloud estate we have reviewed, between 20 and 40 per cent of spend was recoverable. The recurring causes are consistent: development environments running out of hours, over-provisioned instances sized for a launch that never came, storage that was never tiered, orphaned load balancers and volumes, and egress charges caused by a service accidentally calling across regions.
None of that is exotic. It persists because nobody owns it. A tagging standard that is actually enforced in the pipeline, monthly showback to the teams generating the cost, and one named person accountable for the number will recover more money than any architectural change.