The Multi-Cloud Trap and the Vendor Lock-In Myth
In this article
Someone in the boardroom says it every time. “We can’t be locked into one vendor.” Heads nod. The CTO writes “multi-cloud strategy” on the whiteboard. Just like that, the organisation commits to running workloads across two or three cloud providers because it feels like the safe, responsible thing to do.
We have seen this play out across multiple client engagements. The fear of vendor lock-in is real. The cure is almost always more expensive than the problem it claims to solve.
What Lock-In Actually Means
Lock-in is the cost of switching from one provider to another. That is it. Every technology decision creates some degree of lock-in. Your Oracle database locks you in. Your SAP implementation locks you in. Your choice of programming language locks you in. The question is never “does this create lock-in?” but “what is the switching cost, and is it worth paying to avoid it?”
When someone says “we don’t want to be locked into Azure,” they usually mean one of two things. Either they want the ability to move workloads to AWS or GCP if pricing changes unfavourably, or they want bargaining power during contract renewals. Both are valid concerns. Neither requires running production workloads on multiple clouds.
The bargaining power argument is the stronger one. If your entire estate is on Azure and Microsoft raises prices, your negotiating position is weak. But you don’t need to actually run workloads on AWS to have bargaining power. You need a credible exit plan: portable data formats, documented APIs, applications that aren’t welded to cloud-native services. That is a design discipline, not a multi-cloud deployment.
The Real Cost of Multi-Cloud
Let’s talk about what happens when an enterprise deliberately adopts multi-cloud as a strategy. We see the same pattern repeat.
First, the skills gap doubles. Your team needs to understand Azure networking and AWS networking. Azure IAM and AWS IAM. Azure Monitor and CloudWatch. These are not transferable skills. VNet peering does not work like VPC peering. Azure Policy and AWS Service Control Policies solve similar problems with completely different mechanics. The engineer who is excellent at designing Azure landing zones is not automatically competent in AWS Control Tower, and vice versa.
In our experience, a platform team that supports one cloud well typically needs 4 to 5 people. Supporting two clouds adequately often pushes that to 8 to 10. That is not double the headcount doing double the work. That is double the headcount maintaining two parallel systems that each do roughly the same thing.
Second, the tooling multiplies. You need IaC for both clouds. Terraform works across providers, but the modules, the state management, the testing, and the CI/CD pipelines are entirely separate. Your monitoring stack needs to ingest from both. Your security tooling needs to cover both (we wrote about Defender for Cloud’s multi-cloud capabilities when Microsoft launched that feature, and even with multi-cloud CSPM, you still need deep provider-specific security knowledge). Your cost management, your identity federation, your networking between clouds. Each of these is a project in itself.
Third, the networking bill surprises everyone. Cross-cloud data transfer is not free and is not fast. AWS charges for egress. Azure charges for egress. Moving data between them means paying both. In one client engagement, analytics running on AWS against data stored in Azure Blob Storage generated cross-cloud data transfer costs of roughly EUR 4,200/month. Moving the analytics workload to Azure eliminated that cost entirely and took two weeks.
Accidental Multi-Cloud vs Deliberate Multi-Cloud
Here is the distinction that the “multi-cloud is the future” crowd usually ignores: most enterprises that are multi-cloud didn’t choose to be.
They acquired a company that ran on AWS. Their main ERP is on Azure because it is a Microsoft shop. A data science team spun up GCP because BigQuery was the best tool for their use case. A SaaS vendor they depend on runs on a different cloud than their own workloads.
Accidental multi-cloud is fine. It is reality. You manage it pragmatically. Each workload lives where it makes the most sense, and you accept that your operations team needs to handle multiple environments.
Deliberate multi-cloud is different. That is the strategy where you intentionally deploy the same type of workloads across two clouds, design for portability between them, and build abstraction layers to make applications cloud-agnostic. This is the strategy that sounds smart in a board meeting and costs a fortune in practice.
Industry consensus has shifted over the past few years. Multi-cloud is acknowledged as an operational reality for most large enterprises. The deliberate “run everything on two clouds for portability” strategy, however, is increasingly seen as expensive and rarely justified.
The Cloud-Agnostic Abstraction Trap
“We’ll use Kubernetes everywhere so we’re portable.” We hear this at least once a quarter. It is the most expensive sentence in enterprise cloud architecture.
Yes, Kubernetes runs on every major cloud. AKS on Azure, EKS on AWS, GKE on GCP. The container runtime is compatible. The Kubernetes API is (mostly) the same. A production Kubernetes deployment, though, is never just Kubernetes.
Your application uses Azure Key Vault for secrets, Azure Service Bus for messaging, Azure SQL for persistence, and Azure AD for authentication. Or the AWS equivalents. The container is portable. Everything the container connects to is not.
Even if you avoid managed services and run everything inside the cluster (your own message broker, your own database, your own identity provider), you have just recreated an on-premises data centre inside a cloud VM. You are paying cloud prices for on-prem complexity. This is the worst of both worlds.
We wrote about the decision between Container Apps and AKS precisely because the right answer depends on how much Kubernetes complexity your team actually wants to own. Adding “and it needs to be portable to another cloud” to that decision makes everything harder and more expensive, for a capability that almost no one ever exercises.
When Multi-Cloud Actually Makes Sense
Multi-cloud is the right answer in a handful of specific situations.
Best-of-breed SaaS. If Snowflake on AWS gives you better performance for your data workload than anything on Azure, use it. If Google’s AI and ML tooling fits your data science team better than Azure Machine Learning, use it. Picking the best service for a specific job is not a multi-cloud strategy. It is pragmatism.
Mergers and acquisitions. You bought a company that runs on AWS. You run on Azure. Migrating everything to one cloud is a 12 to 18 month project with real risk. Running both for a while (or indefinitely for some workloads) is the rational choice.
Geographic or regulatory requirements. Some workloads need to run in a specific region where one cloud provider has presence and another does not. Some regulations require data to remain within a jurisdiction that one provider serves better than another.
Disaster recovery for the cloud itself. If your business requires continuity even in the event of an entire cloud provider outage (not a region outage, which single-cloud redundancy handles, but a full provider failure), then a warm standby on a second cloud is justified. Very few businesses actually need this. If you are running a stock exchange or a payments backbone, maybe. If you are running an ERP system, a region pair within the same cloud is sufficient.
What To Do Instead
Go deep on one cloud. Pick the provider that fits your organisation (existing skills, licensing agreements, workload types, partner relationships) and invest in mastering it. Build your landing zones, train your teams, adopt the managed services, and get good at operating in that environment.
Design for portability where it is cheap. Use standard protocols (REST APIs, SQL, AMQP) at your application boundaries. Store data in open formats (Parquet, Avro, JSON) rather than proprietary ones. Containerise your applications, not because Kubernetes makes you portable, but because containers give you deployment flexibility and a clean separation between application and infrastructure.
Use SaaS where best-of-breed matters. If a SaaS product on another cloud is the best tool for a specific job, use it. Connect it via APIs. This is not multi-cloud. This is using the internet.
Keep a credible exit plan. Document what a migration to another cloud would require. Estimate the cost and timeline. Update it annually. This document gives your procurement team bargaining power during contract renewals without the operational overhead of actually running a second cloud.
Invest the money you save. The cost difference between a well-run single-cloud environment and a multi-cloud deployment is significant. Based on what we’ve seen in mid-size enterprises, the additional platform team costs, tooling, and operational overhead can range from EUR 500K to EUR 1.5M per year. Put that budget into making your primary cloud environment more secure, more automated, and more efficient. You will get more value per euro spent.
The Uncomfortable Truth
The multi-cloud decision is rarely about technology. It is about organisational fear. Fear of being dependent. Fear of making a bet that turns out wrong. Fear of the vendor having too much power.
Those fears are understandable. But the answer to “what if our cloud provider raises prices?” is not “let’s pay double right now to run two clouds.” The answer is to build well-architected applications with clean interfaces, maintain a realistic exit plan, and negotiate hard during renewals.
Multi-cloud by accident is normal. Manage it pragmatically. Deliberate active-active portability across clouds, though, is rarely worth the cost unless there is a very specific driver (regulatory, geographic, or genuine provider-level DR). The complexity it creates is real. The portability it promises is theoretical. The cost is paid every month, whether you ever switch providers or not.
One caveat: exit plans are not free either. Maintaining portable data formats, clean API interfaces, documented dependencies, and periodic migration feasibility reviews takes real effort. Single-cloud is simpler, but it still requires governance discipline.
What This Means for Azure-First Enterprises
If Azure is your primary cloud, the investment that pays off is going deep: well-architected landing zones, enforced policy guardrails, standardised identity and networking, and managed services where they create real advantage. Keep data formats and APIs portable where the cost of doing so is low (open formats, standard protocols, container packaging). Accept that some SaaS workloads will live on other clouds, and connect them via APIs rather than building abstraction layers.
Portability is a design discipline, not a reason to duplicate your operating model across clouds.
Looking for Azure architecture guidance?
We design and build Azure foundations that scale - landing zones, networking, identity, and governance tailored to your organisation.
