Cloud Vendor Lock-In: Real Risks and Practical Mitigations

Lock-in is a price, not a trap

Discussions of vendor lock-in usually collapse into two unhelpful positions. One says that every proprietary service is a cage. The other says lock-in does not exist because software can always be rewritten. Both dodge the actual question, which is a commercial one.

Lock-in is simply the cost of leaving. Every technology choice carries one, including open source running on your own hardware. A sensible team does not try to reduce that cost to zero; it makes sure the cost is known, proportionate to the benefit received, and not growing silently.

This article separates the kinds of lock-in, ranks the services that create the most of it, and distinguishes the mitigations worth paying for from the ones that are theatre.

Four distinct kinds

Data gravity

The most literal form. Large datasets are expensive and slow to move, and the closer other systems sit to that data, the more they resist relocation. Outbound transfer pricing is a direct tax on leaving, as set out in our article on egress costs.

Service coupling

Code written against a provider-specific interface. A function triggered by a proprietary event source, a query written for a provider's own SQL dialect, an identity flow tied to one vendor's tokens. The deeper the integration, the more of the application has to be rewritten rather than redeployed.

Operational coupling

The least visible and often the largest. Your monitoring dashboards, alerting rules, deployment pipelines, security baselines and the mental models of your engineers are all shaped around one platform. None of that transfers, and none of it appears in a migration estimate drawn up from an architecture diagram.

Commercial coupling

Multi-year commitments, discount agreements tied to spending levels, and marketplace purchases billed through the provider. These are contractual rather than technical, and they are the easiest to overlook when planning an exit date.

Ranking services by how much they bind you

The table is a guide to where to spend your abstraction effort, not a list of services to avoid. A high-binding service that saves a team six months of work is often the correct purchase.

Mitigations worth paying for

A short list of practices reduces the cost of leaving substantially while barely affecting day-to-day work.

• Keep the infrastructure in code. The provider blocks differ, but a reviewed, versioned definition of the estate is the difference between a rebuild and an excavation.
• Own your data export path. Verify that you can get a complete, readable copy of every data store, and time how long it takes, before you need to.
• Keep backups in a second vendor's storage. This doubles as disaster recovery and as proof that the data can actually leave.
• Prefer standard protocols at boundaries: SQL, S3-compatible object access, SMTP, OIDC, plain HTTP. Standard interfaces are where substitution happens.
• Write down the commercial commitments and their end dates in the same place as the architecture notes.

Most of these are good engineering regardless of vendor strategy, which is exactly why they are the ones to do. The related discussion of when a second provider is justified sits in multi-cloud strategy for small and medium businesses.

Mitigations that are mostly theatre

Some popular defences cost more than the risk they address. Building an abstraction layer over every cloud service is the classic example: you end up maintaining an internal framework that supports the intersection of two platforms, which is less capable than either and understood by nobody outside your team.

Refusing all managed services in favour of self-hosting everything is another. It replaces vendor dependence with dependence on a handful of your own engineers, which for a small company is a sharper risk.

Running identical production environments on two providers "for optionality" is the most expensive version. Unless something is genuinely serving traffic on both, the second environment drifts, and a stale standby is a false comfort.

Finally, choosing a weaker provider purely because it feels less binding is usually a mistake. You still pay migration costs if you leave, and in the meantime you have given up capability for a benefit you may never claim.

Writing an exit plan that is actually useful

An exit plan does not need to be a migration design. It needs to answer four questions well enough that a decision could be made under pressure.

1. What would we move, in what order, and what could stay where it is?
2. What is the rough transfer volume, and what would the egress charge be?
3. Which components are high-binding, and what would replace them?
4. What commercial commitments run past the date we would want to leave?

Two pages is enough. Review it annually, and whenever you adopt a new high-binding service. The practical mechanics of an actual move, once a decision is taken, are covered in moving between cloud providers without downtime and in moving data between cloud providers.

Frequently asked

See the AWS and Google Cloud comparison for that detail, and the AWS account listings for what an account on the largest platform covers. AWS documents its own portability guidance in the Well-Architected Framework.