EKS to AKS: How to Migrate Kubernetes Workloads When You Move to Azure for Better Enterprise Pricing

Key Points:

• An EKS to AKS move is a platform migration, not a Kubernetes migration. Deployments, Services, ConfigMaps and Helm charts move unchanged. IAM Roles for Service Accounts, EBS/EFS storage classes, AWS Load Balancer Controller annotations, Route 53 records, ECR pull credentials and Secrets Manager wiring all have to be rebuilt against Azure equivalents. Budget roughly 80% of the effort for that glue layer.
• The only structural cost difference between the two managed services is the control plane. EKS charges about $0.10 per cluster-hour, roughly $73/month per cluster. The AKS Free tier charges nothing for the control plane but carries no financially backed SLA. Nodes, disks, load balancers and egress are priced per resource on both clouds, so a single 200-node cluster sees almost no structural saving.
• Enterprise Azure savings come from commitments and licensing, not from AKS. An Enterprise Agreement or Microsoft Customer Agreement, Azure Reserved VM Instances, the Azure savings plan for compute, and Azure Hybrid Benefit for Windows Server and SQL Server are where the discount lives. Validate that quote against your remaining AWS Savings Plans first, because stranded commitments routinely erase year-one savings.
• The lowest-risk sequence is eight steps: inventory and dependency map, Azure landing zone, replatform manifests, move images, replicate data, parallel run behind weighted DNS, traffic shift, then decommission EKS after 2 to 4 weeks warm.
• Stateful workloads set the timeline. Stateless services cut over in hours. Databases need logical replication or a dual-write window plus a tested rollback. Plan 6 to 14 weeks end to end for a mid-size estate, and expect the dual-infrastructure overlap to cost more than the engineering time.
• Qovery provisions and operates AKS inside your own Azure subscription (and EKS in your AWS account, GKE in GCP, Scaleway, or your existing Kubernetes cluster), so one application definition runs on both clouds during the cutover and the Azure invoice plus your commitment discount stay in your name. Qovery does not migrate your data or convert RDS to Azure Database for you.

The Kubernetes part of an EKS to AKS migration is the easy part. Your Deployments, Services and Helm charts move almost untouched. What eats the quarter is everything around them: IRSA, load balancer annotations, EBS storage classes, the image registry, and the CI pipeline that has to learn a second cloud.

I have spent years operating Kubernetes clusters across AWS, GCP, Azure and Scaleway at Qovery, and I have talked to more than 200 CTOs about why they move. The pattern for an Azure move is almost always the same. Finance or procurement negotiates an Azure Enterprise Agreement that beats current AWS spend, and then the platform team gets handed the job of moving production without breaking it. This is the runbook for that job. It is written for 2026 pricing, and every price here was last checked in October 2026.

Is AKS actually cheaper than EKS, or does the saving come from your Azure enterprise agreement?

AKS is not intrinsically cheaper than EKS. The only structural difference between the two managed services is the control plane: EKS bills about $0.10 per cluster-hour (roughly $73/month) under standard support, while the AKS Free tier bills nothing for the control plane and carries no financially backed SLA. Every meaningful enterprise saving comes from commitments, licensing and a negotiated EA or MCA, not from the Kubernetes service itself.

Do the arithmetic out loud and the point lands. The control plane delta is a fixed fee per cluster. For a fleet of 40 small clusters that is roughly $2,900 a month of pure control plane that AKS Free can zero out. For one 200-node cluster, $73 a month is a rounding error against the node bill. On AWS, running an old Kubernetes version past standard support adds an extended support surcharge of about $0.50 per cluster-hour (so $0.60/hour total), which is a real reason to keep clusters current on either cloud.

Nodes are the bill on both clouds, and they are priced per resource either way. Compare equivalent families (AWS m7i/c7i against Azure Dsv5/Fsv2) at your real node shapes and your real region, using the EC2 on-demand pricing and the Azure Linux VM pricing pages, not the list price of a single VM in us-east-1. The enterprise discount is applied on top of those node prices through commitments.

Here is where the Azure savings actually come from, and it is worth naming each instrument so your finance team models the right one:

