AWS Graviton pricing: what you save

AWS Graviton is the family of Arm processors AWS designs for its own servers, and it has no bill of its own: Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), AWS Lambda, AWS Fargate and the other services that run on it each price their Graviton option on their own lines. What you save is the gap between that line and the Intel or AMD line it replaces, and in the Paris Region (eu-west-3) it is not one figure. A Graviton type costs 20.3% less on EC2's burstable instances and 15.2% less on its newest generation, 20.0% less on Lambda duration and on Fargate, but 4.8% less on RDS for PostgreSQL, and on Amazon ElastiCache a Graviton4 node costs 2.6% more than the newest Intel node, computed. AWS's "up to 20%" holds on EC2, Lambda and Fargate, not on the managed databases. This article explains what Graviton is, which services offer it, how its pricing works service by service, and the levers AWS documents to move to it; four architectures price a move, then a commitment, on whole monthly bills.

What AWS Graviton is

In AWS's words, "AWS Graviton is a family of processors designed to deliver the best price performance for your cloud workloads running in Amazon Elastic Compute Cloud (Amazon EC2)." AWS designs them itself, on Arm: the Amazon EC2 FAQs say they "are based on the 64-bit Arm instruction set and feature Arm Neoverse cores as well as custom silicon designed by AWS". So is AWS Graviton Arm or x86? Arm. Intel and AMD processors are x86: code compiled for them must be rebuilt for arm64, while interpreted code usually runs as is (What does not fit).

Graviton is a processor, not a service you buy. It has no pricing page, and no line of its own on a bill: what a bill shows is the EC2 instance, the DB instance class, the Lambda function or the Fargate task that runs on it, each priced by its own service. It started with EC2 instances, and "AWS Graviton-based instances are also available in popular managed AWS services, such as Amazon Aurora, Amazon RDS, and Amazon EKS"; the full list, nine services, is in Which services offer it. An instance on Graviton against one on Intel, at a glance:

A · AWS Graviton

Instruction set

64-bit Arm (arm64)

One vCPU

A physical core

Operating system

Linux only

In an instance name

The option letter g, as in m7g.large

B · Intel

Instruction set

x86 (x86_64)

One vCPU

A thread: two per core, by default

Operating system

Linux or Windows

In an instance name

The option letter i, as in m7i.large

What differs: the instruction set, which decides what software runs, and what a vCPU is, which decides what the same vCPU count buys.

AWS's own figures for Graviton are of two kinds, and they measure different things. On price, "AWS Graviton-based instances cost up to 20% less than comparable x86-based Amazon EC2 instances" (AWS Graviton); on price-performance, "Amazon EC2 instances powered by AWS Graviton processors provide up to 40% better price performance over comparable x86-based instances" (Getting started with AWS Graviton). The first is a list price: this article computes it for each service, and it holds on EC2, Lambda and Fargate, not on the managed databases (Is AWS Graviton cheaper?). The second depends on what a workload does with the processor, so this article quotes it and never computes it.

Graviton is not AWS's only processor family: the EC2 User Guide also lists AWS Trainium, "purpose built for high-performance, cost-effective deep learning training", and AWS Inferentia, "designed to accelerate machine learning", which this article leaves out.

In short: AWS Graviton is an Arm processor that services offer as an option, not a service of its own: its price is each service's Arm price, and its saving is the gap to that service's x86 price.

How AWS Graviton works under the hood

AWS documents Graviton at the level of its generations, the instance name and the vCPU, and each bears on the bill: the generation sets the price, the option letter tells a Graviton line from an Intel one, and the vCPU decides what an hourly price buys. How each generation's silicon is laid out is not in the pages this article cites, beyond a few figures, and is left out.

Five generations, and the EC2 families of each

The EC2 FAQs give the step from the first generation to the second: "The AWS Graviton2 processors deliver up to 7x performance, 4x the number of compute cores, 2x larger caches, 5x faster memory, and 50% faster per core encryption performance than first generation AWS Graviton processors." The EC2 User Guide's list of current instance families matches each generation to its families, through the generation digit and the option letter g. Against it, what this article prices in Paris:

The pages this article cites date none of the five generations, so the table gives no launch dates. The fifth is announced: "Graviton5 features 192 cores, a 5x larger cache, and up to 33% lower inter-core latency", says the product page, without naming what it compares with. The EC2 User Guide lists M9g, C9g and R9g among the current families, and the RDS User Guide documents "General-purpose DB instance classes powered by AWS Graviton5 processors", but neither the EC2 price list of October 15, 2026 nor the RDS one of October 6 has a Graviton5 row in Paris, so this article prices Graviton2 to Graviton4. At the same size, each of them has cost more per hour than the one before:

