Opportunity Name
DocumentDB Remove Idle Clusters
AWS Resource Type
Amazon DocumentDB (with MongoDB compatibility) — provisioned clusters
Opportunity Description
A provisioned Amazon DocumentDB cluster bills primarily on instance-hours — per instance, per hour, by instance class — plus I/O, storage, and backup. Those instance-hours accrue 24 hours a day whether the cluster serves a million queries or none at all. A cluster that nothing connects to is therefore pure waste, and it costs exactly the same as a busy one.
This CloudFix Finder pulls your actual DocumentDB instance costs from the Cost and Usage Report, rolls the per-instance cost up to the cluster level, and then checks CloudWatch for customer connections to each cluster over a configurable lookback window. Clusters that show no connections at all, and that pass a set of steady-state guards, are surfaced as a recommendation to delete, with their annual cost and the connection evidence behind the finding. The Finder covers provisioned DocumentDB clusters only; DocumentDB Elastic (serverless) clusters are out of scope.
Criteria for Identifying the Opportunity
Candidate clusters are selected from your Cost and Usage Report, then validated in order against the live AWS APIs. A cluster must pass every check below to be recommended.
|
Check |
What it requires |
|---|---|
|
Cluster roll-up |
Instances are grouped by DBClusterIdentifier into a single cluster recommendation, with the instance costs summed. The idle decision is always made at the cluster level, never per instance. |
|
ClusterRunning |
Cluster Status is exactly available. A cluster in any other state — including a stopped cluster — is rejected, and its actual status is recorded on the validation record. |
|
ClusterNotRecentlyCreated |
ClusterCreateTime is older than thresholdDays. A brand-new cluster has no meaningful activity history, so it is never recommended. |
|
ClusterNoUsage |
The CloudWatch metric DatabaseConnections in the AWS/DocDB namespace, dimension DBClusterIdentifier, statistic Maximum, at 5-minute granularity, reads 0 across every datapoint in the lookback window. The dimension is matched exactly, so the separate (DBClusterIdentifier, Role) writer/reader variant is not used. |
Configurable setting
|
Config key |
Default |
Allowed range |
Meaning |
|---|---|---|---|
|
thresholdDays |
31 |
1–60 |
Number of days of history used both for the connection lookback window and for the "not recently created" guard. Displayed in the CloudFix UI as "No of days to consider DocumentDB cluster as idle". |
Potential Savings
Savings come from eliminating the instance-hours of every instance in the idle cluster. The number is derived from your own CUR data, not from list prices, so it already reflects any EDP, Reserved Instance, or Savings Plan coverage on those instances.
The calculation is:
current annual cost = sum of annualized amortized cost of all instances in the cluster
annual savings = current annual cost × 0.99
new cost = current annual cost − annual savings (the remaining 1%)
The 1% that is not counted as savings is an allowance for the final snapshot retained when the cluster is deleted, so the data remains recoverable.
As an illustration, a cluster costing $100.00 per year is reported as $99.00 in annual savings with a $1.00 residual cost after deletion.
What Happens When the Fixer Is Executed?
Note: This is a Finder-only opportunity. There is no automated fixer, and CloudFix will not delete anything on your behalf. The finder source contains no fixer runbook or change template, and the opportunity is registered in the CloudFix catalogue with automatic fixing disabled and manual fix required.
CloudFix produces a recommendation report containing:
-
The cluster ID and the cluster's annual cost
-
Cluster status and creation time
-
The analysis window in days, and a chart of DatabaseConnections over that window
-
Estimated annual savings and the residual cost after deletion
To act on it, remediate manually:
-
Confirm the cluster is genuinely unused. DocumentDB is frequently a system of record. Check with the owning team, and check for applications, batch jobs, or BI tools that connect only occasionally — a job that runs less often than your thresholdDays window could still be a real consumer.
-
Take a final snapshot. Either create a manual cluster snapshot up front, or let the delete operation take one — call DeleteDBCluster with FinalDBSnapshotIdentifier set and SkipFinalSnapshot left off. Verify the snapshot completes before going further.
-
Disable deletion protection on the cluster if it is enabled — the ModifyDBCluster API, or aws docdb modify-db-cluster --db-cluster-identifier <id> --no-deletion-protection.
-
Delete the instances in the cluster (DeleteDBInstance for each member instance), then delete the cluster itself (DeleteDBCluster). A cluster cannot be deleted while it still has instances; the AWS Console performs the same sequence for you.
-
Clean up leftovers you no longer need — the cluster's subnet group, parameter group, and any associated CloudWatch alarms. Note that retained snapshots continue to incur backup storage charges.
Is It Possible to Roll Back Once CloudFix Implements the Fixer?
Not applicable — this is a Finder-only recommendation, so CloudFix never makes the change and there is nothing for CloudFix to roll back.
If you perform the deletion yourself and took a final snapshot, you can recover by restoring a new cluster from that snapshot (RestoreDBClusterFromSnapshot, then adding instances to the restored cluster). The restored cluster is a new cluster: it has a new endpoint, and applications must be repointed. This is why the savings calculation deliberately reserves 1% for the retained snapshot — do not skip it.
Can CloudFix Implement the Fix Automatically Once I Accept the Recommendation?
No. This opportunity is recommendation-only. CloudFix identifies the idle cluster and quantifies the savings, but you must delete the cluster yourself through the AWS Console, CLI, or your infrastructure-as-code tooling after reviewing the recommendation.
Does This Fix Require Downtime?
The deletion is permanent, not a restart. By the Finder's own criteria, the cluster had no client connections at all across the entire lookback window, so no live workload should be affected.
The real risk is not downtime but data availability: any consumer you did not know about loses its database. Treat the verification step above as mandatory, and always retain a final snapshot so the cluster can be restored to a new endpoint if a consumer surfaces later. If your infrastructure is managed by CloudFormation, Terraform, or CDK, delete the cluster through that tooling so the stack does not recreate it or drift.
Bill Gleeson
Comments