Two things routinely wipe out year-one savings. The first is stranded AWS commitments: unused Savings Plans and Reserved Instances keep billing until term end regardless of usage, so if you move off AWS while a one-year Savings Plan still has eight months to run, you pay for both clouds. Model that overlap explicitly. The second is the dual-run period itself, which I cover at the end.

The one-time migration cost is smaller than people fear. AWS waives data transfer out charges when you are leaving AWS, on request to AWS Support, with 180 days to complete the move for non-EU customers and the EU Data Act addendum for EU customers. So the decision rule is simple: get a priced Azure quote for your actual estate (node shapes, disks, egress, managed databases), plus a TCO model that includes the dual-run overlap, before a single manifest is edited.

What actually breaks when you move a Kubernetes workload from EKS to AKS?

Your Kubernetes objects are portable. The cloud integration layer is not. Eight things break in practice: pod identity (IRSA), ingress annotations, the CNI and pod IP plan, storage classes, ReadWriteMany volumes, the image registry and pull secrets, the secrets driver, and every AWS SDK call in your application code.

Pod identity is the one that surprises teams. IAM Roles for Service Accounts (IRSA) becomes Microsoft Entra Workload ID, which is a federated credential on a user-assigned managed identity plus the azure.workload.identity/use: "true" label on the pod. The old AAD Pod Identity project was deprecated in October 2022 and archived in September 2023, with the managed add-on supported only through September 2025, so do not build anything new on it.

The silent blocker is application code. Every SDK call to S3, SQS, DynamoDB, Kinesis or STS keeps pointing at AWS after the pods move to Azure. Grep the codebase for those calls before you plan anything else, because they decide whether you can cut a service over cleanly or whether it has to keep talking back to AWS over a VPN during the overlap.

A note on the parts you can choose not to port. If you already run Prometheus, Grafana and OpenTelemetry instead of CloudWatch, your observability layer moves with the manifests and you never pay this tax again. The same logic applies to ingress: a cloud-neutral ingress-nginx is less work over two migrations than rewriting ALB annotations once and Application Gateway annotations later.

What are the steps to migrate from EKS to AKS, in order?

The safe order is eight steps: inventory, Azure landing zone, replatform manifests, move images, replicate data, parallel run, traffic shift, decommission. Reordering it, especially moving data before the landing zone is proven, is the single most common reason a six-week project becomes a quarter.

The discipline that makes this work is a validation gate after every step. You do not start the next step until a named, measurable thing is green. That is what keeps a migration from turning into a big-bang cutover with no way back.

Step 1 is the one teams rush and regret. The baseline you capture here (p95 latency, error rate, cost per service) is the only objective way to answer "is the AKS version actually as good?" during the parallel run. Without it, the go/no-go decision becomes a vibe.

How do you migrate stateful workloads and databases from AWS to Azure without downtime?

Stateless services cut over in hours. Stateful ones set the whole timeline. Only two patterns reliably avoid downtime: logical replication with a replica promotion, or a dual-write window. Both require a tested rollback plus a verified row-count or checksum comparison before you touch DNS.

Be honest about the hard case up front. There is no zero-downtime path for a ReadWriteOnce volume with a single writer. EBS snapshots cannot restore natively to Azure Disks, so a cross-cloud volume move goes through Velero File System Backup (Kopia or restic), which means a restore window and downtime. Budget a maintenance window for those volumes and tell stakeholders early, in week one, not the night before.

For relational databases the clean pattern is native logical replication (PostgreSQL) or binlog replication (MySQL), or Azure Database Migration Service in online mode, which supports RDS and Aurora as sources. You replicate continuously, then promote the Azure replica during a short write freeze. NoSQL is harder and I will not pretend otherwise: moving DynamoDB to Cosmos DB for NoSQL means rethinking partition keys and the consistency model, which is real engineering work.

During the overlap, workloads on AKS often still need to reach data that is still on AWS. That means a Site-to-Site VPN or ExpressRoute plus Direct Connect, and it means a round-trip latency tax on every cross-cloud query. Factor that into the parallel-run metrics so you do not mistake network latency for an application regression.

Your cutover checklist for each stateful service is the same every time: freeze writes, drain queues and in-flight jobs, verify row counts and checksums, flip the weighted DNS record, then watch the error budget for 60 minutes with the rollback trigger agreed in advance.

