Idle DocumentDB Cluster -- No Connections
What does ZopNight detect here?
DocumentDB clusters are idle when they hold zero connections for 30 days with average and maximum CPU under 5%, or when connected pools issue near- zero opcounter operations. ZopNight would recover the full monthly cost on deletion, but abstains on every cluster today because the cluster row itself prices at $0, a producer gap.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-193 |
| Category | idle |
| Severity | high |
| Metric | none — pure configuration read |
| Source | documentdb_idle.go |
Zero connections, plus the op-counter path
- metric: DatabaseConnections (CloudWatch AWS/DocDB, its own namespace rather than AWS/RDS, Dimension DBClusterIdentifier; replaces the dead connections tag)
- metric: CPUUtilization (CloudWatch AWS/DocDB, same DBClusterIdentifier dimension)
- metric: the four Opcounters* series, the second firing path for a connected-but-idle cluster: DatabaseConnections > 0 (an app holds a pool) fires only when all four op-counter series are present and their combined peak is near-zero (fail-closed; absent ≠ zero). This closes the false negative where an idle connection pool held against a dead cluster keeps the zero-connections gate from tripping
- resource.Status (cluster lifecycle; set by the discoverer)
- STOPPED/STATUS guard: abstains when resource.Status is set and not available (empty/unknown status does not suppress).
- SCHEDULE-WINDOW guard: abstains when the resource has a known recurring schedule (ruletypes.ResourceHasActiveSchedule); a schedule-parked cluster is already optimised, not abandoned.
- CPU corroboration: abstains when the CPUUtilization series is absent (single-axis evidence insufficient), or when Average/Maximum ≥ 5% (cluster is doing non-trivial work despite zero client connections).
Why cluster-level cost prices at zero
concrete-or-abstain. Fires when the cluster is available, unscheduled, has zero connections over 30 days, has near-zero corroborating CPU, AND has a real priced cost (cost > 0); savings = cost × 1.00 (full measured monthly cost recoverable on stop/delete, optimized = 0). Currently abstains on every cluster because of a PRODUCER-GAP: documentdb-cluster is calcFree in the cost registry (MonthlyCost=0), so the cluster UID has $0 priced cost (the real $ lives only on the documentdb-instance children, priced separately via calcSimpleHourly). The fix requires a dedicated calcDocumentDBCluster (storage/IO-only, mirroring calcRDSCluster, matching how DocumentDB bills storage and I/O apart from instance hours) registered for documentdb-cluster. Adding documentdb-cluster to HasOwnCostWithChildren alone is insufficient, since that flag only bypasses the $0 stub and re-runs the parent’s own calc (calcFree); it does not roll child cost onto the parent. Until the dedicated calc lands, the rule abstains rather than emit a $0 idle rec. The metric front (DatabaseConnections/CPUUtilization) and the eval-side guards are already correct; the remaining gap is solely the cluster-level cost producer.
Snapshot first, then delete
- Verify no applications connect to this cluster
- Take a cluster snapshot
- Consider DocumentDB Elastic Clusters for variable workloads
- Delete the cluster if confirmed unused
Connections, CPU, and the four op counters
DatabaseConnections (30-day lookback, full-window coverage gate); CPUUtilization corroboration axis (must be present and below 5% avg/max, mirrors RC-190/RC-169); OpcountersQuery + OpcountersInsert + OpcountersUpdate + OpcountersDelete (op-counter corroboration for the connected-but-idle path)