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 recommends rightsizing node type and count to the actual working set.
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. Recommendations focus on rightsizing node type and node count against observed memory and throughput.
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.