Graviton instance migration
AWS Graviton (arm64) instances, deliver up to 40% better price-performance compared to equivalent x86 instances.
Identify workloads ready for graviton
For sample commands to identify readiness for Graviton (ARM64) migration, see this GitHub repository
Graviton NodePool with Karpenter
For sample commands to configured Karpenter NodePool configured to prefer Graviton (ARM64) instances, see this GitHub repository
For commands to verify Graviton nodes are being used, compare cost, and validate performance, see this verify-graviton-usage.sh
Actions
Start by verifying your container images support multi-arch (most official images do).
Create a Graviton-preferred NodePool with
weight: 80and let Karpenter schedule new workloads there. Monitor for 7 days, then remove amd64 from the pool for workloads that run cleanly on arm64.Build multi-arch container images using
docker buildxwith--platform linux/amd64,linux/arm64Use Karpenter's
preference-policyto prefer Graviton but fall back to x86 if ARM images aren't availableMonitor performance metrics closely during initial migration (latency, error rate, throughput)
Estimate savings: Graviton typically provides 20–40% cost reduction for compute workloads
Migrate plugins and infrastructure components
Start with components that already have multi-arch support:
Component | Graviton Support | Migration Complexity |
|---|---|---|
CoreDNS | ✅ Native | Low |
AWS Load Balancer Controller | ✅ Native | Low |
Karpenter | ✅ Native | Low |
Nginx Ingress | ✅ Native | Low |
Key takeaway: Graviton migration is low-risk, high-reward. Most containerized workloads run on arm64 without code changes, you're simply paying less for the same (or better) performance.
