How Not to Get Lost in Multi-Cloud

If you are reading this, you are probably weighing up a multi-cloud strategy. Perhaps a vendor, a consultant or a board member has told you it is the responsible way to manage risk and avoid lock-in. Before you commit, it is worth asking whether multi-cloud actually delivers on those promises.

Drawing on my experience of cloud transformation programmes, I will look at what multi-cloud really means, why so many organisations believe they are already doing it, and who benefits from the hype. I will then examine how much vendor independence is worth paying for, and whether multi-cloud is the best way to protect business continuity.

Everyone is doing it, so it must be right?

You have probably seen the statistic: almost every company is already multi-cloud. The latest figure is 89% in Flexera’s 2024 State of the Cloud Report, up from 87% a year earlier. It is often presented as proof that multi-cloud is the right choice.

Look at what sits behind the number, though. For most respondents, multi-cloud means one primary hyperscaler, such as AWS, Microsoft Azure or Google Cloud, plus a portfolio of SaaS products such as Microsoft 365, Salesforce or Workday. By that definition, almost every company with corporate email is multi-cloud. The statistic says nothing about whether running core workloads across several providers is a good idea.

Strategic multi-cloud is something else: deliberately running infrastructure and platform services (IaaS and PaaS) on two or more public clouds, usually with the aim of moving workloads between them or running them in parallel. It is a far more demanding architecture, and far fewer organisations practise it in any meaningful way.

How companies end up multi-cloud

When a company describes itself as multi-cloud, people tend to assume a considered strategic decision. In my experience it is usually the product of history.

Mergers and acquisitions are the most common route. The acquired business runs on a different cloud, migrating it would be expensive and distracting, and so two platforms coexist, often for years.

The second route is autonomy. In large organisations, business units and product teams choose their own providers, sometimes because of existing skills, sometimes because a vendor’s account team got there first. Central IT may have a preferred platform, but it rarely has the authority to enforce it.

There are also legitimate, deliberate reasons. Some services are genuinely differentiated: a data team may prefer Google BigQuery, while access to OpenAI’s models through Azure has drawn a number of AWS-centred companies onto a second platform since 2023. Data platforms such as Snowflake and Databricks run on all three major clouds because their customers do. Data residency rules and customer contracts can also dictate where particular workloads live. The hyperscalers themselves are making targeted multi-cloud easier: Oracle’s database service now runs inside Microsoft and Google data centres, and a similar partnership with AWS was announced in September 2024.

None of this amounts to a blanket strategy of spreading everything across providers. So the next time someone quotes the 89% figure to persuade you, ask what they mean by multi-cloud, and what they are selling.

The multi-cloud narrative: separating fact from fiction

Much of the debate is shaped by people with a commercial interest in its outcome. In his widely cited essay “Multi-Cloud is the Worst Practice”, cloud economist Corey Quinn argues that its loudest advocates fall into two groups:

1. Vendors whose relevance shrinks if customers standardise on a single cloud provider. His example was VMware.
2. Smaller public cloud players that lose out when customers commit fully to one of the market leaders.

I would add a third group: consultancies and tool vendors whose services are needed precisely because multi-cloud is complex.

His VMware example now looks prescient. After Broadcom completed its $69 billion acquisition of VMware in November 2023, it ended perpetual licences and moved customers onto subscription bundles. Many reported multi-fold price rises, and in 2024 AT&T went to court, claiming that one proposal would increase its costs by 1,050%. The most painful lock-in story of 2024 involved an on-premises virtualisation platform, not a hyperscaler.

The narrative is also shaped through language. Take “cloud-native”. When Netflix and other early adopters popularised the term in the early 2010s, it described systems designed around the elastic, managed building blocks of a cloud platform. The Cloud Native Computing Foundation’s 2018 definition recast it around containers, microservices and declarative APIs that run in public, private and hybrid clouds. Today many people take cloud-native to mean portable. Who gains from that shift is worth considering.

“Hybrid multi-cloud” is another example. Look for case studies and most describe virtual machines being migrated from an on-premises data centre to a single public cloud. That is hybrid cloud. A hypervisor in your own data centre does not, on its own, meet NIST’s definition of cloud computing, with its on-demand self-service, rapid elasticity and measured service. The “multi” adds marketing value rather than meaning.

Lock-in: what it really costs to avoid it

