GKE to EKS — what carries over, what you re-author, and how to cut over.

IWhat carries over unchanged — and why GKE→EKS is the clean one

A Kubernetes-to-Kubernetes move is the friendliest migration in the GCP→AWS catalog because the contract you build against — the Kubernetes API — is identical on both. It pays to be precise about exactly what transfers so you don't over-scope the project.

Your workload manifests are portable. Deployments, StatefulSets, DaemonSets, Services, ConfigMaps, Secrets (the objects), Jobs, CronJobs, HorizontalPodAutoscalers, PodDisruptionBudgets, NetworkPolicies, and RBAC all apply to an EKS cluster exactly as they applied to GKE — the Kubernetes object schema does not change between clouds, so a Deployment that ran on GKE 1.30 runs on EKS 1.30. Your Helm charts and Kustomize overlays are portable too: the packaging layer sits above the cluster, so what you change inside a chart is the small set of values that reference cloud-specific things — the StorageClass name, the ingress class and annotations, the image registry prefix, and the service-account-to-identity binding. Replica counts, resource requests/limits, probes, affinity rules, and template structure are untouched.

Your container images are portable in content but not in location. The image runs identically on EKS nodes; what changes is where it lives — images move from Google Container Registry (gcr.io) or Artifact Registry (*-docker.pkg.dev) to Amazon ECR, and every manifest reference repoints to the ECR URL. That's a registry migration plus a find-and-replace, not a rebuild. So the honest scope is keep the app, re-author the cluster boundary: the friction is entirely in the cloud-provider integration layer — the controllers, CSI drivers, and IAM glue that bind the cluster to GCP vs. AWS services. The sections that follow take the six boundary concepts in turn — identity, ingress, storage, registry, autoscaling, networking — explaining how GKE did each and exactly what you change. Scope it as "six integrations to swap," not "a Kubernetes rewrite," and the estimate stays honest.

IIIdentity: Workload Identity → IRSA (or EKS Pod Identity)

The single most important re-author — get it wrong and pods end up with no AWS permissions or over-broad ones. GKE's Workload Identity lets a Kubernetes service account act as a Google one; EKS does the equivalent with IAM, and there are now two ways to do it.

On GKE, Workload Identity binds a Kubernetes service account (KSA) to a Google service account (GSA), so a pod using that KSA gets the GSA's GCP permissions with no key files. EKS has a direct analog — two of them. The established option is IAM Roles for Service Accounts (IRSA): you associate an OIDC provider with the cluster, create an IAM role with a trust policy scoped to a specific service account (by namespace + name), and annotate that KSA with the role ARN (eks.amazonaws.com/role-arn). Pods then assume the role via the OIDC token and get short-lived STS credentials — exactly the keyless model Workload Identity gave you. The mapping is 1:1: GSA → IAM role; the WI binding → the IRSA trust policy; the KSA annotation → the role-ARN annotation.

The newer, simpler option — GA since late 2023 and the one most fresh clusters should prefer in 2026 — is EKS Pod Identity. Instead of per-cluster OIDC plumbing you install the Pod Identity Agent add-on and create a Pod Identity association mapping (cluster, namespace, service account) → IAM role, which makes roles reusable across clusters and simplifies the trust policy to a single principal. Prefer it unless a dependency needs IRSA; you can run both during the transition. Either way the work item is the same — for every KSA that had a Workload Identity binding, create one IAM role with a least-privilege policy and bind it. This is genuine work, not a find-and-replace, and where rushed migrations leave the biggest security gaps: re-derive permissions from what each workload actually calls rather than porting blindly, and delete any leftover JSON key files. Both IRSA and Pod Identity issue short-lived STS credentials, so the keyless posture carries over. Inventory the bindings first.

IIIIngress: GCLB Ingress controller → AWS Load Balancer Controller

On GKE an Ingress object provisions a Google Cloud Load Balancer via the built-in controller. EKS has no built-in cloud Ingress controller — you install the AWS Load Balancer Controller, which turns Ingress objects into ALBs and Service type LoadBalancer into NLBs.

