Amazon MemoryDB Cluster
Does ZopNight manage Amazon MemoryDB Cluster?
Amazon MemoryDB bills per node-hour for every node plus per GB of data written, and clusters cannot be stopped, so capacity runs 24/7 until resized or deleted. ZopNight keeps 90 days of MemoryDB namespace metrics and flags clusters with near-zero new connections and commands over 30 days as idle (RC-105).
Rules that fire on Amazon MemoryDB Cluster
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, cost tracking, and recommendations only. |
Amazon MemoryDB is a durable, Redis-compatible in-memory database billed per node-hour plus data written. Like ElastiCache, MemoryDB clusters run continuously, so capacity should track actual working-set size.
Node-hours plus a write meter
Every node in a MemoryDB cluster (primaries and replicas across shards) bills its per-node-hour rate continuously. On top of that sits a meter ElastiCache does not have: data written bills per GB, the price of MemoryDB’s durable multi-AZ transaction log. Snapshot storage beyond the included allowance adds per GB-month. There is no stop operation; a cluster runs at full node count until someone rescales or deletes it.
Durability changes the sizing question
Because MemoryDB persists its data durably, it gets deployed as a primary database, not just a cache. Primary databases inherit production instincts: generous node classes, replicas per shard, room to grow. The billing model punishes that instinct around the clock. The working set, not the aspiration, should size the cluster: memory headroom on an in-memory database is among the most expensive headroom in AWS.
What overspend looks like
Clusters sized at launch for a working set that never arrived. Replica counts copied from production into staging environments where durability of test data is worthless. And write-heavy workloads on MemoryDB where plain ElastiCache would serve, paying the per-GB write meter for durability nobody asked for.
Continuous measurement
Clusters are discovered on the 6-hour cycle, with hourly CloudWatch metrics from the MemoryDB namespace kept over a 90-day lookback and per-cluster cost from Cost Explorer or CUR 2.0. The recommendation flags idle clusters (RC-105 MemoryDB Cluster Idle) whose new connections and read and write commands stay near zero for 30 days; sizing node type and node count to the working set remains a manual review.
Shards and nodes in the console
MemoryDB console, then Clusters. A cluster’s detail page lists shards and their member nodes. Count the nodes, multiply by the node type’s rate, and the fixed half of the bill is in hand; the write meter follows the workload.