Cloud Vendor Lock-In: How to Evaluate the Risk Before You're Stuck

Cloud vendor lock-in is a real risk — but it's one of the most commonly misunderstood ones in early-stage companies. The fear tends to be general: “we're too dependent on AWS” or “what if Google Cloud changes their pricing?” Acting on that general fear leads to engineering teams spending significant resources building abstraction layers over standard cloud services, adding complexity and maintenance burden in exchange for portability they'll probably never need.

Meanwhile, the lock-in that actually creates business risk tends to be more specific and gets less attention: a proprietary ML platform where your trained models can't be exported, a vendor-specific analytics database whose data format doesn't support standard SQL export, or an email service provider that holds your entire contact list in a format you can't cleanly migrate. These are the dependencies where switching costs are genuinely high. Abstracting over your compute layer to be “cloud-agnostic” doesn't help if your data is trapped somewhere you can't get it out of cleanly.

The useful question isn't “how do we minimize cloud dependency?” — it's “which of our cloud dependencies would create significant business disruption if we needed to change them, and are we making those choices with our eyes open?” That framing leads to much better decisions than a general posture of cloud neutrality.

Not all vendor dependencies are equal. Compute is the easiest to migrate: a virtual machine running on AWS EC2 runs almost identically on GCP or Azure, and containerized workloads with Kubernetes are close to portable by design. CDN, DNS, and standard object storage (S3-compatible APIs are industry-standard at this point) are similarly low-risk. The switching cost is real but bounded — you're rewriting infrastructure configuration, not rewriting your application.

The dangerous dependencies are the ones where your data or your application logic is tightly coupled to proprietary behavior. Proprietary database query languages that differ significantly from standard SQL mean every query your application executes is a migration artifact if you switch. Vendor-specific ML inference platforms where the model format isn't portable mean you've bet your AI capabilities on a single provider's continued pricing and availability. Data warehouse products that don't support clean export mean switching requires rebuilding your analytics history from scratch. These aren't reasons to avoid these services entirely — they may be the best tools available — but they're reasons to evaluate the risk explicitly before adopting them.

The first audit is data: where is your data, in what format, and how hard would it be to extract it? Ask your engineering team to walk through every place persistent data is stored — databases, data warehouses, blob storage, analytics platforms, CRM, email service providers — and for each one, describe how you'd export a complete copy in a standard format. If the answer is “we'd run a SQL dump” or “we'd use the standard CSV export,” that's low lock-in risk. If the answer is “I'm not sure that's possible without going through support” or involves proprietary binary formats, that's where your exposure lives.

The second audit is API surface: how much of your application code calls vendor-specific APIs directly, and how central are those APIs to your product? There's a difference between using AWS SES to send email (the API is simple and migration to another provider is a day's work) and using SageMaker's proprietary inference endpoints with custom preprocessing pipelines (migration is a multi-month project). Identify the vendor-specific API calls in your codebase, count how many there are and how central they are to your product, and assess whether a migration would require a rewrite of core functionality or just a configuration change.

Between these two audits, you'll have a clear picture of your actual lock-in profile — not a general anxiety, but a specific list of dependencies ranked by switching cost. From there you can make deliberate choices: accept some lock-in because the service is genuinely the best option, mitigate others by choosing alternatives with better portability, and set architectural guidelines for future adoption decisions.

Very high lock-in risk: proprietary ML platforms where trained models can't be exported in a standard format (ONNX, HuggingFace, etc.); vendor-specific database engines that don't support standard SQL or have significant behavioral differences from open-source equivalents; data warehouse formats that require vendor tooling to read. These services may be worth adopting, but the decision should be made with explicit awareness of the switching cost and a considered view on how likely that cost is to matter.

Medium lock-in risk: managed services with open-source equivalents (RDS for PostgreSQL, ElastiCache for Redis) — the data is portable even if the operational config isn't; container orchestration platforms — Kubernetes is portable in principle, even if the managed flavors differ; monitoring and observability platforms — migrating dashboards and alert configurations is painful but feasible. Low lock-in risk: compute, standard object storage, CDN, DNS, and anything running on open protocols with documented export paths.

Before adopting any new cloud service, ask three questions: Can we export our data in a standard format? Does our application code call a proprietary API, or a standard one with a vendor implementation? If this vendor doubled their prices or discontinued the service, what would it cost us to switch? You don't need the answers to always be “low risk” — sometimes the service is worth the lock-in. You do need the answers to be known before you're committed.