For the generations, AWS gives performance figures, not prices: M7g instances offer "up to 25% better performance over Graviton2-based M6g", and M8g instances "up to 30% better performance ... than the seventh-generation AWS Graviton3-based M7g instances". In Paris, m7g.large costs 5.8% more than m6g.large and m8g.large 10.0% more than m7g.large, computed. It follows that m8g.large costs less than m7g.large per unit of work only if it does more than that share of extra work; AWS's figure says "up to", and only a measurement on your workload says where it lands (Measure price-performance on your workload; the EC2 article weighs generations the same way).

Reading a Graviton instance name

An instance type is named after its family and size: the series, the generation, the options, then the size after the dot. What does the g mean in an EC2 instance name? The naming guide's options list "g – AWS Graviton processors", beside "a – AMD processors" and "i – Intel processors". The series list has one Arm series of its own, "A – Powered by Arm-based AWS Graviton processors": A1, the first generation's. Every later Graviton type carries the g in a series that has Intel siblings:

rseries: memory8generationgoption: Graviton.largesize

Its Intel sibling is r8i.large, with the option letter i; Paris has no seventh- or eighth-generation AMD EC2 type at all. The same letter sits at the same place in the managed services' names: db.r8g.large is an RDS DB instance class, cache.m6g.large an ElastiCache node type and m8g.large.search an OpenSearch Service instance type, each on Graviton. The EC2 article reads the other letters.

One vCPU, one physical core

Many instances run two threads on each core, simultaneous multithreading (SMT), and "each thread is represented as a virtual CPU (vCPU) on the instance". Graviton does not: "Each core of the AWS Graviton2 processor is a single-threaded vCPU", say the EC2 FAQs, and AWS Prescriptive Guidance puts the difference in two sentences: "In the x86 architecture, a vCPU is a logical core achieved by hyperthreading. In Graviton, vCPU equates to a physical core which allows the vCPU to be fully committed to the workload." AWS's table of CPU options gives the defaults of the eighth generation:

• m8i.large Intel: 2 vCPUs on 1 core, 2 threads per core

  CorevCPUvCPU

• m8g.large AWS Graviton4: 2 vCPUs on 2 cores, 1 thread per core

  CorevCPUCorevCPU

Default CPU options. AWS, Supported CPU options for Amazon EC2 instance types

The same table gives AMD's seventh generation (m7a, c7a, r7a) one core per vCPU too, but Paris prices none of it. The layout is fixed: "You can't modify the number of threads per core for T2, C7a, M7a, R7a, and Apple silicon Mac instances, and instances based on the AWS Graviton processor" (CPU options). It follows that an hourly price compared at the same vCPU count, as every table of this article compares it, sets two Graviton cores against one Intel core and its two threads. Whether two cores do more work than two threads depends on the workload: that is why AWS's price-performance figures say "up to".

Two more facts from AWS's pages have no price of their own. Graviton instances run on the AWS Nitro System, as every current EC2 family does (the EC2 article explains it), and "AWS Graviton2 processors support always-on 256-bit memory encryption to further enhance security", say the EC2 FAQs, a sentence the pages this article cites write for Graviton2 only.

In short: A Graviton vCPU is a whole core and a Graviton type carries a g, and each newer generation costs more per hour: compare instances on the work they do, not on their vCPU count or their generation.

What AWS Graviton is used for

Which services offer it, and in which form

Each service offers Graviton in its own form: an instance type or a DB instance class picked as any other, or an Arm setting on a function or a task. Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon EMR reach it through their EC2 nodes:

Scroll the diagram sideways →

Built from each service's own documentation, what each one offers:

Lambda's setting is the function's instruction set architecture, "arm64 – 64-bit ARM architecture, for the AWS Graviton2 processor" (instruction set architectures). Fargate's is the CPU architecture of a task definition, for the tasks of Amazon Elastic Container Service (Amazon ECS) (ECS task definitions for ARM workloads) and only those: "Use Amazon EC2 to run Arm workloads on Amazon EKS, which are not supported on AWS Fargate today" (AWS Fargate FAQs). On EMR Serverless, "x86_64 is the default option for EMR Serverless applications" (EMR Serverless architecture options). The other pages differ in what they leave out: Aurora lists memory-optimized, burstable and serverless classes and no general-purpose one (Aurora DB instance class types); Amazon ElastiCache documents no Intel node type newer than cache.m5 and cache.r5 (supported node types); Amazon OpenSearch Service lists no eighth-generation Intel type, and "You can't combine Graviton and non-Graviton instances in the same cluster" (supported instance types). On EKS, the Auto Mode fee on each instance is lower on Graviton too: 19.0% less for an m7g.xlarge than for an m7i.xlarge in Paris, computed (the EKS article prices the fee).