Should you lift-and-shift, build your own platform layer, or use a platform that already runs on both clouds?

There are three realistic options. Lift-and-shift with hand-rolled Terraform or Bicep is fastest to a running AKS cluster but leaves you maintaining two sets of cloud-specific glue forever. Building your own abstraction with Crossplane or Backstage is clean but means funding a platform team to run it. Adopting a platform that already provisions both EKS and AKS in your own accounts is the shortest path to a genuine side-by-side parallel run.

The reason this choice matters for a migration specifically is the parallel run. Steps 6 and 7 above require both clusters live from the same application definition. If your CI/CD only knows how to deploy to EKS, you are rebuilding the pipeline for AKS before you can even start comparing the two, and you are maintaining both pipelines for the length of the overlap.

The Microsoft-native route for the third option is Azure Arc plus AKS Fleet Manager, which is a reasonable fit if you are standardizing everything on Azure and do not need the AWS side to stay first-class. The independent platforms in this space include Qovery, Northflank, Porter, Humanitec, Rafay and Spectro Cloud Palette, and they differ mainly in how much of the cloud account they run inside and how even their support is across clouds.

Here is where Qovery fits, and I will be specific because the migration case is where it earns its place. Qovery provisions and operates AKS inside your own Azure subscription, and it also runs EKS in your AWS account, GKE in GCP, Scaleway, or your existing Kubernetes cluster. Because the cluster lives in your subscription, the Azure commitment discount and the invoice stay in your name. One application definition drives git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades and per-environment RBAC, and all of that survives the move.

For the cutover that means you run the EKS and AKS environments side by side from the same definition instead of rebuilding the pipeline twice, then delete the AWS side once traffic has shifted. I want to be equally clear about the limits. Qovery does not migrate your data, does not convert RDS to Azure Database for you, and does not remove the work of mapping managed services or rewriting AWS SDK calls. Those stay on your plate regardless of which approach you pick.

How long does an EKS to AKS migration take and what does it really cost?

Plan 6 to 14 weeks for a mid-size estate: assessment 1 to 2 weeks, landing zone 1 to 2 weeks, replatforming 2 to 6 weeks, and a parallel run of 2 to 4 weeks per tranche. The dual-infrastructure overlap, not the engineering hours, is usually the largest line item on the invoice, because for the length of the parallel run you are paying two clouds for the same traffic.

The cost lines to budget are duplicate compute and storage during overlap, AWS egress (often free on exit, as noted above), engineering time, the Azure support plan, cross-cloud VPN or ExpressRoute, and any stranded AWS commitment running to term. On funding, ask your Microsoft account team about Azure Migrate and Modernize and partner-led migration credits, and get the amount in writing before you sign the EA. Migration funding that was verbally promised and never materialized is a classic way a "cheaper" move ends up flat.

The risk controls are boring and they work. Migrate the least critical namespace first. Keep one rollback-tested canary service through the whole project. Never migrate a database and shift traffic in the same change window. And budget time for the three things teams underestimate every single time: CI/CD rework, DNS and certificate management, and re-tuning autoscaling and resource requests for a different VM family, because a pod sized for an m7i node is not sized for a Dsv5 node.

How do I run the EKS to AKS move from Claude Code or Cursor?

You can drive the Azure side of the migration from the coding agent you already use. Install the Qovery Agent Skills once, and your agent can connect your Azure subscription, provision AKS and deploy workloads, asking you to approve every change before it runs.

Install globally for any compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope it to a single project instead of installing globally:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code, which uses OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things, which also requires turning on write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Each skill owns a phase of the move. qovery-onboard connects the Azure subscription and creates the cluster, qovery-deploy ships the workload, qovery-terraform handles the IaC side, qovery-preview sets up per-PR environments, and qovery-troubleshoot and qovery-optimize cover the post-cutover phase. The MCP Server operates what already exists.

Then you ask in plain language, for example "deploy this service to my Azure subscription with Qovery and keep the AWS environment running," and the agent proposes each change and waits for your approval. The full walkthrough is in the AI agent quickstart and the Claude Code integration page.