# 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.

Source: https://zop.dev/integrations/aws/memorydb
Updated: 2026-08-19

---

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.