You can migrate most EC2 workloads to AWS Graviton without changing application code because the common runtimes already support Arm. AWS positions Graviton as delivering up to 40 percent better price-performance than comparable x86 instances for scalable workloads. The work is rebuilding artifacts for arm64, testing on a parallel fleet, shifting traffic gradually, then right-sizing on the faster baseline before you commit. Migrate first, right-size second, commit last: buying a Savings Plan before migrating locks the discount to instances you are about to replace. Workloads tied to x86-only binaries are the exception to test carefully.
Last updated: June 2026 · Written by Fredrik Filipsson and reviewed by Morten Andersen · See, Cut, Lock, Run method
AWS Graviton is Amazon's family of Arm-based processors for Amazon EC2 and many managed services, designed to deliver better price-performance than comparable x86 instances. The phrase "without code changes" is accurate for the large majority of workloads built on interpreted or cross-compiled runtimes: the migration replaces the instance type and rebuilds the artifact for Arm, leaving application logic untouched. This guide is part of our complete guide to AWS cost optimization, the cluster pillar it links up to, and it pairs with the family-selection guidance in AWS Graviton4 instances: C8g, M8g, and R8g cost compared.
Can I really move to Graviton without changing code?
Yes, for most workloads the move requires no application code change because the language runtimes already target Arm. Java, Go, Python, Node.js, Rust, .NET, and PHP all run natively on Graviton, so a service written in any of them runs the same logic on Arm once the artifact is built for arm64. Interpreted languages need only an Arm build of the runtime, which AWS and the distributions provide; compiled languages need a recompile on an Arm toolchain, which produces the same program. What does require care is anything that ships an x86-only binary: a proprietary agent without an Arm build, a third-party library distributed only as x86 native code, or a vendor product not certified on Arm. Identify those early. AWS documents the broad price-performance gain on the AWS Graviton page; treat the headline numbers as directional and benchmark your own workload.
How do I migrate an EC2 workload to Graviton step by step?
Migrate by confirming compatibility, rebuilding artifacts for Arm, testing on a parallel fleet, shifting traffic gradually, then right-sizing. Work through these five steps:
- Inventory runtime compatibility. List each workload's language, runtime, and dependencies, and flag any x86-only binaries or uncertified vendor software. Workloads on Java, Go, Python, Node.js, Rust, .NET, and PHP clear this check easily.
- Build multi-architecture artifacts. Rebuild container images for arm64 with Docker buildx multi-architecture builds, or recompile native binaries on an Arm builder. The output is the same application targeting a different CPU, with no logic change.
- Stand up a Graviton test fleet. Launch the equivalent Graviton instance family alongside the x86 fleet and run the full test and load suites. Confirm correctness first, then compare throughput and latency to establish the new baseline.
- Shift traffic gradually. Route traffic to the Graviton fleet behind a load balancer or weighted target group, increasing the share while watching latency, error rate, and CPU. Roll back instantly if a regression appears.
- Right-size and commit. Because Graviton often finishes the same work faster, re-measure utilization on the new fleet, right-size it, then buy a Savings Plan against the clean baseline rather than the old x86 sizing.
This sequence is the heart of the See, Cut, Lock, Run method our AWS cost optimization service runs. To find the Graviton candidates across many accounts at once, see the sibling guide how to use AWS Compute Optimizer across an organization.
Migrate to Graviton, right-size on the faster baseline, then commit. Buying a Savings Plan before the move locks the discount to x86 instances you are about to retire, and right-sizing after the move usually shrinks the fleet because the Arm cores do more per hour.
Which workloads should move to Graviton first?
Move steady, scalable, stateless fleets first, because that is where Arm price-performance compounds and the migration risk is lowest. Web and application tiers, microservices, containerized services on Amazon ECS or EKS, batch and queue workers, and caches are strong early candidates: they run on Arm-ready runtimes, scale horizontally, and tolerate gradual cutover. Managed services make it even easier, since Amazon RDS, ElastiCache, and OpenSearch offer Graviton options you switch with a configuration change rather than a rebuild. Hold back, and test carefully, on workloads with x86-only dependencies, latency-sensitive systems with hand-tuned x86 assembly, or licensed software your vendor has not certified on Arm. The cost case is strongest where a few percent of price-performance multiplies across many instances every hour.
Want your Graviton candidates found and migrated safely?
Our AWS cost audit identifies which workloads move to Graviton cleanly, runs the parallel-fleet validation, then right-sizes and commits on the new baseline so the saving is proven, not assumed. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →How do I avoid breaking things during a Graviton migration?
Avoid breakage by validating on a parallel fleet and cutting over gradually, never by flipping the whole fleet at once. Keep the x86 fleet running while the Graviton fleet takes a growing slice of traffic, so any regression in latency, memory, or a rare code path shows up under real load with an instant rollback path. Pay attention to dependencies that compile native extensions, such as some Python and Node.js packages, since those need Arm builds even though your own code does not change. Pin multi-architecture base images so your build produces both arm64 and x86 variants, which lets you run a mixed fleet during the transition. This careful, reversible cutover is the same discipline we apply to every change in the Run step of our method, where savings are kept in place rather than risked.
The AWS Cost Optimization Field Guide includes the Graviton migration and right-sizing checklist we run before recommending any commitment, so the discount lands on the fleet you actually keep.
Frequently asked questions
Does migrating to Graviton require rewriting my application?
For most workloads, no. Applications on Java, Go, Python, Node.js, Rust, .NET, and PHP run natively on Arm, so the migration is rebuilding the artifact for arm64 and changing the instance type, not editing application logic. Only x86-only binaries and uncertified vendor software need a rewrite or a wait.
How much can Graviton save versus x86?
AWS positions Graviton as delivering up to 40 percent better price-performance than comparable x86 instances for scalable workloads. The real saving depends on your workload, so benchmark cost per unit of work on both architectures rather than comparing hourly rates alone.
Will my container images work on Graviton?
They will once built for arm64. Use Docker buildx to produce multi-architecture images so the same tag runs on both x86 and Arm, which also lets you operate a mixed fleet during cutover. Watch for dependencies with native extensions, which need Arm builds even when your code does not change.
Should I buy a Savings Plan before or after migrating to Graviton?
After. Migrate to Graviton, right-size on the faster baseline, then commit. Buying a Savings Plan before the migration locks the discount to x86 instances you are about to replace, and right-sizing after the move usually reduces the fleet, so committing first over-commits.
The short version
Migrating EC2 to Graviton is a rebuild, not a rewrite, for the large majority of workloads on modern runtimes. Inventory compatibility, build arm64 artifacts, validate on a parallel fleet, shift traffic gradually, then right-size and commit on the faster baseline for up to 40 percent better price-performance. Keep the order, migrate then right-size then commit, so the discount lands on the fleet you keep. When you want the candidates found and the migration proven down to a lower bill, that is the work our AWS cost optimization service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, AWS documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.