Graviton and ARM Nodes for Kubernetes: Lower Cost per vCPU

Graviton ARM instances are approximately 19% cheaper per vCPU than equivalent Intel x86 on-demand, and ARM nodes in Kubernetes clusters grew 3.5x faster than x86 between Q2 2024 and Q4 2025, now accounting for about 9% of all CPUs, according to Cast AI's 2026 State of Kubernetes Optimization Report. The main migration blocker for ARM in Kubernetes is DaemonSets, which require ARM64 image variants for every monitoring agent, log shipper, and security tool. Multi-arch images built with Docker Buildx can serve both AMD64 and ARM64 nodes, and pairing ARM with Spot instances multiplies savings with up to 90% discounts.

Key takeaways - Graviton3 instances are ~19% cheaper per vCPU than equivalent Intel x86 on-demand. Graviton4 adds up to 30% more compute on top of that. - ARM nodes grew 3.5x faster than x86 between Q2 2024 and Q4 2025, and now account for ~9% of all CPUs across Kubernetes clusters Cast AI 2026 State of Kubernetes Optimization Report https://cast.ai/reports/state-of-kubernetes-optimization/ . - The main migration blocker ARM migration in Kubernetes is DaemonSets: every monitoring agent, log shipper, and security tool on your cluster must have an ARM64 image variant before you enable ARM nodes. - Multi-arch images built with docker buildx let a single manifest tag run on both AMD64 and ARM64 nodes. No separate Deployments needed. - Pairing ARM with Spot multiplies savings: lower on-demand base price plus up to 90% Spot discount. Why ARM cuts Kubernetes cost The price gap between ARM and x86 is consistent across instance families. In us-east-1, on-demand pricing as of 2025 source: instances.vantage.sh : c7g.xlarge Graviton3, compute-optimized : $0.145/hr vs c7i.xlarge Intel : $0.179/hr – 19% cheaper m7g.xlarge general purpose : $0.163/hr vs m7i.xlarge : $0.202/hr – 19% cheaper r7g.xlarge memory-optimized : $0.214/hr vs r7i.xlarge : $0.265/hr – 19% cheaper AWS quotes up to 40% higher price-performance and up to 60% lower energy consumption for Graviton versus comparable x86. Those figures come from AWS’s own benchmarks, so treat them as ceiling numbers. The 19% on-demand list price gap is the conservative, guaranteed baseline you can bring to any cost review. Graviton generations: what changed Graviton3 2022 powers the c7g, m7g, and r7g families. It doubled floating-point performance and memory bandwidth versus Graviton2. Graviton4 2024 powers c8g, m8g, and r8g. It delivers up to 30% better compute performance than Graviton3, with 50% more cores and 75% more memory bandwidth per instance. For most CPU-bound workloads, Graviton4 makes the per-core economics even more compelling. The raw throughput gain means you can often right-size down by one instance size and still outperform the equivalent x86 configuration. Why adoption is accelerating ARM nodes grew 3.5x faster than x86 between Q2 2024 and Q4 2025. That is not a slow migration driven by a handful of early adopters. Teams are acting on the economics at scale. ARM now accounts for roughly 9% of all CPUs in Kubernetes clusters tracked by Cast AI. That share will keep rising: the AWS EKS blog named Graviton combined with Spot the highest-efficiency EKS configuration as of January 2026. How to migrate workloads to ARM The migration path has four concrete steps. Step 1: Build multi-arch images Multi-arch images let a single image tag serve both AMD64 and ARM64 nodes. Docker Buildx handles this with a single command: docker buildx build \ --platform linux/amd64,linux/arm64 \ -t myregistry/app:latest \ --push . Use native ARM64 CI runners to build the ARM64 layer. GitHub Actions now offers ubuntu-24.04-arm runners. Building ARM64 images under QEMU emulation is slow and occasionally produces subtle bugs. Native runners eliminate both problems. When using docker buildx build --platform --push , the multi-platform manifest is created and pushed atomically. No separate docker manifest commands are needed. The docker manifest create workflow is an alternative for teams stitching together separately-built per-arch images. Do not use both in the same pipeline. Step 2: Verify DaemonSets before anything else DaemonSets are the most common migration blocker. Every DaemonSet runs on every node in its scope. Without an ARM64 image, a DaemonSet pod records an ImagePullBackOff event. If the image exists as a multi-arch manifest but the ARM64 layer is absent x86-only binary , the pod launches but immediately fails with exec format error and enters CrashLoopBackOff. If the node has a taint without a matching toleration, the pod enters FailedScheduling. For critical DaemonSets CNI plugins, CSI drivers , any of these failures prevents the node from accepting workload pods. For non-critical DaemonSets monitoring agents, log shippers , the node stays Ready but observability or security coverage gaps emerge on ARM nodes. Audit every DaemonSet in your cluster: monitoring agents Datadog, New Relic , log shippers Fluentd, Fluent Bit , security tools Falco, Sysdig , and CNI plugins. Check whether each image is a manifest list covering ARM64. Most major open-source tools ship ARM64 variants. Proprietary or legacy ISV agents are where you are most likely to find gaps. To audit your cluster for DaemonSets and check their image architectures, run: kubectl get daemonsets --all-namespaces -o jsonpath='{range .items }{.metadata.namespace}/{.metadata.name}: {range .spec.template.spec.containers }{.image}{" "}{end}\n{end}' For each image listed, verify it is a multi-platform manifest list by running docker manifest inspect <image and checking for linux/arm64 in the platforms section. Step 3: Configure scheduling Once images are ready, configure how the scheduler routes workloads. To pin a workload to ARM: nodeSelector: kubernetes.io/arch: arm64 To allow either architecture useful during a gradual rollout : affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/arch operator: In values: - arm64 - amd64 GKE applies a kubernetes.io/arch=arm64:NoSchedule taint to all ARM node pools, including Tau T2A and C4A instances. Add an explicit toleration to any Deployment targeting ARM nodes on GKE. EKS requires explicit NodePool and taint configuration; there is no automatic taint on EKS. Step 4: Test incrementally Run the workload in a non-production environment first. Watch for any crashes, performance regressions, or unexpected behavior, especially in CGO-dependent packages with x86-specific C extensions. Gradually increase the ARM node share in production. A 10-20% ARM share is a reasonable starting point for stateless services. Scale up as confidence builds. Trade-offs and compatibility gaps ARM migration is not universally painless. Know where the friction points are before you start. Language and runtime compatibility Go has first-class ARM64 support via GOARCH=arm64 . Pure-Go code compiles with no changes. This covers the large majority of modern cloud-native tooling. Java JVM works correctly on ARM64. OpenJDK, Amazon Corretto, and Azul Zulu all ship ARM64 builds. JVM-based services are generally low-risk for ARM migration. CGO-dependent packages with x86-specific C extensions need recompilation. Native ARM64 build environments handle this, but it adds complexity to your build pipeline. x86-only binaries The hardest blockers are proprietary software and legacy ISV tools that ship x86-only binaries with no ARM64 equivalent. If you run closed-source monitoring agents or security scanners without ARM64 support, you have two options: run those workloads exclusively on x86 nodes using nodeSelector , or pressure the vendor for an ARM64 build. Mixed-architecture clusters are a valid steady state. You do not need to migrate 100% of workloads to ARM to capture most of the savings. Route what you can to ARM, keep x86-only workloads on x86, and let cost-aware scheduling handle the rest. How Cast AI handles ARM nodes Managing ARM and x86 nodes in the same cluster adds scheduling complexity. Cast AI abstracts this away. Set the node template architecture to Any , and Cast AI evaluates both ARM and x86 instances for every provisioning decision, selecting whichever delivers the best cost-to-fit ratio for pending pods. For workloads that must run on ARM, configure a dedicated ARM node template with a taint and nodeSelector . For workloads that must stay on x86, a separate x86-only template keeps them isolated. Before making any live changes, use the Available Savings panel with the ARM support toggle enabled. It shows the projected savings from adding ARM nodes to your current cluster. Cast AI manages both ARM instance selection and Spot interruption handling in a single automated loop, across AWS Graviton , GCP T2A , and Azure. See the ARM and Graviton support documentation https://docs.cast.ai/docs/guide-arm-and-graviton-support for configuration details. To see how much you could save by enabling ARM nodes in your current cluster, connect your cluster to Cast AI and check the Available Savings panel. Conclusion ARM nodes are not a niche optimization. A 19% list price reduction per vCPU, compounding with Spot discounts, adds up fast at cluster scale. The 3.5x growth rate in ARM adoption shows that engineering teams have done the math and are acting on it. The migration path is well-defined: multi-arch images, DaemonSet compatibility checks, scheduling configuration, and incremental rollout. The blockers are real but manageable. Start with stateless, pure-Go or JVM services. Add ARM nodes to non-production first. Scale ARM share as confidence grows. ARM is one lever among several for reducing Kubernetes infrastructure spend. For a broader view of where to look for cost reductions in your cluster, see our guide to Kubernetes cost optimization https://cast.ai/blog/kubernetes-cost-optimization/ . And if you are running on EKS, the EKS cost optimization https://cast.ai/blog/eks-cost-optimization/ guide covers Spot, right-sizing, and node consolidation alongside ARM node strategies. Frequently Asked Questions Are ARM nodes cheaper than x86 on Kubernetes? Yes. ARM nodes are consistently ~19% cheaper per vCPU on on-demand pricing across AWS instance families. A c7g.xlarge Graviton3 costs $0.145/hr in us-east-1 versus $0.179/hr for a c7i.xlarge Intel . AWS quotes up to 40% higher price-performance across its Graviton benchmark suite. Cast AI data shows ARM nodes grew 3.5x faster than x86 between Q2 2024 and Q4 2025, confirming that engineering teams are converting the economics into actual cluster changes. How do I migrate Kubernetes workloads to Graviton? Four steps: build multi-arch images using docker buildx build --platform linux/amd64,linux/arm64 ; verify that every DaemonSet in your cluster has an ARM64 image variant; configure nodeSelector or nodeAffinity to route workloads to ARM nodes; and test in non-production before scaling ARM node share in production. DaemonSet compatibility is the most common blocker. Audit those first.