The real cost of multi-cloud

The multi-cloud pitch is seductive: no vendor lock-in, negotiate better prices, survive any provider outage. The bill is quieter: every service abstraction you build to stay portable costs engineering time, forbids you the managed services that make a cloud productive, and doubles the surface your team has to secure, monitor, and understand.

In our audits, the most common multi-cloud outcome isn't resilience — it's two half-mastered platforms instead of one well-run one.

The decision is rarely made explicitly. It arrives sideways: an acquisition brings a second provider, a team picks a niche service that only exists on one cloud, someone signs a committed-spend deal to unlock a discount. Two years later the architecture diagram has two of everything and nobody can point to the meeting where that was chosen.

That is worth naming, because an accidental multi-cloud estate carries all of the costs below and almost none of the benefits. The benefits require deliberate design. The costs arrive on their own.

The first is egress. Moving data between providers is charged at rates that make intra-cloud traffic look free, and architectures that split a workload across clouds tend to move far more data than their designers imagined. This is the bill that turns up in month four and prompts an emergency redesign.

The second is expertise. Cloud platforms look similar in a comparison table and diverge sharply in practice — identity models, networking primitives, and failure behaviour are genuinely different. A team fluent in one is competent-at-best in a second, and you are now paying to keep two sets of knowledge current across a group that was probably already stretched.

The third is security surface. Two identity systems, two audit trails, two sets of network rules, two places for a misconfigured bucket to live. Compliance work does not add up across clouds, it multiplies, because the evidence has to be gathered and reconciled twice.

The fourth is cognitive load, and it is the one that never appears in a spreadsheet. Every incident starts with a question that has two possible answers. Every design discussion carries an extra axis. The tax is paid in engineering attention, which is the scarcest thing a small company owns.

Lock-in fear is usually priced wrong. Migrating a well-architected workload between clouds is a project measured in weeks — annoying, bounded, and rare. Running lowest-common-denominator infrastructure to preserve theoretical portability is a tax measured in years — paid continuously, whether you ever migrate or not.

Managed databases, queues, and serverless runtimes are precisely the services that make small teams fast. Refusing them to stay portable means paying the migration cost every single day, in advance, for a move you'll probably never make.

Price it honestly. Estimate what a real migration would cost in engineering weeks, and multiply by the probability you actually do it in the next three years. For most companies that expected cost is smaller — often much smaller — than a year of running your own abstraction layer over two providers' primitives.

There is a second kind of lock-in that deserves more fear than it gets, and it is not technical. Committed-spend agreements, bespoke pricing tied to volume, and the negotiating position you give up by being visibly unable to leave are commercial constraints. They are also the ones a second cloud does least to solve, because the discount you were chasing usually required concentrating spend in the first place.

Surviving a provider outage is the argument that sells multi-cloud, and it is the one that survives scrutiny least often. Full provider-wide failures are rare. The outages that actually take products down are usually regional, or specific to one service, or — far more often — caused by the operator's own deployment.

Against regional and service-level failures, multi-region within a single provider is the better instrument: cheaper, better documented, and exercised by a team that only has to be expert in one platform.

There is also an uncomfortable arithmetic to genuine active-active across two clouds. It requires data replicated across providers with the consistency problems that implies, traffic steering that works when one side is unhealthy, and regular failover drills. Complexity is itself a leading cause of downtime. A system that can survive a provider outage but falls over twice a year under its own weight is not more available — it is less available, in a way that is harder to explain.

The honest test: ask when you last completed a full failover drill. If the answer is never, the second cloud is not a resilience strategy. It is an expense with a comforting story attached.

There are real cases: regulatory requirements that mandate data residency a single provider can't cover; a product that embeds into customers' own cloud accounts; genuine scale where committed-use discounts across providers are worth real money; and best-of-breed splits — training on one cloud's GPUs while serving from another's edge.

Notice what's common: each case is driven by a concrete external constraint, not by abstract fear. If you can't name the constraint, you don't need the second cloud.

The embedded case is the most under-appreciated. If you sell software that runs inside a customer's own account, their cloud choice is yours, and supporting a second provider is a straightforward revenue question — how much business is behind that door, and is it worth more than the cost of the key. That is a decision with numbers in it, which makes it a different species from most multi-cloud debates.

Scale changes the maths too, but later than people expect. Cross-provider negotiating leverage becomes real when your annual spend is large enough that a few percentage points fund a platform team. Below that threshold you are paying a platform team's worth of complexity to chase a discount smaller than their salaries.

These are routinely conflated in the same conversation, and they solve different problems at wildly different prices. Multi-region protects against a regional failure and helps with data residency and latency, inside one provider's tooling and one team's expertise. Multi-cloud protects against a provider-level commercial or availability event, and costs everything described above.

Most teams asking for multi-cloud want what multi-region actually delivers. It is worth establishing which problem is on the table before the architecture is drawn, because the cheap answer solves the common case and the expensive answer is frequently bought by mistake.

Pick one primary cloud and go deep: managed services, infrastructure as code, real cost governance. Keep your escape hatch honest but cheap — containerized workloads, standard Postgres, Terraform — so a future migration is a project, not a rewrite. Revisit the decision when a concrete constraint appears, and not before.

Cheap is the operative word. An honest escape hatch means preferring open protocols where the managed service speaks one anyway, keeping infrastructure declarative, and knowing which components are genuinely provider-specific. It does not mean building an abstraction layer over two providers' primitives on the off chance. That is the expensive version, and it delivers the worst of both: you carry the portability cost continuously and still discover, at migration time, that the abstraction leaked in the places that mattered.

Write the decision down. A short document naming the primary provider, the constraints that would trigger a review, and the components deliberately kept portable is worth more than any diagram. It turns an architectural default into a choice with an owner, and it means the next engineer who wants to add a service from another provider has to argue against something specific.