Executive Summary
This guide outlines the strategic migration of containerized workloads from AWS Elastic Kubernetes Service (EKS) to Azure Kubernetes Service (AKS) within the UK South (London) or UK West (Cardiff) regions. While both platforms manage Kubernetes control planes, differences in networking (VPC vs. VNet), IAM (IAM Roles for Service Accounts vs. Microsoft Entra Workload ID), and storage integration require a structured approach to ensure zero downtime and operational parity.
Why Businesses Migrate
Drivers:
- Enterprise Agreement (EA) Consolidation: Leveraging existing Microsoft spend commitments.
- Hybrid Integration: Seamless connectivity with Azure Arc and Active Directory.
- Regional Strategy: Specific performance requirements in UK-based data centers.
Anti-patterns:
- "Lift-and-Shift" without API adaptation: Ignoring ingress controller differences (ALB/NLB vs. App Gateway/Azure Load Balancer).
- Underestimating Egress Costs: Failing to account for data transfer fees between AWS and Azure during the synchronization phase.
The 6 Rs for EKS to AKS
- Rehost (Lift-and-Shift): Container image porting. Minimal changes to YAML; focus on changing LoadBalancer annotations.
- Replatform: Replacing EKS-specific add-ons (e.g., AWS Load Balancer Controller) with Azure-native equivalents (AGIC or Azure Gateway Ingress).
- Refactor: Moving from EKS-managed IAM to Entra ID (formerly Azure AD) Workload Identity for granular, non-key-based security.
- Repurchase: Switching from AWS-specific marketplace tools (e.g., AWS Distro for OpenTelemetry) to Azure Monitor/Container Insights.
- Retire: Decommissioning legacy EKS nodes and VPC peering connections.
- Retain: Keeping specific microservices on EKS if they rely on proprietary AWS services (e.g., SQS/DynamoDB) that cannot be immediately refactored.
Pre-Migration Assessment
- Inventory: Audit all Kubernetes manifests for AWS-specific annotations (e.g.,
eks.amazonaws.com/role-arn). - Network Mapping: AWS VPC (CIDR) must be mapped to Azure VNet/Subnets. Plan for Azure CNI vs. Kubenet.
- IAM: Map AWS IAM Roles to Azure Managed Identities. Implement Microsoft Entra Workload ID for pod-level security.
- Data Transfer: Calculate total image repository size (ECR) and persistent volume (EBS) data. Use Azure Data Box or AzCopy for large-scale persistent data migration.
Step-by-Step Execution Plan
- Pilot: Deploy a non-production cluster in AKS UK South using Terraform/Bicep.
- Foundation: Establish connectivity via ExpressRoute or VPN. Configure Private Link for ACR (Azure Container Registry).
- Data Migration:
- Mirror ECR images to ACR.
- Use Velero with the Azure plugin to migrate persistent volumes if storage is block-based.
- Cutover:
- Implement Blue/Green deployment using Global Server Load Balancing (Traffic Manager or Azure Front Door).
- Gradually shift traffic weights from AWS to Azure.
Troubleshooting Common Issues
- Ingress Controller Mismatch: AWS ALB annotations will fail in AKS. Replace with AGIC (Application Gateway Ingress Controller) or NGINX Ingress.
- DNS Latency: Ensure CoreDNS configurations account for Azure’s DNS resolution behavior, especially when crossing VNet boundaries.
- CSI Drivers: EKS uses
ebs.csi.aws.com. You must refactor StorageClasses to usedisk.csi.azure.com.
UK-Specific Compliance
- GDPR: Ensure all persistent volumes and logs remain within UK South or UK West regions.
- Data Residency: Utilize Azure Policy to restrict resource deployment to UK-only regions, preventing "region sprawl" into EU/US data centers.
- Sovereignty: Confirm that encryption-at-rest utilizes Customer Managed Keys (CMK) stored in Azure Key Vault (UK).
Cost Modeling
- Egress Fees: AWS charges for data leaving their network; this is the hidden cost of migration.
- Compute: Compare AKS Reserved Instances (RI) against AWS Savings Plans.
- Operational Overhead: Factor in the cost of Azure Monitor and Log Analytics, which differ significantly from AWS CloudWatch pricing models.
Conclusion
Migrating from EKS to AKS is less about the Kubernetes API and more about the surrounding ecosystem. By prioritizing the refactoring of IAM and Storage classes, you ensure a resilient landing zone. Execute the cutover via traffic shifting rather than a hard migration to maintain service availability for your UK users.