Cloud Vendor Lock-In Is a Feature, Not a Bug

There's a piece of received wisdom in enterprise architecture that gets repeated so often it's achieved the status of gospel: you must avoid vendor lock-in. Your infrastructure must be portable. Your services must run on any cloud. You must be free to switch providers at any time.

This advice has cost organisations I've worked with millions of pounds in engineering overhead, slower delivery, and architectures so abstracted they're a nightmare to operate.

I'm going to make the opposite case: committed cloud depth beats theoretical cloud portability, almost every time.

Corey Quinn, who writes Last Week in AWS and has spent years forensically analysing cloud spending patterns, put it bluntly: "Multi-cloud is a procurement strategy masquerading as an architecture strategy." Werner Vogels, Amazon's CTO, has made the same point from the other side: the organisations that extract the most value from cloud aren't the ones hedging across providers — they're the ones who go deep enough to use capabilities their competitors haven't even discovered yet.

---

What Multi-Cloud Actually Costs

Let's be specific about what "avoiding vendor lock-in" means in practice.

It means using the lowest-common-denominator services — the ones that exist on AWS, GCP, and Azure — rather than the best service for your workload. It means maintaining a thick abstraction layer between your application and cloud-native features. It means your Kubernetes cluster can't use EKS-native networking because you might someday move to GKE. It means your data platform avoids BigQuery because you might someday move to Snowflake.

The engineering cost of maintaining that abstraction is real and ongoing. Every time you want to adopt a new managed service, you first have to answer: "Can we use this without creating lock-in?" Most of the time the answer is no, so you don't use it, and you build something worse yourself.

You've paid a premium for optionality you almost certainly won't exercise.

---

The Portability Illusion

Here's the part that architects don't advertise: actual cloud migration is never painless, regardless of how portable your architecture is.

I've been through three major cloud migrations. In each case, the theoretical portability of the "multi-cloud-ready" architecture delivered far less than promised when we actually had to move workloads. Why?

Because portability isn't just about compute. It's about:

• Data gravity. Your 200TB data warehouse isn't moving without significant cost and downtime, regardless of what database abstraction layer you used.
• Networking topology. Your VPC peering, private link connections, and on-premise connectivity is cloud-specific.
• IAM and compliance. Your access policies, audit logs, and compliance attestations are deeply tied to the provider's tooling.
• Team knowledge. Your engineers know AWS. Migration means relearning everything — networking, IAM, monitoring, cost tooling — from scratch.

The idea that a well-designed multi-cloud architecture can be picked up and moved cleanly is a vendor-neutral consultant's fantasy.

---

What Commitment Actually Buys You

When you commit to a single cloud provider and go deep, you get:

Native services that are genuinely better. AWS Lambda and EventBridge together are a better serverless integration pattern than anything you'd build yourself. BigQuery's serverless scaling is remarkable. Azure's Active Directory integration is hard to replicate. These services exist because the provider has invested years and billions into solving specific problems. Use them.

Enterprise pricing leverage. When you consolidate spend with one provider and commit, you can negotiate. Real discounts — 30–40% on reserved instances, private pricing on compute, concessions on support tiers. Multi-cloud spend is fragmented spend, and fragmented spend has no negotiating power.

Operational simplicity. One provider means one observability stack, one IAM model, one support relationship, one team to train. The cognitive overhead of running services across two or three providers is enormous, and it scales badly.

Speed. When your team knows the platform deeply, they ship faster. New managed service? Your team already knows how to secure it, monitor it, and integrate it. Decision fatigue disappears.

---

The Counterargument: Catastrophic Provider Failure

The strongest argument for multi-cloud is existential risk: what if your provider goes down, goes out of business, or changes pricing catastrophically?

Provider outage: Major cloud providers have SLAs in the high nines. Multi-region architecture within a single provider handles most real-world availability requirements far more cost-effectively than multi-cloud.

Provider exit: AWS, GCP, and Azure aren't going out of business. This risk is theoretical. Planning your architecture around it is like buying earthquake insurance in Manchester — technically possible, practically pointless. Interestingly, the most radical "exit" in recent memory was DHH and 37signals leaving the cloud entirely for their own hardware. Even they didn't hedge with multi-cloud first — they made a committed call and executed it cleanly. That's the lesson: have conviction, pick a direction, go.

Pricing changes: Real risk, managed by contract — enterprise agreements with committed spend and fixed pricing. Not by architecture.

---

The Real Question

The multi-cloud orthodoxy exists because it's a defensible recommendation. If you tell a client to use managed services heavily and commit to a single provider, you're making a business call that requires context and conviction. If you tell them to build a portable architecture, you can always point to the optionality as a feature, regardless of outcome.

The defensible recommendation and the optimal recommendation are not the same thing.

Go deep on one cloud. Use its native services unapologetically. Negotiate hard. Optimise relentlessly. Build a team that knows it cold.

The companies I've seen win on cloud aren't the ones hedging. They're the ones committing.

Strongly disagree? I find this one generates the most pushback and the best conversations. Book a call or argue with me on LinkedIn.