"You can check out any time you like, but you can never leave." — The Eagles
Vendor lock-in happens when the cost and effort of switching away from a product outweigh the benefits of switching. In the cloud, lock-in is not a binary on/off state — it exists on a spectrum, and different parts of your architecture can sit at different points on that spectrum simultaneously.
The Lock-in Spectrum
1. Low Lock-in — Infrastructure as a Service (IaaS)
Using basic compute VMs (like AWS EC2, Azure Virtual Machines, or GCP Compute Engine) and standard block storage. The underlying operating system is Linux or Windows — the same everywhere. Your application runs on a VM today; it can run on a different provider's VM tomorrow with moderate effort.
Switching Cost: Moderate. You need to re-provision infrastructure and potentially adjust networking and security group configurations, but the application itself doesn't change.
2. Medium Lock-in — Managed Open-Source Services
Using AWS RDS for PostgreSQL, Azure Database for MySQL, or GCP Cloud SQL. The database engine itself (PostgreSQL, MySQL) is open-source and runs anywhere. However, the management plane — automated backups, failover configuration, monitoring integrations, IAM-based authentication — is entirely proprietary to the cloud provider.
Switching Cost: High. You can export your data (PostgreSQL dump files are portable), but you must rebuild all the operational tooling around the database: backup schedules, alerting, connection pooling, and access control.
3. High Lock-in — Proprietary Platform as a Service (PaaS)
Using AWS DynamoDB, Google BigQuery, AWS Lambda, or Azure Cognitive Services. These services have unique APIs, query languages, and performance characteristics that exist nowhere else. Your application code is written against these specific APIs.
Switching Cost: Extreme. Moving off DynamoDB doesn't mean finding another key-value store — it means re-architecting your data model, rewriting all data access code, and migrating potentially terabytes of data to a completely different system.
Making the Lock-in Decision Deliberately
The mistake most teams make is not choosing high lock-in services — it's choosing them without acknowledging the trade-off. Using DynamoDB is a perfectly valid choice if you document: "We are accepting high lock-in here because DynamoDB's performance characteristics are critical to our use case, and we have no near-term plans to migrate." That is an engineering decision. Accidentally drifting into high lock-in because it was the default option is a liability.
Interviewers frequently ask: "How do you think about vendor lock-in?" A weak answer is "we avoid it." A strong answer is: "Lock-in is a spectrum, and the right level depends on the trade-off between development velocity and migration risk. We make explicit, documented decisions about where we accept lock-in and why — rather than treating all proprietary services as forbidden or all of them as free choices."