Avoiding vendor lock-in is the most common argument for multi-cloud. Spread your workloads, the theory goes, and no single provider can raise prices, cut support or hold your data hostage.

In practice, the major clouds are far less interchangeable than their service catalogues suggest. Identity and access management, networking, key management, logging and automation all work differently. Every workload that has to run in two places needs two sets of security controls, two operating models and engineers who understand both platforms in depth. Those people are scarce and expensive.

To hide the differences, companies build abstraction layers: Kubernetes for compute, Terraform for provisioning, an internal platform on top. These help, but they carry their own costs. They take considerable effort to build and maintain, and they tend to reduce every cloud to the lowest common denominator, cutting teams off from the managed databases, analytics and AI services that are often the reason for using the cloud in the first place.

Abstraction layers can also create lock-in of their own. When HashiCorp moved Terraform to a restrictive business source licence in August 2023, many organisations discovered how dependent they were on a single tooling vendor; the community responded with OpenTofu, an open-source fork now hosted by the Linux Foundation. IBM’s pending $6.4 billion acquisition of HashiCorp, announced in April 2024, has added further uncertainty.

Meanwhile, the cost of leaving a provider is falling. In early 2024 Google, AWS and Microsoft all began waiving data egress fees for customers moving their data out. The EU Data Act will require providers to make switching easier from September 2025 and to abolish switching charges entirely by January 2027, while the UK Competition and Markets Authority spent 2024 examining egress fees, committed-spend discounts and software licensing as part of its cloud market investigation. Lower exit costs strengthen the case for committing to one provider while keeping a credible exit plan.

Concentration also has commercial value. Hyperscaler discounts are tied to committed spend, so splitting a budget across providers usually weakens your negotiating position. Flexera found that managing cloud spend was organisations’ top challenge for the second year running, ahead of security. Multi-cloud makes that challenge harder, not easier.

For most organisations, the rational goal is to make exit possible rather than to stay permanently portable. Define infrastructure as code, document your dependencies on proprietary services, keep critical data in open formats and accept that some refactoring would be needed if you ever switched. Paying that cost once, if and when it arises, is usually far cheaper than paying a portability premium every month.

Multi-cloud for business continuity: a critical assessment

The other common argument is resilience: if your main provider suffers a major outage, goes out of business or cuts off access, you can fail over to another.

These scenarios need to be kept in proportion. Most hyperscaler outages are regional. The AWS us-east-1 incident of December 2021 disrupted thousands of services, but organisations running across several regions largely rode it out. Designing for multiple regions within one provider addresses the most likely failures at a fraction of the cost of multi-cloud. Provider-wide failures are rare, and the collapse of a hyperscaler is not a realistic near-term risk.

Running active workloads on two clouds means keeping components, software versions, security policies and data in sync across platforms that were never designed to work together. Every failover path has to be tested regularly, or it will fail when it is needed. The result is higher operating costs, more complexity and, ironically, more opportunities for misconfiguration, itself one of the leading causes of cloud incidents.

The CrowdStrike incident of July 2024 is instructive. A faulty update to a security agent crashed around 8.5 million Windows machines worldwide, including servers on every major cloud. Organisations that had spread workloads across providers but ran the same agent everywhere were hit just as hard. Concentration risk often sits in shared software, identity providers and processes rather than in the choice of cloud.

Regulators recognise this. The EU’s Digital Operational Resilience Act (DORA), which applies to financial firms from January 2025, requires them to assess ICT concentration risk and maintain exit strategies for providers that support critical functions. The UK’s Prudential Regulation Authority expects firms to plan for a stressed exit from material outsourcing arrangements. Neither requires running everything on two clouds.

A better investment is the ability to rebuild. With infrastructure as code, automated deployment pipelines, immutable backups held outside the primary account and a documented, rehearsed recovery plan, a company can restore critical services in another region, or with another provider if it ever came to that, without paying to run two environments permanently.

Conclusion

Multi-cloud is not wrong in itself. It makes sense when a specific service is genuinely better elsewhere, when an acquisition leaves you with two platforms, or when customers and regulators require it. What rarely makes sense is multi-cloud as a default insurance policy. For most organisations, the stronger position is deep, well-governed use of one primary provider, multi-region resilience for critical services and a tested exit plan. Those decisions should rest on measurable risks and real operating costs, not on a survey statistic or a vendor’s sales pitch.