This question is testing whether you can turn "lock-in" — usually a vibes word — into a computable number. A strong answer reads the provider's pricing as a switching-cost schedule, separates the visible tariff from the invisible one, and ends with a measurement method.
The mental model: lock-in is a cost model, not a conspiracy. Providers engineer pricing where the cheapest way to use the service is to use more of it, and the most expensive operation is the one that takes data elsewhere. Egress is the visible tariff: S3 to the internet is $0.09/GB, same-region EC2 is free, cross-region is $0.02/GB. One hundred terabytes out of S3 is ~$9,200 before you pay for transfer machines or destination ingress — scale to a petabyte data lake and egress alone becomes a seven-figure line item. The structure is the message: ingress free, same-provider cheap, leaving metered at the premium tier.
The invisible lock is the control plane. You cannot migrate a workload by copying data; you reimplement the contract your application was written against — IAM policies and STS, KMS, SQS's at-least-once semantics with visibility timeouts that have no direct analog in RabbitMQ's ack model, DynamoDB's single-digit-millisecond consistency and GSI semantics that don't map 1:1 onto Postgres or Cassandra. That is data gravity: data and control plane accumulate in the same place, and every byte and every API call makes the next decision to stay cheaper than the decision to leave.
How to measure it. A migration is a project with a real budget, so price it like one: egress and transfer, engineering time for API rewrites, parallel-run infrastructure during cutover, retesting, and residual risk. The surprising property: egress is usually the smallest of the five — a 10 TB database is ~$1,000 in egress but months of engineering. So the metric that matters is exit cost per service in engineering effort, not bytes. The way to make it measurable is to price the exit before you enter: write the migration cost for any service before adopting it, and if the answer is "re-architecture," you have a strategic dependency — isolate it behind an interface of your own, a repository abstraction over DynamoDB costs a day to write and makes the exit a swap instead of a rewrite.
Tradeoffs. Portability is a spectrum: containers and Kubernetes manifests move, but the managed control planes — EKS vs. GKE vs. AKS — the IAM integration, and the CNI/CSI plugins stay behind. S3-compatibility is the de facto standard protocol: most object stores speak it, which is why R2's zero-egress pricing is the tariff removed from a protocol everyone already speaks. Multi-cloud is not the answer; it triples the control-plane surface and the egress bill. The one non-negotiable: run a full export test at your scale before storing anything irreplaceable — "the export API exists" and "the export API works at your scale" are different features, and a release requirement should be the only thing standing between them.