AWS EC2 Support
EC2 Graviton migration: move to arm64 with proof it works.
Graviton instances use Arm-based processors and are priced lower than comparable x86 instances for many workloads. The move is simple for interpreted and containerized apps and needs real testing for native code. We assess, port, benchmark and roll out gradually.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You want a lower price per unit of compute on EC2, RDS, ElastiCache or containers
- Workloads are Java, Node.js, Python, Go or .NET and mostly portable
- You are rebuilding AMIs or container images anyway
- A vendor binary or native library might not support arm64
- You need evidence before changing production fleets
What you get
- Compatibility report listing blockers and fixes
- arm64 AMIs and multi-architecture images in your pipeline
- Benchmark results comparing x86 and Graviton on your workload
- Rollout and rollback plan with monitoring
How we do it
A clear, safe process you can follow along with.
1. Inventory what runs where
We list instances by family, the OS and the software on each. Anything with compiled third-party binaries, agents, drivers or licensed software is checked against arm64 support before we plan the move.
2. Scan code and dependencies
We run the AWS Porting Advisor for Graviton on source and review native modules in npm, pip wheels, Java JNI libraries and Docker base images. Many popular packages have arm64 builds, but older or niche ones may need a rebuild.
3. Build arm64 images
We create arm64 AMIs, with Image Builder if you use it, and build multi-architecture container images with docker buildx so the same tag works on both architectures. Existing x86 AMIs cannot be used on Graviton.
4. Test functionally and for performance
We run the test suite on a Graviton instance of the same generation and size, then load test with production-like traffic. Results vary by workload, so we compare throughput, latency and cost per request on your own data.
5. Roll out gradually
We add Graviton capacity in a separate Auto Scaling group or node group behind the same load balancer with a small share of traffic, watch error rates and latency, then increase the share. The x86 group stays as an instant rollback.
6. Update the commitments
Compute Savings Plans cover both architectures, while EC2 Instance Savings Plans and Reserved Instances are tied to family. We adjust commitments after the migration so nothing is stranded.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Assuming everything just works
Native dependencies and bundled binaries are the usual failure point. A test run finds them quickly.
Comparing mismatched sizes
Compare same generation and size, and judge on cost per unit of work, not on instance price alone.
Mixing architectures in one launch template
An AMI is architecture specific. We keep separate groups or use architecture-aware configuration.
Forgetting CI and developer machines
Builds on x86 produce x86 binaries. The pipeline must build for arm64.
Frequently Asked Questions
Is AWS Graviton cheaper than x86?
Graviton instances are priced lower than comparable x86 types, and many workloads see good price-performance. Actual savings depend on your workload, so we measure before committing.
Do I need to change my code to run on Graviton?
Interpreted and managed-runtime code usually needs no change. Compiled code must be rebuilt for arm64, and native dependencies need arm64 versions.
Can Lambda and containers use Graviton too?
Yes. Lambda supports arm64, ECS and EKS can run arm64 tasks and nodes, and RDS has Graviton instance classes.
Want Help With EC2 Graviton migration: move to arm64 with proof it works?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required