Graviton or x86 on EKS: when moving to arm64 pays off

Graviton instances, based on AWS's arm64 processors, usually have a lower hourly price than their x86 equivalents, and AWS also advertises better price-performance. The question that matters is not whether Graviton is cheaper on the price list, but how much of your cluster can run on it without disproportionate effort.

What changes in practice

• Image architecture. An image only runs on arm64 if it has that variant. Images with a multi-architecture manifest work on both node types, and amd64-only images fail to start on an arm64 node.
• Native dependencies. Languages such as Go, Java, Node.js and Python usually run unchanged, but libraries with native code, binaries downloaded at build time and amd64-only third-party images need checking.
• Build pipeline. You need to build images for both architectures, for example with docker buildx, and CI runners that support it.
• Scheduling. The kubernetes.io/arch label tells the scheduler where each pod can run.

What usually blocks it

1. amd64-only third-party images, such as security agents, sidecars and legacy tools.
2. Binaries and native dependencies with no arm64 build.
3. Software with licensing or support tied to x86.
4. Build pipelines that only produce amd64, which is the easiest blocker to fix.

To find out which workloads in your cluster are in that situation, graviton-readiness reads the manifests and, with --check-images, the manifest of each image, and separates what is ready from what was not verified.

A canary with Karpenter

1. Take inventory with graviton-readiness and pick 1 or 2 services with no native dependencies.
2. Build multi-architecture images for them.
3. Create a tainted arm64 NodePool, so only pods that tolerate the taint land there. The NodePool generator helps with the architecture requirement.
4. Compare for a few weeks: p95 latency, error rate, CPU usage and cost per request, on both node types.
5. Expand in steps, and only then mix amd64 and arm64 in the same NodePool.

Avoid enabling arm64 in a general NodePool before you are sure every image supports it. A pod with an amd64-only image on an arm64 node becomes a startup failure, not a saving.

How to measure the gain

The hourly discount is not the result. Measure cost per request or per unit of work, because performance per vCPU can differ from x86 for your workload. If the service needs more replicas on arm64, part of the saving disappears. If it needs fewer, it grows.

How this fits with commitment

Compute Savings Plans apply to any instance family, so a move to Graviton does not leave the commitment unused. An EC2 Instance Savings Plan, on the other hand, is tied to one family: before migrating, check whether any commitment points at x86. More in Savings Plans or Reserved Instances. Spot is also available on Graviton instances, and the logic for combining them is in Spot or Savings Plans.

When to stay on x86

• When the cost of porting a dependency is higher than the expected saving.
• When a critical component only exists for amd64 and there is no alternative.
• When the service is small and the absolute saving does not pay for testing and maintaining two build targets.

To estimate

The savings calculator includes the Graviton effect alongside rightsizing, Spot and off-hours shutdown. The numbers are estimates, and real measurement depends on your workloads. If you want help with the inventory, the canary and the measurement in your environment, the efficiency assessment is the starting point.