The conceptual mapping is clean — Ingress still means "expose HTTP(S) through a managed L7 load balancer" — but the annotations are entirely different, and that's the part you rewrite. On GKE you used kubernetes.io/ingress.class: "gce", BackendConfig/FrontendConfig CRDs (health checks, CDN, IAP), and GCP-managed certs via ManagedCertificate. None of those carry over. On EKS you install the AWS Load Balancer Controller (a Helm chart that needs its own IAM role via IRSA/Pod Identity), and your Ingress uses ingressClassName: alb with annotations under alb.ingress.kubernetes.io/ — scheme (internet-facing vs internal), target-type (ip for VPC-CNI pod IPs is the common choice), certificate-arn for TLS, healthcheck-*, and group.name to share one ALB across Ingresses. For L4 traffic, a Service of type: LoadBalancer with the aws-load-balancer-type: "external" annotation provisions an NLB.

TLS and DNS change with it. GKE's ManagedCertificate becomes a certificate in AWS Certificate Manager (ACM) referenced by ARN; the DNS record that pointed at the GCLB now points at the ALB's DNS name in Route 53 (an alias record). Add ExternalDNS so Ingress hostnames auto-create Route 53 records — it makes the cutover a controlled DNS flip. Where GKE used Identity-Aware Proxy (IAP), the EKS equivalent is an OIDC authentication action on the ALB listener (Cognito or your IdP) — different mechanism, same intent. Validate the health-check path end to end before shifting any real traffic to the new endpoints.

IVStorage: Persistent Disk CSI → EBS CSI (and EFS for shared volumes)

Stateless workloads have no storage migration. Stateful ones do, and it's the part of a GKE→EKS move that needs the most care because block volumes are zonal and do not travel across clouds — you migrate the data, not the disk.

On GKE a PersistentVolumeClaim provisions a Compute Engine Persistent Disk via the PD CSI driver; on EKS the equivalent is the Amazon EBS CSI driver (a managed add-on) provisioning gp3 volumes by default. The PVC/PV/StorageClass objects are the same kind — what changes is the StorageClass provisioner (pd.csi.storage.gke.io → ebs.csi.aws.com) and its parameters. But the hard truth about block storage is that a Persistent Disk and an EBS volume are both zonal, cloud-specific resources — you cannot attach a GCP PD to an AWS node. So for any StatefulSet the migration is a data move, not a volume re-attach: migrate a database at the data layer (DMS or native replication/snapshot-restore) rather than copying the raw disk, and copy generic file data into a fresh EBS-backed PVC. Plan a sync-and-cutover per stateful workload, just like any database migration.

