Amazon DocumentDB Cluster
Does ZopNight manage Amazon DocumentDB Cluster?
A DocumentDB cluster bills per instance-hour for each member instance, plus per GB-month storage and per million I/O requests. ZopNight stops and starts non-production clusters on schedule through the DocumentDB management API and keeps 90 days of DocDB namespace metrics to catch clusters idling at zero connections.
Rules that fire on Amazon DocumentDB Cluster
No active rule family targets Amazon DocumentDB Cluster today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | cluster stopped and started via the DocumentDB management API on schedule. |
Amazon DocumentDB is a managed, MongoDB-compatible document database billed per instance-hour plus storage and I/O. Non-production DocumentDB clusters typically only need business-hours availability but bill around the clock by default.
Aurora’s meter shape, MongoDB’s API
A DocumentDB cluster bills like its relational cousin: per instance-hour for every member instance at its instance-class rate, per GB-month for cluster storage, and per million I/O requests. Replicas multiply the instance meter: a three-instance dev cluster is three hourly meters carrying one workload’s traffic. Storage grows automatically with the data set, so it needs no capacity decision, but I/O charges scale with workload behavior, and a poorly indexed collection can turn a modest cluster into a surprising I/O line item.
Stop, start, and the seven-day clock
ZopNight stops and starts non-production clusters on schedule through the DocumentDB management API. A stopped cluster halts every member’s compute meter while storage keeps billing. As with RDS, AWS automatically restarts a cluster that has been stopped for 7 days, so only a recurring schedule keeps a cluster reliably parked; a manual stop is a one-week reprieve.
Where DocumentDB money leaks
Clusters idling at zero connections are the flagship finding, since document databases often back prototypes that were quietly retired. Replica counts copied from production into staging environments that serve no read traffic. And instance classes sized for peak loads that never materialized. None of these show up as errors: the cluster stays healthy, replicated, and unused, which is exactly why the detection needs 90 days of connection metrics rather than a status check.
Metrics and attribution
Clusters are discovered on the 6-hour cycle. Hourly CloudWatch metrics from the DocDB namespace run with a 90-day lookback, per-cluster cost comes from Cost Explorer or CUR 2.0, and recommendations cover scheduling and rightsizing.
Console route
Amazon DocumentDB console, then Clusters. Each cluster row expands into its member instances (the meter count), and the Monitoring tab carries the connection metrics the idle detection reads.