Over-provisioned ElastiCache findings apply to clusters that are receiving traffic but run on a node type larger than memory and CPU metrics justify. This is different from idle ElastiCache findings, which flag clusters with near-zero cache traffic or connections.
Before you downsize
- Review cache hit rate, evictions, and memory usage over several days — downsizing during a quiet period can hide peak demand.
- Confirm no upcoming events (launches, sales, batch jobs) will spike memory or connection counts beyond the smaller node type's capacity.
- Plan the resize during a maintenance window; cluster mode and replica counts affect whether AWS can resize in place or requires replacement.
- Update application connection pools and timeouts if the smaller node type has different connection limits.
Paid plans include remediation scripts to modify the cluster node type. Monitor hit rate and latency after the change and be ready to roll back if evictions spike.
What triggers this finding
An ElastiCache cluster on a node type larger than its memory and CPU utilization metrics justify.
Typical fix
Downsize to a smaller node type during a maintenance window. Monitor cache hit rate and evictions after resizing.
Example savings
The difference between current and recommended node pricing — often 25–50% of cluster cost.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
What a node type actually buys
A cache node is sold as a bundle: memory, vCPU, and network capacity at one fixed hourly price. You cannot buy more memory without also buying more CPU, and you cannot give any of it back. Moving one size down within the same family — cache.r6g.xlarge to cache.r6g.large, say — roughly halves both the resources and the price, which is exactly the step Parsivex proposes. It only ever suggests a smaller size in the same family, never a different family or generation, and it verifies that the suggested type is genuinely cheaper before reporting anything.
The saving is per node, multiplied by node count. On a three-node replication group, a $165-per-month step down is a $495-per-month finding, because every replica must be the same node type as the primary. That multiplier is also the reason this finding tends to rank higher than its single-node appearance suggests.
Parsivex flags a cluster when the 14-day average of EngineCPUUtilization sits above zero but below 15%, and the 14-day average of DatabaseMemoryUsagePercentage is below 30%. Both conditions must hold. Clusters that already qualify as idle are excluded so the same cache is never reported twice.
Reading the utilization metrics yourself
EngineCPUUtilization is the metric that matters, and it is not the same as CPUUtilization. Redis and Valkey execute commands on a single thread, so on a multi-core node the host-level CPU figure can look comfortable while the engine thread is saturated — a cluster at 25% host CPU may be at 100% engine CPU and dropping requests. Using the engine metric avoids that trap. Memcached does not publish it at all, which means Memcached clusters have no CPU signal here and are skipped rather than flagged.
aws cloudwatch get-metric-statistics --namespace AWS/ElastiCache \
--metric-name EngineCPUUtilization \
--dimensions Name=CacheClusterId,Value=catalog-cache-001 \
--start-time 2026-07-28T00:00:00Z --end-time 2026-08-11T00:00:00Z \
--period 86400 --statistics Average Maximum
Repeat for DatabaseMemoryUsagePercentage, then add the two metrics the thresholds do not cover: Evictions and CacheHitRate. Low memory usage with zero evictions and a high hit rate is real headroom. Low memory usage with evictions means keys are being pushed out before they expire, and the memory percentage is telling you about a maxmemory-policy rather than about spare capacity.
Headroom that exists for a reason
- Seasonality. Fourteen days in March say nothing about November. A cache sized for peak trading looks wildly over-provisioned for most of the year and is correctly sized for the week that matters.
- Replicas hold the whole dataset. In a Multi-AZ replication group each replica carries a full copy so it can be promoted. Memory usage percentages are low by design when the dataset is small relative to the node, but the node also has to serve the primary's full throughput after a failover.
- Growth. A dataset at 28% today is at 56% after a doubling. Downsizing into a growth curve buys a second migration in six months.
- Connection ceilings. Smaller node types support fewer concurrent connections. A cache that is bound by connection count rather than CPU or memory will hit that limit without either threshold ever warning you, and connection errors are far more disruptive than a slightly oversized bill.
Cost and risk of a node type change
Scaling is not free of disruption, and the amount of disruption depends on the topology:
- Replication group with replicas. ElastiCache scales by replacing nodes and promoting a replica, so expect a failover: a brief window of connection resets and a reconnect storm from every client at once. Applications with retry logic and a sensible connection pool ride through it; applications that resolve the endpoint once at startup do not.
- Single-node Redis or Valkey with no replicas. There is no failover partner, so the node is replaced and the cache comes back empty. Plan for a cold cache and the load spike on the backing store that follows.
- Memcached. Scaling replaces nodes and always discards cached data.
The change itself is reversible — scaling back up is the same operation in the other direction — but each direction costs another maintenance event and another failover, so treat it as one decision rather than a dial to tune. After the resize, watch Evictions, CacheHitRate, and client-side latency across a full daily cycle. Evictions appearing where there were none is the clearest signal that the smaller node cannot hold the working set, and it is the point to roll back rather than tune around.