Amazon ElastiCache Cluster
Does ZopNight manage Amazon ElastiCache Cluster?
ElastiCache bills per node-hour by node type for as long as a cluster exists. AWS offers no stop operation, so an idle cache bills 24/7 until deleted or resized. ZopNight tracks 90 days of node metrics and recommends idle-cluster removal, Graviton node types, fewer replicas on non-critical caches, and reserved nodes instead of scheduling.
Rules that fire on Amazon ElastiCache Cluster
At a glance
| Field | Value |
|---|---|
| Scheduling notes | a scheduling executor exists but is a deliberate no-op placeholder, because ElastiCache offers no native stop operation; discovery, metrics, cost, and recommendations only. |
Amazon ElastiCache runs managed Redis and Memcached clusters billed per node-hour. Cache nodes cannot be natively stopped, only deleted, so oversized or idle caches accumulate cost until someone rightsizes or removes them.
A meter with no pause
Every node in a cluster bills its per-node-hour rate from creation to deletion. There is no stop API, and the choice is running or gone, which makes ElastiCache unusual among stateful services: an idle cache bills all 168 hours of every week until a human intervenes. Backup storage beyond the free allowance adds a per-GB-month meter. Reserved nodes lower the hourly rate for steady production caches, which sharpens the question an idle one raises: a cache that cannot be stopped should either be reserved or challenged.
Why ZopNight does not schedule it
A scheduling executor exists for ElastiCache but is a deliberate no-op placeholder, precisely because there is no native stop operation to call. Deleting and recreating a cache nightly would drop the entire dataset and force a cold-start repopulation every morning, so the safe cost levers are rightsizing and removal, never scheduling.
The three usual findings
Idle clusters: nodes serving near-zero commands for weeks, typically left behind by a decommissioned application. Multi-AZ replica nodes protecting caches whose data is disposable by definition. And older non-Graviton node families paying more per node-hour than the equivalent Graviton generation for the same memory.
Tracking an unstoppable meter
Clusters are discovered every 6 hours through a dedicated ElastiCache provider, with hourly CloudWatch metrics from the ElastiCache namespace kept over a 90-day lookback and per-cluster cost from Cost Explorer or CUR 2.0. Recommendations cover idle clusters, Graviton node types, replica counts on non-critical Multi-AZ caches, and reserved nodes.
Cache inventory in the console
ElastiCache console, then Redis OSS caches or Memcached caches in the left navigation. A cluster’s node type and node count, the two multiplicands of its bill, sit on the cluster detail page.