{"slug": "graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu", "title": "Graviton and ARM Nodes for Kubernetes: Lower Cost per vCPU", "summary": "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.", "body_md": "## Key takeaways\n\n- Graviton3 instances are ~19% cheaper per vCPU than equivalent Intel x86 on-demand. Graviton4 adds up to 30% more compute on top of that.\n- 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 (\n[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.\n- Multi-arch images built with\n`docker buildx`\n\nlet 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.\n\n## Why ARM cuts Kubernetes cost\n\nThe 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):\n\n**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\n\nAWS 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.\n\n### Graviton generations: what changed\n\nGraviton3 (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.\n\nFor 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.\n\n### Why adoption is accelerating\n\nARM 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.\n\n## How to migrate workloads to ARM\n\nThe migration path has four concrete steps.\n\n### Step 1: Build multi-arch images\n\nMulti-arch images let a single image tag serve both AMD64 and ARM64 nodes. Docker Buildx handles this with a single command:\n\n```\ndocker buildx build \\\n  --platform linux/amd64,linux/arm64 \\\n  -t myregistry/app:latest \\\n  --push .\n```\n\nUse native ARM64 CI runners to build the ARM64 layer. GitHub Actions now offers `ubuntu-24.04-arm`\n\nrunners. Building ARM64 images under QEMU emulation is slow and occasionally produces subtle bugs. Native runners eliminate both problems.\n\nWhen using `docker buildx build --platform --push`\n\n, the multi-platform manifest is created and pushed atomically. No separate `docker manifest`\n\ncommands are needed. The `docker manifest create`\n\nworkflow is an alternative for teams stitching together separately-built per-arch images. Do not use both in the same pipeline.\n\n### Step 2: Verify DaemonSets before anything else\n\nDaemonSets 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.\n\nAudit 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.\n\nTo audit your cluster for DaemonSets and check their image architectures, run:\n\n```\nkubectl get daemonsets --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {range .spec.template.spec.containers[*]}{.image}{\" \"}{end}\\n{end}'\n```\n\nFor each image listed, verify it is a multi-platform manifest list by running `docker manifest inspect <image>`\n\nand checking for `linux/arm64`\n\nin the platforms section.\n\n### Step 3: Configure scheduling\n\nOnce images are ready, configure how the scheduler routes workloads. To pin a workload to ARM:\n\n```\nnodeSelector:\n  kubernetes.io/arch: arm64\n```\n\nTo allow either architecture (useful during a gradual rollout):\n\n```\naffinity:\n  nodeAffinity:\n    requiredDuringSchedulingIgnoredDuringExecution:\n      nodeSelectorTerms:\n      - matchExpressions:\n        - key: kubernetes.io/arch\n          operator: In\n          values:\n          - arm64\n          - amd64\n```\n\nGKE applies a `kubernetes.io/arch=arm64:NoSchedule`\n\ntaint 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.\n\n### Step 4: Test incrementally\n\nRun 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.\n\n## Trade-offs and compatibility gaps\n\nARM migration is not universally painless. Know where the friction points are before you start.\n\n### Language and runtime compatibility\n\n**Go** has first-class ARM64 support via `GOARCH=arm64`\n\n. Pure-Go code compiles with no changes. This covers the large majority of modern cloud-native tooling.\n\n**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.\n\n**CGO-dependent packages** with x86-specific C extensions need recompilation. Native ARM64 build environments handle this, but it adds complexity to your build pipeline.\n\n### x86-only binaries\n\nThe 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`\n\n, or pressure the vendor for an ARM64 build.\n\nMixed-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.\n\n## How Cast AI handles ARM nodes\n\nManaging 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.\n\nFor workloads that must run on ARM, configure a dedicated ARM node template with a taint and `nodeSelector`\n\n. For workloads that must stay on x86, a separate x86-only template keeps them isolated.\n\nBefore 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.\n\n## Conclusion\n\nARM 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.\n\nThe 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.\n\nARM 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.\n\n## Frequently Asked Questions\n\n**Are ARM nodes cheaper than x86 on Kubernetes?**\n\nYes. 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.\n\n**How do I migrate Kubernetes workloads to Graviton?**\n\nFour steps: build multi-arch images using `docker buildx build --platform linux/amd64,linux/arm64`\n\n; verify that every DaemonSet in your cluster has an ARM64 image variant; configure `nodeSelector`\n\nor `nodeAffinity`\n\nto 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.", "url": "https://wpnews.pro/news/graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu", "canonical_source": "https://cast.ai/blog/kubernetes-arm-graviton-nodes/", "published_at": "2026-07-22 12:47:32+00:00", "updated_at": "2026-07-22 12:56:18.535030+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "developer-tools"], "entities": ["AWS", "Graviton3", "Graviton4", "Cast AI", "Docker Buildx", "GitHub Actions", "Kubernetes", "EKS"], "alternates": {"html": "https://wpnews.pro/news/graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu", "markdown": "https://wpnews.pro/news/graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu.md", "text": "https://wpnews.pro/news/graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu.txt", "jsonld": "https://wpnews.pro/news/graviton-and-arm-nodes-for-kubernetes-lower-cost-per-vcpu.jsonld"}}