You Chose Every Cloud. Now You're Drowning in All of Them.

Somewhere in a conference room, probably around 2019 or 2020, a VP of Engineering made a very reasonable-sounding argument. Something along the lines of: we can't be dependent on a single vendor. AWS has outages. Google could change pricing overnight. Azure has its own quirks. The smart move, the argument went, is to spread the risk across multiple providers.

That argument made total sense on a slide. It makes considerably less sense at 2am when your on-call engineer is debugging a Terraform drift issue that behaves differently across three separate provider modules, each with its own authentication model, networking primitives, and logging format.

This is the multi-cloud trap. And a surprising number of engineering teams are stuck inside it.

The Promise vs. The Paperwork

The pitch for multi-cloud has always been seductive: avoid lock-in, create competitive pressure between vendors, and build resilience by not putting all your eggs in one basket. On paper, it reads like a CTO's dream. In practice, it reads like a support ticket backlog.

The operational reality is that every cloud provider has its own mental model. AWS thinks in terms of IAM roles, VPCs, and availability zones. GCP has its own identity layer, its own networking concepts, its own way of handling service accounts. Azure adds Active Directory integrations that behave differently from everything else you've ever touched. These aren't just syntax differences — they're fundamentally different philosophies about how infrastructure should work.

When you commit to running production workloads across multiple clouds, you're not just doubling your infrastructure. You're multiplying your cognitive load. Your team now needs to maintain fluency in two or three different systems simultaneously. That context-switching has a real cost, and it shows up in slower incident response, higher onboarding time for new engineers, and a general sense that nobody fully owns anything.

The Hidden Tax Nobody Budgeted For

Here's what the multi-cloud pitch almost never includes in the business case: the tooling overhead.

You'll need observability that works across providers — and most of the best native monitoring tools are deeply tied to a single cloud. You'll end up paying for a third-party platform to unify your metrics and logs, which adds another vendor relationship and another monthly line item. Your CI/CD pipelines get more complex because deployment targets now have different authentication flows and different artifact registries. Your security posture doubles in surface area because you're managing IAM policies in multiple systems that don't talk to each other.

Then there's the networking cost that nobody mentions until the first big bill lands. Egress fees between clouds aren't trivial. If your architecture involves data moving between AWS and GCP with any regularity — and in a real multi-cloud setup, it will — those transfer costs compound fast. Teams that modeled their multi-cloud savings against hypothetical single-vendor price increases sometimes discover they've already exceeded those savings just in cross-cloud data transfer within the first year.

The Lock-In Fear Is Often Overblown

The core anxiety driving multi-cloud adoption is vendor lock-in — the fear that AWS or Google could raise prices dramatically, or worse, discontinue a service you've built around. It's a legitimate concern in theory. In practice, the major cloud providers have strong competitive incentives to keep enterprise customers happy, and the switching costs work both ways. They don't want to lose you either.

More importantly, the services most likely to create real lock-in — managed databases, serverless functions, proprietary ML platforms — are often the ones that provide the most value. Avoiding them to stay portable means building more yourself, which reintroduces the operational complexity you were trying to escape.

There's also a survivorship bias in how we talk about cloud risk. You hear about the AWS outage that took down a bunch of services. You don't hear as much about the companies that quietly built on a single cloud for a decade, moved fast, kept costs predictable, and never had a meaningful incident caused by their cloud provider.

When Multi-Cloud Actually Makes Sense

This isn't an argument that multi-cloud is always wrong. There are legitimate cases where it's the right call.

Regulatory requirements sometimes mandate geographic distribution across providers. M&A activity can leave you with inherited infrastructure on different clouds that's genuinely expensive to consolidate. Some workloads — particularly ML training — have cost profiles that genuinely favor one provider's spot instance market over another's, making a deliberate best-of-breed approach worth the overhead.

The key word there is deliberate. The teams that make multi-cloud work tend to be the ones who chose it for a specific, concrete reason — not as a hedge against a vague future risk. They've also typically invested heavily in platform engineering to abstract away provider differences, which is itself a significant investment that needs to be weighed against the supposed benefits.

If you're running a 15-person startup and your multi-cloud strategy exists primarily because someone read a Gartner report, that's a different situation.

The Operational Debt You're Already Carrying

Here's a useful exercise: ask your team how long it would take to fully onboard a new senior engineer onto your current infrastructure. If the answer involves weeks of documentation review across multiple cloud consoles, multiple CLI tools, and multiple networking models — that's a signal. Not necessarily that you should rip everything out tomorrow, but that the complexity you've accumulated has a real carrying cost.

Multi-cloud architectures tend to concentrate institutional knowledge in a small number of people who've been around long enough to understand the full picture. That's a retention risk and a bus-factor problem. When those people leave, the knowledge doesn't transfer cleanly because there's no clean mental model to transfer.

Single-cloud environments aren't immune to this, but they have a meaningful advantage: the cloud provider's own documentation, training programs, certifications, and community resources all apply consistently. Your team can build shared fluency faster.

Build for the Problem You Actually Have

The b8c.io take is pretty simple: infrastructure decisions should be driven by actual requirements, not hypothetical ones. The vendor lock-in risk is real, but it's often less acute than the operational complexity risk you're creating to avoid it.

If you're already deep in multi-cloud and feeling the weight of it, the answer probably isn't a big-bang consolidation — that's its own nightmare. But it might mean drawing clearer lines about which workloads live where, investing in internal platform tooling that creates consistent abstractions, and being honest with stakeholders about what the current setup actually costs to operate.

And if you're earlier in the decision, it's worth asking a harder question before you commit: are you choosing multi-cloud because it solves a specific problem you have today, or because it feels like the kind of decision a serious engineering organization makes?

Those are very different reasons. And they tend to lead to very different outcomes.