It follows that a move to Graviton is not the same work on each service: a setting on Lambda and Fargate, a class change on RDS, an arm64 Amazon Machine Image (AMI) and rebuilt binaries on EC2. How to reduce costs with AWS Graviton orders the moves by that work.

What AWS recommends it for

The EC2 FAQs recommend each Graviton2 family for its own kind of work:

None of these pages lists a workload that Graviton serves badly; the limits come from the software, below.

What does not fit

Will my application run on Graviton without changes? It depends on the language it is written in, and AWS says so plainly:

Applications that are based on interpreted languages (such as Java, Node, Python) not reliant on native CPU instruction sets should run with minimal to no changes. Applications developed using compiled languages (C, C++, GoLang) will need to be re-compiled to generate Arm binaries.

The same answer adds that "Most Linux distributions as well as containers (Docker, Kubernetes, Amazon ECS, Amazon EKS, Amazon ECR) support the Arm architecture", and the machine image matters as much as the code: "x86 AMIs are not compatible with M6g and A1 instances". Windows does not fit at all: "Graviton instances only run the Linux operating system. As a result, Graviton instances are a strong offering for .NET running on Linux, but aren't an option for the Windows operating system or legacy .NET Framework applications" (AWS Prescriptive Guidance). GPU instances and AWS's machine learning chips are other series of instances, chosen for their accelerator before their processor. Decide what stays on x86 is the lever for what cannot move yet.

In short: Graviton fits Linux workloads, those in interpreted languages and those on a managed service first; compiled code moves once it is rebuilt, and Windows stays on x86.

How AWS Graviton pricing works

Graviton has no price of its own. Each service prices its Graviton option on its own lines, so "is AWS Graviton cheaper?" has one answer per service. This section reads the Paris price lists service by service, with one pairing rule: the same series (m, c, r, t) and size, Graviton against the Intel or AMD type of the same generation; where a service offers no Intel type of that generation, the newest one it offers, said each time. It keeps AWS's price-performance figures apart, then turns to the commitments and to the bill.

Is AWS Graviton cheaper? The gap, service by service

On every service, yes, at least at one generation: in Paris, almost every Graviton type costs less per hour than the x86 type it is paired with, by a gap each service sets, a fraction of EC2's on the managed databases. The exception is ElastiCache's Graviton3 and Graviton4 nodes, which cost more (OpenSearch Service and ElastiCache):

On OpenSearch Service, RDS, Aurora and ElastiCache, the newer Graviton types are set against an older Intel type, the newest each service offers. AWS Lambda and AWS Fargate are metered by the GB-second and the vCPU-hour, so they are not on this chart: each of their Arm rates costs 20.0% less than its x86 rate, Lambda's requests excepted (Lambda and Fargate).

Amazon EC2: Intel, AMD and the generations

Against Intel, the EC2 gap is the same across the series of a generation, c, m and r alike, and the burstable t4g.small costs 20.3% less than t3.small. The gap narrowed with Graviton4 because the Graviton price rose more than the Intel one: m8g.large costs 10.0% more than m7g.large, where m8i.large costs 5.0% more than m7i.large, computed.

Against AMD, the gap is smaller. Paris prices no seventh- or eighth-generation AMD EC2 type, so the sixth generation and the burstable family are where Graviton, Intel and AMD can be set side by side:

AMD already costs 10.0% less than Intel at this generation, computed, so m6g.large costs 10.7% less than m6a.large, where it costs 19.6% less than m6i.large. The EC2 article prices the move for instances.

RDS and Aurora: a smaller gap, narrower since Graviton3

On the managed databases, Graviton saves much less than on EC2, and less since Graviton3 than at Graviton2. On RDS for PostgreSQL, the Graviton4 class saves this much against the newest Intel class of its series in Paris:

Two prices explain it. The Graviton class rose with Graviton3: db.m7g.large costs 6.0% more than db.m6g.large, and db.m8g.large costs what db.m7g.large costs. The Intel class did not move: db.m7i.large costs what db.m6i.large costs, $0.206 per hour, and Paris has no db.m8i or db.r8i, so Graviton4 is set against a seventh-generation Intel class. So the gap narrowed at Graviton3 and has not moved since. RDS for PostgreSQL also has no db.r7g in Paris, though the RDS User Guide documents the class, so its memory-optimized pairs jump from db.r6g to db.r8g. Every pair, by generation:

