Multi-cloud strategy is one of the most frequently debated and least rigorously evaluated technology decisions in engineering leadership. It is sold by consultants as risk management, by cloud providers as optionality, and by architects as technical sophistication. The reality is more prosaic: most organisations that adopt multi-cloud do so for reasons that do not withstand scrutiny, and the costs they absorb significantly exceed the benefits they receive.
The Multi-Cloud Promise vs the Reality
Multi-cloud promises vendor independence, competitive pricing leverage, best-of-breed service selection, and resilience against provider outages. In practice: vendor independence requires abstraction layers that constrain access to provider-native capabilities; pricing leverage requires a procurement sophistication that most organisations do not have; best-of-breed selection produces operational complexity that typically exceeds the capability advantage; and the major cloud providers have not had correlated global outages that a multi-cloud architecture would have prevented.
Why Companies Adopt Multi-Cloud
The legitimate reasons for multi-cloud adoption are few and specific: regulatory requirements that mandate data residency in jurisdictions served by different providers; acquisition integration where different entities use different cloud providers; specific technical capabilities that exist only on one provider; and — most legitimately — different workloads with genuinely different technical requirements. The illegitimate reasons are more common: fear of vendor lock-in based on hypothetical future risk, executive preference for provider diversification without analysis, and cargo-cult adoption based on what large technology companies do without understanding why they do it.
The Hidden Costs Nobody Budgets For
Multi-cloud multiplies operational complexity. Every provider has different networking models, different IAM systems, different monitoring integrations, different support processes, and different cost models. Engineers must develop and maintain expertise across multiple providers. Security posture must be assessed and managed across multiple environments. Cost optimisation — already complex within a single provider — becomes dramatically more difficult across multiple. The abstraction layers required to make workloads portable across providers add latency, cost, and another layer of software to maintain.
Vendor Lock-In: How Real Is the Risk?
Vendor lock-in risk is real but frequently overstated. The most significant form of lock-in is not at the infrastructure level — VMs, object storage, and networking are broadly portable — but at the managed service level. A system built on provider-native AI/ML services, serverless platforms, or specialised data services is genuinely difficult to migrate. The question for engineering leaders is whether the capability advantage of those native services justifies the migration cost if the relationship with the provider deteriorates. For most organisations, the answer is yes, because the probability of a forced migration is low and the capability advantage is immediate and concrete.
When Multi-Cloud Makes Strategic Sense
Multi-cloud is strategically justified when: workloads have materially different technical requirements that map to different provider strengths; regulatory requirements impose data residency obligations across different geographies served by different providers; or the organisation has the engineering maturity and operational scale to absorb the complexity. Specifically, this typically means large enterprises with dedicated cloud centre of excellence functions, significant multi-geography presence, and engineering teams with deep expertise across providers.
When Multi-Cloud Is Just Distributed Complexity
Multi-cloud is distributed complexity without strategic benefit when: the primary motivation is vendor lock-in avoidance based on hypothetical risk; the organisation does not have the engineering capacity to maintain expertise across multiple providers; the abstraction layers required for portability constrain access to the provider capabilities that justify cloud adoption in the first place; or the operational overhead of managing two environments exceeds any cost or capability benefit.
The Abstraction Layer Trap
The most common architectural response to multi-cloud requirements is an abstraction layer that presents a uniform interface across providers. This approach is technically appealing and practically problematic. Abstraction layers constrain the features available from each provider to the lowest common denominator. They require continuous maintenance as providers update their services. They add latency and cost. And they rarely achieve the portability they promise, because the semantic differences between providers are too significant to fully abstract. The abstraction layer often delivers the worst of both worlds: additional complexity without genuine portability.
A Decision Framework for Cloud Strategy
Before committing to multi-cloud: identify the specific risk or capability gap that multi-cloud addresses. Quantify the cost of the abstraction and operational overhead required. Assess whether a single-provider strategy with appropriate redundancy and contractual protections addresses the same risk at lower cost. Evaluate the engineering team’s capacity to maintain expertise across multiple providers. If the analysis produces a clear answer, act on it. If it produces significant uncertainty, the single-provider strategy is almost always the more pragmatic choice until the need for multi-cloud is concrete rather than hypothetical.
Evaluating your cloud strategy and want an independent perspective?
Our cloud architects work with CTOs and heads of infrastructure to design cloud strategies that are right for your organisation’s scale, regulatory environment, and engineering maturity.
Schedule a Consultation