Multi-cloud is sold as the future of enterprise infrastructure. Use the best services from each cloud provider. Avoid vendor lock-in. Improve redundancy. Negotiate better pricing through competition.

The theory sounds great. The reality is that multi-cloud is expensive, operationally complex, and often creates problems it claims to solve. Most organizations pursuing multi-cloud would be better served by committing to one primary cloud with tactical use of others for specific purposes.

I’m not saying multi-cloud never makes sense. But the benefits are oversold and the costs are undersold, and most enterprises don’t have the operational maturity to make it work well.

How We Ended Up Multi-Cloud

Our multi-cloud situation wasn’t a deliberate strategy. It happened through acquisition and tactical decisions over several years.

We started on AWS because that’s where everyone started in 2015. Our core application infrastructure, databases, and most services run there. Then we acquired a company that was built on Azure. Migrating their infrastructure to AWS would have taken months and introduced significant risk, so we kept them on Azure.

Later, a data science team chose Google Cloud Platform for machine learning workloads because they preferred Google’s ML tools. Marketing wanted to use GCP for BigQuery. These decisions seemed reasonable in isolation.

Now we’re running production workloads across all three major cloud providers. We’re paying for connectivity between them. We need expertise in all three platforms. Our monitoring, security, and operational tooling needs to work everywhere. It’s complicated.

The Vendor Lock-in Myth

The main pitch for multi-cloud is avoiding vendor lock-in. Don’t get dependent on AWS. If they raise prices or have service issues, you can move to Azure or GCP.

This sounds compelling until you think through what “lock-in” actually means and what it would take to avoid it.

If you’re using cloud-native services like AWS Lambda, RDS, DynamoDB, or S3, you’re locked in regardless of whether you also use other clouds. Migrating these services to Azure or GCP equivalents requires rewriting code, changing infrastructure patterns, and testing everything again. The fact that you also run some workloads on Azure doesn’t change this.

To truly avoid lock-in, you need to use only services that are truly portable. Open-source databases instead of managed services. Kubernetes instead of cloud-specific container services. Object storage accessed through standard APIs. Portable application frameworks.

But this means giving up cloud-native services that are often better, cheaper, and easier to operate than portable alternatives. You’re accepting worse infrastructure to preserve theoretical portability that you’ll probably never use.

The companies I know that successfully use multi-cloud strategically aren’t doing it to avoid lock-in. They’re doing it because they have specific workloads that genuinely work better on different clouds. That’s different from multi-cloud as a lock-in avoidance strategy.

The Cost of Abstraction

To make multi-cloud work, you need abstraction layers. Infrastructure-as-code tools like Terraform or Pulumi that work across clouds. Service meshes and container orchestration that abstract away cloud differences. Custom tooling that provides consistent interfaces to different cloud services.

Building and maintaining these abstractions is expensive. You need engineers who understand all three clouds and the abstraction layers on top. You need to keep tooling updated as cloud providers change their services. You need to handle the edge cases where abstraction breaks down.

We built a deployment system that works across AWS, Azure, and GCP. It took two senior engineers about six months. Now it requires ongoing maintenance as cloud providers evolve their services. The value is questionable because 80% of our workloads run on AWS anyway.

The abstraction also limits you to the common denominator of what all clouds support. Cloud-specific innovations can’t be used because they don’t work in your abstraction layer. You’re giving up velocity and capability to maintain portability.

The Operational Complexity

Running one cloud well is hard. Running three clouds well is more than three times as hard because of the interactions and differences.

Your operations team needs expertise in AWS, Azure, and GCP. They need to understand how networking works in each. How IAM and security models differ. How monitoring and logging work. How billing and cost management operate.

Hiring for this is difficult. Engineers who are expert in one cloud are common. Engineers who are genuinely proficient in multiple clouds are rare and expensive. More commonly, you have engineers who are expert in one cloud and know enough about others to be dangerous.

Incident response becomes harder. When something breaks, you need to figure out which cloud it’s on, check status pages for all providers, understand provider-specific logging and monitoring, and apply provider-specific fixes. The cognitive overhead is significant.

