What is vendor lock-in?
Vendor lock-in is the state where moving away from a cloud provider costs so much time, money or risk that you stay even when another option would suit you better. It builds up quietly, through APIs only one provider speaks, identity tied to its accounts and fees for taking your data with you.
Think of a phone contract with a handset you can only unlock after two years. Nothing stops you from leaving, but every month you stay, the exit gets a little more expensive. Cloud lock-in works the same way: each new dependency is small, and the sum is what you pay on the way out.
Lock-in is not always bad. A proprietary service can save months of work. The problem starts when you take it on without knowing the exit price.
Where does lock-in come from?
Most lock-in in a cloud setup comes from three places. Each one is a technical choice that is easy to make on day one and hard to undo later.
Proprietary APIs
A hosted queue, database or function runtime with its own API ties your code to that provider. Moving means rewriting the calls, and often the data model behind them. Open interfaces such as the Kubernetes API or the S3 API are implemented by many platforms, so code written against them moves with fewer changes.
Even on Kubernetes, some parts stay provider-specific. Load balancer settings live in annotations, storage classes have provider names and parameters, and the cloud controller that sets up load balancers and labels nodes talks to one provider’s API.
Identity and access
Workload identity is often the hardest part to move. Pods that get cloud credentials through a provider’s identity system depend on its role model, its token exchange and its policy language. On a new platform you rebuild those roles and permissions from scratch, and you test every path again.
Data and egress
Data is heavy. Moving terabytes takes time, and many providers charge per GB for traffic that leaves their network. A large bucket or database can make the exit bill alone a reason to stay, so egress pricing is part of lock-in even if your code is fully portable.
How do you keep lock-in low?
You cannot avoid every dependency, but you can choose them on purpose. A short checklist:
- Prefer open APIs (Kubernetes, the S3 API, standard SQL) for the core of the system.
- Keep provider-specific settings in one layer, such as Helm values or infrastructure as code.
- Write down which services you would have to replace, and what that would take.
- Check egress prices and data volumes before the data grows.
- Run a small exit test once, for example syncing one bucket elsewhere.
How enum handles vendor lock-in
enum runs upstream Kubernetes with no fork and no proprietary layer, and object storage speaks the S3 API, so manifests, Helm charts, GitOps pipelines and S3 tools carry over. What changes are load balancer annotations, storage classes and how pods get credentials. The migration team maps those parts with you and runs both platforms in parallel before cutover.
FAQ
Is every cloud-specific service lock-in? It creates some dependency, but the size varies. A service built on an open API or open-source software is cheaper to replace than one with a proprietary API and data format. Weigh the time saved against the exit cost.
Does Kubernetes remove lock-in? It removes a lot of it, because conformant clusters expose the same API. Load balancers, storage classes, identity and any proprietary services around the cluster still differ, so plan for those parts when you move.
How do I measure my lock-in? List every provider-specific service, API and identity binding, then estimate the work to replace each one. Add the egress cost for your data volume. The total is your exit price, and it should be a known number.