AKS to EKS — what carries over, what you re-wire, and who pays for it.

IWhat carries over verbatim — and why AKS→EKS is mostly an edges problem

People search "aks to eks" expecting a hard migration. The reassuring truth is that the Kubernetes layer is genuinely portable — both AKS and EKS run upstream, conformant Kubernetes, so the API objects your application depends on are identical. The migration is not a rewrite; it is a re-platforming of the cluster's cloud-specific edges around a workload definition that barely changes — and knowing which is which is the whole game.

Separate your repo into two buckets. The first is portable Kubernetes: Deployments, StatefulSets, DaemonSets, Jobs/CronJobs, Services, ConfigMaps, HPAs, PodDisruptionBudgets, NetworkPolicies, RBAC, and the bulk of your Helm charts and Kustomize bases. These reference images, ports, env vars, resource requests, and labels — none of it Azure-specific — so applied to EKS they create the same workloads. Expect ~80% of your YAML to fall here and move with no edits.

The second bucket is the cloud-coupled edges — the five places a manifest names an Azure construct or leans on an AKS add-on and therefore must change: the ServiceAccount annotations bound to Azure AD Workload Identity, the Ingress annotations driving AGIC, the StorageClass/PVC parameters provisioning Azure Disks/Files, the image references pointing at ACR, and the autoscaler that grows the node pool. This page is mostly about that second bucket, because that is where the genuine engineering — and the risk — lives.

Against the 7 Rs, an AKS→EKS move is a rehost/replatform of the platform itself: you are not refactoring the application (the containers are already built and orchestrated), you are re-homing the cluster onto AWS primitives. That is why it is fast relative to a heterogeneous database migration — the unit of work is well understood and the manifests are the same on both ends. The rest of this page is the detail, edge by edge.

IIIdentity: Azure AD Workload Identity → IRSA or EKS Pod Identity

This is the edge that most often blocks go-live, and the one teams leave too late. On AKS, Azure AD Workload Identity federates a ServiceAccount to a managed identity via an OIDC trust, and the pod exchanges a token for Azure credentials. On EKS the equivalent is the same OIDC pattern pointed at AWS instead.

EKS gives you two mechanisms. IRSA (IAM Roles for Service Accounts) is the mature one: the cluster has an OIDC provider, you annotate a ServiceAccount with eks.amazonaws.com/role-arn, and its pods assume the IAM role via the SDK's web-identity token flow — almost one-to-one with the Azure AD Workload Identity model. EKS Pod Identity is the newer mechanism: an EKS-managed agent plus a Pod Identity Association removes the per-cluster OIDC-provider and trust-policy boilerplate, so role association is a simple API call. For greenfield EKS in 2026, Pod Identity is the lower-friction default; for tooling/Helm that already expects the IRSA annotation, IRSA is the compatibility-safe choice — many estates use both during transition.

The work is bounded and tedious: for every workload that talked to Azure (Key Vault, Blob, a database via managed identity), inventory the permissions it actually used, author a least-privilege IAM policy, create the role, and either annotate the ServiceAccount (IRSA) or create a Pod Identity Association. The biggest mistake is recreating Azure's broad managed-identity grants as one wide IAM role — it passes a casual review and fails a real audit. The migration is the moment to tighten, not to port the over-grants forward.

This also re-homes node identity: EKS nodes run under a node IAM role, and the managed add-ons (VPC CNI, EBS CSI, etc.) each want their own IRSA/Pod-Identity role. Stand these up in the landing zone so the cluster is functional before any application pod lands.

IIIIngress: AGIC → AWS Load Balancer Controller

On AKS, north-south traffic typically arrives through the Application Gateway Ingress Controller (AGIC) — which programs an Azure Application Gateway from your Ingress resources — or through ingress-nginx behind a LoadBalancer Service. On EKS the like-for-like is the AWS Load Balancer Controller, which provisions ALBs for Ingress and NLBs for Service type LoadBalancer.

