Cloud providers are exceptional at making their managed services easy to adopt. The first week of using DynamoDB or Azure Service Bus or Google Spanner is smooth, well-documented, and impressively capable. The cost of that convenience becomes visible two years later when your architecture is so deeply entangled with one provider's ecosystem that a pricing change or an outage in a single region brings your entire business to a halt.
The categories of lock-in
Lock-in exists at multiple levels. Data lock-in means your data is stored in a proprietary format or location that's expensive to move. Service lock-in means your architecture depends on a managed service with no portable equivalent. Operational lock-in means your team's knowledge is specific to one provider's tooling. All three compound over time.
The trade-off that's worth making
Not all lock-in is bad. Using RDS PostgreSQL instead of managing your own PostgreSQL cluster is a sensible trade — PostgreSQL is a standard protocol and your data is portable. Using Aurora Serverless with its proprietary auto-scaling and connection pooling is a different calculation. The question to ask is: if I needed to move away from this service, what would it cost and how long would it take?
Designing for optionality
The antidote to lock-in is abstraction. Service interfaces, open data formats (Parquet, Iceberg, Delta), and container-based deployments give you the option to move without rewriting your business logic. Infrastructure as Code with Terraform means your architecture is portable by definition. These are not premature optimisations — they are engineering hygiene.