Home/Library/Graviton4 C8g, M8g, R8g Compared
Comparison · AWS Cost Optimization · Updated June 2026

AWS Graviton4 Instances: C8g, M8g, and R8g Cost Compared

The three Graviton4 families differ by the resource they pack the most of: C8g leans compute, M8g balances, and R8g leans memory. Pick by your workload's bottleneck, not by the lowest hourly rate, because the cheapest cost per hour is rarely the cheapest cost per unit of work.

Key takeaways

AWS Graviton4 ships in three Amazon EC2 families: C8g for compute-bound work, M8g for balanced general-purpose services, and R8g for memory-bound work. Choose the family whose vCPU-to-memory ratio matches your bottleneck, then size to real utilization. Graviton4 delivers up to 30 percent better performance and up to roughly 29 percent better price-performance than Graviton3, and Savings Plans apply on top. The order that saves the most: migrate to Graviton, right-size on the new baseline, then commit. Committing first locks in the wrong family.

Last updated: June 2026 · Written by Morten Andersen and reviewed by Fredrik Filipsson · See, Cut, Lock, Run method

AWS Graviton4 is Amazon's fourth-generation Arm-based processor, and it powers three eighth-generation Amazon EC2 instance families that share a CPU but differ in how much memory rides alongside each vCPU. C8g is the compute-optimized family with the least memory per core, M8g is the general-purpose family with a balanced ratio, and R8g is the memory-optimized family with the most memory per core. The cost decision is not which family is cheapest per hour, but which family lets your specific workload finish its work on the fewest, smallest instances. This article is part of our complete guide to AWS cost optimization, the cluster pillar it links up to.

What is the difference between C8g, M8g, and R8g?

The three Graviton4 families are the same processor with three different memory ratios. C8g, M8g, and R8g all run on the Graviton4 CPU; what changes is the gigabytes of RAM attached to each vCPU, which is what makes one family cheaper than another for a given job. C8g carries roughly 2 GB of memory per vCPU and suits compute-bound work. M8g carries roughly 4 GB per vCPU and suits balanced services. R8g carries roughly 8 GB per vCPU and suits memory-bound work. AWS reports that all three offer up to 30 percent better performance and up to 3x more vCPUs and memory at the top end than the equivalent Graviton3 families (C7g, M7g, R7g). Confirm the exact vCPU and memory specs and current on-demand rates for your Region against the C8g, M8g, and R8g pages, since pricing varies by Region and changes over time.

FamilyMemory per vCPUBest forChoose when the bottleneck is
C8g (compute)~2 GBBatch, media encoding, HPC, ad serving, gamingCPU, with modest memory needs
M8g (general purpose)~4 GBWeb and app tiers, microservices, small databasesA balanced mix of CPU and memory
R8g (memory)~8 GBIn-memory caches, large relational and NoSQL databases, real-time analyticsRAM, with CPU to spare

The verdict: pick the family whose memory ratio matches your workload, because paying for memory a compute job never touches, or starving a memory job until it spills, both waste money. The right family lets the same work run on fewer or smaller instances.

How much do Graviton4 instances save versus Intel and AMD?

The saving comes from price-performance, not a lower sticker price alone. Graviton4 instances are typically priced below comparable current-generation Intel and AMD instances and do more work per vCPU, so the cost per request or per completed job is usually lower even where the hourly rate looks similar. AWS positions Graviton broadly as delivering up to 40 percent better price-performance than comparable x86 instances for scalable workloads, and Graviton4 specifically as up to roughly 29 percent better price-performance than Graviton3. Treat these as directional. The number that decides your bill is your own cost per unit of work, measured by running a representative load on both architectures and comparing the total instance hours each needed. For the broader commitment picture, see our AWS Savings Plans vs Reserved Instances comparison.

Sequence matters

Migrate to Graviton first, right-size on the new and faster baseline, then buy a Savings Plan against that clean number. Commit before you migrate and you lock a discount to instances you are about to replace.

