Guides

Multi-cloud: when it makes sense and when it only adds complexity

An honest look at multi-cloud: the few cases where a second provider earns its keep, the costs people underestimate, and a cheaper way to keep options open.

Updated September 25, 2026

Multi-cloud: when it makes sense and when it only adds complexity

Multi-cloud is one of the most recommended and least examined ideas in infrastructure. The pitch is resilience and leverage: if one provider fails or raises prices, you move. The reality for most teams is two sets of identity systems, two networks that need stitching together, two bills and one exhausted on-call engineer. This article separates the cases where a second provider genuinely pays for itself from the cases where it is just complexity with a strategy label.

What multi-cloud actually costs

The visible cost is money: data transfer between providers is billed, and duplicated services double the baseline. The invisible cost is larger. Every provider has its own identity model, networking primitives, monitoring hooks and failure modes. Running two means your team must be competent in both, your infrastructure code must abstract over both, and every incident has twice the surface area.

  • Two identity and access systems to secure and audit
  • Cross-provider networking, usually over the public internet or a paid interconnect
  • Two monitoring integrations and two sets of alerts
  • Data that must be replicated, with egress charged on every copy
  • Skills spread thinner across the team

None of this is fatal. It is simply a price, and the question is whether what you get back is worth it.

When a second provider earns its keep

A residency or jurisdiction requirement

If a client contract requires data to stay in a particular region and your primary provider does not serve it well, a second provider is the correct answer. Hetzner runs data centers in Germany and Finland, and OVHcloud designs and operates its own infrastructure across Europe and North America. A US-centric stack on AWS with a European tenant on Hetzner or OVH is a common and defensible shape; the article on European data residency providers covers the options.

One specific managed service

Sometimes a single service justifies a second account: a foundation-model API, a particular GPU family, a managed database engine. Using AWS purely for Amazon Bedrock while the rest of the stack runs elsewhere is a narrow, contained form of multi-cloud that does not require stitching networks together. The Buy AWS Account page lists Bedrock-oriented options for exactly this kind of use.

Cost arbitrage for stateless work

Batch jobs, CI runners, rendering and other stateless compute can run wherever it is cheapest, because nothing needs to persist. A team on a hyperscaler that pushes its build fleet to a Hetzner 10 Server Limits Account or an OVH vCPU34 Account, both listed on the marketplace, gets real savings without touching the production database. See hyperscale or developer-focused cloud for how the two tiers of provider divide work.

When it only adds complexity

The weak cases share a pattern: the benefit is theoretical and the cost is immediate.

Stated reason Why it usually fails Cheaper alternative
Provider outage protection Stateful failover across clouds is rarely tested and often slower than a multi-region setup on one provider Multi-zone or multi-region on the primary
Negotiating leverage Small and mid-size accounts do not negotiate list prices Committed-use pricing on one provider
Avoiding lock-in Running on two clouds locks you into both Portable formats, containers, infrastructure as code

The cheaper way to keep options open

Most of what people want from multi-cloud is exit capability, not simultaneous operation. That is achievable on a single provider by keeping the stack portable: containers instead of provider-specific runtimes, open database engines, object storage accessed through a standard API, and every resource defined in code. Test the exit once a year by standing up a minimal copy of the stack on a second provider, then tear it down. The exercise costs a few days and proves more than a permanent second deployment ever will.

A decision rule

Add a second provider only when you can name the specific workload that moves, the specific reason it cannot run on the primary, and the person who will own the second account. If any of those three is vague, the answer is not yet. When the reason is a European tenant, the Hetzner vs OVH accounts comparison is a sensible place to start choosing which provider gets the job.

Questions on this topic

Does multi-cloud improve availability?

Rarely for small and mid-size teams. Stateful failover between providers requires continuous data replication, cross-cloud networking and regular failover testing, and most teams skip the testing. Deploying across multiple zones or regions on one provider gives most of the resilience at a fraction of the complexity. Reserve cross-provider redundancy for the few systems whose downtime cost justifies it.

What is the simplest form of multi-cloud?

Using a second provider for one stateless or self-contained workload. Examples include CI runners on Hetzner while production stays on AWS, or calling a foundation-model API on AWS from an application hosted elsewhere. No shared network, no replicated database, one clear owner. This captures most of the cost or capability benefit without the operational burden.

How do I keep the option to leave a provider without running two?

Keep the stack portable: containers, open database engines, standard object storage APIs and infrastructure defined in code. Once a year, rehearse an exit by deploying a minimal copy elsewhere, then removing it. The infrastructure as code guide explains how to structure definitions so a second provider is a variable rather than a rewrite.

More from the Blog

All articles
Providers

Civo accounts for Kubernetes-first teams

Why Civo suits teams that start from Kubernetes: free control plane, no egress fees, fast clusters, and what the listed Civo Cloud…

Read article September 25, 2026