Where to start
Order by effort, lowest first:
| Workload | Effort |
|---|---|
| Managed services (RDS, Aurora, ElastiCache, OpenSearch, MSK) | Change instance class; no code |
| Lambda (Python, Node.js, Java) without native binaries | Change architecture setting |
| Interpreted/JVM apps on EC2 or containers | Rebuild image for arm64, test |
| Go/Rust | Cross-compile with GOARCH=arm64 |
| C/C++ or apps with native libraries / vendor agents | Recompile, check vendor support |
| Windows workloads | Not supported on Graviton — keep x86 |
1. Compatibility check
- List native dependencies: Python wheels with C extensions, Node native addons, JNI libraries.
- Check third-party agents (monitoring, security, backup) publish arm64 builds.
- AWS publishes a Graviton getting-started guide and the Porting Advisor tool that scans source code for x86-specific issues.
2. Managed services first
aws rds modify-db-instance --db-instance-identifier orders-prod --db-instance-class db.r7g.large --apply-immediately
aws elasticache modify-replication-group --replication-group-id sessions --cache-node-type cache.r7g.large --apply-immediately
For Multi-AZ RDS, the change happens with a failover; schedule it in a maintenance window.
3. Lambda
aws lambda update-function-code --function-name thumbnailer --zip-file fileb://function-arm64.zip --architectures arm64
Architecture is set together with the code because native dependencies differ. Rebuild the deployment package (and layers) for arm64.
4. Multi-arch container images
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 \
-t 111122223333.dkr.ecr.eu-west-1.amazonaws.com/orders:2.4.0 --push .
A manifest list lets each node pull the right image. Build in CI with native arm64 runners for speed, or QEMU emulation for small images.
5. Mixed fleets during rollout
EKS with Karpenter: allow both architectures in the NodePool (kubernetes.io/arch In [amd64, arm64]) once images are multi-arch, or start with a separate arm64 NodePool and a nodeSelector on a canary deployment.
Auto Scaling groups: use a launch template per architecture (AMIs differ) and shift capacity gradually.
ECS Fargate: set runtimePlatform.cpuArchitecture to ARM64 in the task definition.
6. Benchmark and compare
Compare p50/p99 latency, throughput and CPU at the same load on x86 and Graviton. Choose the instance size by results, not by matching vCPU counts — Graviton vCPUs are physical cores, x86 vCPUs are usually hyperthreads.
Tip
Recompile with current compilers and runtimes (recent JDK, Python and Node releases have arm64 optimisations). Old runtimes understate Graviton performance.
Checklist
- Inventory sorted by migration effort
- Agents and native dependencies confirmed for arm64
- Managed services moved in maintenance windows
- Multi-arch images in CI
- Benchmarks recorded; x86 capacity reduced; savings tracked