Opportunity Name
MemoryDB Remove Idle Clusters
AWS Resource Type
Amazon MemoryDB
Opportunity Description
Amazon MemoryDB bills primarily on node-hours, and those node-hours accrue 24/7 whether or not any application is talking to the cluster. A MemoryDB cluster that was stood up for a project that ended, a service that was decommissioned, or an environment that is no longer used keeps costing exactly as much as a busy production cluster. Because MemoryDB is provisioned once and then largely forgotten, idle clusters tend to sit unnoticed for months.
MemoryDB is deliberately treated more conservatively than a cache. Unlike ElastiCache, MemoryDB is a durable primary database. For that reason the finder applies a strict zero-activity test, refuses to judge clusters that are too new to have a full window of history, skips members of Multi-Region clusters entirely, and refuses to declare a cluster idle on incomplete CloudWatch data. The recommendation report leads with the activity evidence so you can verify the idle conclusion yourself before acting.
Criteria for Identifying the Opportunity
CloudFix first builds a candidate list from your CUR, then validates each candidate against the live MemoryDB and CloudWatch APIs. A
|
Validation |
Criteria |
|---|---|
|
NotMultiRegionMember |
The cluster is not a regional member of a MemoryDB Multi-Region cluster. A member is a live active-active replica whose local command activity can legitimately be zero, so the idle signal is not sound and deleting it would be a topology change. Members are rejected before any metrics are fetched. |
|
NotRecentlyCreated |
The cluster is older than the lookback window, measured from the oldest node's creation time. A cluster younger than the window has no full window of history to judge. A cluster whose age cannot be determined is treated as old enough. |
|
Complete metric data |
The CloudWatch response must be complete. If any metric series comes back truncated or partial, CloudFix rejects the cluster rather than risk reading missing data as zero activity — an incomplete response is indistinguishable from genuine idleness, and this is a destructive recommendation on a durable database. |
|
ResourceIdle |
Total read plus write command activity over the window is exactly zero: GetTypeCmds + SetTypeCmds = 0, taken from the AWS/MemoryDB CloudWatch namespace with the ClusterName dimension, statistic Sum, at a 3600-second period. Any non-zero command activity rejects the cluster. |
Configuration
|
Config key |
Default |
Notes |
|---|---|---|
|
lookbackPeriodInDays |
30 days |
Configurable. Selectable values are 7, 30 or 90 days. This single setting drives both the CloudWatch metric window and the minimum cluster age required by NotRecentlyCreated — a cluster must be both idle for and older than this period. |
Two further values are fixed in the finder and are not customer-configurable: the measured window is floored at 2 hours (so a very short configured window still queries a real span), and the CloudWatch datapoint period is 3600 seconds.
Potential Savings
Estimated annual savings equal the cluster's full annualized amortized cost as reported in your CUR:
annual_savings = annualized_amortized_cost (per cluster, from the CUR)
Because the figure comes straight from the amortized CUR cost, it already reflects your EDP, private pricing and any Savings Plan or Reserved Node amortization — no list prices are assumed and no fixed percentage is applied. An idle cluster produces no offsetting value, so deleting it eliminates the entire node-hour charge; the size of the saving is therefore driven by the cluster's node type, its node count (nodes summed across all shards), and its region.
Two things the estimate does not account for:
-
A retained final snapshot. If you keep a final snapshot after deleting the cluster, its snapshot storage continues to be billed. That residual cost is not deducted from the figure above.
-
An active reservation. If your account holds an active MemoryDB reservation covering that node type, CloudFix flags this in the recommendation. Deleting the cluster stops node-hour billing immediately, but the reservation remains a paid commitment until it lapses, so the realized cash saving is muted until then. In that case treat the reported figure as the upper bound on what deleting the cluster recovers.
What Happens When the Fixer Is Executed?
This is a recommendation-only opportunity. CloudFix does not have an automated fixer for it and will not delete any MemoryDB cluster on your behalf.
CloudFix produces a report containing the cluster name, engine, node type, node count and annual cost, the analysis window, and the observed GetTypeCmds, SetTypeCmds and NewConnections totals — the evidence for the idle conclusion. You then apply the change yourself:
-
Verify no consumers. MemoryDB is your system of record. Confirm no application, job or service still reads from or writes to the cluster. Check the cluster's security groups and VPC endpoints as well as your application configuration.
-
Take a final snapshot. Create a manual snapshot so the data can be restored if the cluster turns out to be needed. Note that a retained snapshot continues to incur snapshot storage charges.
-
Schedule the deletion. Plan it during a maintenance window.
-
Delete the cluster. Use the MemoryDB console, or aws memorydb delete-cluster --cluster-name <name> --final-snapshot-name <name>. This removes all of the cluster's shards and nodes.
-
Monitor. Watch dependent systems after deletion to confirm no errors surface.
Is It Possible to Roll Back Once CloudFix Implements the Fixer?
Not applicable — CloudFix does not implement this fix, so there is nothing for CloudFix to roll back.
Your own rollback path is the final snapshot: if you captured one before deleting, you can create a new MemoryDB cluster from that snapshot. Without a final snapshot, deletion is irreversible and the data is lost. MemoryDB is a durable database, not a cache, so it will not repopulate itself from a backing store. Always take the snapshot.
Can CloudFix Implement the Fix Automatically Once I Accept the Recommendation?
No. This is a recommendation-only finder; there is no automated fixer, no runbook and no approval workflow attached to it. Accepting the recommendation records your intent in CloudFix; you must delete the cluster yourself through the AWS Console, CLI or SDK.
Does This Fix Require Downtime?
There is no downtime in the usual sense, because by definition the cluster being deleted is serving no traffic. Deletion is, however, destructive and permanent: every shard, node and all data in the cluster are removed. If any consumer you did not know about is still pointed at the cluster, it will start failing immediately and permanently.
Bill Gleeson
Comments