---
title: ElastiCache Graviton4 (M8g, R8g, C8gn): When to Leave m7g/r7g — and When to Wait
description: On Aug 6, 2026 ElastiCache added Graviton4 M8g/R8g/C8gn for Valkey and Memcached — up to 47% higher throughput, 43% lower P99, 31% better price-performance vs Graviton3. Field guide: family pick, RI traps, canary checklist.
url: https://www.factualminds.com/blog/amazon-elasticache-graviton4-m8g-r8g-c8gn-2026/
datePublished: 2026-08-07T00:00:00.000Z
dateModified: 2026-08-07T00:00:00.000Z
author: palaniappan-p
category: Cost Optimization & FinOps
tags: aws-elasticache, valkey, graviton, cost-optimization, performance
---

# ElastiCache Graviton4 (M8g, R8g, C8gn): When to Leave m7g/r7g — and When to Wait

> On Aug 6, 2026 ElastiCache added Graviton4 M8g/R8g/C8gn for Valkey and Memcached — up to 47% higher throughput, 43% lower P99, 31% better price-performance vs Graviton3. Field guide: family pick, RI traps, canary checklist.

import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingCalculatorCta from '~/components/blog/PricingCalculatorCta.astro';

On **August 6, 2026**, AWS [announced](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-elasticache-graviton4-m8g-r8g-c8gn/) that Amazon ElastiCache supports **Graviton4-based M8g, R8g, and C8gn** node families for **Valkey** and **Memcached**. AWS claims up to **47% higher throughput**, up to **43% lower P99 latency**, and up to **31% better price-performance** (on-demand) versus equivalent Graviton3 sizes on ElastiCache for Valkey — depending on family, size, and workload. Graviton4 nodes also ship more memory at the same size class; AWS’s example is **m8g.8xlarge at 124.65 GiB** versus **m7g.8xlarge at 103.68 GiB** (~**20%** more). **C8gn** adds up to **200 Gbps** network bandwidth for network-intensive caches.

If your Valkey fleet already runs on **r7g/m7g**, this is not a Friday cutover — but it is the moment to **stop buying new Graviton3 RIs** until you have canary data. Node-hour math, replica multipliers, and Serverless ECPU stay in the [ElastiCache pricing post](/blog/amazon-elasticache-pricing-nodes-serverless-2026/). Cache patterns stay in the [Redis/Valkey strategies guide](/blog/aws-elasticache-redis-caching-strategies-for-production/).

<PricingHeroStats
  stats={[
    { value: 'Up to 47%', label: 'Higher throughput', note: 'vs Graviton3 Valkey (AWS)' },
    { value: 'Up to 43%', label: 'Lower P99', note: 'AWS lab band' },
    { value: '~20%', label: 'More memory', note: 'm8g.8xl vs m7g.8xl example' },
    { value: '200 Gbps', label: 'C8gn network', note: 'When network-bound' },
  ]}
/>

<PricingCalculatorCta blogSlug="amazon-elasticache-graviton4-m8g-r8g-c8gn-2026" />

> **Engagement shape we reuse (published)** — A **subscription analytics SaaS** (~**$9k/mo** ElastiCache, Redis/Valkey cluster mode) ran three shards × 2 replicas with **12% average CPU** and rightsized to save **$2,400/mo** ([pricing post](/blog/amazon-elasticache-pricing-nodes-serverless-2026/)). That silhouette is a **Graviton4 candidate only after** CPU or memory is actually bound — generation upgrades do not fix idle over-replication. If their next win is throughput/p99 at constant topology, score **r7g → r8g** with the matrix below before another RI term.

> **Reproduce this** — Score [`m7g-to-m8g-family-decision-matrix.md`](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/m7g-to-m8g-family-decision-matrix.md). Run [`elasticache-graviton4-canary-checklist.md`](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/elasticache-graviton4-canary-checklist.md). Model node-hours on the [ElastiCache pricing calculator](/tools/aws-elasticache-pricing-calculator/).

---

## What AWS shipped on August 6, 2026

| Family   | Role                        | When it wins                                                            |
| -------- | --------------------------- | ----------------------------------------------------------------------- |
| **M8g**  | General-purpose Graviton4   | Balanced CPU + memory; modest working sets                              |
| **R8g**  | Memory-optimized Graviton4  | Large working sets, eviction pressure — **default for most app caches** |
| **C8gn** | Network-optimized Graviton4 | Up to **200 Gbps**; measured network saturation                         |

