How do you avoid cloud vendor lock-in?
Cloud vendor lock-in is the situation where moving workloads or data away from a cloud provider costs so much time or money that leaving becomes impractical. You avoid it by keeping the layers you would otherwise have to rebuild (compute platform, data services, identity and networking) on open interfaces, by knowing what it costs to move your data out, and by testing an exit plan before you need one. Kubernetes removes part of the lock-in, not all of it.
Types of lock-in
| Type | Example | Why it binds you |
|---|---|---|
| Data gravity and egress | Hundreds of terabytes in object storage | Moving data out takes time and incurs outbound transfer fees |
| Proprietary managed services | Provider-specific databases, queues and serverless functions | Applications are written against an API no other provider offers |
| Identity and networking | IAM roles, security groups, private endpoints | Access rules and network design have to be rewritten for another provider |
| Commercial commitments | Multi-year committed-spend discounts and reservations | Leaving early forfeits the discount or the prepaid amount |
| Software licensing | Licenses priced higher on rival clouds | Moving makes the same software more expensive |
| Skills and tooling | Scripts, modules and runbooks for one provider’s console and API | The team has to relearn and rebuild |
Regulators treat some of these as competition problems. The UK Competition and Markets Authority concluded its cloud market investigation on 31 July 2025, naming egress fees, technical barriers to interoperability and Microsoft’s software licensing as limits on switching and multi-cloud use.
Does Kubernetes prevent lock-in?
Kubernetes makes the workload layer portable. Every distribution certified under the CNCF Certified Kubernetes conformance program serves the same core APIs, so the same manifests run on any of them. It does not make the rest of a cloud account portable.
| Portable with Kubernetes | Not portable by default |
|---|---|
| Deployments, StatefulSets, Services, ConfigMaps | Managed databases and message queues |
| Horizontal Pod autoscaling | The provider’s IAM integration for workloads |
| Helm charts and operators | Load balancer annotations specific to one provider |
| Network policies and RBAC | Storage classes and CSI drivers |
| Container images in a standard registry | Provider add-ons for logging, monitoring and secrets |
A cluster that depends on a managed database, the provider’s identity system and five provider-specific annotations is only slightly more portable than one without Kubernetes. What a Kubernetes distribution is explains how distributions differ beyond the conformant core.
Practical controls
- Keep provider specifics out of application manifests. Put load balancer annotations, storage classes and node selectors in a per-environment overlay, so the application itself stays the same everywhere.
- Run data services on open-source engines. PostgreSQL, MySQL, Kafka or Redis-compatible stores run through Kubernetes operators or as managed services elsewhere, and their dump and restore formats work on any provider.
- Use the S3-compatible API for object storage. Most providers and storage products accept it, so moving data becomes a copy job instead of a code change.
- Describe infrastructure as code. Terraform or OpenTofu configurations with provider modules kept separate make rebuilding in another environment repeatable.
- Use standard identity federation. Workloads that authenticate with OIDC tokens instead of static provider keys can be pointed at another provider’s API. See how workloads access cloud APIs without static keys.
- Know your egress bill before you need it. Measure how much data you would have to move and what the provider charges for it. What cloud egress fees are explains the pricing.
- Write an exit plan and test it. Restore backups into another environment on a schedule. A restore that has never been tested is a hope, not a plan.
Running workloads in two environments at once, even if one is small, keeps every one of these controls in daily use instead of on paper.
What the EU Data Act changes
The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. Its Chapter VI gives customers of data processing services a right to switch providers or move to on-premises infrastructure, with a notice period of at most two months and a transition period of at most 30 calendar days, which the provider can extend only when the switch is technically unfeasible in that time. Providers may charge only reduced switching charges until 12 January 2027 and no switching charges after that date. The details are in what the EU Data Act changes for switching cloud providers.
The regulation lowers the cost of leaving. It does not rewrite applications built on proprietary services, so the technical controls above still matter. For a full migration path, see how to migrate to a European cloud and the guide to cloud sovereignty, data residency and portability.
Portability with Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) is CNCF-conformant upstream Kubernetes with one control plane for nodes in AWS, GCP, Hetzner Cloud, other clouds and your own data center. Moving a workload between providers changes its scheduling constraints, not its manifests. See what Cloudfleet is.