- "For resilience" without ever testing the failover path. You've built a $50k/month insurance policy you can't actually claim against. - "To avoid lock-in" when your data layer is still tied to one cloud's database. The lock-in is at the data layer, not the compute layer. - "Because we got AWS credits / GCP credits" — credits are great; running the workload on both forever is not. - "Because the second cloud's sales team gave us a discount" — short-term saving, long-term ops debt.

Multi-Cloud Cost: When It Pays and When It Hurts

Q: When multi-cloud genuinely pays?

Three concrete cases where I'd sign off on it: 1. You need a specific service that's only one cloud's — Vertex AI for a specific Gemini integration, BigQuery for Petabyte-scale analytics where Athena fails, Cloudflare Workers on the edge. 2. You acquired a company on the other cloud and migration is more expensive than running both for a year. 3. You sell to enterprises with deployment requirements. If half your customers want Azure-deployed and half want AWS-deployed, you have multi-cloud wheth

Multi-cloud is sold as risk reduction. Most of the time it's just doubled spend, doubled ops, and doubled blast radius. Here's when it actually pays.

By Andrii Votiakov on 2026-04-16

"Multi-cloud" gets pitched as the responsible architecture choice. Reduces vendor lock-in. Improves resilience. Lets you negotiate. In practice, for most companies, it's none of those things — it's a 30-50% cost premium and twice the operational surface, with most of the lock-in still intact at the data layer.

Quick answer

Real multi-cloud (live workloads on two clouds) is rarely worth it. Disaster-recovery multi-cloud (cold standby on a second cloud) is almost always overkill. Service-by-service multi-cloud (BigQuery on GCP, ML on AWS) is the only flavour that consistently pays back. Pick one primary cloud, use the second only where the second's specific service is materially better.

The four flavours of multi-cloud

1. Active-active multi-cloud (rare and expensive)

Same workload running live on two clouds with traffic split between them. Sounds great, costs awful:

Doubled compute spend (you can't both be at 50% utilisation efficiently)
Cross-cloud data transfer ($0.04-0.09/GB depending on direction)
Doubled monitoring, doubled secrets management, doubled CI/CD complexity
Latency penalty for cross-cloud writes

When it makes sense: regulated financial services with explicit regulator mandate, hyperscale companies (Netflix-tier) where outage minutes cost millions.

For 99% of companies it doesn't pay back.

2. Active-passive multi-cloud (rarely worth it)

Production on one cloud, cold standby on another. Sounds like cheap insurance:

Low compute cost on the standby (sleeping VMs, on-demand startup)
Storage replication is the actual cost (cross-cloud egress every change)
The disaster scenario you're insuring against (a full AWS outage) has happened a few hours per decade
The DR you actually need is region-to-region within the same cloud, not cloud-to-cloud

When it makes sense: hard regulatory requirement for cross-cloud DR. Otherwise, multi-region within one cloud is faster, cheaper, and tested more often.

3. Service-by-service multi-cloud (often pays)

Pick the best service per workload:

BigQuery on GCP for analytical workloads — usually cheaper than Athena/Redshift at scale, fewer ops (see the GCP cost optimisation playbook for the full picture)
Vertex AI / Gemini on GCP for some ML/LLM workloads
Azure OpenAI for enterprise GPT integration with tighter compliance
Cloudflare Workers in front of any cloud for edge compute and DDoS; Cloudflare Workers and R2 cost breakdown is worth reading before committing
Cloudflare R2 for egress-free object storage

This works when the second cloud's specific advantage justifies the operational overhead. Egress between clouds for these specific paths usually stays manageable because data flows are bounded (analytics ingest, not OLTP traffic).

4. Edge + primary cloud (almost always worth it)

Cloudflare or Fastly at the edge plus AWS/GCP/Azure for origin. This is technically multi-cloud but doesn't feel like it:

Cloudflare's free tier handles enormous traffic
Workers + R2 for the cacheable surface saves egress and origin cost
One operational control plane (Cloudflare) for security, caching, edge logic

For any consumer-facing product, edge + cloud is the modern default. Not really multi-cloud — more like "cloud + CDN/security layer" — but worth naming.

The hidden costs people miss

Cross-cloud egress

The killer. AWS egress to GCP is around $0.09/GB for the first tier. GCP to AWS, similar. A few TB/month of cross-cloud data movement can quietly add $1-5k/month.

Solutions exist (Megaport, Equinix Fabric, AWS Direct Connect to a peering point) but they take effort to set up and have minimum spends.

Operational surface

Doubled monitoring stack. Doubled IAM model. Two completely different storage primitives. Two billing dashboards. Two on-call rotations of expertise required. For most teams below ~50 engineers, this is the dominant cost.

Per-cloud commitment discounts

Savings Plans on AWS and CUDs on GCP both reward concentration. Splitting workloads dilutes both commitments. You'll typically get 15-25% less discount stacking than a single-cloud-equivalent commitment.

When multi-cloud genuinely pays

Three concrete cases where I'd sign off on it:

You need a specific service that's only one cloud's — Vertex AI for a specific Gemini integration, BigQuery for Petabyte-scale analytics where Athena fails, Cloudflare Workers on the edge.
You acquired a company on the other cloud and migration is more expensive than running both for a year.
You sell to enterprises with deployment requirements. If half your customers want Azure-deployed and half want AWS-deployed, you have multi-cloud whether you like it or not — manage it deliberately.

When it's a trap

"For resilience" without ever testing the failover path. You've built a $50k/month insurance policy you can't actually claim against.
"To avoid lock-in" when your data layer is still tied to one cloud's database. The lock-in is at the data layer, not the compute layer.
"Because we got AWS credits / GCP credits" — credits are great; running the workload on both forever is not.
"Because the second cloud's sales team gave us a discount" — short-term saving, long-term ops debt.

My usual recommendation

Pick one cloud as primary. Keep ~95% of workload there. Use a second cloud only for:

Specific services where the gap is real (e.g., BigQuery if you're an AWS shop with petabyte analytics)
Edge layer (Cloudflare/Fastly)
Compliance-driven workloads where data residency requires it

This gives you the operational simplicity of a single primary cloud, the cost benefit of concentrated commitment discounts, and the strategic flexibility to use the right tool when needed.

Realistic numbers

Recent client running active-active multi-cloud (~$60k/month combined):

Migrated 80% of GCP workload to AWS (their primary): $11,200/month saved on duplication
Kept BigQuery for analytics: net cost increase $1,800/month, but unblocked a delayed analytics roadmap
Eliminated cross-cloud data sync infrastructure: another $2,400/month saved
Net: $11,800/month reduction, much cleaner operationally

The "resilience" they thought they were buying? They tested failover for the first time as part of consolidation and found three undocumented dependencies that would have failed anyway. Reality > theory.

If you're also looking at Azure as a second cloud, the Azure cost optimisation playbook covers the levers worth pulling before committing to a second provider.

If you're considering multi-cloud — or trying to escape it — and want a no-pressure assessment, book a call.