7 min read
Last updated:
Multi-cloud is the architecture pattern most often defended on principle and most often regretted in practice. The pitch is that distributing workloads across AWS, Azure, and GCP avoids vendor lock-in, improves resilience, and gives you negotiating leverage. The reality is that multi-cloud done well requires a level of platform engineering investment that most organizations cannot sustain, and multi-cloud done badly is single-cloud with extra steps and an extra bill.
This post is the conversation we have with technology leaders who are about to spend a quarter on a multi-cloud strategy. The goal is not to argue against it categorically. The goal is to tell you when it is actually justified, when single-cloud with cross-region failover does the same job for a fraction of the cost, and what the honest budget looks like in either direction.
Why People Want Multi-Cloud
Three motivations dominate the conversation. The first is vendor lock-in anxiety, often framed in board meetings as risk management. The second is resilience against a full provider outage, which became a fixture of architecture decks after every multi-hour AWS or Azure incident in the last five years. The third is procurement leverage, the belief that being able to credibly threaten to move workloads will produce better pricing.
Each motivation is real. Each is also, in most organizations, addressable by something less drastic than a full multi-cloud architecture.
The True Cost of Operational Multi-Cloud
Running production workloads across two hyperscalers is not 2x the cost of running on one. It is closer to 2.5x to 3x once the second-order effects are honest. The line items that nobody includes in the original deck include the ones below.
- Duplicated platform expertise: separate IAM models, separate networking primitives, separate observability stacks, separate compliance tooling, separate cost management. Each cloud requires people who know it deeply, and those people are not interchangeable.
- Egress charges: cross-cloud data transfer is the line item that surprises every CFO. Pulling data from one cloud to another costs roughly 5 to 9 cents per gigabyte at most providers. At terabyte scale, this becomes a recurring six-figure cost that pure single-cloud architectures do not pay.
- Lowest common denominator services: if you want true portability, you cannot use Aurora, BigQuery, Cosmos DB, or any other proprietary managed service that gives you most of your leverage on a given cloud. You end up running self-managed Postgres, MySQL, and Kafka on Kubernetes across both clouds, and you have just bought yourself a database team.
- Identity and networking: cross-cloud VPN or interconnect, federated identity, consistent secret management, and unified network policies all become real engineering projects. Solutions like HashiCorp Boundary, AWS Verified Access, Azure Arc, and Anthos help, but each adds its own operational burden.
- Observability: stitching together logs, metrics, and traces across two clouds requires either a vendor like Datadog, New Relic, Honeycomb, or Grafana Cloud (which makes the cloud underneath irrelevant but adds a real bill) or significant investment in OpenTelemetry collectors, retention policies, and unified dashboards.
The fully loaded cost of a credible multi-cloud capability
When Multi-Cloud Is Genuinely Forced
Some organizations do not have a choice. The patterns where multi-cloud is the correct answer are recognizable and worth naming directly.
Regulatory or Sovereignty Requirements
EU data residency under sovereignty regimes, financial services rules in jurisdictions that mandate provider diversity, government work that requires GovCloud, healthcare in regions where the dominant provider does not have a presence, and any contract with a sovereign cloud requirement (Bleu in France, Delos in Germany, GAIA-X-aligned offerings) all force a multi-cloud or sovereign-cloud posture. This is not a choice and the cost is part of the cost of doing business in that vertical.
Mergers and Acquisitions
If you acquire a company on a different cloud, you inherit a multi-cloud posture by accident. The honest path is usually to pick a target cloud and migrate within 12 to 24 months, but the interim period is real multi-cloud and needs to be staffed and budgeted accordingly.
Vendor-Down Business Continuity for Critical Services
For a small set of services where a multi-hour outage of the primary cloud would cause material harm to customers or to the business, having a warm standby on a second cloud is justifiable. Note that this is rarely the entire system. It is usually the customer-facing critical path: authentication, the core read API, the payment confirmation flow. Everything else can tolerate a regional incident.
Specialist Workloads That Genuinely Differ Per Cloud
If your ML training workloads benefit materially from GCP TPUs, your enterprise integrations rely on Microsoft Entra and Office 365 connectivity, and your core platform runs on AWS for ecosystem reasons, you have a workload-driven multi-cloud posture. This is the most common form in practice and the most defensible. Each cloud earns its place by being best for a specific category of workload.
When Single-Cloud With Cross-Region Is Enough
For the majority of mid-market and even enterprise SaaS workloads, a single cloud with two or three regions delivers higher availability, lower complexity, and dramatically lower cost than a multi-cloud architecture. The reasoning is straightforward.
Provider-wide outages are rare. Regional outages are also rare but somewhat more frequent. Architecting for cross-region failover within AWS, Azure, or GCP gives you 99.99 percent realistic availability without the egress charges, the lowest-common-denominator services, or the duplicated expertise burden. AWS Route 53 with health checks across regions, Azure Front Door, and Cloud Load Balancing in GCP all handle the routing layer cleanly. Aurora Global Database, Cloud Spanner multi-region, and Cosmos DB multi-region cover the data layer at a real but tractable cost.
The honest comparison is that a well-architected single-cloud, multi-region deployment delivers 99.99 percent availability for roughly 1.3x to 1.5x the cost of a single-region deployment. A credible multi-cloud architecture targeting the same availability target costs 2.5x to 3x and adds operational risk that often pushes effective availability lower, not higher, because every additional system is a system that can fail.
The Vendor Lock-In Question, Reframed
Lock-in concern is real but the mitigation is not multi-cloud. The mitigation is portable abstractions where they matter and proprietary services where they pay. The discipline looks like this: use Kubernetes (EKS, AKS, GKE) for compute orchestration so the deployment model is portable; use Terraform or OpenTofu for infrastructure so the provisioning model is portable; use OpenTelemetry for instrumentation so the observability model is portable; and use proprietary managed databases, message brokers, and AI services where the operational savings outweigh the portability cost. Document the assumptions, track the cost of staying versus leaving each year, and accept that some lock-in is the price of leverage.
The Procurement Leverage Question, Reframed
The credible threat to move workloads is not multi-cloud. It is having a recent migration cost estimate in your back pocket and a procurement lead willing to use it. Hyperscaler reps know which customers actually have the engineering muscle to migrate and which do not. The leverage comes from credibility, not from running production traffic on the second cloud. A pilot workload, a Terraform-defined reference architecture, and a documented migration runbook produce most of the leverage at a fraction of the cost.
The Practical Posture We Recommend
For most engineering organizations the honest recommendation is a primary cloud, a deliberate set of cross-region failover patterns, and a small set of intentional workloads on other clouds where they earn their place. ML on GCP if that is where the talent and the TPUs live. Enterprise integration on Azure if that is where the customers live. Core SaaS on AWS if that is where the ecosystem fits. Each cloud has a clear reason to exist, no workload spans two clouds without justification, and the platform team is not stretched across three operational models.
When Multi-Cloud Applies
True multi-cloud applies when regulation forces it, when M&A creates it temporarily, when a critical service genuinely needs vendor-down BCDR, or when distinct workloads have distinct best-of-breed homes. In those cases, budget for the operational tax up front and staff it.
When It Does Not
Multi-cloud does not apply when the motivation is generic vendor lock-in worry, theoretical resilience against rare provider-wide outages, or procurement leverage you can earn more cheaply through credibility. It does not apply when your engineering team is under 200 people and already stretched on the primary cloud. And it does not apply when the alternative is a single cloud with a serious cross-region failover story, which for most workloads delivers more availability for less money. The hardest part of this decision is admitting that the simpler answer is also the better one.