There’s a moment in every cloud strategy workshop where someone says it. You can feel it coming… the CIO leans back, crosses their arms, and declares: “We’re going multi-cloud.”
The room nods. It sounds smart. It sounds strategic. It sounds like the kind of thing you’d read in an analyst report. And that’s the problem.
Hedging Your Bets Fallacy
I recently worked with a large consumer branding organization that had committed to a cloud-first strategy. Good. They had executive sponsorship. Great. They had a roadmap. Fantastic. Then they decided they needed to run workloads across AWS, Azure, and GCP, simultaneously, to avoid vendor lock-in. It’s the enterprise equivalent of signing up for three gyms because you’re worried one might close.
Vendor lock-in is of course a real concern. But the cure has to be proportional to the disease. Most organizations haven’t even figured out how to operate well in one cloud, and they’re already architecting for multiple that, oh by the way, need to interoperate.
What’s Actually Happening
Here’s what I see on the ground. Organizations land on multi-cloud for one of three reasons:
- By Accident. One team adopted AWS for a project two years ago. Another group went with Azure because it came bundled with their Enterprise Agreement. Someone in data science spun up GCP because of BigQuery. Nobody planned this. It just happened. Like a junk drawer, but with billing accounts.
- As Insurance Policy. Leadership wants leverage in vendor negotiations and fears dependency. This is rational in theory but often counterproductive in practice. Running production workloads across multiple platforms to save 8% on your cloud bill is likely to be more expensive than negotiating better rates for one provider.
- The Best-of-Breed Fantasy. The idea to cherry-pick the best services from each provider, say AWS for compute, Azure for enterprise integration, or GCP for machine learning is intellectually appealing. It’s also a staffing nightmare. Finding people who are expert in one cloud platform is hard enough. Finding people fluent in three adds about order of magnitude approaching unicorn territory.
The Hidden Tax
The glossy multi-cloud pitch decks happily ignore the notion of the operational tax. Every additional platform means: a separate security model to manage, different networking paradigms to reconcile, distinct monitoring and observability tools. On top of that, you’d need separate skill sets teams and multiple vendor relationships to manage, each with their own pricing models that take inspiration from cloudy opaqueness.
One could, of course, build an abstraction layer so applications could run on any cloud. I watched one client do exactly that, spending six months to create an elegant and well-engineered solution. Sadly, it also negated every cloud-native advantage they were migrating to the cloud to get in the first place. They had built a platform to avoid platforms.
So What Can You Actually Do?
Pick one. Get good at it. Seriously.
Choose a primary cloud platform that aligns with your organization’s skills, vendor relationships, and workload profile. Go deep. Build competency. Establish your operating model, security patterns, and cost management discipline in that one environment.
That doesn’t mean ignoring others entirely: there are legitimate reasons to use a second platform for specific workloads. You might need a data analytics capability that’s genuinely superior, perhaps you face a regulatory requirement for data residency, or an acquisition that brings its own cloud footprint. But these should be deliberate, justified exceptions, not a starting point for a strategy.
At this stage, most organizations that succeeding with cloud aren’t the ones with the most sophisticated multi-cloud architecture, they seem to be ones that picked a work mule and ride it.
