The situation. Somewhere in most cloud strategy decks is a slide arguing for multi-cloud: run across two or more providers so you’re never locked in, never held hostage on price, never one outage away from ruin. It sounds like prudence. In practice, for most organizations, running multi-cloud as a default posture is a tax you pay every day for insurance you almost never claim.

Portability isn’t free, and it isn’t a switch. True provider independence means refusing the managed services that make a cloud worth using (the good queue, the good database, the good identity layer) and rebuilding those capabilities on the lowest common denominator you can run anywhere. You trade a service the provider operates for one your team now owns. The bill you were trying to avoid reappears as headcount, undifferentiated infrastructure work, and a slower path to shipping anything.

The lock-in you fear is rarely the lock-in you have. The genuinely sticky dependency is almost never compute or storage. It’s data gravity and operational habit. Your data is large and expensive to move; your team knows one provider’s failure modes in their bones. A second provider doesn’t dissolve either of those. It doubles the operational surface you have to know well, which is the opposite of resilience.

Redundancy has a cheaper address. Most of what people want from multi-cloud (survive an outage, survive a bad region) is available within a single provider, across regions and availability zones, without a second control plane, a second security model, and a second on-call rotation to keep fluent. Multi-region on one cloud is a well-worn path. Multi-cloud active-active is a research project that never ends.

Where it does earn its cost. The honest exceptions are specific, not architectural. A regulatory requirement to keep certain data on a certain provider. A specialized service that genuinely exists in one place and nowhere else. An acquisition that arrived on a different cloud and isn’t worth migrating. These are real, and they’re narrow: you adopt a second cloud for a named workload with a named reason, not as a company-wide stance.

A test for the exception. Before a second provider goes into the architecture, make someone answer four questions in writing. Which named workload is going there, and why can’t it live where everything else lives? What event are we buying protection against, and how would we know it happened? Who operates it at 3 a.m., the same on-call rotation or a second one we now have to staff and keep fluent? And what does the exception cost us in the boring places: identity, networking, secrets, deployment, compliance evidence, the pipeline that now has to build for both? If those answers are vague, the second cloud isn’t a strategy. It’s a preference nobody has priced.

What it means for you. Default to one cloud and go deep: learn its failure modes, use its managed services, spend the saved effort on your actual product. Treat a second provider as a deliberate exception you can justify per workload, not a hedge you buy for everything. Portability is real optionality, and optionality has a price. Pay it where you’ll exercise it. Don’t pay it, continuously, on the off chance.