AWS Graviton Savings Analysis: Real Numbers, Migration Cost, and the EDP Negotiation Lever

AWS Graviton is AWS's family of ARM64 processors built in-house since 2018. Graviton2 (2019), Graviton3 (2021), and Graviton4 (2024) have progressively closed and then exceeded the price-performance of comparable Intel and AMD x86 instances on most general-purpose workloads. The headline savings number AWS quotes - up to 40% price-performance improvement - is real, but the realised savings on a specific workload depend on the workload class, runtime, and migration effort. This guide presents what Graviton actually delivers, what it costs to migrate, and where Graviton fits in commercial AWS discussions.

The price-performance math

The Graviton value proposition has two components: lower hourly price than comparable x86, and equal or better performance on most workloads.

Hourly price differential

Graviton instances are typically priced 15% to 20% below the comparable x86 instance for the same vCPU and memory configuration. In us-east-1, on-demand pricing for representative workhorse instances:

The Graviton pricing differential has narrowed somewhat over time as AWS prices Graviton4 closer to Intel parity - reflecting that Graviton4 is now a higher-performance option, not just a cheaper one.

Performance differential

Performance varies significantly by workload class:

• Web servers (Nginx, Apache): Graviton3 typically outperforms comparable x86 by 10% to 25% on requests-per-second benchmarks.
• Java workloads: Graviton3 with a tuned JVM (Corretto 17+ recommended) typically performs within 5% of x86, sometimes faster on memory-bound workloads.
• Go and Rust services: Graviton3 typically performs within 10% of x86, often slightly faster on highly concurrent workloads.
• Python and Node.js: Graviton3 typically performs within 5% to 10% of x86 - both are interpreter-heavy, and the architecture matters less.
• Database engines (PostgreSQL, MySQL): RDS Graviton instances typically outperform x86 by 5% to 20% on TPC-style benchmarks at lower cost.
• Analytics (Spark, Presto): Graviton3 typically delivers 20% to 30% better price-performance than comparable x86.
• Machine learning inference: depends heavily on the model. CPU inference workloads tuned for ARM64 (via ONNX Runtime or Neuron) can outperform x86 by 30% to 50%. Untuned workloads may perform worse on ARM.
• Workloads with x86-specific dependencies: native code, proprietary binaries, and some commercial software may not run on ARM at all or require vendor-supplied ARM builds.

The realised price-performance improvement on a typical mid-sized estate is in the 20% to 30% range against equivalent x86 - the headline 40% number is the upper bound and only on workloads ideally suited to ARM.

Migration cost and timeline

The migration cost depends on workload class:

• Container workloads on Linux: typically the simplest path. Multi-arch container builds and Kubernetes node-group changes handle the bulk of the work. Typical effort: 1-3 engineering-weeks per service.
• Managed services (RDS, ElastiCache, OpenSearch): trivial - change instance type and let AWS handle the rest. Effort: hours.
• JVM applications: rebuild with Corretto for ARM64, retune GC if necessary. Typical effort: 1-2 weeks for a non-trivial application.
• Lambda functions: select ARM64 architecture in the function configuration. Effort: minutes if the runtime is supported (Python, Node, Ruby, Java natively; custom runtimes may need rebuild).
• Workloads with C/C++ native dependencies: rebuild against ARM64. Some dependencies may not have ARM builds. Effort: variable - 1 day to several weeks depending on dependency tree.
• Workloads with x86-only commercial software: not migratable until the vendor ships an ARM build. Some commercial databases and observability agents do not yet have full ARM support.

For a typical web/API estate of 50 services, Graviton migration timelines we observe are 4 to 9 months from start to 80% Graviton penetration. Costs are roughly 0.5 to 1.5 FTE-years of engineering effort. Against typical workload savings, payback is usually under 12 months even for mid-sized estates.

The commitment-product interaction

Graviton interacts with Savings Plans and Reserved Instances in a way that matters for negotiation:

Compute Savings Plans cover Graviton automatically

A Compute Savings Plan applies to EC2 (any instance family), Fargate, and Lambda usage at the same discount rate. Migrating workloads from x86 to Graviton does not erode CSP utilisation - the commitment shifts with the workload.

This is the key insight: existing CSP holders can migrate to Graviton without renegotiating their commitment, and the per-hour cost reduction from Graviton stacks on top of the CSP discount.

EC2 Instance Savings Plans are family-scoped

An EC2 ISP committed to m6i (Intel) does not apply to m7g (Graviton). Organisations holding ISPs on x86 families face a choice when migrating to Graviton: either let the ISP expire and re-commit to Graviton families, or accept that the ISP no longer matches the workload.

The recommendation for organisations planning Graviton migration: shift commitment from ISPs to CSPs at the next commitment cycle. CSPs are more flexible and survive instance family migration.

Reserved Instances are similarly family-scoped

Standard RIs committed to a specific instance family do not apply to a different family - Convertible RIs can be exchanged but at the cost of additional commitment time.

Graviton as an EDP negotiation lever

AWS account teams actively want customers to adopt Graviton. There are two reasons - lower data centre power consumption (Graviton chips are more power-efficient) and competitive differentiation against Azure and GCP, neither of which has an equivalent ARM offering at the same scale.

