Leaving EKS, AKS or GKE: a Kubernetes Cloud Exit in Phases

Have the cluster's dependencies assessed before you leave? The cloud exit assessment from €1,490 net classifies every service as transferable, replaceable or in need of rework and delivers target architecture, migration path with fallback path and a fixed-price proposal. One possible target is Kubernetes on Hetzner.

Kubernetes manifests that use only the Kubernetes API run on any conformant cluster. Leaving EKS, AKS or GKE is still more than moving manifests, because load balancers, ingress, volumes, identities, registry, logs and the network model depend on the cloud. This guide treats the three services as migration sources, separates the portable from the bound, describes six phases with parallel run and fallback path, and shows what the data transfer costs. Status October 2026.

Table of contents

• What is portable and what is not
• Provider-bound components in EKS, AKS and GKE
• The approach in six phases
• Moving data: volumes, databases, registry
• Cutover and fallback path
• Egress and data transfer when leaving
• Targets: where the cluster goes
• Deadlines, Data Act and UP KRITIS
• Checklist: taking inventory of dependencies
• Our approach at WZ-IT
• Status and methodology
• Further guides

What is portable and what is not

Portable is whatever uses only the Kubernetes API: Deployments, StatefulSets, ConfigMaps, ClusterIP Services, Helm charts and the GitOps repository. Bound is whatever the cluster obtains through the cloud integration. The cloud-controller-manager embeds the cloud-specific control logic, a Service of type LoadBalancer creates a load balancer at providers with external load balancers, a StorageClass names the volume plugin through provisioner, and ingress controllers are often configured through annotations whose meaning depends on the controller.

Provider-bound components in EKS, AKS and GKE

Sources, load balancer and ingress: AWS, Azure, GKE load balancers, GKE Ingress. Volumes: EBS, Azure Disks, Persistent Disk. Identity: EKS, AKS, GKE. Network and add-ons: VPC CNI, Azure CNI, EKS add-ons, AKS add-ons.

The approach in six phases

The source stays unchanged and runnable to the end. Each phase has a result and a condition for rolling it back.

Three rules apply to phase 2. The target has at least the Kubernetes version of the source, because Velero does not restore into a cluster with a lower version. Ingress moves to the Gateway API: ingress-nginx has not been maintained since March 2026, and for the NGINX add-on of AKS Microsoft provides critical security patches until November 2026. Certificates are issued before the cutover: cert-manager knows HTTP01 and DNS01, and HTTP01 needs a name that already points to the new cluster.

Moving data: volumes, databases, registry

Volumes. Velero does not migrate volume snapshots across cloud providers; for volume data between cloud platforms the documentation names File System Backup, which reads the files through the nodes, and the CSI Snapshot Data Mover. According to the documentation, File System Backup backs up only volumes that a pod has mounted, is listed as beta and takes long on large files such as databases because of deduplication. The development version of the documentation adds that a restore onto Azure Files (SMB) and blob FUSE mounts can lose file ownership without an error message. Here, file volumes go through File System Backup and databases through replication or dump. The backup storage is attached read-only in the target (--access-mode=ReadOnly, as recommended).

Databases. Logical replication first copies a snapshot of the tables and then streams the changes. Schema and DDL, sequences and large objects are not replicated (PostgreSQL 18 documentation): create the schema beforehand with pg_dump --schema-only and advance the sequences before the switch. PostgreSQL 19 (release candidate, status 28 October 2026) can synchronize sequences with ALTER SUBSCRIPTION ... REFRESH SEQUENCES. The managed services document logical replication: Amazon RDS, Cloud SQL, Azure Database for PostgreSQL. Where a maintenance window is acceptable, dump and restore suffice (RDS and Aurora guide).

Images and object storage. crane copy copies images into the target registry and retains the digest, so manifests with digest pinning run unchanged. For S3 see the rclone guide.

Cutover and fallback path

Beforehand, lower the DNS TTL, issue the certificates through DNS01 and fix the fallback condition in writing. On the day of the switch:

