Cloud vendor lock-in: the cost that does not appear in the invoice
Dependency on a single cloud provider looks cheap on paper until the moment you need to renegotiate, migrate, or recover from an outage. What to account for before you are locked in.
I hear a version of the same question every few months from a CTO or IT director: "We are 100% on [provider], is that a problem?" The honest answer is: it depends, but the risk is almost always underestimated, and the cost only becomes visible when it is too late to act cheaply.
This is not an argument for hybrid cloud as a principle. Multi-cloud for its own sake creates more complexity than it solves. The question is whether you have made an active choice about your dependency, or whether it has just accumulated.
What lock-in actually consists of
Lock-in is not a single thing. It has several layers, and they compound.
The first layer is data egress. Moving data out of a cloud costs money, and the billing is structured to discourage it. If your data volumes are large and you ever need to migrate or run analytics on premises, this cost can be substantial.
The second layer is proprietary services. Managed databases, serverless functions, event buses, ML platforms - each one that you adopt deeply creates an abstraction only that provider offers. Rebuilding on equivalent services elsewhere takes months, not days.
The third layer is operational knowledge. Your team knows one provider's console, CLI, IAM model, and monitoring. That knowledge does not transfer. If you switch, you are effectively rebuilding operational capability from scratch.
The fourth layer is contract leverage. When renewal comes around, a provider who knows you cannot easily leave is not negotiating the same way as one who knows you have real alternatives.
Where the actual risk concentrates
Not all lock-in is equal. I find the highest-risk situations are:
- mission-critical data stored exclusively in a proprietary format or database engine;
- business logic wired directly to platform-specific event or messaging systems;
- monitoring and alerting that only works through the provider's own tooling;
- vendor contract with no SLA for data export speed on short notice.
These are the scenarios where a provider outage, a pricing change, or a failed renegotiation leaves you with no exit that does not cost more than staying.
The portability test
A useful exercise: walk through what a migration would look like for your three most critical workloads. Not "can we migrate" in theory - "what would we actually do in 90 days if we had to?" Write down the blockers. That list is a clearer picture of your real lock-in than any architecture diagram.
If nobody on your team can answer that question for a workload, that workload is locked in whether or not you intended it to be.
What reasonable mitigation looks like
Full portability is usually not worth the cost. But a few targeted decisions reduce risk significantly:
- Store critical data in open formats (Parquet, Avro, JSON) wherever possible, even if you query it through a proprietary engine.
- Prefer managed open-source databases (Postgres, MySQL, Redis) over proprietary equivalents unless the proprietary one solves a specific problem the open-source version cannot.
- Keep infrastructure-as-code portable enough that another provider could read it - even if you never run it there.
- Ensure your contracts include a clear data export commitment with defined timelines.
These decisions cost a little more to maintain but do not require a philosophical commitment to multi-cloud. They just keep options open.