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

On August 6, 2026, AWS announced 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. Cache patterns stay in the Redis/Valkey strategies guide.

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). 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. Run elasticache-graviton4-canary-checklist.md. Model node-hours on the ElastiCache pricing calculator.

What AWS shipped on August 6, 2026

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

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).

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 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.
3. Modify one node — same size class; tag MigrationWave=elasticache-graviton4-canary (checklist).
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.
• Cache-aside, stampede, and Redis/Valkey pattern design — strategies guide.
• Per-Region On-Demand dollar tables for every size — ElastiCache pricing page and our 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 — pick R8g vs M8g vs C8gn before size.
3. Canary one replica or shard for 72 hours using the checklist.
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 >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.

Related reading

• Amazon ElastiCache Pricing: Nodes, Serverless, Replicas (2026)
• ElastiCache Redis Caching Strategies for Production
• AWS Graviton Cost Optimization Guide
• EC2 M9g/M9gd Graviton5 GA Field Guide
• Reserved Instances vs Savings Plans (2026)
• ElastiCache pricing calculator