**Engines (announcement):** Valkey and Memcached. **Sizes:** large through 16xlarge. **Regions:** over 30, including GovCloud (US) and China Regions — verify before multi-Region DR designs.

**Opinionated take:** For production Valkey already on Graviton3, plan an **r7g → r8g** (or m → m) **same-size** canary before new RI purchases. Use **C8gn** only when `NetworkBytesIn/Out` is the bottleneck. Do not treat AWS’s **47% / 43% / 31%** bands as your invoice.

---

## Performance claims — how to read them

| AWS claim                              | What to measure in your account                                  |
| -------------------------------------- | ---------------------------------------------------------------- |
| Up to **47%** higher throughput        | Ops/sec at equal EngineCPU on canary vs control                  |
| Up to **43%** lower P99                | **Application** cache p99, not only ElastiCache engine latency   |
| Up to **31%** better price-performance | **$/million ops** On-Demand before and after                     |
| ~**20%** more memory (8xlarge example) | `DatabaseMemoryUsagePercentage`, evictions, deferred shard-split |

> **Benchmark pattern (not a cited client)** — Modeled a Valkey cluster-mode fleet: **6 × cache.r7g.xlarge** (3 shards × 1 replica), **us-east-1**, steady **~45%** EngineCPU at peak, app p99 cache get **2.8 ms**. Same-size move of **one replica** to **cache.r8g.xlarge** for **72 hours** is the experiment design — not a promised uplift. Pass criteria: app p99 **≤ control**, EngineCPU headroom up, and **$/op** not worse before rolling other nodes. If p99 is flat while EngineCPU was never the limiter, stop and fix cardinality or client pooling instead of chasing generations.

---

## Pick the family before the size

**R8g when:**

- Working set and eviction risk dominate
- You previously bought r7g for the same reason
- You want the Graviton4 memory bump at a given size class

**M8g when:**

- CPU and memory are both moderate
- You are on m7g today and the profile still fits

**C8gn when:**

- Network is saturated (high client fan-out, large payloads, cross-AZ chatter)
- You have already ruled out client-side batching and connection storms

> **What broke** — Pattern failure: a team moves a network-bound session-store cache to **R8g** expecting the Valkey throughput headline. **EngineCPU drops slightly; application p99 barely moves** — `NetworkBytesIn` was already near the prior generation’s ceiling. **Detection:** CloudWatch network metrics alongside p99 during the canary. **Fix:** re-canary on **C8gn** at the same size class, or reduce payload/chattiness. **Lesson:** family mismatch looks like “Graviton4 did nothing.”

---

## RI timing and FinOps gates

ElastiCache still uses **Reserved Nodes**, not Compute Savings Plans ([RI vs Savings Plans guide](/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/)).

1. Inventory open **m7g/r7g** RI terms and days remaining.
2. Canary on On-Demand or near-expiry capacity first.
3. Only after a winning canary, buy **r8g/m8g/c8gn** RIs — do not double-commit across generations.
4. Pair with the broader [Graviton cost optimization guide](/blog/aws-graviton-cost-optimization-guide/) if the app tier is still on x86.

---

## Canary playbook (one shard first)

1. **Baseline (14 days)** — EngineCPU, memory %, evictions, connections, network bytes, app p99.
2. **Score** — [family matrix](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/m7g-to-m8g-family-decision-matrix.md).
3. **Modify one node** — same size class; tag `MigrationWave=elasticache-graviton4-canary` ([checklist](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/elasticache-graviton4-canary-checklist.md)).
4. **72 hours including peak** — compare ops/sec, p99, $/op.
5. **Promote by wave** — pause new Graviton3 RI purchases after success.

---

## What This Post Doesn't Cover

