# ElastiCache m7g/r7g → M8g/R8g/C8gn canary checklist

Run against a **non-production** replication group or a single shard/replica first. Source: [ElastiCache Graviton4 nodes — Aug 6, 2026](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-elasticache-graviton4-m8g-r8g-c8gn/).

AWS-published uplifts (Valkey, depending on family/size/workload): up to **47%** higher throughput, up to **43%** lower P99 latency, up to **31%** better price-performance vs equivalent Graviton3 sizes. Treat these as lab bands — measure your own p99 and $/op.

## Pre-flight (30 minutes)

- [ ] Confirm engine is **Valkey** or **Memcached** (announcement scope). If Redis engine only, check current AWS docs before modifying.
- [ ] Score the [family decision matrix](./m7g-to-m8g-family-decision-matrix.md) — pick **R8g**, **M8g**, or **C8gn** before size.
- [ ] Export 14-day baseline: `EngineCPUUtilization`, `DatabaseMemoryUsagePercentage`, `Evictions`, `CurrConnections`, `NetworkBytesIn`, `NetworkBytesOut`, application **p99** cache latency.
- [ ] Note Reserved Instance coverage on current `*7g*` nodes — do not strand >90 days of RI without finance sign-off.
- [ ] Model node-hours on the [ElastiCache pricing calculator](https://www.factualminds.com/tools/aws-elasticache-pricing-calculator/).

## Canary modify (same day)

- [ ] Prefer **same size class** first (e.g. `cache.r7g.large` → `cache.r8g.large`) so you isolate generation uplift from right-sizing.
- [ ] Modify **one** replica or one shard primary (cluster mode) via Console, SDK, or CLI — not the whole fleet.
- [ ] Tag canary `MigrationWave=elasticache-graviton4-canary` for Cost Explorer.
- [ ] Run production-like or shadow traffic ≥ **72 hours** including peak window.
- [ ] Compare: ops/sec, EngineCPU, memory %, network bytes, **application p99** vs control nodes.

## Rollback triggers

- [ ] Application p99 **> 15%** worse than control at equal ops/sec.
- [ ] Unexpected connection resets / failover storms during modify.
- [ ] Evictions spike after move (wrong family — e.g. chose M8g when R8g memory was required).
- [ ] Network still saturated on M8g/R8g — re-evaluate **C8gn**, do not keep upsizing general-purpose blindly.

## Promote or park

- [ ] If canary wins on p99 and $/op: roll remaining shards/replicas by wave; keep 48h rollback capacity on prior type if RI allows.
- [ ] If memory headroom was the win (m8g/r8g ~20% more memory at example 8xlarge sizes): document deferred shard-split decision.
- [ ] Pause new **m7g/r7g** RI purchases for this fleet after a successful canary.
- [ ] Revisit Serverless vs provisioned only if traffic shape changed — see [pricing post](https://www.factualminds.com/blog/amazon-elasticache-pricing-nodes-serverless-2026/); do not re-litigate that decision mid-canary.