Every few months a client comes to us with a multi-cloud mandate handed down from procurement or leadership. “We can’t be dependent on one vendor.” Sometimes this is a reasonable risk management position. More often, it’s a decision made without fully accounting for the operational cost.
Let’s be precise about the word, because it covers different things. Running separate, unconnected workloads on two providers because two teams chose differently is multi-cloud by accident, and it’s usually harmless. Running one system across two providers — shared identity, cross-cloud networking, workloads that depend on each other — is multi-cloud by design. That last one is what the mandate usually asks for, and it’s the one this article is about.
When multi-cloud genuinely helps
Regulatory requirements that mandate geographic or vendor distribution. Specific workloads that need capabilities one provider does significantly better (ML training on GCP, then inference on AWS, for instance). Negotiating leverage — though this requires real commitment to execute, not just the threat of it.
Regulation is the clearest case. If a regulator, a data-residency rule or a large customer’s contract requires you to demonstrate that you could exit a provider, or requires certain data to stay in a region only one provider serves well, then the decision is made for you. The job becomes meeting the requirement at the lowest operational cost, which usually means isolating the regulated workload rather than spreading everything.
Best-of-breed workloads are the second case, and it is narrower than people think. The example above is real: teams train on GCP for TPU access or the tooling around Vertex AI, then serve from AWS because that is where the product and the customer data already live. The boundary between the two is a model artefact in a bucket. That is a clean seam. If the seam is a shared database, it isn’t a clean seam and the case collapses.
Leverage is the third case. A credible threat to move workloads can improve a committed-spend negotiation. But credible means you have actually moved something and could move more. A slide deck that says “we are evaluating Azure” moves nobody’s pricing. If you are not going to run real production workload on the second provider, don’t count leverage as a benefit.
When it mostly creates problems
The biggest cost of multi-cloud isn’t the infrastructure — it’s the cognitive overhead. Your team needs to be proficient in two (or more) security models, two sets of networking primitives, two billing systems, two sets of managed services with different APIs and failure modes. That proficiency is expensive to build and expensive to maintain.
We’ve seen teams spend 40% of their infrastructure engineering time managing cross-cloud networking and identity — time that would have been better spent on reliability, cost optimisation, or developer experience in a single well-operated environment.
Some specifics, because “cognitive overhead” sounds abstract until you are paying for it.
- Identity. AWS IAM and Microsoft Entra ID are different models with different primitives. Federating between them works, but every permission decision now has to be reasoned about twice, and least-privilege reviews double in size.
- Networking. A VPC and a VNet look similar on a diagram and behave differently in the details — routing, private endpoints, DNS resolution, how security groups and NSGs evaluate rules. Cross-cloud connectivity means either paid interconnects or VPNs over the public internet, and both need monitoring you didn’t previously need.
- Egress. Data leaving a cloud is billed. Chatty services split across providers pay that toll on every request, and it rarely appears in the business case that justified the split.
- Observability and on-call. Two sets of logs, two metrics stacks, and on-call engineers who must be competent in both consoles at three in the morning.
- Tooling. Terraform covers both, which helps, but the modules, state layout, CI runners and secrets management all fork. Every platform improvement is done twice, or for one side only.
The 40% figure deserves underlining. That team was competent, and the plumbing still ate close to half its capacity while the things that actually reduce risk — tested restores, sensible commitment coverage, a boring deploy process — sat waiting.
The honest question to ask
What specific, quantified risk does multi-cloud mitigate? If the answer is “vendor lock-in” — ask what the actual scenario is. Cloud providers have been extraordinarily stable. If the answer is “regional outage” — ask whether your application is truly designed to fail over between clouds, or whether that’s aspirational architecture that’d take 18 months to actually implement.
Push on the outage scenario in particular, because it is the one that sounds most reasonable. Genuine cross-cloud failover requires your data to be replicated across providers with an acceptable lag, your identity and DNS to be independent of the failed provider, your deployment pipeline to not itself live on the failed provider, and a runbook someone has rehearsed. Most organisations that say “we have multi-cloud for resilience” have none of those. What they have is a second bill.
Compare the alternative. A multi-region deployment within one provider protects you from the far more common failure — a single-region incident — using the provider’s own replication, global load balancing and a single security model. It is not free, but it is far less engineering than the cross-cloud version, and you will actually finish it.
“If your failover plan has never been run, you don’t have a failover plan. You have a diagram.”
What we ask before agreeing to build it
- Which specific workloads need to be on the second provider, and why those?
- Where is the seam between the two, and does it survive a failure on either side?
- Who on the team is already proficient in the second provider, and who will be on call for it?
- What is the egress bill at projected traffic?
- What single-cloud work is being deferred to fund this?
If you are going to do it anyway
Multi-cloud done well is an engineering discipline, not a procurement strategy. If you’re not treating it as the former, you’re incurring the cost without the benefit.
Sometimes the mandate stands. Here is how to keep the cost bounded.
- Keep the seam narrow and asynchronous. Bucket replication, queues, exported artefacts. Not shared databases or synchronous calls across the boundary.
- Pick a primary. One provider carries identity, DNS, CI runners and the majority of workloads. The other is deliberately secondary, with a defined scope that does not grow by default.
- Standardise on portable layers where it is cheap — containers, Terraform, OpenTelemetry — and stop pretending you will abstract away the managed services. You won’t, and trying costs more than being locked in.
- Budget the operational cost explicitly. Headcount, training, egress, interconnect. Put it next to the risk it mitigates and revisit the comparison annually.
- Rehearse whatever the second provider is meant to give you. If it is failover, fail over. If it is exit, run a scoped exit exercise. Untested capability is a line item, not a capability.
Done this way, multi-cloud is a bounded, deliberate investment with a measurable return. Done the other way, it is a second set of everything and a team that is slower at all of it.
