Multi-cloud is a hedge against your own bad decisions. Most companies should not.
Multi-cloud is sold as resilience. It is usually overhead. Here is when it actually pays off, when it is just expensive, and the question I ask before I let a client commit.
Pattern·Multi-cloud without commercial justificationWhen multi-cloud actually pays off
Three legitimate reasons. Three expensive excuses.
Regulatory data residency
No single provider can satisfy your geo footprint
Genuine vendor escape
After a contract renegotiation went badly
M&A inherited
You did not choose this. Exit is not free.
"What if AWS goes down?"
Most outages are app bugs. You are not multi-region yet.
"Negotiating leverage"
You can get the discount without the second cloud.
"Best of breed"
Your platform team cannot keep up. Integration costs win.
The question that filters everyone
If your primary cloud became 20% more expensive overnight,
would you actually move workloads within six months?
If the answer is no, you do not have a strategy. You have a bill.
Single-cloud done well beats multi-cloud done poorly.
I have helped four companies abandon multi-cloud strategies in the last three years. Two of them had spent over 4 million pounds getting partway through. None of them ended up less reliable when they consolidated.
Multi-cloud is sold as a hedge against vendor risk. In practice, it is more often a hedge against the company's own indecision. A team that cannot commit to a primary cloud is usually a team that cannot commit to a primary strategy. The cost of that indecision is paid every month, in every environment.
Single-cloud done well beats multi-cloud done poorly. Most companies do exactly one of those, and it is not the first one.
Here is the cost most companies do not see until they are deep in. Every service you build needs two implementations. Every observability dashboard needs two integrations. Every IAM model needs two abstractions. Every cost report needs two tools to reconcile. Every senior engineer needs to know two networking models, two storage models, two managed Kubernetes flavours.
The platform team scales by one engineer per major cloud, minimum. That is the visible cost. The invisible cost is the decisions that get made slower because nothing has a clear owner.
Multi-cloud is the right answer in three situations.
- Regulatory data residency that no single provider can satisfy
- Genuine vendor lock-in escape, usually after a contract renegotiation went badly
- M&A reality where you inherited it and exit is not free
It is the wrong answer in three more.
- "What if AWS goes down?" Most outages are application bugs. Your app is not multi-region inside one cloud yet, let alone multi-cloud.
- "Negotiating leverage." You can get the same discount with a credible spend commitment and a meeting.
- "Best of breed." Your platform team cannot keep up. Best of breed becomes worst of integration.
The question I ask before any client commits to multi-cloud is this. If your primary cloud became 20% more expensive overnight, would you actually move workloads to the second one within six months? If the answer is no, you do not have a multi-cloud strategy. You have a multi-cloud bill.
The cheapest multi-cloud is the one you decide not to do. The second cheapest is the one you commit to with a specific reason, a primary cloud, and a hard ceiling on how much workload sits in the secondary one.
Get the next one in your inbox
One short, opinionated field note per fortnight on platform engineering, cloud, and making AI work in production. No spam. Unsubscribe anytime.
