# MemoryDB Cluster Idle

> ZopNight calls a MemoryDB cluster idle only when three CloudWatch series agree for 30 days: NewConnections, GetTypeCmds and SetTypeCmds all below 1.0 on both average and maximum. A missing series means abstain, and the saving is the cluster's full measured run-rate, since MemoryDB bills per node-hour regardless of use.

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

---

## Why new connections, not current ones

`CurrConnections` is the obvious idle signal and the wrong one. A connection pool that
was never torn down keeps that gauge pinned above zero for months against a cluster
nothing actually uses. `NewConnections` counts the fresh connections opened per
period, which makes it the truer "is anyone showing up" axis, and it is this rule's primary
trigger.

## Commands are counted on both sides

Connections alone still are not proof. The rule corroborates with MemoryDB's two
command counters: `GetTypeCmds`, the per-period count of read-type commands (`get`,
`hget`, `lrange`), and `SetTypeCmds`, the write-type count (`set`, `hset`, `lpop`). A
cluster serving reads **or** writes is not idle, so both counters must sit at the
floor before anything fires.

An earlier revision keyed the corroborating axis to a metric called `PrimaryCmdCount`,
which AWS/MemoryDB does not publish. CloudWatch returned no data, the corroboration was
unconditionally absent, and the rule silently abstained on every cluster in every
fleet. The current counters are real entries in [the AWS/MemoryDB metric catalog](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

## The gate, precisely

All three series must be present, covered for at least 30 days, and below 1.0 on both
their Average and their Maximum. A single busy spike anywhere in the month
disqualifies the cluster. The floor is "below 1.0" rather than exactly zero because a
handful of stray health-probe connects or `PING`s over a month still describes an idle
cluster.

Every failure of that gate abstains: a missing series, a series covering fewer than 30
days, any axis at or above its floor, or a missing priced run-rate. Partial evidence
for deleting a datastore is treated as no evidence.

## Confirming from the CLI

```bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/MemoryDB --metric-name NewConnections \
  --dimensions Name=ClusterName,Value=my-cluster \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum
```

Repeat for `GetTypeCmds` and `SetTypeCmds`. All three flat means the finding is real.

## What deleting recovers

MemoryDB [bills per node-hour](https://aws.amazon.com/memorydb/pricing/) (node type times shards times replicas) regardless of
use, so the recoverable saving is the cluster's entire measured run-rate. Before
acting, search application config and Secrets Manager for the cluster endpoint (a
cache with no traffic is sometimes a cache nothing was pointed at yet), take a final
snapshot, then delete. If the cluster is merely oversized rather than abandoned, cut shards
and replicas instead.