Production ElastiCache caches paying on-demand with no Reserved Node
What does ZopNight detect here?
ZopNight surfaces a 1-year ElastiCache Reserved Node purchase only for caches that look production, have at least 60 days of observed history with high uptime and utilization, are not already covered by a reservation or Savings Plan, and where the reserved rate times 730 hours beats current monthly spend.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-107 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Source | elasticache_reserved.go |
Where it applies
“Production” is decided on two axes
A 1-year Reserved Node is an irreversible commitment, so misclassifying a scratch cluster is the expensive mistake. The rule reads two independent signals: the cache’s name and its environment tag. An explicit dev/test tag is an authoritative suppressor. It wins even when the name says “prod”. With no dev/test tag present, the cache must look production either by name or by a production environment tag before the rule will consider it at all. Ambiguous caches produce nothing.
The bar for recommending a lock-in
Looking production is necessary, not sufficient. The cache must also prove it is a commitment candidate: at least 60 days of observed history, high uptime across that window, and meaningful CPU and memory utilization drawn from the series ElastiCache publishes for each node. A cache that runs part-time should be scheduled instead, and an underutilized one should be rightsized. Locking either into a 1-year reservation just cements the waste. Caches already covered by a reservation or Savings Plan in the billing data are skipped outright, as is anything the discoverer already marked reserved.
Break-even math, not a discount table
The saving is computed as a real break-even. The Reserved Node is priced at its fixed full-month rate (the reserved hourly rate multiplied by 730 hours) and recommended only when that figure is lower than the cache’s actual, uptime-adjusted monthly cost. The saving is exactly the net difference, and the headline percentage is derived from that same net. There is no fallback: when live reserved-node rates are unavailable the rule abstains rather than applying the roughly 40% average discount AWS lists for 1-year partial-upfront reservations. A reservation that would cost more than today’s spend is rejected by the same arithmetic.
The full list of silent exits
No finding is produced for dev/test-tagged caches; caches that are neither production-named nor production-tagged; caches already under a commitment; caches with no resolved monthly cost; caches that fail the 60-day history, uptime or utilization bar; and caches where reserved rates are missing or the break-even does not clear.
Check your current reservations
aws elasticache describe-reserved-cache-nodes \ --query "ReservedCacheNodes[?State=='active'].[ReservedCacheNodeId,CacheNodeType,CacheNodeCount,StartTime]" \ --output tableCompare active node types and counts against your running clusters. Before buying, confirm the cache will still exist in 12+ months. The reservation bills for its full term whether the cluster survives or not, and it must match the node type it is meant to cover.