Skip to content

Migrating Workloads from EC2 to EKS

First PublishedLast UpdatedByAtif Alam

Moving from EC2 (or other VMs) to EKS is rarely a single cutover — migration runbooks and architecture briefs should emphasize phases, traffic control, and rollback. This page is a runbook-shaped outline, not a full lab.

Prerequisites: EKS overview, Terraform EKS cluster, and Cluster upgrades for skew and add-on hygiene. For stateful cutover and backups, see Stateful backup and restore.

Phase 0 — Inventory and constraints

Section titled “Phase 0 — Inventory and constraints”
  • Traffic entry — ALB/NLB today? Static IPs? TLS certificates and renewal owner?
  • Session stickiness — in-memory sessions break naive blue/green; plan Redis or sticky sessions at the load balancer.
  • Data — RPO/RTO for databases; prefer managed data outside the cluster or a tested StatefulSet + volume story.
  • Identity — move from IMDS instance roles to IRSA (or EKS Pod Identity) per workload.

Phase 1 — Containerize without changing traffic

Section titled “Phase 1 — Containerize without changing traffic”
  • Build a production-like image; run health endpoints that match what the load balancer will probe later.
  • Deploy to EKS behind a ClusterIP Service; validate with internal testers or VPN-only routes — no customer DNS yet.
  • Load-test pod networking, CoreDNS, and ingress controller separately from EC2 capacity.

Phase 2 — Parallel run (strangler-friendly)

Section titled “Phase 2 — Parallel run (strangler-friendly)”
  • Run EC2 and EKS side by side behind the same DNS name using weighted routing (Route 53, service mesh gateway, or ALB rules) — start with 1–5% canary.
  • Align idle timeouts, WebSocket behavior, and large upload paths with the old stack.
  • Watch 5xx, p99 latency, and ** saturation** on both legs; roll forward only when error budget allows.

Phase 3 — Ingress, DNS, and connection draining

Section titled “Phase 3 — Ingress, DNS, and connection draining”
  • Terminate TLS at Ingress / Gateway with the same cert trust chain customers already use (or plan a controlled cert rotation).
  • Lower DNS TTL before the migration window; drain old connections at the load balancer while pods scale on EKS.
  • Keep a fast revert path: DNS or weight back to EC2 until the new path is proven.

Phase 4 — Data cutover (stateful)

Section titled “Phase 4 — Data cutover (stateful)”
  • Prefer managed RDS/DynamoDB with no in-cluster primary; if you must run in-cluster, use StatefulSets, volumeClaimTemplates, and a rehearsed backup/restore drill (Velero, snapshots).
  • For read replicas, migrate read traffic first; flip write only after replication lag is stable.

Illustrative: Apache-style static + mod_proxy

Section titled “Illustrative: Apache-style static + mod_proxy”

A classic Apache httpd VM might front Tomcat or APIs:

  • Containerize as two containers or a sidecar pattern — or replace Apache with Ingress rules where possible.
  • Map VirtualHost hostnames to Ingress rules and path routing to Services.
  • Offload TLS to Ingress or keep passthrough if clients pin cert validation to the app — see Ingress controllers for passthrough tradeoffs.

Rollback and upgrades after migration

Section titled “Rollback and upgrades after migration”
Section titled “Related”