- **Node-hour vs Serverless ECPU crossover** — [pricing post](/blog/amazon-elasticache-pricing-nodes-serverless-2026/).
- **Cache-aside, stampede, and Redis/Valkey pattern design** — [strategies guide](/blog/aws-elasticache-redis-caching-strategies-for-production/).
- **Per-Region On-Demand dollar tables for every size** — [ElastiCache pricing page](https://aws.amazon.com/elasticache/pricing/) and our [calculator](/tools/aws-elasticache-pricing-calculator/).
- **Redis-engine-only fleets** — announcement scope is Valkey and Memcached; confirm current AWS docs before modifying Redis clusters.
- **Your account’s realized % of the 47/43/31 bands** — run the canary; we published a measurement design, not a guaranteed uplift.

---

## What to Do This Week

1. **Filter** Cost Explorer / ElastiCache inventory for `*7g*` Valkey/Memcached nodes and open RI end dates.
2. **Score** each fleet with the [family decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/m7g-to-m8g-family-decision-matrix.md) — pick R8g vs M8g vs C8gn before size.
3. **Canary** one replica or shard for **72 hours** using the [checklist](https://www.factualminds.com/examples/architecture-blog-2026/elasticache-graviton4/elasticache-graviton4-canary-checklist.md).
4. **Compare $/million ops and app p99** — promote only on measured wins.
5. **Block new m7g/r7g RI purchases** for fleets that pass; schedule finance review for fleets with &gt;90 days RI remaining.

Need a structured ElastiCache generation review across accounts? FactualMinds runs AWS cost and performance reviews as an AWS Select Tier Partner — [AWS cost optimization services](/services/aws-cloud-cost-optimization-services/).

---

## Related reading

- [Amazon ElastiCache Pricing: Nodes, Serverless, Replicas (2026)](/blog/amazon-elasticache-pricing-nodes-serverless-2026/)
- [ElastiCache Redis Caching Strategies for Production](/blog/aws-elasticache-redis-caching-strategies-for-production/)
- [AWS Graviton Cost Optimization Guide](/blog/aws-graviton-cost-optimization-guide/)
- [EC2 M9g/M9gd Graviton5 GA Field Guide](/blog/ec2-m9g-m9gd-graviton5-ga-2026/)
- [Reserved Instances vs Savings Plans (2026)](/blog/aws-reserved-instances-vs-savings-plans-decision-guide-2026/)
- [ElastiCache pricing calculator](/tools/aws-elasticache-pricing-calculator/)

## FAQ

### What ElastiCache node families did AWS announce on August 6, 2026?
Graviton4-based M8g, R8g, and C8gn node families for Valkey and Memcached. Sizes range from large to 16xlarge in over 30 AWS Regions, including AWS GovCloud (US) and the China Regions. Confirm current pricing and availability on the ElastiCache pricing page for your Region.

### How much faster are Graviton4 ElastiCache nodes than Graviton3?
Per the AWS announcement, Graviton4-based nodes provide up to 47% higher throughput, up to 43% lower P99 latency, and up to 31% better price-performance for on-demand pricing versus equivalent Graviton3 sizes on ElastiCache for Valkey — depending on node family, size, and workload. These are AWS lab bands; measure your own ops/sec and application p99.

### How much more memory do M8g nodes have versus M7g?
AWS cites more memory per node versus equivalent Graviton3 sizes. Example: m8g.8xlarge provides 124.65 GiB versus 103.68 GiB on m7g.8xlarge — up to about 20% more memory at the same size class. That can defer a shard split if you were memory-bound, not CPU-bound.

### When should I choose C8gn over R8g or M8g?
Choose C8gn when network is the measured bottleneck — C8gn offers up to 200 Gbps of network bandwidth for network-intensive cache workloads. Choose R8g when the working set and evictions dominate. Choose M8g for balanced CPU/memory. Do not buy C8gn because the number is large if NetworkBytesIn/Out are not saturating.

### When should we NOT migrate to M8g/R8g/C8gn yet?
Wait if: (1) you hold long-term Reserved Instances on m7g/r7g with more than ~90 days remaining and finance will not approve early write-off, (2) your engine path is Redis-only and you have not confirmed current AWS support for that engine on these families, (3) you have no 14-day CloudWatch + app p99 baseline, or (4) CPU and network are idle — rightsizing or replica count is the cheaper win first.

### Does this replace the Serverless vs provisioned decision?
No. Graviton4 nodes are a generation choice inside provisioned clusters. If you are still deciding Serverless ECPU vs node-hours, use the ElastiCache pricing post and calculator first. Do not jump generations mid-debate about Serverless.

### What could go wrong during an m7g/r7g to Graviton4 canary?
Common failures: modifying the whole fleet before a single-shard canary, assuming AWS’s 47% throughput uplift equals 47% lower application p99 on an I/O- or network-bound path, stranding RIs on m7g, and picking M8g when you needed R8g memory (evictions after cutover). Always roll one replica or shard first with rollback triggers.

### Are Savings Plans available for ElastiCache Graviton4 nodes?
ElastiCache does not use Compute Savings Plans in 2026 — Reserved Nodes remain the commitment instrument for provisioned clusters. Plan RI renewals around the canary outcome; see the RI vs Savings Plans guide for why database/cache services stay on RIs.

---

*Source: https://www.factualminds.com/blog/amazon-elasticache-graviton4-m8g-r8g-c8gn-2026/*
