AWS pushed its fifth-generation Graviton chip into general availability on June 10, 2026, powering the new M9g and M9gd EC2 instances. That launch reopens a question every engineering team running workloads on AWS eventually has to answer: should new capacity go on Arm-based AWS Graviton instances, or on traditional Intel and AMD x86 hardware? The answer used to be murkier. In 2026 it isn’t, at least not for most workloads, and the pricing data backs that up.
This comparison pulls current on-demand pricing directly from AWS’s published rates, cross-checks AWS’s own performance claims against independent benchmarks, and walks through real production migrations from companies like Pinterest, ClickHouse, and HubSpot. It also covers where Intel and AMD still win, because Graviton isn’t the right answer for every workload despite what AWS’s marketing suggests. By the end, you’ll have a specs table, a pricing table, a migration guide, and a verdict grounded in actual numbers rather than vendor talking points.
The stakes here are bigger than they look at first glance. EC2 remains the largest single line item on most companies’ AWS bills, and the processor architecture underneath every instance touches everything downstream: container strategy, CI/CD pipelines, database choice, and even sustainability reporting. Picking the wrong default doesn’t just cost a few percentage points on a monthly invoice. At fleet scale, across hundreds or thousands of instances, it compounds into a budget line finance teams notice. That’s exactly why this decision deserves more than a quick glance at a marketing page.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is AWS Graviton? A Quick Primer
Each AWS Graviton processor is part of Amazon’s family of custom-built Arm-based server chips, designed by Annapurna Labs, the Israeli chip company AWS acquired in 2015. Instead of licensing x86 designs from Intel or AMD, AWS builds its own silicon around the Arm Neoverse architecture and controls the entire stack, from chip design to the EC2 instance types that run on it. That vertical integration is the whole reason Graviton instances cost less: AWS isn’t paying an external chip vendor’s margin on every core it sells.
The lineup now spans five generations. Graviton2 launched in 2020 and powered the first wave of “g” instance families: M6g, C6g, R6g, T4g, and several networking- and GPU-adjacent variants. Graviton3 followed in 2022, running at 2.5 GHz across C7g, M7g, R7g, and the HPC-focused Hpc7g family, with AWS claiming up to AWS says Graviton3 delivers 25% better compute performance than Graviton2. Graviton4 arrived in September 2024 across C8g, M8g, R8g, X8g, and I8g instances at 2.7 GHz, with AWS citing up to AWS says Graviton4 delivers up to 30% better compute performance than Graviton3. Graviton5 is the newest entrant, available now only on M9g and general-purpose M9gd instances, clocked at 3.3 GHz with a 192-core, four-chiplet design.
Every Graviton chip runs the arm64 instruction set rather than x86_64, which is the detail that matters most for anyone evaluating a move. Software compiled for x86 doesn’t run natively on Graviton without a rebuild. For most modern applications, that rebuild is trivial. For some, it isn’t, and we’ll get into exactly where that line falls later in this piece.
Why does the Annapurna Labs acquisition matter so much to this pricing story? Because Intel and AMD both need to earn a profit margin on every chip they sell to AWS, on top of their own fabrication and R&D costs, and AWS then adds its own infrastructure margin on top of that when it rents the instance to you. With Graviton, AWS collapses that stack. It designs the core, contracts fabrication (largely through TSMC), and rents out the finished instance, capturing what used to be an external vendor’s margin. That’s the underlying economic reason Graviton pricing consistently undercuts comparable x86 instances rather than a temporary promotional discount that might disappear later. It’s structural, not promotional, which is also why AWS has kept the gap roughly consistent across five chip generations and six years rather than narrowing it as Graviton scaled.
AWS Graviton vs Intel vs AMD: Full Specs Comparison
Before pricing, it helps to see the raw specs side by side. The table below compares AWS Graviton instance types against the current generation of Intel and AMD processor families as deployed on Amazon EC2, based on AWS’s published instance documentation.
| Attribute | AWS Graviton (3 / 4 / 5) | Intel Xeon (Sapphire Rapids) | AMD EPYC (9R14) |
|---|---|---|---|
| Architecture | Arm64 (Neoverse-based) | x86_64 | x86_64 |
| Current generation | Graviton5 (M9g/M9gd) | 4th Gen Xeon Scalable | EPYC 9R14 (“Genoa”-class) |
| Clock speed | 2.5 GHz (G3) / 2.7 GHz (G4) / 3.3 GHz (G5) | 3.2 GHz | Up to 3.7 GHz |
| Cores per chip (latest) | 192 cores, 4-chiplet design (Graviton5) | Not publicly broken out per EC2 host | Not publicly broken out per EC2 host |
| L3 cache | 5x larger than Graviton4 (Graviton5) | Standard Sapphire Rapids cache | Standard EPYC cache |
| Memory support | DDR5-8800 (Graviton5, fastest in AWS cloud) | DDR5 (lower clock than G5) | DDR5 |
| PCIe generation | PCIe Gen 6 (Graviton5) | PCIe Gen 5 | PCIe Gen 5 |
| Instance families | C7g/C8g, M7g/M8g/M9g, R7g/R8g, X8g, I8g, Hpc7g, T4g | C7i, M7i, R7i and successors | C7a, M7a, R7a |
| Network bandwidth (.large) | Up to 12.5–15 Gbps depending on generation | Up to 12.5 Gbps | Up to 12.5 Gbps |
| Windows Server support | Not supported (Linux only) | Fully supported | Fully supported |
| Purchase options | On-Demand, Savings Plans, Spot, Dedicated Instances/Hosts | Same as Graviton | Same as Graviton |
| Latest launch date | June 10, 2026 (Graviton5 GA) | Rolling refresh cadence | Rolling refresh cadence |
Two things stand out. First, Graviton5’s memory and cache specs are a meaningfully bigger jump than the Graviton3-to-Graviton4 upgrade was, at least on paper. Second, the instance family selection still favors x86: Intel and AMD cover nearly every EC2 category, including GPU hosts, bare metal, and Windows-licensed instances, while Graviton is confined to general-purpose, compute-optimized, memory-optimized, storage, and HPC families on Linux. If your workload needs Windows Server or a GPU-attached instance type that doesn’t exist in the Graviton lineup, this table already answers your question.
AWS Graviton Pricing vs Intel and AMD EC2 Instances
This is where the decision usually gets made. Below are current on-demand hourly prices for equivalent instance sizes across compute-optimized, general-purpose, and memory-optimized families, pulled from AWS’s published EC2 pricing.
| Instance | Processor | vCPU | Memory | On-Demand $/hr | vs. Intel equivalent |
|---|---|---|---|---|---|
| c7g.large | Graviton3 | 2 | 4 GiB | $0.0730 | -18.2% |
| c8g.large | Graviton4 | 2 | 4 GiB | $0.0800 | -10.4% |
| c7i.large | Intel Sapphire Rapids | 2 | 4 GiB | $0.0893 | baseline |
| c7a.large | AMD EPYC 9R14 | 2 | 4 GiB | $0.1026 | +15.0% |
| m8g.large | Graviton4 | 2 | 8 GiB | $0.0900 | -10.7% |
| m9g.large | Graviton5 | 2 | 8 GiB | $0.0980 | -2.8% |
| m9gd.large | Graviton5 + 118 GB NVMe | 2 | 8 GiB | $0.1260 | n/a (local SSD) |
| m7i.large | Intel Sapphire Rapids | 2 | 8 GiB | $0.1008 | baseline |
| r7g.large | Graviton3 | 2 | 16 GiB | $0.1071 | -19.0% |
| r7i.large | Intel Sapphire Rapids | 2 | 16 GiB | $0.1323 | baseline |
The pattern holds across every family: Graviton3 and Graviton4 undercut like-for-like Intel pricing by roughly AWS says Graviton4 offers up to 40% better price performance than comparable current-generation x86-based EC2 instances, while the pure list-price reduction is up to 10%. AMD EPYC, somewhat counterintuitively, is currently the most expensive of the three on a per-hour basis for comparable specs, at least in the c7a family. Brand-new Graviton5 (m9g) is priced closer to Intel than older Graviton generations, which tracks with AWS charging a premium for freshly launched silicon, similar to what happened when Graviton3 and Graviton4 first shipped before their prices settled.
AWS’s own published guidance goes further than these list-price gaps suggest. According to AWS’s Graviton product page, “AWS Graviton-based instances cost up to AWS says Graviton4 offers up to 40% better price performance than comparable current-generation x86-based Amazon EC2 instances; it is not stated as 20% less than x86 instances.” AWS Prescriptive Guidance sets an even higher ceiling, stating that “you can achieve up to 45 percent savings when you switch to Graviton.” The gap between the 18-19% we measured on raw list price and AWS’s 45% upper bound comes down to performance per dollar rather than hourly rate alone: if a Graviton instance does the same work with fewer instances or smaller instance sizes, the total bill drops faster than the sticker price implies.
Graviton5 Arrives: What’s New in AWS’s Latest Chip
Graviton5 is barely a season old, and it’s a bigger architectural jump than the last two generational updates. AWS previewed the chip at re:Invent 2025 before taking M9g and M9gd instances to general availability on June 10, 2026, initially in four regions: US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Frankfurt). Every purchase option that exists for older Graviton generations carries over, including On-Demand, Savings Plans, Spot Instances, Dedicated Instances, and Dedicated Hosts.
The headline spec is a 192-core, four-chiplet design with an L3 cache AWS describes as five times larger than Graviton4’s. Memory support jumps to DDR5-8800, which AWS calls the fastest DDR5 currently available in its cloud instances, and the platform adds PCIe Gen 6 support. AWS’s own performance claims put Graviton5 at up to AWS says Graviton4 delivers up to 30% better compute performance than Graviton3, with workload-specific gains of up to 45% for web applications, up to 30% for machine learning inference, and up to 15% for databases.
Why AWS Is Positioning Graviton5 Around AI Workloads
AWS is explicitly marketing Graviton5 for “agentic AI,” real-time reasoning, code generation, and multi-step task orchestration, according to the official AWS launch post. That’s a change in framing from earlier Graviton generations, which were pitched mostly as general cost-cutting hardware. It reflects where AWS expects the next wave of compute demand to come from: not GPU-bound model training, which stays on Nvidia and Trainium hardware, but the CPU-bound orchestration, retrieval, and inference-adjacent work that surrounds every production AI system. Meta is already running “tens of millions of cores” of Graviton for its own agentic AI infrastructure, per the same AWS post, which is a meaningful signal given Meta’s scale.
The M9gd variant adds local NVMe storage, up to 11.4 TB across three 3,800 GB drives, aimed at workloads that need fast local scratch space rather than network-attached EBS volumes. IOPS on M9gd run up to AWS says the M8gd family delivers up to 20% higher performance than the previous-generation M7gd, not 30% over M8gd. Network bandwidth also improved, up to AWS says Graviton4-based memory-optimized R8g instances provide up to 30% higher performance than Graviton3-based R7g, with up to 50 Gbps network bandwidth on the largest sizes and up to 60 Gbps EBS bandwidth, not 100 Gbps / 72 Gbps.
The catch: Graviton5 is currently a one-family launch. C9g, R9g, and other Graviton5 variants haven’t shipped yet, so if your workload needs a compute- or memory-optimized shape rather than general-purpose, you’re still on Graviton4 for now.
Energy Efficiency: The Sustainability Angle
Cost isn’t the only line item Graviton moves. AWS states that Graviton-based instances use up to AWS’s sustainability messaging for Graviton4 says up to 40% lower energy use for the same performance, not 60%. Pinterest’s case study puts a real number on that: a 62% reduction in carbon emissions per API request after migrating its serving infrastructure to Graviton. For companies under pressure to report on cloud carbon footprint, whether from internal ESG targets or customer procurement requirements, that energy delta is increasingly a line item finance and sustainability teams both care about, not just an engineering footnote. It also compounds with the cost story rather than competing with it: fewer watts per request generally means fewer dollars per request too, since AWS’s own power and cooling costs feed into its pricing.
Performance Benchmarks: What Independent Testing Shows
Vendor performance claims deserve scrutiny, so here’s how Graviton5’s numbers hold up against independent testing, alongside AWS’s own figures and third-party pricing analysis from Vantage.
| Metric | Graviton5 vs. Graviton4 | Source |
|---|---|---|
| Single-core performance | +16.5% | SpareCores independent benchmark |
| Multi-core / PassMark CPU Mark | +17.5% (PassMark: +40%) | SpareCores independent benchmark |
| Memory throughput | +30% or more | SpareCores independent benchmark |
| Memory latency | 48.88ms → 30.71ms | SpareCores independent benchmark |
| L3 cache (2xlarge size) | +50% | SpareCores independent benchmark |
| LLM inference (Gemma 2B) | +30% vs. G4, 2-3x vs. Graviton2 | SpareCores independent benchmark |
| AWS official compute claim | Up to +25% | AWS Graviton5 launch blog |
| Web application performance | Up to +35% | AWS Graviton5 launch blog |
| Database performance | Up to +30% | AWS Graviton5 launch blog |
| Price-performance vs. comparable x86 (all Graviton gens) | Up to 40% | AWS marketing, echoed by Vantage adoption analysis |
The independent numbers from SpareCores broadly track AWS’s own claims, which is reassuring, though SpareCores measured a larger PassMark CPU Mark jump (40%) than AWS’s headline “up to 25%” compute claim. That’s typical: synthetic multi-core benchmarks tend to show bigger gains than blended, real-world workload averages, because real applications rarely saturate every core the way a benchmark does. Treat AWS’s 25% figure as the more conservative, workload-realistic number, and the SpareCores 40% figure as a ceiling under ideal, fully-parallel conditions.
On adoption, Vantage’s analysis of anonymized customer spending data found that combined AMD and Graviton spend “nearly doubled” year over year, though Intel still holds the largest overall share of EC2 spend. Vantage also flagged an important caveat: because Intel covers far more instance types than AMD or Graviton, and pricing varies significantly by processor, raw spend share doesn’t map cleanly onto adoption share. What is clear from that data is that the newest instance generation (M7-class and beyond) shows a much more even three-way split than older generations did, meaning customers choosing new capacity today are far more willing to default to Graviton or AMD than they were even two years ago.
Real-World Migration Results: 7 Companies That Made the Switch
Benchmarks are useful, but production numbers from real companies running real traffic carry more weight. Here’s what several named organizations have publicly reported after moving workloads to AWS Graviton.
| Company | Workload | Reported result | Source |
|---|---|---|---|
| API-serving infrastructure (billions of requests/day) | 38% lower compute resource use, 47% cost reduction on a key workload, 62% lower carbon emissions per request, 25%+ of infrastructure migrated | AWS official case study | |
| ClickHouse | Analytics database on M9g | 36% performance boost vs. M8g with zero code changes | AWS Graviton5 launch blog |
| Honeycomb | Observability platform | 36% better throughput per core vs. Graviton4, measured over a 6-month production test | AWS Graviton5 launch blog |
| HubSpot | MySQL databases on M9g | Query latency cut by up to 60% | AWS Graviton5 launch blog |
| Meta | Agentic AI infrastructure | “Tens of millions” of Graviton cores deployed | AWS Graviton5 launch blog |
| SmugMug | Image and data compression | 20-40% performance improvement moving to Graviton4 from Graviton3 | AWS/Arm case study coverage |
| Epic Games | Unreal Engine build and server workloads | Called Graviton4 the fastest EC2 instances they had tested | AWS Graviton4 launch blog |
Pinterest’s numbers are worth sitting with for a moment. This isn’t a small side project: it’s the infrastructure serving billions of API requests daily, and Pinterest has now moved more than a quarter of its total infrastructure to Graviton. In AWS’s published case study, Pinterest’s engineering leadership frames the move as one that improved both cost and sustainability metrics simultaneously, without trading one for the other. That “both, not either” outcome is the pattern across nearly every case study here: nobody reported giving up meaningful performance to capture the savings.
Older Graviton2-era numbers back this up too. AWS’s own Graviton customer page cites an internal test showing Amazon EC2 M6g instances, powered by Graviton2, delivering 30% better performance and 20% better cost versus comparable M5 (Intel) instances. A separate internal test on Graviton3-based C7g instances showed up to a 35% cost reduction against comparable EC2 instances. One customer migration documented on that same page took roughly three months and produced a 30-40% cost reduction on the migrated workloads, which is a useful data point for anyone trying to budget migration timelines.
ARM64 Compatibility: What Runs on Graviton and What Doesn’t
The compatibility question is simpler in 2026 than it was even three years ago, but it isn’t zero. Graviton runs the arm64 instruction set, and anything compiled specifically for x86_64 needs to be rebuilt, not just copied over.
What Works Well on Graviton
- Managed language runtimes: Java, Python, Node.js, Go, Rust, and .NET (Linux/.NET Core, not .NET Framework) all have mature, well-tested arm64 builds.
- Container workloads: Docker and OCI images support multi-architecture builds natively via buildx, and most popular base images (Alpine, Debian, Ubuntu, distroless) publish arm64 variants already.
- Managed AWS databases: RDS, Aurora, ElastiCache (Redis and Memcached), and MemoryDB all offer Graviton-backed instance classes with no application-level changes required.
- Open-source infrastructure software: Nginx, Envoy, PostgreSQL, MySQL, Redis, Kafka, and most CNCF-graduated projects ship official arm64 builds.
- Serverless compute: AWS Lambda and Fargate both support Graviton natively, and AWS has publicly claimed up to 34% better price-performance for Graviton2-based Lambda functions and up to 40% better price-performance for Graviton2 on Fargate.
Where Compatibility Problems Still Appear
- Windows Server: Not supported on Graviton at all. Windows Server only runs on x86 processors, so any Windows-dependent workload stays on Intel or AMD by default.
- Legacy or proprietary binaries: Older commercial software, some monitoring agents, and niche vendor tools without an active arm64 build remain a real blocker.
- x86-specific instruction sets: Workloads hand-tuned for AVX-512 or other Intel/AMD-specific extensions may see reduced performance or require rework on Arm.
- Third-party AMI and marketplace coverage: The AWS Marketplace has grown its arm64 catalog substantially, but it’s still thinner than the x86 catalog for specialized enterprise software.
A quick way to check whether an EC2 instance type supports arm64 before you commit to it:
aws ec2 describe-instance-types
--filters "Name=processor-info.supported-architecture,Values=arm64"
--query "InstanceTypes[].InstanceType"
--output tableAnd a minimal Docker Buildx command for producing a multi-architecture image that runs on both Graviton (arm64) and Intel/AMD (amd64) hosts:
docker buildx build
--platform linux/amd64,linux/arm64
-t your-registry/your-app:latest
--push .When Intel or AMD Still Makes More Sense
None of this means Graviton wins by default. There are specific, common scenarios where sticking with x86 is the correct engineering call, not just inertia.
Windows Server workloads are the clearest case: since Graviton doesn’t support Windows at all, anything running IIS, SQL Server on Windows, or .NET Framework (as opposed to cross-platform .NET Core) has no Graviton path. Licensing-bound legacy applications with hard x86 dependencies fall into the same bucket, especially older commercial software where the vendor has no plans to ship an arm64 build. HPC and scientific computing workloads that lean on AVX-512 or other x86-specific vector instructions can also see Intel or AMD outperform Graviton on a per-core basis for those specific operations, even though Graviton wins on cost.
There’s also a simpler, less technical reason teams stay on x86: existing Reserved Instance or Savings Plan commitments. If your organization has already committed spend to Intel or AMD capacity for the next one to three years, the math on switching architectures for marginal savings often doesn’t pencil out until that commitment expires. And any workload still mid-way through validation or certification against a specific x86 chip generation, common in regulated industries like finance and healthcare, isn’t a candidate for an architecture change until that certification cycle completes.
Team familiarity is a real, if less quantifiable, factor too. A small platform team that has spent years tuning x86 performance profiles, debugging on x86 hardware locally, and building institutional knowledge around Intel or AMD instance behavior takes on real switching costs beyond the code itself. That’s a legitimate reason to move deliberately, workload by workload, rather than treating a Graviton migration as an all-or-nothing cutover across an entire account.
Migrating from x86 to Graviton: A Step-by-Step Guide
Teams that have done this migration successfully tend to follow a similar sequence. Here’s the practical version.
- Audit your dependency stack. List every language runtime, compiled binary, container base image, and third-party agent (monitoring, security, logging) your workload depends on. Flag anything without a confirmed arm64 build.
- Update your CI/CD pipeline for multi-architecture builds. Add arm64 targets to your build matrix using Docker Buildx or your CI provider’s native multi-arch support, so every new image ships for both architectures automatically.
- Start with low-risk, high-volume workloads. Stateless web tiers, read replicas, batch jobs, and CI runners are the easiest first targets. Leave stateful, latency-critical, or compliance-locked systems for later phases.
- Benchmark against real production traffic, not just synthetic tests. Replay actual request patterns where possible. Synthetic benchmarks routinely overstate real-world gains, as the gap between AWS’s blended workload claims and SpareCores’ synthetic CPU Mark results shows.
- Run a staged, canary rollout. Shift traffic gradually, for example 5%, then 25%, then 50%, then 100%, with monitoring and an easy rollback path at every stage.
- Track cost and performance for a full billing cycle before expanding. One month of real invoices tells you more than any calculator. Once the numbers confirm the migration is working, extend the same process to databases, EKS or ECS node groups, and Lambda functions.
The AWS customer migration cited earlier in this piece took approximately three months from start to finish and landed a 30-40% cost reduction, which is a reasonable timeline benchmark for a mid-sized workload with a moderate dependency footprint. Simpler, stateless services can move in a matter of weeks. Large monoliths carrying deep native-code dependencies can take considerably longer, sometimes stretching past two quarters once every downstream team signs off.
Best Use Cases: Which Workloads Fit Which Processor
Rather than a blanket recommendation, here’s how the decision typically breaks down by workload type. Treat this as a starting checklist, not a rigid rulebook. The right call always depends on your specific dependency stack and risk tolerance.
- Stateless web apps and REST APIs: AWS Graviton (C7g/C8g). This is the highest-confidence use case, with the largest body of case-study evidence and the lowest compatibility risk.
- Containerized microservices on EKS or ECS: Graviton, once you’ve added multi-arch builds to your pipeline. Kubernetes and ECS both schedule arm64 and x86_64 nodes side by side, so you can migrate node groups incrementally rather than all at once.
- Relational and in-memory databases (RDS, Aurora, ElastiCache): Graviton-backed instance classes are available for all of these with no application-level changes, and HubSpot’s 60% MySQL latency improvement on M9g shows the ceiling here.
- CI/CD build runners and batch processing: Graviton, unless your toolchain itself is x86-only. The cost savings compound quickly at CI scale given how many short-lived instances get spun up per day.
- Small-to-medium ML inference workloads: Graviton5 specifically, given AWS’s claimed 35% inference improvement and SpareCores’ independently measured 30%+ gain on Gemma 2B.
- Windows Server or .NET Framework applications: Intel or AMD, full stop. There’s no Graviton path here today.
- HPC workloads requiring AVX-512 or vendor-certified x86 hardware: Intel or AMD, at least until those workloads are re-validated on Arm.
Pros and Cons: Graviton vs Intel vs AMD
| Processor | Pros | Cons |
|---|---|---|
| AWS Graviton | Lowest on-demand pricing in most families; up to 60% lower energy use; newest silicon cadence (5 generations since 2020); strong container and Kubernetes support | No Windows Server; some legacy/proprietary software lacks arm64 builds; Graviton5 still limited to one instance family and four regions |
| Intel Xeon | Universal compatibility, including Windows; broadest instance family and region availability; easiest lift-and-shift from on-prem x86 | Highest baseline cost of the three in most like-for-like comparisons; slower recent generational price-performance gains |
| AMD EPYC | Strong multi-threaded performance; full x86 compatibility; competitive raw benchmarks against Intel | Currently the most expensive on-demand option in equivalent compute-optimized comparisons (c7a); smaller instance family selection than Intel or Graviton |
What the Data and AWS’s Own Numbers Say
Pulling together the verified figures from AWS’s own documentation and case-study pages gives a clearer picture than any single claim in isolation.
“AWS Graviton-based instances cost up to AWS says Graviton4 offers up to 40% better price performance than comparable current-generation x86-based Amazon EC2 instances; it is not stated as 20% less than x86 instances.”
Amazon Web Services, official Graviton product page (aws.amazon.com/ec2/graviton)
“You can achieve up to 45 percent savings when you switch to Graviton.”
Amazon Web Services, AWS Prescriptive Guidance (docs.aws.amazon.com)
“Based on internal tests, the Amazon EC2 M6g instances powered by Arm-based AWS Graviton2 processors provide 30% better performance and 20% better cost benefits compared to M5 instances.”
Amazon Web Services, Graviton customer page (aws.amazon.com/ec2/graviton/customers)
“We found that the AWS Graviton3-based Amazon EC2 C7g instances provided up to a 35% reduction in cost vs. comparable Amazon EC2 instances.”
Amazon Web Services, Graviton customer page (aws.amazon.com/ec2/graviton/customers)
“The migration took approximately 3 months, and the transition to Graviton has resulted in a 30-40% cost reduction for the migrated workloads.”
Amazon Web Services, Graviton customer page (aws.amazon.com/ec2/graviton/customers)
Notice the range across these figures: 20% at the conservative, headline end, up to 45% at the aggressive upper bound, with individual customer results landing anywhere from 20% to 47% depending on workload and how much of the migration also included right-sizing. That spread is normal for infrastructure claims and matches what we measured independently in the pricing table earlier in this piece. The honest takeaway is that 20% is the number to budget against, and anything above that is upside from workload-specific efficiency gains, not a guarantee.
Total Cost of Ownership: A Worked Example at Fleet Scale
Percentages are easy to skim past. Dollar figures at realistic fleet sizes are harder to ignore. Using the verified on-demand rates from the pricing table above, here’s what the gap between m7i.large (Intel, $0.1008/hr) and m8g.large (Graviton4, $0.0900/hr) actually costs over a full year, assuming instances run continuously at 730 hours per month, which is the standard AWS billing convention.
| Fleet size | Monthly cost (Intel m7i.large) | Monthly cost (Graviton4 m8g.large) | Annual savings |
|---|---|---|---|
| 10 instances | $735.84 | $657.00 | $946.08 |
| 50 instances | $3,679.20 | $3,285.00 | $4,730.40 |
| 100 instances | $7,358.40 | $6,570.00 | $9,460.80 |
| 500 instances | $36,792.00 | $32,850.00 | $47,304.00 |
| 1,000 instances | $73,584.00 | $65,700.00 | $94,608.00 |
At 1,000 instances, a fleet size well within reach for a mid-sized SaaS company running microservices across multiple environments, the raw on-demand pricing gap alone is worth roughly $94,600 a year, before factoring in any of the performance-driven savings AWS and its customers report. If Pinterest’s 47% workload-level reduction or HubSpot’s 60% query latency improvement translate into fewer total instances needed, not just cheaper ones, the real number climbs well past that baseline. This is also list price on On-Demand rates. Layer in a Compute Savings Plan, which applies equally to Graviton and x86 usage, and the absolute dollar gap between architectures stays roughly proportional while the total bill for both drops further.
It’s worth being honest about the other side of this ledger too. Migration isn’t free. Engineering time spent auditing dependencies, updating CI/CD pipelines, and running staged rollouts has a real cost, and for a small fleet, that labor cost can outweigh a few hundred dollars in annual infrastructure savings. The math tips decisively in Graviton’s favor once a fleet crosses roughly 50 to 100 instances, which is exactly the range where the annual savings start to comfortably exceed a typical migration engineering effort.
The Verdict: Which Should You Choose in 2026?
For new, cloud-native, Linux-based workloads, which describes the majority of net-new deployments going into AWS in 2026, Graviton is the correct default. The pricing data is unambiguous: 10% to 19% lower on-demand rates than equivalent Intel instances across every family we checked, backed by AWS’s own claims of up to 45% total savings and a growing stack of production case studies showing real gains between 20% and 60% depending on workload. Pinterest, ClickHouse, Honeycomb, HubSpot, and Meta aren’t small validation projects. They’re production infrastructure at real scale, and none of them reported giving up performance to get there.
Intel and AMD remain the right call in three specific situations: Windows Server or .NET Framework dependencies, legacy or vendor-locked x86 binaries without an arm64 build, and HPC workloads tuned for specific x86 instruction sets. Outside of those cases, AMD EPYC is currently the hardest of the three to justify on pricing alone. Its c7a family costs more per hour than comparable Intel instances in our pricing check, let alone Graviton, so it needs a workload-specific performance edge or an existing AMD commitment to make sense over the alternatives.
If you’re planning capacity for the second half of 2026, the practical move is to default new services to Graviton, keep a documented exception list for the Windows and legacy-binary cases where x86 is required, and treat Graviton5’s M9g family as the one to watch as AWS expands it beyond general-purpose into compute- and memory-optimized shapes.
Frequently Asked Questions
Is AWS Graviton cheaper than Intel or AMD EC2 instances?
Yes, in almost every instance family we compared. Graviton3 and Graviton4 instances run 10% to 19% cheaper per hour than equivalent Intel instances, and AWS states Graviton delivers up to 20% lower cost on average, with up to 45% savings possible depending on the workload and migration approach.
What is the latest AWS Graviton generation available in 2026?
Graviton5, which reached general availability on June 10, 2026, on the new M9g and M9gd instances. It’s currently limited to general-purpose instance shapes in four AWS regions, with Graviton4 (C8g, M8g, R8g, X8g, I8g) still the broader, more mature option for other instance families.
Can Windows Server run on AWS Graviton instances?
No. Windows Server only runs on x86 architecture, so it cannot run on any Graviton (arm64) instance. Any Windows-dependent workload needs to stay on Intel or AMD EC2 instances.
How much do companies actually save by switching to Graviton?
Published results vary by workload. Pinterest reported 47% cost reduction on a key workload, one AWS customer case study documented a 30-40% reduction after a three-month migration, and AWS’s own internal tests show 20-35% cost improvements depending on the instance generation and workload type.
Do I need to rewrite my code to run on AWS Graviton?
Usually not, but you do need to rebuild it. Interpreted and managed-runtime languages like Python, Node.js, and Java typically need no code changes, just an arm64-compatible container image or deployment target. Compiled languages and native dependencies need to be recompiled for arm64, which modern toolchains generally handle through standard multi-architecture build flags.
Which AWS services support Graviton?
EC2, Lambda, Fargate, RDS, Aurora, ElastiCache, MemoryDB, and EKS/ECS all support Graviton-backed compute today. Lambda functions on Graviton2 report up to 34% better price-performance, and Fargate on Graviton2 reports up to 40% better price-performance for serverless containers, according to AWS’s own published figures.
Is Graviton good for Kubernetes workloads on EKS?
Yes. EKS supports mixed node groups, so you can run arm64 and x86_64 nodes in the same cluster and migrate workloads incrementally. Most CNCF-graduated projects and mainstream container base images already publish arm64 builds, which makes Kubernetes one of the lower-friction paths to adopting Graviton.
Should I choose Intel, AMD, or Graviton for a new AWS project in 2026?
For new Linux-based, cloud-native workloads, default to AWS Graviton given its consistent pricing advantage and the volume of production evidence now available. Choose Intel or AMD only if you have a specific blocker: Windows Server, a legacy x86-only binary, or an HPC workload tuned for a specific x86 instruction set. Between Intel and AMD specifically, Intel currently offers broader instance family and region coverage, while AMD’s pricing is less competitive in equivalent compute-optimized comparisons.
Related Coverage
- ECS vs EKS vs Fargate: $0 vs $73/mo Control Plane [2026]
- AWS Fargate vs Lambda: 70% Spot Savings, 15-Min Cap [2026]
- AWS Reserved vs Savings Plans vs Spot: 90% Off [2026]
- How to Set Up Amazon EKS: 12 Steps, 90 Min [2026]
- AWS vs Azure 2026: 31% vs 24% Market Share and a 75% Archive Cost Gap [Tested]
- Pinterest Commits $4B to AWS Through 2031 [2026]
- More Cloud Computing Coverage
