ElastiCache nodes on x86 with a priced Graviton equivalent

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

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.