Avoiding vendor lock-in: how to build cloud applications you can actually move
You don’t avoid vendor lock-in with a single tool – you avoid it through architecture decisions: containers and Kubernetes instead of proprietary compute services, S3-compatible object storage, PostgreSQL instead of vendor-bound databases, and Infrastructure as Code with Terraform or OpenTofu. The EU Data Act eases the situation legally – since September 12, 2025, switching charges for changing providers may only cover actual costs, and from January 12, 2027 they are banned entirely. But the ban only applies to the switch itself, not to ongoing operational egress. That bill is still written by your architecture. If you’re building or migrating today, treat portability as a design goal, not an emergency plan.
TL;DR
- The two biggest lock-in drivers are proprietary managed services and egress fees: 1 TB of internet egress costs around 90 USD at AWS (~$0.09/GB for the first 10 TB/month), while Hetzner includes 20 TB with its cloud servers – a factor of ~90.
- EU Data Act: since September 12, 2025, switching charges are capped at cost-covering levels; from January 12, 2027 they are banned entirely. But this only applies to exit fees, not to ongoing operational egress.
- Technical levers: containers/Kubernetes, S3-compatible object storage, PostgreSQL and open standards, Terraform/OpenTofu for reproducible environments.
- Abstract with care: Crossplane and multi-cloud frameworks only pay off when you genuinely need multi-cloud.
- Cost context: according to Flexera 2026 (753 respondents), 29% of cloud spend is considered wasted, and fewer than half of companies use commitment discounts.
- EU alternatives are real: Hetzner delivers ~14.3x compute value per euro compared to AWS, Scaleway ~4.8x, IONOS includes 2 TB of free egress per month.
What is vendor lock-in – and where does it actually come from?
Vendor lock-in means switching to another provider is so expensive – technically or financially – that in practice it never happens. In the cloud, this rarely comes from bad intent. It almost always comes from two mechanisms.
First: proprietary managed services. If you build your application directly against a hyperscaler’s vendor-specific APIs – compute, database, queues, auth – you’re writing code that only runs there. Each of these services is convenient on its own. Taken together, they produce an application that can’t run anywhere else without re-engineering.
Second: egress fees. Getting data into the cloud is cheap; getting it out is expensive. At AWS, internet egress costs around $0.09/GB for the first 10 TB per month – so 1 TB of egress runs you about 90 USD. At Hetzner, 20 TB is simply included with cloud servers. That’s a factor of roughly 90. The more data you accumulate, the more expensive every path out becomes – whether to a new provider, to your customers, or to an external system. This “data gravity” is the quietest but most effective lock-in mechanism of all.
What does the EU Data Act change – and what doesn’t it?
The EU Data Act has applied since September 12, 2025 and tackles exactly this problem – though only partially. Specifically:
- Until January 12, 2027, switching charges for changing providers may only be cost-covering. The provider is no longer allowed to make a profit on your exit.
- From January 12, 2027, switching charges are banned entirely. Exporting your data when changing providers can no longer be billed at all.
That’s real relief – but with one important caveat: the ban covers only switching and exit fees, not ongoing operational egress. If you deliver data to users, partners, or other systems during normal operations, you keep paying your provider’s regular egress rates. The Data Act makes moving out cheaper – not the rent.
The sober takeaway: the legal framework helps you at exit time, but architecture remains the bigger lever – it determines whether a switch is technically realistic at all and what day-to-day operations cost. And as with any young regulation, many questions of interpretation will only be settled in practice. This article is a technical assessment, not legal advice.
Which technical levers keep you portable?
Portability isn’t all-or-nothing. It’s about choosing open standards in the right places so that the core of your application stays movable.
| Building block | Lock-in variant | Portable alternative |
|---|---|---|
| Compute | proprietary compute/serverless services | Containers + Kubernetes |
| Object storage | vendor-specific storage APIs | S3-compatible object storage |
| Database | proprietary database services | PostgreSQL |
| Identity/login | proprietary auth services | OpenID Connect |
| Provisioning | click-ops setups in the console | Terraform/OpenTofu |
Containers and Kubernetes instead of proprietary compute services. Whatever runs as a container fundamentally runs at any provider offering Kubernetes – and today that’s practically all of them. One honest caveat: Kubernetes solves the portability problem, not the cost problem. According to Cast AI, average CPU utilization in Kubernetes clusters in 2026 sits at just 8%. If you adopt K8s, plan rightsizing from day one – otherwise you’re trading lock-in costs for overprovisioning costs.
S3-compatible object storage. The S3 API is the de facto standard for object storage and is supported by almost all EU providers. If you write your code against the S3 API rather than vendor-specific extensions, you can switch storage providers without touching the application.
Open standards for database and identity. PostgreSQL instead of a proprietary database service means: dump, restore, done – at any provider. OpenID Connect instead of a vendor-bound auth service means: the login flow works the same everywhere.
Infrastructure as Code with Terraform or OpenTofu. When your entire environment is described as code, it’s reproducible – at your current provider (disaster recovery, staging) and as the foundation for a move. Infrastructure that exists only as a collection of console clicks can never be reliably rebuilt anywhere else.
When is abstraction worth it – and when is it overkill?
We have to be honest here, because this is where teams often overshoot: not every abstraction layer pays off. Every additional layer – whether a multi-cloud framework like Crossplane or a home-grown adapter level over every cloud API – costs development time, complexity, and often functionality, because you limit yourself to the lowest common denominator.
Our rule of thumb: Crossplane and multi-cloud frameworks only when you genuinely need multi-cloud. If you actually have to run at multiple providers in parallel, the math can work out. For most mid-market companies, though, the goal isn’t “runs everywhere simultaneously” but “can move with reasonable effort.” For that, the standards from the previous section – containers, S3 API, PostgreSQL, OIDC, IaC – are entirely sufficient, with no extra platform to maintain.
What does lock-in cost – and what do the alternatives cost?
Lock-in isn’t just a risk for the day you switch; it’s an ongoing cost factor: if you can’t leave, you have no negotiating position. Context from the Flexera 2026 study (753 respondents): 29% of cloud spend is considered wasted, and fewer than half of companies use commitment discounts. Many are paying premium prices without capturing what they’re paying for.
Meanwhile, the European alternatives are remarkable on price – a few verified data points (as of June 2026; ”–” = no verified figure available):
| Provider | Internet egress | Compute price-performance vs. AWS |
|---|---|---|
| AWS | ~$0.09/GB (first 10 TB/month); 1 TB ≈ 90 USD | reference |
| Hetzner | 20 TB included with cloud servers | ~14.3x value per euro (Callista benchmark, Feb 2026) |
| Scaleway | – | ~4.8x price-performance |
| IONOS | first 2 TB/month free | – |
Honesty also requires noting: Hetzner raised prices by 30–37% on April 1, 2026 (DRAM crisis) – the CX23 with 2 vCPU/4 GB went from EUR 2.99 to EUR 3.99/month. Even after that increase, compute value per euro according to the Callista benchmark is still around 14.3 times that of AWS. The point isn’t “hyperscalers are evil” – they offer services you can’t get anywhere else. The point is: only if you build for portability can you actually exploit these price differences, workload by workload.
What does a pragmatic approach look like?
Portability doesn’t have to be a megaproject. A realistic roadmap:
- Take inventory. Which proprietary services do you use today, and which of them are wired deep into your code? That’s your lock-in map.
- Assess exit costs per workload. Not every application needs to be portable. An internal tool with a handful of users can stay locked in; the core system holding your data probably shouldn’t.
- Build new projects portable by default. Containers, S3 API, PostgreSQL, OpenID Connect – on a greenfield build, this adds barely any overhead, but it saves re-engineering later.
- Introduce Infrastructure as Code. Terraform or OpenTofu for everything new, with gradual back-documentation of what already exists.
- Plan for rightsizing. Especially with Kubernetes: at an average of 8% CPU utilization across clusters, overprovisioning is the silent cost driver.
At Rocket-Monkeys, this is exactly how we build cloud applications: open standards at the core, proprietary services only where they deliver clear, deliberate value – and always with a documented exit path. For how this topic fits into the bigger picture of the Data Act, EU providers, and digital sovereignty, see our overview page on cloud sovereignty.
Want to talk it through – no strings attached?
If you want to know how tightly your current architecture is bound and what a realistic path to more portability would cost, let’s look at it together. In a free initial consultation, we walk through your workloads, identify the biggest lock-in points, and assess where portability genuinely pays off for you – and where it doesn’t. Just drop us a line at info@rocket-monkeys.com.