When should I migrate to Graviton4, and when should I wait?

Migrate when your workload runs on open-source runtimes or interpreted languages, where Arm support is mature and the move is often a rebuild rather than a rewrite. Java, Go, Python, Node.js, Rust, .NET, PHP, and most container images already run cleanly on Arm, and managed services such as Amazon RDS, ElastiCache, and OpenSearch offer Graviton options you can switch with a configuration change. Wait, or test carefully, when you depend on x86-only binaries, proprietary agents without Arm builds, or third-party software your vendor has not certified on Arm. The migration mechanics are covered in how to migrate EC2 workloads to Graviton without code changes, the sibling guide in this cluster. The cost case is strongest for steady, scalable fleets where a few percent of price-performance compounds across many instances every hour.

Not sure which Graviton4 family fits your fleet?

Our AWS cost audit benchmarks your workloads on C8g, M8g, and R8g, sizes each service to real utilization, then proves the saving against a clean baseline before any commitment. On the performance model, you pay only from realized savings. No savings, no fee.

Book a cloud cost audit →

How do I keep Graviton4 instances right-sized after migrating?

Right-sizing after a Graviton move matters more than usual because the faster cores often mean the old instance count is now oversized. Because Graviton4 finishes the same work faster, a fleet sized for x86 throughput frequently has headroom to shrink, so re-measure CPU and memory utilization after the cutover rather than carrying the old sizing across. Use AWS Compute Optimizer, which now recommends Graviton instance types, to surface the candidates; the organization-wide approach is covered in our AWS cost optimization service. Then, once the new baseline is stable for a week or two, commit the steady portion with a Savings Plan and leave the variable portion on demand.

Go deeper · free field guide

The AWS Cost Optimization Field Guide includes the Graviton migration and right-sizing checklist we run before recommending any commitment, so the discount lands on the fleet you actually keep.

Frequently asked questions

Are C8g, M8g, and R8g cheaper than Intel and AMD instances?

On price-performance, yes for most scalable workloads. Graviton4 instances are typically priced below comparable Intel and AMD instances and do more work per vCPU, so the effective cost per unit of work is usually lower. The on-demand hourly rate alone is not the comparison that matters; cost per request or per job is.

How much better is Graviton4 than Graviton3?

AWS reports Graviton4 delivers up to 30 percent better compute performance than Graviton3, with up to 40 percent faster databases and up to 45 percent faster large Java applications, and up to about 29 percent better price-performance. Actual gains depend on the workload, so benchmark your own.

Which Graviton4 family should I choose?

Match the family to the bottleneck. Choose C8g for compute-bound work such as batch, media encoding, and HPC, M8g for balanced general-purpose services like web and app tiers, and R8g for memory-bound work such as in-memory caches, large databases, and analytics.

Do Savings Plans apply to Graviton4 instances?

Yes. Compute Savings Plans and EC2 Instance Savings Plans both apply to Graviton4 instances, so you can stack the architectural saving from Graviton on top of the commitment discount once your baseline is stable. See our explainer on AWS Savings Plans for Lambda and Fargate for how the same plans extend beyond EC2.

The short version

C8g, M8g, and R8g are one Graviton4 processor in three memory ratios: compute, balanced, and memory. Choose the family that matches your workload's bottleneck, size to real utilization after migrating, and only then buy a Savings Plan against the clean baseline. Graviton4 buys up to roughly 29 percent better price-performance than Graviton3 and meaningful gains over comparable x86, but the saving is only real if the family fits and the fleet is right-sized. When you want each workload matched to the right family and the AWS bill proven down, that is the work our AWS cost optimization service delivers.

Primary sources & further reading

Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, AWS documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.

Written by Morten Andersen

Co-founder of Cloud Cost Room and a FinOps Certified Practitioner, with 20 years in IT and cloud cost optimization across AWS, Azure, Google Cloud and OCI. More about Morten →

More from the AWS Cost Optimization cluster

See every guide in the AWS Cost Optimization cluster →

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only