I've been running EKS worker nodes on c5a.2xlarge instances in development, but I'm considering c8g.2xlarge Graviton nodes for production to improve price-performance. I'd like to hear about real-world migrations from x86 instances such as c5a or c6a to Graviton generations such as c7g or c8g. My applications are mainly Node.js and Next.js. I'm especially interested in ARM64 Docker image compatibility, Helm charts and dependencies, performance changes, autoscaling, monitoring, networking, unexpected production issues, and whether it's better to use mixed node groups or migrate everything to ARM. Any practical lessons or gotchas would be helpful before I begin testing.
5 Answers
I had good results with ARM: lower cost, better concurrency, less memory usage, and improved bin-packing, with no noticeable performance regression. The savings depend on the workload, but Graviton 3 was a particularly good price-performance point for us. Check all upstream images before migrating, because most are available for ARM now but a few deprecated or specialized components may still need replacement.
I’d start with a separate ARM node group in development or staging. Taint the nodes and migrate workloads one at a time by adding tolerations and node selectors, while adjusting PodDisruptionBudgets and resource requests as needed. This phased approach can expose forgotten images, init containers, and old tooling without affecting the whole cluster. During the transition, keep both node groups available and reduce the x86 capacity gradually instead of replacing everything at once.
A full node-pool replacement can work, but it may temporarily degrade services and create a noisy rollout. Moving applications individually made it much easier to find technical debt and tune the manifests.
The migration is usually straightforward as long as every workload has a native ARM64 image. Build images with Docker Buildx or on an ARM runner, and be particularly careful with external binaries and native dependencies such as image-processing tools. Running x86 images through emulation is possible, but the performance cost generally makes it a poor production choice. ARM64 is the right target for modern deployments, and most mainstream software now supports it.
It’s also worth checking the exact architecture of any older binaries or dependencies rather than assuming the base image covers everything. A dependency can still be the thing that prevents a container from starting.
Build multi-architecture images for both AMD64 and ARM64, then publish them under one tag using a manifest. Your deployment can stay the same while each node pulls the correct image. This works well for Node.js, Next.js, Java, and Python workloads. Build the two architectures on appropriate native runners when possible; emulation works for occasional builds but is slower.
There is some extra storage and build work because both image variants exist, but the runtime pull normally fetches only the architecture-specific image rather than downloading both.
Helm itself generally doesn’t cause problems. The important parts are the scheduling settings: node selectors, affinity, taints, and tolerations. Some teams avoid Alpine for ARM migrations and use a Debian Bookworm slim base instead, since native libraries and tooling can be less surprising. An image inventory tool such as KubeArchInspect can help identify images that lack ARM support before you start moving workloads.
Don’t inspect only currently running containers. Init containers and less frequently deployed jobs can be missed, so review the complete set of images referenced by your manifests.