Multi-Cloud: When It Makes Sense and When It Is a Tax

The three meanings

Most teams that say multi-cloud mean the first or second. The third is genuinely expensive and rarely justified outside specific regulatory or contractual requirements.

Good reasons

• Cost arbitrage. Bulk compute or bandwidth on a cheaper provider while using specialised services elsewhere. This is the most common sound reason.
• A specific capability available on one provider and not another.
• Data residency requiring a provider with presence in a particular country.
• Contractual or regulatory requirements naming provider diversity.
• Acquisition, where you inherit an estate and consolidation is not worth it.
• Negotiating position, which is real at large contract sizes and irrelevant at small ones.

Weaker reasons

• “Avoiding lock-in” in the abstract, without a scenario in which you would actually move.
• “Redundancy against provider outage” — multi-region on one provider addresses most of this at a fraction of the cost.
• “Best of breed for every service”, which usually means integration work exceeding the benefit.
• “It is what large companies do”, where the constraints are entirely different.

Provider-wide outages are rare; regional outages are more common and handled within one provider. The redundancy argument is weaker than it sounds.

The costs, which are ongoing

1. Egress between providers. Data leaving one and entering another is billed, often the largest recurring cost.
2. Two sets of expertise. Different IAM models, networking, tooling and failure modes.
3. Two sets of tooling for monitoring, deployment, cost management and security.
4. Latency between providers, which affects anything chatty across the boundary.
5. Lowest common denominator architecture, if you insist on portability across both.
6. Doubled security surface — two sets of credentials, policies and audit logs.

The expertise cost is the one that persists. Every incident requires someone who knows the relevant platform well.

Lighter alternatives

Most of the benefit, much less of the cost:

• Containers everywhere. Portable by construction, without running anywhere else today.
• Standard technologies — PostgreSQL rather than a proprietary database, S3-compatible object storage APIs, Kubernetes if you already have it.
• Infrastructure as code, so rebuilding elsewhere is a known quantity.
• Backups with a second provider, which gives real protection against account-level problems at very low cost.
• Multi-region within one provider for availability.
• A documented exit plan, tested at least on paper.

Backups with a second provider deserves particular attention: it costs very little and covers the scenario people actually fear.

If you do it, do it cleanly

1. Split by workload, not by component. Keep tightly coupled things together on one provider.
2. Minimise cross-provider traffic; it is the cost and the latency.
3. Use one identity provider across both, so access management is not duplicated.
4. Centralise monitoring and logging into one place.
5. Write down which provider owns which workload and why.
6. Review annually; inherited multi-cloud often outlives its reason.

Common questions

Where to go next

See hyperscaler versus VPS provider and planning a cloud migration.