This is an annotation rewrite, not a redesign. Your Ingress objects keep their rules, paths, and backends; the controller-specific annotation namespace changes. AGIC annotations (appgw.ingress.kubernetes.io/*) become alb.ingress.kubernetes.io/* — listen ports, health-check paths, SSL policy, target-type (ip for VPC-CNI pod IPs vs. instance), and ingressClassName. TLS shifts from Application Gateway listener certs (often Key Vault-sourced) to ACM certificates referenced by ARN. If you ran ingress-nginx on AKS, the simplest path is to keep it on EKS fronted by an NLB — near-zero rewrite — and adopt the ALB controller later for native WAF/ALB features.

Validate two behaviors explicitly. Target type: with VPC-CNI giving every pod a routable IP, target-type: ip lets the ALB target pods directly (skipping the node-port hop) — usually what you want, but it ties target health to pod readiness, so get your readiness probes honest. Health checks and timeouts: Application Gateway and ALB have different default probe intervals, deregistration delays, and idle timeouts, so a service healthy on AGIC can flap on an ALB until you align the health-check path and grace periods. Re-test every external endpoint before shifting production traffic.

DNS is the lever that makes cutover safe (section VII): publish the ALB/NLB behind a Route 53 record and shift weight gradually rather than repointing everything at once. WAF/rate-limiting policies on Application Gateway map to AWS WAF web ACLs on the ALB — re-author the rules; they do not translate automatically.

IVStorage: Azure Disk / Files CSI → EBS / EFS CSI (and the data actually moves)

Stateless workloads carry zero storage baggage. The moment you have PersistentVolumeClaims, you have two distinct problems: re-pointing the StorageClass at an AWS CSI driver (easy) and physically moving the data inside the volume (the part that actually takes time, because a PV is cloud-specific and does not migrate by reapplying YAML).

The driver mapping is clean. Azure Disk CSI → Amazon EBS CSI for ReadWriteOnce block volumes (databases-in-cluster, write-ahead logs, single-writer state). Azure Files CSI → Amazon EFS CSI for ReadWriteMany shared file storage. You create new StorageClasses referencing ebs.csi.aws.com or efs.csi.aws.com, map the performance tier (Azure Premium SSD → EBS gp3/io2, setting IOPS/throughput explicitly on gp3), and update PVC storageClassName references. The EBS/EFS CSI drivers themselves want IRSA/Pod-Identity roles — another reason identity (section II) comes first.

The data is the work. A PersistentVolume bound to an Azure Disk is an Azure resource and cannot be reattached to EKS — you provision a fresh EBS/EFS-backed PVC and copy the bytes, choosing the method by data type. For in-cluster datastores (PostgreSQL, MySQL, MongoDB), use the application's own replication or dump/restore, not a block copy. For opaque file volumes, use a sync job (an rsync/rclone pod reading from the Azure side over the parallel-run link), Velero backup/restore (which also moves the Kubernetes objects), or AWS DataSync for large file sets landing in EFS.

Honest verdict: stateless-only clusters skip this section and migrate in days; stateful clusters spend most of their budget here, with each cutover a small maintenance window (quiesce writes, final sync/replicate, switch the app to the EKS volume, verify). Strongly consider externalizing in-cluster databases to managed RDS/Aurora/DocumentDB while you are touching the storage layer — the broader Azure→AWS estate migration usually does.

VRegistry and images: ACR → ECR, plus manifests and secrets

Your images live in Azure Container Registry; your pods pull from it. On EKS they pull from Amazon Elastic Container Registry. This edge is the most mechanical of the five — but the manifest and secret rewiring around it is where small mistakes cause crash-loops, so it is worth doing deliberately.

The registry. Create ECR repositories, then move the images. The brute-force path is docker pull/push, but for many repos and tags use crane or skopeo to copy image-to-image without a local docker daemon — faster and scriptable across all tags. For ongoing builds, repoint CI to push to ECR directly; for a transition window, ECR pull-through cache lazily mirrors upstream images. Turn on ECR image scanning while you are there — a free security win.

The manifests. Image references change from myregistry.azurecr.io/app:tag to <account>.dkr.ecr.<region>.amazonaws.com/app:tag. If your charts templatize the registry, this is a one-line values change per environment; if references are hard-coded across manifests, introduce that indirection now. Crucially, with node roles granting ECR pull permission you delete the imagePullSecrets AKS needed for ACR — EKS nodes authenticate to ECR via their IAM role, so the pull-secret is a stale credential to remove.

The secrets. On AKS these often come from Key Vault via the Secrets Store CSI driver. On EKS the equivalent is AWS Secrets Manager or SSM Parameter Store via the AWS provider for the same CSI driver, or synced into native Secrets by External Secrets Operator. Re-create each secret in Secrets Manager/SSM, point the SecretProviderClass at the AWS provider, and grant the workload's IRSA/Pod-Identity role read access to exactly those secrets. Never carry secret values across in a manifest or git diff — re-create them and let the CSI/operator inject them at runtime, as on Azure.

VIAutoscaling and networking: Cluster Autoscaler → Karpenter, and the VPC-CNI model

The last edge is how the cluster grows; the substrate underneath it is the network. AKS scales node pools with the Cluster Autoscaler — EKS can too, but the AWS-native answer in 2026 is Karpenter, a genuinely different and better model — and underneath, the AWS VPC CNI changes how pod networking and IP allocation work.

Autoscaling. The Cluster Autoscaler grows and shrinks predefined node pools. Karpenter instead provisions right-sized EC2 capacity on demand from pending-pod requirements: you define NodePools and EC2NodeClasses (instance families, capacity type, AZs, limits), and it picks instances that fit the unscheduled pods, consolidates underutilized nodes, and handles Spot natively. You translate node-pool definitions into Karpenter NodePools/EC2NodeClasses — a small amount of new authoring that pays off in better bin-packing and lower cost. You can run the Cluster Autoscaler first for a faithful lift, but most teams go straight to Karpenter because the cost win is the reason to be on EKS.

Networking — the CNI. Understand this substrate difference before sizing the cluster. The default AWS VPC CNI gives every pod a real VPC IP — pods are first-class on the network (great for ALB target-type: ip and security-group-per-pod), but pod density is bounded by ENI/IP limits per instance type, so you must size subnet CIDRs to avoid exhausting addresses. If your AKS cluster used Azure CNI Overlay or kubenet, the IP-planning math differs; budget VPC/subnet CIDRs for your real pod count (or use VPC-CNI prefix delegation to raise per-node density). NetworkPolicies are enforceable via the VPC CNI's network-policy support or Calico — re-test them, because enforcement engines differ at the edges.

Load balancing, DNS, observability. Service type LoadBalancer provisions an NLB via the AWS Load Balancer Controller. CoreDNS runs on both, so in-cluster discovery is unchanged; external DNS automation maps to ExternalDNS pointed at Route 53. Azure Monitor / Container Insights → CloudWatch Container Insights or a Prometheus/Grafana stack (Amazon Managed Prometheus + Managed Grafana), which most teams keep portable across the move.

VIIA parallel-cluster cutover that doesn't take the service down

A good AKS→EKS cutover never flips a switch. You stand up EKS alongside the live AKS cluster, run both in parallel, shift traffic gradually with weighted DNS, and keep a tested rollback for every wave. Here is the shape of a typical 4–10 week migration — faster than a full-estate move because the unit of work (a cluster of mostly-portable manifests) is well bounded.

The principle is run-in-parallel, shift-by-weight, roll-back-by-revert: because the manifests are portable, the EKS cluster can be made functionally identical and validated under real traffic before it owns 100% of it.

VIIIThe AKS→EKS gotchas nobody warns you about

These don't appear in the tidy service-mapping table but reliably cost a first-time team a day each. A partner who has done AKS→EKS before front-loads all of them; a first-timer discovers them one crash-loop at a time.

• Subnet IP exhaustion (VPC CNI) — Every pod takes a real VPC IP, so an undersized subnet CIDR caps pod count and fails scheduling with no obvious cause. Size CIDRs for real pod density up front, or enable VPC-CNI prefix delegation. No AKS-with-overlay equivalent — it surprises teams at scale.
• imagePullSecrets left behind — AKS needed an ACR pull secret; EKS nodes pull from ECR via their IAM role. A leftover imagePullSecret is a stale credential that masks broken node-role permissions — delete it and confirm node-role ECR access instead.
• Stateless NACLs and SG default-deny — AWS network ACLs are stateless (allow ephemeral return ports 1024–65535) and security groups deny inbound by default. A service that worked on Azure's more permissive model goes dark on EKS until the rule is added.
• PVs don't migrate — data is copied — A PV bound to an Azure Disk is an Azure resource; reapplying the PVC on EKS creates an empty EBS volume. Plan the data copy (app replication, Velero, DataSync) per stateful workload — the line item teams forget until cutover.
• Identity left to last blocks go-live — IRSA / Pod Identity and per-workload IAM roles must be ready before workloads move, or pods crash-loop on AccessDenied. The EBS/EFS CSI drivers and VPC CNI also need their own roles — stand them up in the pilot.
• Health-check and timeout drift on the LB — Application Gateway and ALB/NLB have different default probe intervals, deregistration delays, and idle timeouts. A service healthy on AGIC can flap behind an ALB until you align the health-check path and grace periods.

IXWho actually runs the migration — and why it's usually MAP-funded

You can run an AKS→EKS migration in-house, and because the manifests are portable a strong platform team can. Most still shouldn't carry the whole thing alone — the edges (IRSA mapping, the AGIC→ALB rewrite, the stateful-data copy) are where time and incidents hide. The better question is who runs it and who pays.

The mechanism that makes this nearly free is the AWS Migration Acceleration Program (MAP), which runs in three phases — Assess (readiness + TCO, often fully funded), Mobilize (the EKS landing zone + pilot cluster, funded), and Migrate & Modernize (the production cutover, where AWS credits a meaningful share of the cost). The partner is paid through MAP and AWS engagement funding, and credits scale with workload size. Honest framing: MAP applies to qualifying migrations — typically tied to a committed level of post-migration AWS spend, not a blank check — but for a real AKS estate moving to EKS, the assessment is commonly free and a large share of the migration cost is covered. The mechanics match the broader Migration Acceleration Program path and tie into the AWS credits and POC-funding programs.

This is where CloudRoute fits. We don't run migrations — we route you to a vetted, MAP-eligible AWS partner, matched to your stack (Kubernetes/EKS, your specific add-ons, any in-cluster databases), region, and timeline. You get someone who has done the Azure AD Workload Identity → IRSA translation and the AGIC → ALB rewrite before, the migration is largely MAP-funded, and CloudRoute is paid by the partner — so the routing costs you nothing. The migration persona page walks through how an engagement runs end to end. If the Kubernetes move is part of a wider Azure exit, start at Azure to AWS; if you're on GKE, see GKE to EKS.