1. Stop write traffic or put the application into read mode.
2. Check that replication lag is zero, set the sequences, detach the subscription, make the target database writable.
3. Switch DNS to the target, read traffic first or gradually through weighted records.
4. Watch error rate and latency against the agreed threshold.

The fallback path is fixed before phase 5. The source stays unchanged and ready to start. For the reverse direction there are two options: a prepared replication from the target back into the source, or the decision that after the cutover only a restore from the backup leads back. The choice depends on how much data loss the application tolerates.

Egress and data transfer when leaving

The Data Act has applied since 12 September 2025. According to the European Commission, switching charges including egress charges are removed from 12 January 2027; until then providers may charge reduced switching charges up to the level of their costs (Article 29 of Regulation (EU) 2023/2854). The three hyperscalers have their own exit programs (status of the pages: 28 October 2026):

All three programs apply to the switch, not to permanent parallel operation, and require advance notice before the transfer. For ongoing exchange between clouds, Google names Data Transfer Essentials for European customers.

Without a credit the list price applies, for example on Azure 0.087 USD per GB for the next 10 TB after 100 GB per month (pricing page, North America and Europe, Premium Global Network, retrieved 28 October 2026): 9,900 GB × 0.087 USD = 861.30 USD for 10 TB. The transfer duration often limits the schedule more than the price:

Assumptions: 1 TB equals 8,000 Gbit, usable throughput 70 percent of the line rate.

Targets: where the cluster goes

Leaving a managed control plane makes etcd, upgrades and control plane security your responsibility; k3s, RKE2 or Talos helps choose the distribution. Migration pages by source: AWS, Azure, Google Cloud.

Operations by WZ-IT cost from €590 net per cluster per month including 3 worker nodes, each additional worker node €129.90. With hosting in Germany, the cluster base from €129.90 (HA control plane with 3 nodes, load balancer, IPv4, 100 GB storage, backup storage) and the worker nodes are added: S from €64.90 (4 vCPU, 8 GB), M from €119.90 (8 vCPU, 16 GB), L from €179.90 (bare metal, 8 cores, 64 GB).

Amounts net per month from operations, cluster base and worker nodes, status October 2026. Essential is included, Production provides a 60-minute response to P1 incidents (service levels). Monitoring runs 24/7, the response to P1 incidents follows the service level. Hosting can be terminated monthly, 30 days to the end of the month.

Deadlines, Data Act and UP KRITIS

Notice periods, commitments and support plans in the contract run independently of the technical schedule; the Data Act regulates switching charges from 12 January 2027 (see above). The UP KRITIS paper Empfehlungen zur Vorbereitung einer Exit-Strategie bei Nutzung von Cloud Dienstleistungen (in German; version 1.0, released 31 March 2022, published on bsi.bund.de) addresses operators of critical infrastructure. Its questions carry over to any cloud use:

• Guarantee that the data can be retrieved, document the retrieval process, specify data formats and target system, and where appropriate keep the target system available (section 2.1.1).
• Agree a minimum transition period in the contract (2.2.2).
• Define which data is needed in which form, which outage is acceptable and which switchover times apply, at night or during the day (2.3.1).
• Design the entry address of portals independently of the platform (2.3.4).

Checklist: taking inventory of dependencies

1. Version and CRDs: Kubernetes version, custom resources, their operators. Done when every CRD has an operator in the target.
2. Load balancers and ingress: Services of type LoadBalancer, ingress objects with provider annotations. Done when every annotation has a counterpart or is dropped.
3. Storage: StorageClasses, provisioners, sizes, access mode (ReadWriteMany for file services). Done when every volume has a copy path.
4. Identity and secrets: service accounts with a cloud binding, origin and rotation of secrets. Done when every application gets its credentials without the source store.
5. Data services outside the cluster: databases, queues, object storage. Done when the switch is tested per service.
6. Registry and images: registry hosts, pull secrets, signatures. Done when all images are reachable in the target.
7. Logs, metrics, alerts: agents, dashboards, alert routes. Done when alerts reach the same recipients.
8. Network: pod and service CIDR, peerings, VPN, fixed egress IPs, allowlists at third parties, DNS zones. Done when every allowlist is switched.
9. Managed add-ons: list per provider. Done when every add-on has a replacement.
10. Contracts: notice periods, commitments, marketplace contracts, support plans, exit program applied for. Done when all deadlines are scheduled.
11. Fallback path: condition, reverse direction, observation period in writing. Done when approved before the cutover.