The pages this article cites give no price-performance figure for these classes: the RDS User Guide's sentences on the eighth generation are about vCPUs and memory, not price. The RDS article prices the move class by class, and pattern 2 a Multi-AZ database.

OpenSearch Service and ElastiCache

On OpenSearch Service, m7g.large.search costs 16.0% less than m7i.large.search, its own generation's Intel type, and m8g.large.search 7.4% less than the same m7i.large.search, since the service lists no m8i: the Graviton4 type costs 10.1% more than the Graviton3 one. ElastiCache documents no Intel node newer than cache.m5 and cache.r5, so this article sets every Graviton node against them, by its pairing rule, and there only the Graviton2 nodes cost less:

The Graviton4 nodes list a little more memory than the Intel ones (6.79 GiB for cache.m8g.large, 6.38 GiB for cache.m5.large, in the price list), and cost 2.6% more (cache.m8g.large) and 1.9% more (cache.r8g.large) per hour. It follows that on ElastiCache, a move to Graviton saves money at Graviton2 only; at Graviton3 and Graviton4 it is a move for what the newer node does, to measure, not for its price.

Lambda and Fargate: one gap on duration, vCPU and memory

Lambda and Fargate price Arm by the same units as x86, and in Paris each Arm rate costs 20.0% less than its x86 rate, except Lambda's requests, which cost the same:

Lambda's guide stays qualitative: "Lambda functions that use arm64 architecture (AWS Graviton2 processor) can achieve significantly better price and performance than the equivalent function running on x86_64 architecture" (instruction set architectures). It follows that a function's bill falls by less than its duration rate, since its requests do not move: pattern 3's bill is 18.5% less after the move. The Lambda article weighs the move on every duration tier.

Price or price-performance: AWS's 20% and 40%

AWS gives both kinds of figure, for one service, in one sentence:

AWS Fargate powered by AWS Graviton processors delivers up to 40% improved price/performance at 20% lower cost over comparable Intel x86-based Fargate for a variety of workloads such as application servers, web services, high-performance computing, and media processing.

The 20% is a price, and the Paris price list matches it to the decimal. The 40% is price-performance, the work done per dollar, as AWS measured it on its workloads: performance enters it, and only a measurement on your own workload says what you get. AWS's other price-performance figures for Graviton each set their own pair:

The pages this article cites give no such figure for RDS, Aurora, ElastiCache or OpenSearch Service. It follows that the list-price gap is the one figure that holds for every workload, and a price-performance figure the one that says what a workload gains: this article computes the first, and leaves the second to a measurement.

Savings Plans and Reserved Instances on Graviton

Do Savings Plans apply to Graviton? Yes: Graviton usage is usage like any other. "Compute Savings Plans provide the most flexibility and prices that are up to 66% off of On-Demand rates", and "They also apply to your Fargate and Lambda usage" (Savings Plans types); the Savings Plans FAQ has them "automatically apply to EC2 instance usage regardless of instance family, size, AZ, region, OS or tenancy, and also apply to Fargate and Lambda usage", and says nothing of the architecture. In Paris, most plans take the same share off Graviton and x86; two do not:

EC2 Instance Savings Plans, Reserved Instances, Lambda's Compute Savings Plan and the Database Savings Plan take the same share off Graviton and Intel, so the gap carries into the committed price: an m7g.large on a 1-year EC2 Instance Savings Plan costs 19.0% less than an m7i.large on the same plan, as it does On-Demand. On EC2, a Compute Savings Plan does the same for the m, r and t types, but takes less off the c types: committed for three years, c8g.large costs 9.0% less than c8i.large, against 15.2% less On-Demand. On Fargate it goes the other way: committed for three years, an ARM64 vCPU-hour costs 28.0% less than an X86_64 one on the same plan, computed. Together, Graviton and a commitment go further than either:

Two limits in Paris. Reserved Instances exist for c8g, m8g and r8g, and none for c8i, m8i or r8i, so the eighth generation compares on Savings Plans only. And Database Savings Plans have one term there: the 1-year No Upfront plan is the only one of the offer for eu-west-3, so a three-year commitment on RDS or Aurora is a Reserved Instance. Commit after the move, not before says why the order of the two levers matters.

Reading the Graviton lines of a bill

A Graviton line reads as its service's own usage type, after the Region's code, EUW3- in Paris: the instance type names the processor, or an ARM in the usage type does:

The services' own articles read the rest of their lines: the EC2 bill, the RDS bill, the Lambda bill.