The Data Transfer Costs

Moving data between clouds is expensive. AWS charges egress fees for data leaving their network. Azure and GCP have similar charges. If your architecture requires data to flow between clouds, these costs add up quickly.

We have a data pipeline that processes data in GCP and stores results in AWS. The data transfer costs are about $2K monthly. This is invisible until you look at itemized bills, but it’s real money spent on moving bits between networks.

The solution is to minimize cross-cloud data movement, but this limits architecture flexibility. If you can’t easily move data between clouds, you’re effectively building separate silos, which defeats much of the multi-cloud value proposition.

When Multi-Cloud Actually Makes Sense

There are legitimate reasons to use multiple clouds:

Acquisition situations where migrating acquired infrastructure would be expensive and risky. It’s often better to run two clouds temporarily (or permanently if the acquired infrastructure is relatively isolated).

Specific workload requirements where one cloud genuinely has superior services. Machine learning teams might prefer GCP for TensorFlow and specialized ML hardware. Media companies might prefer Azure for integration with Microsoft services.

Geographic coverage where one cloud has better presence in specific regions you need to operate in. China operations often require local cloud providers regardless of what you use elsewhere.

Customer requirements where you’re selling to enterprises that mandate their vendors use specific clouds for security or compliance reasons.

Risk diversification for extremely large companies where cloud provider outages would be catastrophic. Google, Amazon, and Microsoft are unlikely to all fail simultaneously. But this only matters at very large scale.

These are tactical uses of multiple clouds for specific purposes. That’s different from “multi-cloud strategy” where you try to run everything portably across multiple clouds.

What We’re Doing

We’re slowly consolidating toward AWS as our primary cloud. New workloads default to AWS unless there’s a specific reason to use something else. We’re migrating Azure workloads that aren’t tightly coupled to the acquired company’s infrastructure.

We’re keeping GCP for ML and data analytics workloads where the tools are genuinely better. But we’re not trying to maintain portability. Those workloads are GCP-native, using BigQuery and Vertex AI. If we ever need to migrate, we’ll rewrite them.

The goal isn’t to get to single-cloud because of purity. It’s to reduce operational complexity where it doesn’t provide corresponding value. Every additional cloud is overhead. That overhead needs to be justified by clear benefits.

The Hidden Agenda

Multi-cloud is heavily promoted by vendors who benefit from it. Kubernetes providers want you to run multi-cloud because that requires container orchestration platforms. Monitoring vendors want multi-cloud because you need unified observability tools. Consulting firms want multi-cloud because implementation complexity creates services revenue.

Cloud providers themselves have mixed incentives. They claim to support multi-cloud but their economic model depends on you running primarily on their platform. The deeper you integrate with cloud-native services, the more locked in you are and the more you spend with them.

The truth is that multi-cloud serves vendor interests more than customer interests in most cases. There are real use cases where it makes sense, but the aggressive promotion of multi-cloud as a default strategy is driven by vendor economics, not customer benefit.

The Pragmatic Approach

Choose a primary cloud provider based on your requirements, team expertise, and specific needs. Run most of your infrastructure there. Integrate deeply with their services. Get good at operating in that environment.

Use other clouds tactically when there’s clear justification. Specific services that are genuinely better elsewhere. Acquired infrastructure that’s expensive to migrate. Customer or compliance requirements. But treat these as exceptions, not a core strategy.

Avoid abstraction layers that try to make everything portable unless you have specific need for portability. The cost of abstraction usually exceeds the benefit unless you’re actually switching clouds regularly, which most organizations aren’t.

Focus on architecture patterns that are inherently portable: service-oriented architecture, containerization, infrastructure-as-code. These make migration possible if needed without requiring you to avoid cloud-native services in normal operations.

Multi-cloud sounds sophisticated and strategically smart. In practice, it’s usually complicated and expensive without commensurate benefits. Most organizations would be better served by focus and depth rather than breadth and abstraction. That’s the reality behind the marketing.