AWS Graviton Migration Cost Savings: What Enterprises Actually Achieve

The Graviton Price Performance Case

AWS Graviton processors deliver two distinct advantages over equivalent x86 instances: a lower hourly rate for the same nominal vCPU and memory configuration, and better computational throughput per vCPU for the majority of cloud-native and containerised workloads. The combination of lower price and higher throughput produces the headline "up to 40 percent better price performance" figure AWS quotes — and that figure is broadly accurate for well-suited workloads.

The pricing differential is straightforward. A C7g.large (Graviton3, 2 vCPU, 4 GB) runs at approximately $55 per month in us-east-1. The equivalent C7i.large (Intel Sapphire Rapids, same configuration) runs at approximately $67.55 per month — an immediate 18.5 percent hourly saving before any performance differential is applied. In compute-intensive workloads where Graviton delivers 20 to 25 percent more throughput per core, the effective price performance improvement reaches 35 to 40 percent.

For organisations with significant EC2 compute bills — a frequent characteristic of enterprises running EDP-eligible spend levels — this represents a material cost reduction opportunity that does not require Reserved Instance commitments or Savings Plans to realise. Graviton discounts are embedded in the On-Demand price itself.

Graviton Generations: Knowing What You Are Running

AWS has released three Graviton processor generations, each with distinct performance and price characteristics. Understanding which generation applies to which instance family determines your realistic savings expectation.

Graviton2: The Established Baseline

Graviton2 powers the M6g, C6g, R6g, T4g, X2gd, and Im4gn instance families, as well as the A1 family (first-generation Graviton). These instances typically offer 20 percent lower cost than equivalent x86 families and are the most widely adopted Graviton instances in production. Graviton2 is mature, well-supported, and available in all major AWS regions. For most general compute, web serving, and containerised microservices workloads, Graviton2 is the appropriate migration target.

Graviton3: The Performance Leader

Graviton3 powers the C7g, M7g, R7g, and Hpc7g families. Graviton3 delivers approximately 25 percent better compute performance than Graviton2, with specific advantages in floating-point computation, cryptographic operations, and machine learning inference. For database workloads, Graviton3-based RDS instances deliver up to 30 percent lower compute costs compared to equivalent x86-based RDS deployments, with no degradation in throughput for PostgreSQL, MySQL, and MariaDB workloads. This is one of the most compelling Graviton cost cases: database migrations frequently account for 20 to 30 percent of total EC2 and RDS spend in enterprise environments.

Graviton4: The Emerging Option

Graviton4, powering the R8g family, delivers significant improvements for memory-intensive and high-throughput workloads. Graviton4 reduces compilation costs by approximately 35 percent compared to x86 alternatives and shows particular strength in in-memory analytics and high-memory web tier applications. Graviton4 availability is more limited than Graviton2 and Graviton3 and may not be available in all regions required for multi-region architectures.

Workloads That Benefit Most

The Graviton savings case is not uniform across workload types. Enterprises that achieve 35 to 50 percent cost reductions typically concentrate their migration on specific workload categories. Organisations that achieve disappointing results tend to have applied Graviton broadly without workload screening.

High-Benefit Workload Categories

• Containerised microservices on EKS or ECS: Containerised applications built on Linux are among the best-suited workloads for Graviton. Most container base images support ARM64 natively, and application code compiled for multi-architecture deployment runs on Graviton without modification. Enterprises running large Kubernetes clusters on x86 instances typically achieve 25 to 35 percent cost reduction by migrating compute nodes to Graviton.
• Web application servers and API gateways: Applications running Node.js, Python, Go, or Java on Linux show strong Graviton performance. These runtimes are fully ARM64-native in current versions and typically show flat or improved throughput on Graviton at lower cost per request.
• Open-source relational databases (PostgreSQL, MySQL, MariaDB): RDS on Graviton3 delivers 30 percent lower compute costs with consistent performance. Aurora PostgreSQL and Aurora MySQL support Graviton3 instances and show particular benefit in read-heavy OLTP workloads.
• AWS Lambda functions: Lambda on Graviton2 is priced approximately 20 percent lower than equivalent x86 Lambda and delivers better throughput per invocation for most function profiles. For high-volume Lambda architectures with millions of daily invocations, the cumulative saving is material.
• Compilation and build workloads: CI/CD build pipelines, particularly those running extensive test suites or compiling large codebases, show some of the highest Graviton performance gains. Graviton3 and Graviton4 deliver 30 to 35 percent faster compilation than equivalent Intel instances.