In short: Graviton is cheaper per hour on almost every pair priced here, by a gap each service sets, not a flat 20%: read it in that service's price list, check what the commitment you plan does to it, and leave AWS's "up to 40%" to a measurement.

Architecture patterns: four moves to Graviton and what they cost

Four illustrative configurations in Paris, each priced before the move, after it, and with a commitment bought once the move is measured, line by line from the AWS Price List: an EC2 web tier, an RDS for PostgreSQL database, a Lambda function and containers on Fargate. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out. One cost is in none of them: the engineering of the move, the arm64 builds and the tests, which no price list prices and which differs with every codebase. To give it a scale, each card says how long a thousand dollars of that work takes to pay back from the move alone.

Pattern 1 of 4 · Illustrative configuration

An EC2 web tier moved from Intel to Graviton

An Application Load Balancer sends traffic to an EC2 Auto Scaling group of four general-purpose instances across two Availability Zones in Paris, running Linux web servers: moved from m7i.large to m7g.large, then committed for one year.

Scroll the diagram sideways →

The move alone makes the bill 19.0% less, the gap of m7g.large to m7i.large, and pays back a thousand dollars of migration work in 15.3 months; the 1-year plan then makes the moved bill 34.0% less. The Application Load Balancer, part of Elastic Load Balancing, is not counted: the move does not change it. Bought before the move, an EC2 Instance Savings Plan for the m7i family would not have covered the m7g instances: Commit after the move, not before prices that mistake.

Before · 4 × m7i.large, On-Demand$343.39

With the levers · 4 × m7g.large, 1-year EC2 Instance Savings Plan$183.38

• Compute$343.39 → $183.38, too small to draw

Before · 4 × m7i.large, On-Demand: compute $343.39, total $343.39 a month.

With the levers · 4 × m7g.large, 1-year EC2 Instance Savings Plan: compute $183.38, total $183.38 a month.

With the levers: $160.01 a month less (46.6% less), computed.

An EC2 web tier moved from Intel to Graviton, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
4 × m7i.large, On-DemandBefore the levers		$343.39	—
Moved to m7g.large, On-DemandLever: Move EC2 workloads by language		$277.98	−$65.41
1-year EC2 Instance Savings PlanLever: Commit after the move, not before		$183.38	−$94.60

USD, before tax. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 15, 2026, fetched October 16, 2026.

Levers

• Move EC2 workloads by language
• Commit after the move, not before

The bills line by line, the assumptions and the sources

An EC2 web tier moved from Intel to Graviton, before: 4 × m7i.large, On-Demand Illustrative

The group's four Intel instances, On-Demand.

Line	A month
Compute
m7i.large, On-Demand4 instances × 730 h × $0.1176 /h	$343.39
A month, computed	$343.39

An EC2 web tier moved from Intel to Graviton, with the levers: 4 × m7g.large, 1-year EC2 Instance Savings Plan Illustrative

The same four instances on Graviton3, committed for one year, No Upfront, once the move is measured.

Line	A month
Compute
m7g.large, 1-year EC2 Instance Savings Plan, No Upfront4 instances × 730 h × $0.0628 /h	$183.38
A month, computed	$183.38

4 × m7g.large, On-Demand, no commitment: $277.98 a month, 19.0% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• Four instances before and after: the move keeps their count, their size and the load balancer, an assumption to measure on the workload.
• One vCPU of an m7g.large is a physical core, where one of an m7i.large is a thread of a core: the same number of vCPUs is not the same work in every workload.
• The 1-year EC2 Instance Savings Plan, No Upfront, commits to the m7g family in Paris and is bought after the move: a plan bought for m7i would not cover m7g.

Not counted

• The Application Load Balancer, the EBS volumes and data transfer, the same before and after.
• The engineering cost of the move (an arm64 build, an arm64 AMI, tests): real, different for every codebase, and on no price list.

Sources

• Amazon EC2 User Guide, "Amazon EC2 instance types"
• EC2 Instance Types Guide, "Amazon EC2 instance type naming conventions"
• EC2 User Guide, "CPU options for Amazon EC2 instances"
• Amazon EC2 FAQs
• AWS Savings Plans FAQs
• Savings Plans User Guide, "Savings Plans types"

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 15, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 2 of 4 · Illustrative configuration

An RDS for PostgreSQL Multi-AZ database moved to a Graviton class

A production PostgreSQL database runs Multi-AZ on a memory-optimized DB instance class, a primary and a synchronous standby in two Availability Zones: moved from db.r7i.large to db.r8g.large, then reserved for three years.

