Cloud vendor lock-in: the tradeoffs that actually matter

When a company starts planning a cloud migration, vendor lock-in comes up early in the conversation. The concern is reasonable: once you build deeply on one provider's services, moving becomes expensive. But the discussion usually gets stuck in the abstract. People talk about portability in principle without asking what they would actually do differently if they had it.

I want to try to make the tradeoff more concrete.

What lock-in actually is

There are several distinct types, and they carry different costs:

• Infrastructure lock-in: your VMs, networking, and storage are on one provider. Moving is painful but possible, usually over months.
• Managed service lock-in: you use the provider's Kafka, managed Kubernetes, or serverless compute. Replacing these means re-architecting, not just re-pointing configuration.
• Data lock-in: your data is sitting in a proprietary store or warehouse format. Egress fees and transformation work make migration expensive.
• Operational lock-in: your team's skills and tooling are built around one provider's console, CLI, and APIs. The organisation becomes slow to move even if the technology could.

The first type is the one most people think about. The last two are the ones that usually hurt more.

The argument for accepting lock-in

Managed services save real engineering time. A managed database that handles backups, failover, and patching is not the same as a self-hosted database that you have to operate yourself. The time you save is not hypothetical - it shows up as fewer people needed to run the infrastructure layer.

When a company is below a certain size - say, fewer than 20 engineers - the abstraction a managed service provides often justifies the dependency. Building a multi-cloud abstraction layer costs more to build and maintain than the optionality is worth.

The argument for keeping distance

The companies I have seen regret deep lock-in share a pattern: they optimised for speed early, and then their circumstances changed. The acquisition target was on a different cloud. The enterprise customer's compliance requirements demanded data residency in a region the provider did not cover. The pricing for the service they had built on top of changed significantly.

The hard part is that these scenarios feel unlikely at the time you make the architectural decision. They are worth thinking about anyway.

A practical approach

I do not advise clients to go fully multi-cloud for its own sake. The operational complexity is real and expensive. But there are a few habits that preserve useful optionality without paying the full price:

• Separate your data storage layer from your compute layer. Data that can be read from multiple places is more portable than data embedded in a proprietary pipeline.
• Avoid proprietary formats for data at rest when open formats work just as well. Parquet instead of a vendor-specific columnar format, for instance.
• Build application logic against standard APIs where they exist rather than proprietary SDKs. This is not always possible, but it is often possible more than people assume.
• Track which services you depend on and whether alternatives exist. Not to be ready to move, but to know what movement would cost if you had to.

The question worth asking

The right question is not "are we locked in?" The right question is: "what would we lose if this provider raised prices by 40 percent, or discontinued this service, or had a six-hour outage during our peak period?" If the answer is uncomfortable, that is worth knowing before it is the urgent problem.