Workloads Where Graviton Delivers Less Value

• Windows Server workloads: AWS does not offer Windows Server on Graviton instances. x86 instances are required for all Windows workloads.
• x86-compiled legacy applications without ARM64 builds: Applications with statically linked x86 binaries or native code compiled specifically for x86 require recompilation before running on Graviton. If recompilation is not feasible, the migration is blocked.
• Third-party software without ARM64 support: Some commercial software vendors do not provide ARM64 builds. Before migrating any workload that relies on third-party binaries, confirm ARM64 availability from the vendor.
• GPU-accelerated workloads: GPU instances (P, G, and Inf families) are x86 only. GPU compute workloads cannot benefit from Graviton.

Sizing the Opportunity Before Migrating

The most reliable way to assess your Graviton savings opportunity is to run the AWS Graviton Savings Dashboard, available within the AWS Cost Explorer. The dashboard analyses your current EC2 and RDS spend, identifies instances that have a direct Graviton equivalent, and projects the monthly savings from migrating each candidate instance type. For large fleets with hundreds of instance types in use, the dashboard output provides a ranked migration shortlist that prioritises by savings magnitude.

Before acting on the dashboard output, apply a workload compatibility screen to each candidate. The compatibility check should confirm: the operating system is Linux (not Windows), the application runtime is ARM64-compatible, no third-party binaries are x86-only, and the instance is not part of a licensed software deployment with x86-specific terms (some IBM, Oracle, and SAP software products have processor-specific licensing terms that could be affected by instance type changes).

The Migration Approach

Phase 1: Identify and Prioritise

Use the Graviton Savings Dashboard to identify eligible instances. Prioritise by three criteria: savings magnitude (largest first), deployment type (containerised and stateless workloads before stateful), and team availability to support testing. Create a migration backlog with each item assigned to an application owner and a target migration date.

Phase 2: Test in Non-Production

For each workload category in the migration backlog, stand up a Graviton equivalent in a non-production environment and run your standard performance and functional test suite. Most organisations find that containerised workloads pass compatibility tests with zero code changes. Applications running JVM-based workloads (Java, Kotlin, Scala) typically run on Graviton without modification — the JVM handles the ARM64 translation automatically.

Note any performance differences. Where Graviton delivers higher throughput, you may be able to right-size to a smaller instance type, compounding the savings further. Where throughput is flat, the hourly rate reduction alone justifies migration. Where throughput is lower (uncommon in tested workloads), investigate the specific workload characteristic before proceeding.

Phase 3: Migrate Production Incrementally

Use blue-green deployment or canary rollout to migrate production workloads to Graviton. For Auto Scaling Groups, update the launch template to use a Graviton instance type and allow gradual scale-in of existing x86 instances as capacity normalises. For EKS clusters, add a new Graviton node group and migrate workloads using pod disruption budgets and node affinity rules.

Interaction With EDP and Reserved Instances

Graviton migrations interact with your EDP and Reserved Instance strategy in a way that requires planning. If you hold Standard Reserved Instances for specific x86 instance types and migrate those workloads to Graviton, the x86 Reserved Instances become unused and continue to incur charges without applied benefit. Before migrating workloads covered by Standard RIs, assess whether the RIs can be sold on the AWS Reserved Instance Marketplace, converted to Convertible RIs (which can be exchanged to cover Graviton instances), or allowed to naturally expire if the remaining term is short.

Savings Plans, by contrast, are architecture-agnostic for Compute Savings Plans — they apply automatically to Graviton EC2 and Lambda consumption as well as x86. If you hold Compute Savings Plans, your Graviton migration will be covered by the existing Savings Plan discount, and the lower Graviton On-Demand rate means your Savings Plan goes further — reducing the effective cost per unit of compute even further.

Finally, do not forget data egress when modelling total Graviton migration costs. If migrating to Graviton involves restructuring how data flows between services or regions, verify that the migration does not introduce additional egress charges. Data egress — charges for transferring data out of AWS — remains the most common hidden cost in AWS architectures and should be modelled explicitly in any significant migration project.