Scroll the diagram sideways →

The class change alone makes the bill 4.6% less, and pays back a thousand dollars of migration work in 50.7 months; on RDS, the 3-year Reserved Instance does most of the work, making the moved bill 53.0% less. A Database Savings Plan, the other way to commit on RDS, has a single term in Paris, one year.

Before · db.r7i.large, Multi-AZ, On-Demand$429.24

With the levers · db.r8g.large, Multi-AZ, 3-year Reserved Instance$192.43

• Compute$429.24 → $192.43, too small to draw

Before · db.r7i.large, Multi-AZ, On-Demand: compute $429.24, total $429.24 a month.

With the levers · db.r8g.large, Multi-AZ, 3-year Reserved Instance: compute $192.43, total $192.43 a month.

With the levers: $236.81 a month less (55.2% less), computed.

An RDS for PostgreSQL Multi-AZ database moved to a Graviton class, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
db.r7i.large, Multi-AZ, On-DemandBefore the levers		$429.24	—
Moved to db.r8g.large, On-DemandLever: Move managed services first		$409.53	−$19.71
3-year Reserved InstanceLever: Commit after the move, not before		$192.43	−$217.10

USD, before tax. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 16, 2026.

Levers

• Move managed services first
• Commit after the move, not before

The bills line by line, the assumptions and the sources

An RDS for PostgreSQL Multi-AZ database moved to a Graviton class, before: db.r7i.large, Multi-AZ, On-Demand Illustrative

The Intel class, Multi-AZ, On-Demand.

Line	A month
Compute
db.r7i.large, Multi-AZ, On-Demand1 instance × 730 h × $0.588 /h	$429.24
A month, computed	$429.24

An RDS for PostgreSQL Multi-AZ database moved to a Graviton class, with the levers: db.r8g.large, Multi-AZ, 3-year Reserved Instance Illustrative

The Graviton4 class, reserved for three years, No Upfront, once the move is measured.

Line	A month
Compute
db.r8g.large, Multi-AZ, 3-year Reserved Instance, No Upfront1 instance × 730 h × $0.2636 /h	$192.43
A month, computed	$192.43

db.r8g.large, Multi-AZ, On-Demand, no commitment: $409.53 a month, 4.6% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• Storage, backups and the parameter group stay as they are: only the DB instance class changes.
• A class change makes the database unavailable for a few minutes; in Multi-AZ, RDS applies it to the standby first, then fails over (Amazon RDS FAQs).
• db.r8g.large (Graviton4) is the Graviton class the database moves to: Paris prices no db.r7g for RDS for PostgreSQL, and no db.r8i.
• The 3-year Reserved Instance, No Upfront, is bought after the move, for the class the database runs on.

Not counted

• Storage, backup storage, data transfer and RDS Proxy, the same before and after (the Amazon RDS article prices them).
• The engineering cost of the move: testing the database on the new class.

Sources

• Amazon RDS User Guide, "DB instance class types"
• Amazon RDS FAQs

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 3 of 4 · Illustrative configuration

A Lambda function moved from x86_64 to arm64

A function serves 20 million requests a month, each 150 ms of billed duration at 1,024 MB, invoked through Amazon API Gateway (not counted): moved from x86_64 to arm64, then committed for one year with a Compute Savings Plan.

Scroll the diagram sideways →

Duration costs 20.0% less and requests the same, so the bill is 18.5% less, and a thousand dollars of migration work takes 100.0 months to pay back at this traffic; the 1-year plan then makes the moved bill 9.1% less, since it discounts duration only. Amazon API Gateway, in front of the function, is not counted: the move does not change it.

Before · x86_64, On-Demand$54.00

With the levers · arm64, 1-year Compute Savings Plan$40.00

• Compute$54.00 → $40.00, too small to draw

Before · x86_64, On-Demand: compute $54.00, total $54.00 a month.

With the levers · arm64, 1-year Compute Savings Plan: compute $40.00, total $40.00 a month.

With the levers: $14.00 a month less (25.9% less), computed.

A Lambda function moved from x86_64 to arm64, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
x86_64, On-DemandBefore the levers		$54.00	—
Moved to arm64, On-DemandLever: Set Lambda functions to arm64		$44.00	−$10.00
1-year Compute Savings PlanLever: Commit after the move, not before		$40.00	−$4.00

USD, before tax. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 16, 2026, fetched October 16, 2026.

Levers

• Set Lambda functions to arm64
• Commit after the move, not before

The bills line by line, the assumptions and the sources

A Lambda function moved from x86_64 to arm64, before: x86_64, On-Demand Illustrative