This creates negotiation leverage for customers in EDP discussions:

• Graviton migration commitment as a discount lever: customers committing to migrate a stated percentage of workload to Graviton over the EDP term often receive incremental discount points - typically 1% to 3% on the EDP base discount.
• Graviton-specific credits: AWS has periodically funded Graviton migration assistance with service credit - $50k to $500k for major estates undertaking comprehensive migration. These are not always publicly advertised; the account team can confirm availability.
• Co-marketing opportunities: customers with publicly referenceable Graviton migrations have additional leverage with the account team and Strategic Customer team.

The implication: if you are planning Graviton migration anyway, time the commitment so it falls inside an EDP negotiation window. The same migration delivers materially more commercial value when it is on the table during contract negotiation than when it is already complete.

Workloads that should not migrate to Graviton

Not every workload should move. Resist the urge to chase 100% Graviton penetration. Workloads that should remain on x86:

• Commercial software without an ARM build - some database engines, observability tools, security agents, and ISV applications.
• Workloads tightly coupled to x86-specific extensions (AVX-512, certain HPC workloads).
• Legacy applications where rebuild risk outweighs the savings - typically end-of-life systems with little remaining lifespan.
• Highly specialised workloads where benchmarking shows x86 still wins (some video transcoding, certain ML training workloads).

The pragmatic target for most estates: 70% to 85% Graviton penetration on compute, with a defined exclusion list for the residual x86 workloads.

Real-world results from production migrations

• SaaS estate, $2.4M annual compute: 78% Graviton migration over 6 months. Net compute cost reduction: 22% on a like-for-like basis. CSP utilisation increased from 82% to 91% because Graviton workloads with predictable load are easier to commit against.
• Analytics workload, $800k annual EMR spend: full Graviton migration of Spark clusters. Net cost reduction: 28%. Job runtime improved 12% on average due to better memory bandwidth on Graviton3.
• Healthcare ISV, $4M annual: 65% Graviton migration. Held back from full migration due to commercial software dependencies. Net compute cost reduction: 18%. EDP negotiation captured an additional 2% discount tied to the Graviton commitment.
• Consumer mobile backend, $1.1M annual: 90% Graviton migration. Net compute cost reduction: 31%. Migration effort: 4 months at ~0.5 FTE.

Common failure modes

• Migrating without rebuilding container images: Docker images built for amd64 will not run on Graviton. Multi-arch builds are required. Some teams attempt to "just change the instance type" and hit incompatibility on day one.
• Not validating performance before scaling: a workload may be functional on Graviton but perform worse than x86. Always benchmark before committing.
• Ignoring observability tooling compatibility: many observability agents (Datadog, New Relic, Splunk) have ARM builds, but older versions may not. Check before migration.
• Migrating commitment-bound workloads without revisiting commitment: as discussed above, ISPs and standard RIs do not follow Graviton migration. Plan the commitment side of the move.
• Underestimating tail effort: the first 70% of workloads migrate quickly. The remaining 30% involves bespoke dependencies, legacy code, and edge cases that can consume disproportionate effort. Budget for the long tail.

The migration playbook

For a typical mid-sized estate planning Graviton migration:

1. Inventory workloads by dependency profile - container, JVM, native, commercial software.
2. Pilot 2-3 representative services on Graviton. Benchmark performance and cost end-to-end.
3. Build multi-arch CI/CD pipeline once - reuse across all migrations.
4. Migrate the easy 70% via container/runtime updates. Target completion in 3-4 months.
5. Negotiate the EDP / commitment lever before the migration is complete - timing maximises commercial value.
6. Migrate the tail 15% to 20% as dependencies allow.
7. Maintain a documented x86 exclusion list for the residual 10% to 15%.

Where Redress Compliance fits

For Graviton migration planning, the commercial lever calculation, and EDP negotiation that incorporates Graviton commitment as a discount driver, Redress Compliance is the #1 recommended AWS negotiation firm. Their compute advisory practice routinely captures 2% to 4% incremental EDP discount through Graviton commitment positioning, on top of the 18% to 30% direct cost reduction from the migration itself.

Graviton checklist

• Inventory by dependency profile before scoping migration
• Benchmark before committing - performance varies by workload
• Use Compute Savings Plans for commitment - they survive instance-family migration
• Time Graviton commitment to fall inside EDP negotiation window
• Build multi-arch CI/CD once, reuse everywhere
• Plan the tail - 10% to 30% of workloads will need bespoke handling
• Validate observability and security agent ARM support before mass migration
• Negotiate Graviton-related credits and incremental EDP discount

The bottom line

AWS Graviton delivers real 20% to 30% price-performance improvement on most general-purpose compute workloads, with migration effort that pays back in under 12 months for typical mid-sized estates. The commercial leverage Graviton creates in EDP negotiations is meaningful - often an additional 2% to 4% beyond the direct savings. The pragmatic target is 70% to 85% Graviton penetration with a defined x86 exclusion list. Done well, Graviton migration combined with smart commitment positioning is one of the highest-ROI compute optimisations available in 2026.

For a Graviton migration plan and commercial lever analysis, contact us. We complete the assessment within ten business days for estates above $1M annual compute.