Production ElastiCache clusters on On-Demand nodes where a reserved node pays off
What does ZopNight detect here?
ZopNight flags production ElastiCache clusters with no reserved node or Savings Plan coverage that have run at least 70% of the time over 60 days of history. The saving is the cluster's actual monthly cost minus a 1-year No Upfront reserved node rate for 730 hours, and a `reserved=true` tag or a dev/test tag stops it.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-107 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | production, uncovered, 70% uptime |
| Evaluation window | 60d history |
| Source | ZopNight |
| Permissions used | elasticache:DescribeCacheClusters · elasticache:DescribeReservedCacheNodes · elasticache:DescribeReservedCacheNodesOfferings |
Where it applies
On-Demand cache nodes bill every hour they exist
ElastiCache pricing bills On-Demand nodes hourly from launch until termination, and each partial node-hour counts as a full hour. A cache is usually the least idle thing in a production stack, so its nodes run every hour of the month and pay the highest rate for it.
Reserved nodes trade that for a discounted hourly rate on a one-year or three-year term, paid No Upfront, Partial Upfront or All Upfront. They are size flexible within a node family and engine, and AWS adds a useful twist: Redis OSS reserved nodes also apply to Valkey nodes in the same family, and because Valkey is priced 20% lower, the same reservation covers 20% more Valkey capacity.
Listing clusters and matching offerings
aws elasticache describe-cache-clusters \ --query 'CacheClusters[].[CacheClusterId,CacheNodeType,Engine,NumCacheNodes]'
aws elasticache describe-reserved-cache-nodes
aws elasticache describe-reserved-cache-nodes-offerings \ --cache-node-type cache.r7g.large --duration 1 --offering-type "No Upfront"Anything running without a matching active reserved node is paying On-Demand rates.
Signals that make a cache a reservation candidate
ZopNight raises this only when all of the following hold:
- The cluster reads as production, by a name containing
prod,production,liveorprd, or by an environment tag with a production value. A dev or test environment tag always suppresses it, even when the name looks like production. - Billing data shows no Reservation or Savings Plan applied, and the cluster has no
reserved=truetag. - ZopNight has a positive monthly cost for it.
- At least 60 days of observed history, 70% or higher uptime, and measured utilization of 30% or more on CPU or memory.
Clusters the rule does not touch
A staging cache named like production but tagged as test is skipped, because a year-long commitment on non-production capacity is the wrong advice. A cache with too little history, low uptime or low utilization is skipped too; right-sizing it comes before reserving it. When there is no live reserved rate for the node type, there is no provable saving and no finding. Graviton moves are handled separately by ElastiCache Non-Graviton Instance, and it is worth doing that before buying, since a reservation is tied to the node family.
What the saving compares
reserved cost = 1-year No Upfront reserved node rate x 730saving = actual monthly cluster cost - reserved cost (only if positive)The actual cost already reflects the hours the cluster ran, so the comparison fails honestly for a cluster that was not up all month.
Reserving the nodes
- Confirm the cluster will run for at least 12 more months on this family and engine.
- Consider the Valkey move first if you run Redis OSS, since existing reservations carry over.
- Buy:
aws elasticache purchase-reserved-cache-nodes-offering --reserved-cache-nodes-offering-id <offering-id> --cache-node-count 2 - Check the next billing cycle shows the nodes at the reserved rate.