ElastiCache nodes on x86 m5, r5 or t3 types with a cheaper Graviton equivalent
What does ZopNight detect here?
ZopNight flags available Redis OSS, Valkey or Memcached nodes on `cache.m5`, `cache.r5` or `cache.t3` types and prices a move to the same size in `cache.m6g`, `cache.r6g` or `cache.t4g`. The saving is the On-Demand node rate difference applied to the node's cost, and gaps above 25% are treated as bad data and not shown.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1517 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | Graviton rate lower, gap no more than 25% |
| Source | ZopNight |
| Permissions used | elasticache:DescribeCacheClusters · elasticache:DescribeReplicationGroups |
Where it applies
Graviton cache nodes cost a little less per hour
ElastiCache offers Graviton node families alongside the x86 ones, listed with their sizes on the
supported node types page.
The AWS price list for US East (N. Virginia) shows the gap for Redis OSS nodes: cache.m5.large is
$0.156 an hour and cache.m6g.large $0.149; cache.r5.large is $0.216 and cache.r6g.large
$0.206. That is under 5% at these sizes, so on a small fleet the saving is modest.
The same price list shows a bigger lever next to it: the Valkey engine is priced below Redis OSS on
the same node, $0.1248 an hour for cache.m5.large. Engine choice is outside this rule, but worth a
look while you are changing nodes.
Listing x86 cache nodes
aws elasticache describe-cache-clusters \ --query 'CacheClusters[?starts_with(CacheNodeType, `cache.m5`) || starts_with(CacheNodeType, `cache.r5`) || starts_with(CacheNodeType, `cache.t3`)].[CacheClusterId,CacheNodeType,Engine,EngineVersion,CacheClusterStatus]' \ --output table
aws elasticache list-allowed-node-type-modifications --replication-group-id cart-prodThe second command lists the node types a replication group can scale to, which confirms the Graviton type is available for your engine version.
Node checks before a Graviton move is priced
- The node’s status is
available, not creating, modifying or deleting. - The engine is Redis OSS, Valkey or Memcached; any other or unknown engine is skipped.
- The node type has a same-size Graviton equivalent:
cache.m5tocache.m6g,cache.r5tocache.r6g,cache.t3tocache.t4g. - A monthly cost and both On-Demand rates are known, and the Graviton rate is lower.
When the rate data is not trusted
A rate gap above 25% is not realistic for a same-size move between these families, so the finding is dropped rather than shipped on what is probably bad catalog data. Missing rates also mean nothing is shown; there is no assumed percentage. The equivalent check for EC2 instances is Graviton Migration Opportunity, and for RDS it is RDS Non-Graviton Instance.
The node rate gap as the saving
saving = monthly node cost x (x86 hourly rate - Graviton hourly rate) / x86 hourly rateFor the cache.m5.large to cache.m6g.large example that is about 4.5% of the node’s cost.
Changing the node type
- Take a backup of the replication group first.
- Confirm the target type appears in
list-allowed-node-type-modifications. - Change the type in your maintenance window:
aws elasticache modify-replication-group --replication-group-id cart-prod --cache-node-type cache.m6g.large --apply-immediately - Watch evictions, CPU and latency afterwards. The engine is unchanged, so client libraries stay the same.