Every cloud infrastructure decision carries some degree of lock-in. The question worth asking before signing is not whether lock-in exists, but how expensive it will be to leave, and whether that cost is proportionate to what you're getting.
Data egress is the cost nobody reads closely
Many providers price data transfer out of their platform meaningfully higher than data transfer in. That asymmetry is easy to miss in a pricing page built around inbound usage and storage, and it becomes very visible the moment a migration is actually underway. Ask directly what it costs, per gigabyte, to leave, not just to stay.
Proprietary tooling versus open standards
A provider's own orchestration layer, monitoring stack, or deployment tooling can make day-to-day operations smoother while quietly increasing the cost of migrating away, because your team's operational knowledge becomes specific to that one platform. That is not automatically a reason to avoid a provider. It is a reason to understand, upfront, how much of what you'll build is portable and how much is not.
Support SLAs that hold up under real incidents
Every provider publishes uptime guarantees. What matters more is what actually happens during a real incident: how fast a human responds, what remediation looks like, and what the provider is contractually obligated to do when the SLA is missed. Ask for the incident history for accounts at your scale, not just the published number.
Why this evaluation gets rushed
Infrastructure decisions often get made under real time pressure, with a technical team eager to start building and an executive focused on the launch date rather than the exit clause. That is precisely the condition under which lock-in terms get accepted without real scrutiny. A vendor evaluated properly before the contract is signed costs a few extra days. A vendor evaluated properly only after a bad experience costs a migration.