The function on x86_64, On-Demand.

Line	A month
Compute	$54.00
Lambda requests, x86: 20 million20 M requests × $0.20 /M req	$4.00
Lambda duration, x86: 20 million × 0.15 s × 1 GB3,000,000 GB-s × $0.0000166667 /GB-s	$50.00
A month, computed	$54.00

A Lambda function moved from x86_64 to arm64, with the levers: arm64, 1-year Compute Savings Plan Illustrative

The same function on arm64, its duration committed for one year, No Upfront, once the move is measured.

Line	A month
Compute	$40.00
Lambda requests, Arm: 20 million20 M requests × $0.20 /M req	$4.00
Lambda duration, Arm, 1-year Compute Savings Plan: 20 million × 0.15 s × 1 GB3,000,000 GB-s × $0.0000120001 /GB-s	$36.00
A month, computed	$40.00

arm64, On-Demand, no commitment: $44.00 a month, 18.5% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 20 million requests a month, each a billed duration of 150 ms at 1,024 MB: 3,000,000 GB-seconds.
• The function runs as fast on arm64 as on x86_64: an assumption to measure, with an alias that splits traffic between the two versions.
• Requests cost the same on both architectures, and the Compute Savings Plan leaves them at their On-Demand rate: only duration changes.

Not counted

• Amazon API Gateway, CloudWatch Logs, data transfer and the free tier.

Sources

• Lambda Developer Guide, "Selecting and configuring an instruction set architecture for your Lambda function"
• Savings Plans User Guide, "Savings Plans types"

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 16, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Pattern 4 of 4 · Illustrative configuration

Containers on ECS with Fargate moved to ARM64

An Amazon ECS service runs 10 Fargate tasks of 1 vCPU and 2 GB around the clock, behind a load balancer (not counted): moved from X86_64 to ARM64 with a multi-architecture image, then committed for three years with a Compute Savings Plan.

Scroll the diagram sideways →

The move makes the bill 20.0% less, the full Fargate gap, since both rates fall by the same share, and pays back a thousand dollars of migration work in 11.6 months; the 3-year plan then makes the moved bill 46.0% less, more than the same plan would take off X86_64, because its Paris rates discount ARM64 more (Savings Plans and Reserved Instances on Graviton).

Before · X86_64, On-Demand$432.16

With the levers · ARM64, 3-year Compute Savings Plan$186.73

• Compute$432.16 → $186.73, too small to draw

Before · X86_64, On-Demand: compute $432.16, total $432.16 a month.

With the levers · ARM64, 3-year Compute Savings Plan: compute $186.73, total $186.73 a month.

With the levers: $245.43 a month less (56.8% less), computed.

Containers on ECS with Fargate moved to ARM64, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
X86_64, On-DemandBefore the levers		$432.16	—
Moved to ARM64, On-DemandLever: Build multi-architecture container images		$345.72	−$86.44
3-year Compute Savings PlanLever: Commit after the move, not before		$186.73	−$158.99

USD, before tax. AWS Price List, eu-west-3, offer files published September 11, 2026 and October 13, 2026, fetched October 16, 2026.

Levers

• Build multi-architecture container images
• Commit after the move, not before

The bills line by line, the assumptions and the sources

Containers on ECS with Fargate moved to ARM64, before: X86_64, On-Demand Illustrative

The service's tasks on X86_64, On-Demand.

Line	A month
Compute	$432.16
Fargate X86_64 vCPU: 10 tasks × 1 vCPU × 730 h7,300 vCPU-h × $0.0486 /vCPU-h	$354.78
Fargate X86_64 memory: 10 tasks × 2 GB × 730 h14,600 GB-h × $0.0053 /GB-h	$77.38
A month, computed	$432.16

Containers on ECS with Fargate moved to ARM64, with the levers: ARM64, 3-year Compute Savings Plan Illustrative

The same tasks on ARM64, committed for three years, No Upfront, once the move is measured.

Line	A month
Compute	$186.73
Fargate ARM64 vCPU, 3-year Compute Savings Plan: 10 tasks × 1 vCPU × 730 h7,300 vCPU-h × $0.021 /vCPU-h	$153.30
Fargate ARM64 memory, 3-year Compute Savings Plan: 10 tasks × 2 GB × 730 h14,600 GB-h × $0.00229 /GB-h	$33.43
A month, computed	$186.73

