If you're using the Azure Migration Hub as your starting point, you're already ahead. But when it comes to migrating Kubernetes workloads from EKS to AKS, there are still a few key details that can make or break your deployment.

We recently walked through a real-world migration of a typical web app from AWS EKS to Azure AKS, and while the core containers came over cleanly, the supporting architecture required some careful rework.

Here’s what stood out during the process—no fluff, just what matters when you're doing the work.

Mind the Infrastructure, Not Just the App

The app itself (a voting tool using Redis and Postgres) migrated easily. But things got more complex when we looked at the surrounding infrastructure:

• Ingress and Load Balancing: AWS ALB maps loosely to Azure Application Gateway, but you’ll likely need to use it alongside an ingress controller like NGINX or AGIC. Expect to configure both.
• Secrets: Azure Key Vault works great, but you’ll need to use the CSI driver and define a SecretProviderClass to surface TLS certs inside the cluster.
• TLS Routing: End-to-end encryption isn’t automatic—you’ll configure TLS termination at the gateway and re-encryption to the pod. Watch your ports and certs.

These aren’t blockers—but they do mean rewriting pieces of your deployment and rethinking your ingress patterns.

WAF Configuration Is Not Plug-and-Play

Both AWS and Azure support WAF, but the way you configure and test them differs:

• Azure WAF runs OWASP rules by default—but you can add custom rules for things like bot protection or query string filtering.
• Testing matters: The guide provides curl-based attack simulations (SQL injection, XSS, etc.) to verify rules are active and working. Definitely do this before you call it “done.”
• Logs and telemetry: The WAF integrates with Azure Monitor and Log Analytics, so once you enable diagnostics, you get access to Kusto queries to drill into matched rules, IPs, and trends.

If you’ve never tuned a WAF before, this migration is a good excuse to learn.

DNS, Hostnames, and Session Trouble

One final tip that saved us some debugging: use the same hostname across your Application Gateway and ingress controller. This avoids all kinds of session, cookie, and auth issues that are hard to trace.

• Certificates: Both the gateway and ingress pull certs from Key Vault, so reusing the same hostname simplifies your cert management.
• DNS: You’ll need to set up A records pointing to your Application Gateway’s public IP. The guide includes scripts to handle this via Azure CLI.

It’s a small detail that makes a big difference when your app suddenly loses session state for no obvious reason.

Ready to Dive In?

The full article walks through this step-by-step, including code, architecture diagrams, and deployment scripts. If you're migrating from EKS to AKS, or just curious how these two platforms compare under the hood, it’s a solid guide worth your time.  

👉 Read the full walkthrough here

👉 Visit the Azure Migration Hub and leave us feedback to help us shape what comes next.