For shared, ReadWriteMany volumes — where GKE used Filestore — the EKS equivalent is Amazon EFS via the EFS CSI driver, with the data move a file copy (DataSync or rsync into the mount). Mind the access-mode difference up front: EBS is ReadWriteOnce (one node at a time), so a workload that genuinely needs RWX must land on EFS — discovering that at cutover is a classic late-stage surprise. Finish with the easy-to-forget housekeeping: set a default StorageClass (so PVCs without one don't fail), choose reclaimPolicy: Retain for anything you can't lose, and use volumeBindingMode: WaitForFirstConsumer so volumes provision in the same AZ as their pod — the AWS analog of GKE's zonal-disk scheduling.

VRegistry → ECR, autoscaling → Karpenter, networking → VPC CNI

The last three boundary concepts: where images live, how nodes scale, and how pods get IPs. The registry move touches every manifest, the autoscaling choice shapes node economics for the life of the cluster, and the networking model is the one that surprises GKE-native teams at scale.

VIMoving the images, manifests, and secrets — then the cutover

With the boundary concepts mapped, execution is mechanical and scriptable. Because Kubernetes workloads are mostly stateless and the data lives in databases and object storage, the cutover itself is primarily a traffic-shift problem.

Stand up EKS, migrate images, transform manifests, re-create secrets. Provision the cluster and install the integration layer up front — VPC CNI, CoreDNS, kube-proxy, EBS/EFS CSI, the AWS Load Balancer Controller, Karpenter, ExternalDNS, and the Pod Identity Agent — then set a default StorageClass and IngressClass. Copy images GCR/Artifact Registry → ECR with crane/skopeo (digest-preserving; multi-arch for Graviton). Transform manifests via the boundary swaps — ECR prefix, StorageClass provisioner, ALB Ingress annotations, identity annotations, dropping GKE-only CRDs — mostly a few Helm values and a base overlay. Re-create secrets in AWS Secrets Manager/SSM surfaced via the Secrets Store CSI Driver or External Secrets Operator, granting access through the pod's IAM role; never paste plaintext into manifests. Apply to a non-prod namespace first.

Run both clusters in parallel, shift traffic gradually, hold rollback open. Bring EKS to full readiness while GKE still serves 100%, keeping stateful backends synced (DMS CDC for databases, DataSync for object/file data). Then move traffic with weighted DNS in Route 53 — records for both the GCLB endpoint and the EKS ALB, weight shifted 5% → 25% → 50% → 100% with error rates and p99 latency watched at each stage. The principle is ramp, don't flip: because the switch is DNS weight, rollback is a weight change back to GKE, not a re-migration. Keep GKE warm and replication reversible through a soak; only after EKS holds 100% clean do you stop replication, drain GKE, and decommission — the last step, never a same-day one.

VIIThe GKE→EKS gotchas (each costs a week if you hit it blind)

Most of these are not Kubernetes problems — they're cloud-integration assumptions baked into a GKE-native team's muscle memory, the kind teams doing their first move tend to hit at least once. Knowing them in advance turns a week of debugging into a line on the checklist.

• VPC IP exhaustion — The VPC CNI gives pods real VPC IPs, so undersized subnets run out of addresses before compute. Size subnet CIDRs for the pod count, spread across AZs, and use prefix delegation to pack more pod IPs per node.
• No built-in cloud Ingress controller — Unlike GKE, EKS doesn't provision load balancers from Ingress out of the box — nothing happens until you install the AWS Load Balancer Controller (and it needs its own IAM role). Forgetting this leaves Ingresses with no address.
• EBS is ReadWriteOnce — A workload that quietly relied on RWX on GKE (Filestore) will fail to schedule multi-pod on EBS. RWX must go on EFS. Catch it in the storage inventory, not at cutover.
• Persistent Disks don't travel — You can't attach a GCP PD to an AWS node. Every stateful volume is a data move (DMS / replication / file copy into a fresh EBS/EFS PVC), not a re-attach. Budget per stateful workload.
• Graviton needs multi-arch images — Moving nodes to arm64 Graviton for the cost win silently breaks amd64-only images. Build multi-arch manifests during the registry move, or pin node architecture deliberately.
• Node IAM vs pod IAM confusion — Nodes pull from ECR via the node role; pods access AWS APIs via their own IRSA/Pod Identity role. Conflating the two is a common source of either pull failures or permission leaks. Keep them distinct.

VIIIHow CloudRoute makes the GKE→EKS move funded and done-for-you

Everything above is the honest engineering, and it's genuinely doable. The reason teams hand it off is the same reason they hand off a SOC 2 audit: it's a time-boxed, specialist project that pulls senior platform engineers off the roadmap for weeks. CloudRoute's job is to make it someone else's project — and to make AWS pay for most of it.

The mechanism is the AWS Migration Acceleration Program (MAP). On a qualifying migration — one with a meaningful AWS-spend commitment after you land — AWS funds the Assess phase (readiness + TCO, often free), credits a share of Mobilize (the EKS landing zone + add-ons + pilot), and credits a large share of Migrate & Modernize (the full workload move, the IAM re-author, and modernization like Karpenter + Graviton). The partner is paid through MAP, so you move from GKE to EKS at little-to-no cost. CloudRoute routes you to a vetted AWS partner matched to a Kubernetes-heavy stack who runs the whole execution — cluster + controllers, ECR migration, manifest transformation, Workload Identity → IRSA/Pod Identity, Karpenter + ALB controller, the stateful data moves, and the weighted cutover — with your team reviewing rather than executing. We don't run the migration and we don't charge you; the partner is paid via MAP, and CloudRoute is paid by the partner.

The honest framing: MAP funding applies to qualifying migrations only — typically those with a real post-migration AWS spend commitment. If yours doesn't qualify, CloudRoute is still useful as a vetted-partner referral that de-risks the cutover — a team that has done dozens of GKE→EKS moves instead of doing your first one in production. The funding ties into the broader AWS credits picture; see the credits cluster for how the pools fit together.