ARM64, On-Demand, no commitment: $345.72 a month, 20.0% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 10 tasks of 1 vCPU and 2 GB, running all month (730 hours).
• A multi-architecture image in Amazon ECR, built before the move, lets the task definition's CPU architecture change to ARM64 without a second image to maintain.
• The 3-year Compute Savings Plan, No Upfront, is bought after the move, on the ARM64 usage: in Paris its rates take a larger share off ARM64 than off X86_64 (computed).

Not counted

• The Application Load Balancer, Amazon ECR storage, CloudWatch Logs and data transfer.
• The engineering cost of building and testing the multi-architecture image.

Sources

• Amazon ECS Developer Guide, "Amazon ECS task definitions for 64-bit ARM workloads"
• AWS Fargate FAQs
• AWS Savings Plans FAQs

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 11, 2026 and October 13, 2026, fetched October 16, 2026. Illustrative configuration, not a client case.

Across the four, the move alone makes the bill from 4.6% less (RDS) to 20.0% less (Fargate), and a thousand dollars of migration work pays back in 11.6 months on the Fargate service but 100.0 months on the Lambda function, computed. The commitments differ in term, one year on EC2 and Lambda, three on RDS and Fargate, so their results are not compared across the cards.

In short: The move sets a lower rate and the commitment takes its share off that rate: the two compound, and the commitment comes second, so that it covers the Graviton usage.

How to reduce costs with AWS Graviton

Each lever below comes from AWS documentation; their order is this article's. Graviton has nothing to trim: its levers are a migration path, from the moves that cost the least work to those that cost the most, with the commitment last, once the usage it covers runs on Graviton. See the gap, move the managed services, then the functions and the containers, then EC2, measure, keep on x86 what cannot move, and commit to what remains. The levers, in that order:

1. Lever 01,SeeSee the gap, service by serviceAlways, and first
2. Lever 02,SeeSize the opportunity before movingBefore spending engineering time
3. Lever 03,ReshapeMove managed services firstDatabases, caches and search clusters on an Intel class
4. Lever 04,ReshapeSet Lambda functions to arm64Functions whose dependencies have arm64 builds
5. Lever 05,ReshapeBuild multi-architecture container imagesContainers on Amazon ECS and Fargate
6. Lever 06,ReshapeMove EC2 workloads by languageAfter the managed services, functions and containers
7. Lever 07,ReshapeMeasure price-performance on your workloadBefore a commitment, and after each move
8. Lever 08,RouteDecide what stays on x86Windows, and code that cannot move yet
9. Lever 09,CommitCommit after the move, not beforeSteady usage, once the move is measured
10. Lever 10,ReviewReview as new generations shipQuarterly or yearly, by the workload's share of the bill

In short: Move where the work is smallest first, the managed services, the functions and the containers, then EC2 by language; measure each move, keep on x86 what cannot move, and commit last, to the Graviton usage that remains.

FAQ

Is AWS Graviton cheaper than Intel or AMD?

Almost always, by a gap each service sets: in Paris, 19.0% less on EC2 at Graviton3, 20.0% less on Lambda duration and Fargate, 5.3% less on RDS for PostgreSQL at Graviton3, computed. Against AMD the gap is smaller, since AMD already costs less than Intel, and on ElastiCache the Graviton3 and Graviton4 nodes cost more than the newest Intel ones (Is AWS Graviton cheaper?).

What does the g mean in an EC2 instance name?

An AWS Graviton processor: it is the option letter after the generation digit, as in m7g.large, where i means Intel and a means AMD. The A series, A1, is the first generation's (Reading a Graviton instance name).

Will my application run on Graviton without changes?

If it runs on Linux and is written in an interpreted language such as Java, Node or Python, with no native code, AWS says it should run with minimal to no changes on an arm64 AMI. Compiled code is rebuilt for Arm, and Windows does not run on Graviton (What does not fit).

Do Savings Plans and Reserved Instances apply to Graviton?

Yes, as to any usage. In Paris, EC2 Instance Savings Plans, Reserved Instances, Lambda's plan and the Database Savings Plan take the same share off Graviton and x86; a Compute Savings Plan takes less off Graviton's c types and more off Arm on Fargate. Buy them after the move: an EC2 Instance Savings Plan or a reserved DB instance does not follow a change of family or class (Savings Plans and Reserved Instances on Graviton).

Is AWS Graviton available in Paris?

Yes: every service this article prices has a Graviton option in Paris. The Paris price lists of EC2, RDS, Aurora, ElastiCache and OpenSearch Service carry Graviton2 to Graviton4 types; Lambda names Graviton2 and Fargate names no generation. Graviton5 is documented for EC2 and RDS, but the Paris price lists of October 15, 2026 (EC2) and October 6, 2026 (RDS) have no row for it (Five generations).