Vendor lock-in is a real cost, not an abstraction

Vendor lock-in tends to come up in architecture discussions as a theoretical concern. Engineers mention it, someone notes it as a risk, and then the team proceeds to use the most convenient tools available from the primary cloud provider. Five years later, the company discovers that moving to a different provider, or negotiating better terms with the current one, is far more expensive than anyone expected.

I am not arguing that lock-in should always be avoided. Sometimes the productivity gains from deep platform integration genuinely outweigh the switching costs. But those trade-offs should be made consciously, with a realistic estimate of what the dependency will cost to exit. That calculation is almost never done.

What lock-in actually accumulates to

Lock-in is not a single decision. It is the sum of hundreds of small decisions made over time, each of which individually seems trivial: we will use the managed database service instead of running our own; we will use the provider's message queue instead of an open-source one; we will write our deployment pipeline using the provider's own tooling.

Each of these is reasonable on its own. The managed database saves engineering time. The message queue is well-integrated and easy to use. The deployment tooling has good documentation.

The accumulation is what creates the problem. After three years of those decisions, the system is not just hosted on the cloud - it is built with the cloud platform as load-bearing structure. Migrating is not a matter of moving containers to different hardware. It requires replacing a dozen services that have no equivalent elsewhere, and that have years of operational history and tuning behind them.

The cost that is hardest to see

The most concrete form of lock-in cost is the inability to negotiate. A company that could genuinely run on a different provider has real leverage when renewing contracts. A company that cannot realistically migrate cannot credibly threaten to, and the commercial terms reflect that.

At large scale, cloud bills are negotiated, not posted. The ability to walk away - or the credible threat of it - is worth something measurable in those negotiations. A company that built everything on a single provider's proprietary services has traded that leverage away.

What portable and non-portable looks like

Not all cloud services carry equal lock-in risk. Compute and storage at the infrastructure level are relatively portable - containers can run on multiple providers, object storage has standard enough access patterns that migration tools exist. The higher lock-in risk sits in managed services that have no direct equivalent elsewhere: proprietary databases with features not available in open-source equivalents, serverless execution environments with provider-specific trigger models, ML platform integrations built around the provider's own APIs.

The architectural choice is not about avoiding all proprietary services. It is about knowing which services you are accepting lock-in for, explicitly, and whether the benefit justifies the accumulated exit cost.

A practical audit question

At any given point in time, a useful question is: if our cloud bill doubled tomorrow and we decided to evaluate alternatives seriously, what would it actually cost to migrate, in engineering time and in rebuilding functionality? If the answer is "a few months of work for a moderate team", the lock-in is manageable. If the answer is "we honestly cannot do it in under two years", the dependency has grown beyond what most managements explicitly decided to accept.

That question is much easier to answer when asked regularly, in small doses, than when asked for the first time during a commercial crisis.