Managed services reduce operational burden. A managed database eliminates backup and replication management. Object storage eliminates disk capacity management. Serverless functions eliminate scaling management. The cloud provider handles the infrastructure, and the team focuses on business logic. The result is agility, scalability, and efficiency.

Then the first large bill arrives. The breakdown shows charges for data transfer between services, API requests, storage IOPS, provisioned capacity that is not being used. Estimating next month’s bill is impossible because the pricing model is too complex. Moving to a different provider is considered, but the application uses RDS-specific features, S3 event notifications, Lambda integrations. The abstraction that made the team agile has made them dependent.

This is the lock-in curve. When a managed service is first used, the cost is low. Payment is for what is used, and the convenience is worth it. But as the application grows, more features are used. Read replicas are added, auto-scaling is enabled, event-driven architectures are configured. Each feature adds dependency on the provider’s specific implementation. The abstraction becomes deeper. The cost increases not just because more resources are being used, but because more provider-specific features are being used.

Vendor lock-in is not a technical problem; it is an architectural problem. Lock-in does not happen because data cannot be migrated; data can always be exported from RDS or files can be downloaded from S3. Lock-in happens because application logic depends on provider-specific features. RDS’s automatic failover is used, S3’s event notifications, Lambda’s integrations with other AWS services. These features are convenient, but they tie the application to the provider’s ecosystem. Migrating to a different provider means rewriting the parts of the application that depend on these features.

The pricing model amplifies the lock-in. Cloud providers charge for data transfer between services, for API requests, for provisioned capacity. The pricing is complex and opaque. Costs cannot be easily compared between providers because the pricing models are different. Bills cannot be predicted because they depend on usage patterns that change over time. The complexity of pricing makes it difficult to evaluate alternatives, which reinforces lock-in.

The practical implication is that choosing managed services is a trade-off between short-term speed and long-term flexibility. Managed services allow faster building because infrastructure does not have to be managed. But they reduce flexibility because dependency on the provider’s specific implementation is created. The trade-off is not whether to use managed services; the trade-off is how much dependency is acceptable in exchange for how much speed.

This is why some teams choose to abstract the abstraction. Tools like Terraform are used to manage infrastructure as code, so providers can be switched by changing the provider configuration. Kubernetes is used to abstract compute, so the same workloads can run on any cloud. Standard protocols (S3-compatible storage, PostgreSQL-compatible databases) are used so providers can be switched without rewriting application code. The abstraction layer adds complexity, but it reduces lock-in.

The trade-off is that abstraction layers have their own costs. Kubernetes is complex to operate. Terraform requires expertise in multiple provider APIs. Standard protocols might not support all the features of managed services. Provider lock-in is being traded for abstraction complexity. The question is which complexity is preferred to manage.

Managed services trade infrastructure complexity for application complexity. If the abstraction removes operational burden without creating dependency, it is a good trade. If the abstraction creates dependency on provider-specific features, it is a trade-off that will cost later. The abstraction is not free; it just shifts the cost from today to the future.