I hear “multi-cloud” constantly. Conference talks, vendor pitches, job descriptions, all of it assumes that a serious engineering organization should run workloads across two or more cloud providers. But when I actually look inside these organizations, the picture rarely matches the pitch. It’s usually 95 percent Azure and 5 percent Google Cloud Platform (GCP), or 80 percent Azure and 20 percent Amazon Web Services (AWS ). Technically, yes, that’s multi-cloud. Practically, it’s one cloud with a side project.
There are good reasons this lopsided pattern keeps showing up, and understanding them tells you more about how multi-cloud decisions actually get made than any architecture diagram does.
What Lopsided Multi-Cloud Actually Looks Like#
The dominant provider runs the identity platform, the core databases, the primary compute, and the networking backbone that everything else depends on. The “5 to 20 percent” provider is doing, well… other stuff.
This isn’t a failure of execution. It’s just what happens when you follow the incentives honestly. Deep expertise, volume discounts, and existing automation all pull toward one provider. Nobody is confused about why enterprises that have been invested in Microsoft for decades tend to prefer Azure.
The Cognitive Overhead Nobody Budgets For#
Every cloud provider has its own console, its own naming conventions, its own quirks in how identity and access management works, and its own way of doing basically everything. AWS has Identity and Access Management (IAM) policies. Azure has role-based access control (RBAC) and a completely different resource hierarchy. GCP has yet another model built around projects and organizations.
Asking an engineering team to maintain fluency across all three is asking a lot. You either end up with generalists who are mediocre at all three platforms, or specialists in silos who can’t cover for each other. Neither outcome is good for on-call rotations, incident response, or hiring. When something breaks at an inconvenient time, you want someone who can troubleshoot in their half-awake state.
Abstraction Layers Just Move the Problem#
A common answer to this overhead is to build an abstraction layer, some internal platform or third-party tool that presents a unified interface over multiple clouds. The idea is that your teams write to one API and the abstraction handles the translation underneath.
In practice, these layers become their own maintenance burden. You’re now supporting a piece of software whose entire job is to paper over meaningful differences between providers, and those differences leak through anyway. Latency goes up because you’ve added a hop. Bugs show up in the translation layer itself, not just in the underlying cloud services. And when a provider ships a new feature, you’re waiting on your abstraction layer to catch up before your teams can use it.
You haven’t eliminated the complexity of multi-cloud. You’ve just given it a name and put it on your own team’s backlog.
Lowest Common Denominator Architecture#
If you design for portability across providers, you have to restrict yourself to the services that exist, roughly equivalently, on all of them. That usually means basic compute, basic object storage, and basic managed databases.
But the best reasons to use a given cloud provider are usually the services that aren’t portable. AWS’s managed services for machine learning inference, Azure’s deep integration with enterprise identity systems, and GCP’s data analytics stack all offer real advantages precisely because they’re not replicated feature-for-feature elsewhere. Designing for portability means you deliberately avoid the tools that would make your architecture better, in exchange for a flexibility you’ll likely never use.
When Multi-Cloud Actually Makes Sense#
Having said all that, there are legitimate cases for multi-cloud.
Regulatory requirements sometimes mandate data residency or separation that a single provider can’t satisfy across every jurisdiction you operate in. Redundancy at the business continuity level, not just the availability zone level, can justify a second provider if an outage at your primary provider would be genuinely catastrophic and not just inconvenient. And in some negotiations, having a credible second provider gives you real leverage on pricing and contract terms.
Notice what these cases have in common. They’re specific, they’re driven by a concrete requirement, and someone can articulate the exact business or regulatory reason for the second provider. That’s very different from adopting multi-cloud as a default architectural posture because it sounds responsible.
The Real Reasons Multi-Cloud Gets Adopted#
If regulatory and redundancy needs were the actual drivers, we’d see multi-cloud show up far less often than we do. The more honest explanation involves people, not architecture.
Engineers want experience with multiple platforms on their resumes, and building out a footprint on a second cloud is a good way to get it. Executives have relationships with account teams at competing providers, and a strategic deal or a personal connection can steer workloads in a direction that has nothing to do with technical fit. And leadership sometimes fears being locked into a single provider so much that they’ll accept real architectural cost just to avoid the discomfort of dependency.
None of this is unique to cloud computing. It’s just business. Vendors have always competed for influence inside organizations, and decision-makers have always had incentives that don’t perfectly align with the cleanest technical outcome. Cloud strategy isn’t exempt from office politics just because it involves infrastructure instead of, say, procurement contracts.
What To Do Instead#
If you’re deciding how to architect a new system, start by asking what regulatory, redundancy, or leverage requirement actually exists. If you can’t name one, you probably don’t need multi-cloud. You need depth on one provider.
Depth means your team actually masters the native services on that platform instead of tiptoeing around the lowest common denominator. It means your on-call engineers know the platform well enough to debug it fast. It means you get the full benefit of the provider’s more differentiated offerings instead of avoiding them for the sake of theoretical portability.
If you’re building that depth on AWS specifically, investing in a real AWS certification, not just a weekend cram session, pays off far more than spreading your team thin across three consoles. I’ve written a few books on AWS certification prep for exactly this reason. A team with one engineer who deeply understands AWS IAM, networking, and its managed services will outperform a team of generalists juggling three platforms, almost every time.
Multi-cloud isn’t necessarily wrong. It just shouldn’t be the mindless default. Treat it like any other architectural decision: name the requirement first, and let the requirement drive the provider, not the other way around.
Recommended Reading#
If you found this post useful, you might also be interested in:
- AWS Certified Solutions Architect Study Guide: Associate SAA-C03 Exam, 4th Edition
- AWS Certified Cloud Practitioner Study Guide With 500 Practice Test Questions: Foundational (CLF-C02) Exam (Sybex Study Guide)
- The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
Featured image by Jason Mavrommatis on Unsplash