# ElastiCache Non-Graviton Instance

> ZopNight flags an available ElastiCache node on an x86 node type only when a same-shape Graviton equivalent (cache.r6g, m6g, m7g, r7g, t4g) exists, the engine is confirmed Redis, Memcached or Valkey, and live catalog rates show a genuine saving no larger than roughly 25%. Otherwise it abstains.

Source: https://zop.dev/integrations/aws/recommendations/elasticache-non-graviton-instance
Updated: 2026-08-19

---

## The honest version of "20% cheaper"

AWS's published number for ElastiCache Graviton is up to 20% better price-performance,
which is not the same thing as a 20% smaller bill. Several Graviton node types are
priced close to their x86 siblings; the gain arrives as more throughput per dollar
rather than a lower invoice. An earlier version of this rule assumed the discount and
multiplied every finding by a flat 0.20, fabricating savings whenever real rates were
missing. That fallback is gone: the rule now prints a dollar figure only when the
catalog rates for both node types actually show one, and [AWS lists those two rates side by side](https://aws.amazon.com/elasticache/pricing/) for anyone who wants to check the delta by hand.

## Four gates before anything fires

- **The node is `available`.** A cluster mid-create, mid-delete or mid-modify is not a
  stable migration target, and pricing it as one surfaces a lever nobody can pull.
- **The engine is confirmed.** Redis, Memcached and Valkey all offer Graviton node
  types, but the rule default-denies when the engine attribute is absent. It never
  names a migration target for an engine it cannot see.
- **A same-shape Graviton sibling exists.** The target is resolved from the current
  node type into the `cache.r6g` / `cache.r7g` / `cache.m6g` / `cache.m7g` /
  `cache.t4g` families. No equivalent, no finding.
- **The rates prove a saving.** Both the x86 and the Graviton on-demand rates must
  resolve, and the Graviton rate must be genuinely lower.

## The plausibility ceiling

A computed delta above roughly 25% is treated as evidence of a SKU mismatch or a stale
rate row rather than a windfall: a same-class x86-to-Graviton swap does not save a
quarter of the bill. The rule abstains instead of publishing an implausible number. It
also abstains when the node is already Graviton, when the resource has no resolved
monthly cost, and when the Graviton rate is equal or higher than the x86 rate.

## Finding your x86 nodes

```bash
aws elasticache describe-cache-clusters \
  --query "CacheClusters[?CacheClusterStatus=='available'].[CacheClusterId,CacheNodeType,Engine]" \
  --output table
```

Any node type outside the five Graviton families above is a candidate.

## Migrating without surprises

Check engine version compatibility first (Redis 6.0+ and Memcached 1.6.6+), then take
a backup, modify the replication group to the Graviton node type, and schedule the
change inside a maintenance window. The modification is a customer console action:
ZopNight detects the opportunity but performs no ElastiCache writes of any kind.