MemoryDB clusters with no connections and no commands for 30 days

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.

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 PINGs 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

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