How to Avoid Cloud Vendor Lock-In (Without Building for Two Clouds)
Running everything on two clouds is a fantasy that doubles infrastructure cost and halves velocity. Treat lock-in as a gradient instead: Docker + Postgres + S3-compatible storage keep roughly 90% of a typical stack portable by default. Keep business logic out of proprietary glue, describe everything as code, and you get the thing that actually matters in a pricing negotiation: a credible exit.
We run client projects on AWS, Azure, GCP, and Hetzner — and not one of them runs on two clouds at the same time. That's deliberate.
Why "just run on two clouds" fails
True multi-cloud means duplicating networking, IAM, pipelines, and monitoring, while restricting yourself to the lowest common denominator of every service. In our experience that roughly doubles infrastructure spend and adds weeks to anything that touches infrastructure. The goal isn't symmetry across providers. The goal is being able to leave.
Which cloud services lock you in the most?
Lock-in isn't binary. Rank each service by what leaving would actually cost:
| Service category | Portability | Lock-in risk |
|---|---|---|
| Compute & containers | Docker runs anywhere | Low |
| Managed Postgres | Dump, restore, repoint | Low |
| S3-compatible object storage | Standard API across providers | Low — watch egress fees |
| Queues & messaging | Concepts port, APIs don't | Medium |
| Serverless functions | Code ports, triggers and glue don't | High |
| Proprietary AI & analytics suites | You rebuild, not migrate | Very high |
The pattern is consistent: the closer a service sits to an open standard, the cheaper the exit.
Three rules that keep the exit real
1. Build on a boring core. Docker for compute, Postgres for data, S3-compatible storage for files. That combination covers about 90% of a typical product stack and moves to any provider in days, not quarters.
2. Keep business logic out of proprietary glue. Cloud functions and workflow engines are fine as thin triggers that call your code. The moment pricing rules or domain logic live inside them, you've written your own migration blocker.
3. Describe everything as code. If your environment is a pile of console clicks, your exit is theoretical. If it's Terraform-style definitions plus container images, standing up on another provider is a project, not an odyssey.
When lock-in is a fine trade
Not all lock-in is a mistake. A managed database with tested failover, automated patching, and point-in-time recovery can genuinely replace a chunk of an ops hire — and at senior engineering rates of €95–€160/hour, that math often favors the managed service. Take those trades knowingly, at the edges of your system, never in the core.
That's how we operate across clouds for clients: portable core, deliberate lock-in at the margins. The leverage isn't that we migrate workloads all the time — we almost never do. It's that we could, in weeks, and every provider we negotiate with knows it.
Want an honest read on your exit cost? That's a standard part of our cloud & DevOps audits — or start with our take on the EU sovereign cloud stack.
Olio on LinkedIn