Commands for items 2, 4, 6 and 9:

# Item 2: services and ingress with cloud annotations
kubectl get svc,ingress -A -o json | jq -r '.items[] | . as $o
  | ($o.metadata.annotations // {} | keys | map(select(test("aws|azure|gcp|cloud\\.google|gke\\.io|alb\\.ingress"))))
  | select(length > 0) | "\($o.kind)/\($o.metadata.namespace)/\($o.metadata.name): \(join(", "))"'

# Item 4: service accounts with a cloud binding
kubectl get sa -A -o json | jq -r '.items[]
  | select((.metadata.annotations // {}) | keys | any(test("eks\\.amazonaws\\.com|azure\\.workload\\.identity|iam\\.gke\\.io")))
  | "\(.metadata.namespace)/\(.metadata.name)"'

# Item 6: registry hosts of the running images (images without a host come from Docker Hub)
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}' \
  | awk -F/ 'NF > 1 && ($1 ~ /[.:]/ || $1 == "localhost") { print $1; next } { print "docker.io (implicit)" }' \
  | sort | uniq -c | sort -rn

# Item 9: managed add-ons and pod identity associations
aws eks list-addons --cluster-name <name>
aws eks list-pod-identity-associations --cluster-name <name>
az aks show -g <resource-group> -n <name> --query addonProfiles
gcloud container clusters describe <name> --location <location> --format="yaml(addonsConfig)"

The annotations come from the providers' documentation: eks.amazonaws.com/role-arn for IAM roles for service accounts, azure.workload.identity/client-id for Entra Workload ID and iam.gke.io/gcp-service-account for GKE identities with impersonation. The command for item 4 finds only annotated service accounts: EKS Pod Identity assigns roles through associations in the EKS API (see item 9), and GKE can grant service accounts access directly through IAM principal identifiers, without an annotation. CLI reference: AWS, AWS Pod Identity, Azure, Google Cloud.

Our approach at WZ-IT

The cloud exit assessment (from €1,490 net) starts with invoices, resource list and architecture documents. It classifies every service as directly transferable, replaceable by open source software or removable only with rework, sizes the target operation and delivers workload order, risks, fallback path and a fixed-price proposal. Read access, exports and a talk with IT suffice; the cloud environment stays unchanged.

Afterwards WZ-IT builds the target cluster, moves data and applications and secures tests, cutover and fallback path. Managed Kubernetes then operates it on Proxmox, bare metal, at a European provider or as hosting in Germany.

Status and methodology

Status: 28 October 2026. Programs, prices and deadlines of the providers were read on that day on the linked pages and change without notice; the page at the time of the application is binding. The table of bound components names typical services, not every variant. The transfer duration is a calculation with disclosed assumptions, not a measurement. The Azure list price is in USD without discounts. The UP KRITIS paper dates from 2022. WZ-IT prices are from-prices, net. A cost comparison with the source provider depends on the individual case.

Further guides

• Kubernetes backup: the four layers and Taking over a cluster: audit checklist
• Kubernetes on Hetzner and Kubernetes on Proxmox as targets
• OpenShift alternatives for OpenShift as a service at the hyperscalers
• Cloud exit strategy for SMEs, Leaving AWS and Egress costs compared

The cloud exit assessment from €1,490 net clarifies dependencies, target operation and fallback path. Managed Kubernetes describes operating a cluster on own or hosted infrastructure.