Scheduling Amazon DocumentDB Cluster
Can ZopNight schedule Amazon DocumentDB Cluster?
Stopping a DocumentDB cluster halts the primary and every replica in one operation, so a 3-instance cluster saves 3 instance-hours for each hour off. AWS restarts any stopped cluster automatically after 7 days, and storage, backups and snapshots keep billing throughout, leaving only the instance line to save.
How the stop works
| Field | Value |
|---|---|
| Behaviour | cluster stopped and started via the DocumentDB management API on schedule. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
One operation, the whole cluster
DocumentDB has no per-instance stop. The management API stops the cluster as a unit: the primary and up to 15 replicas power down together and come back together. That makes the saving scale with cluster size: a three-instance dev cluster banks three instance-hours for every hour of the off window, which is why replica-heavy non-production clusters are the best candidates on the whole account.
Because the service sequences the shutdown itself, there is nothing to orchestrate on your side, with no ordering of replicas and no way to end up with a replica running against a stopped primary.
A stopped cluster is on a timer
AWS will start the cluster again on its own after 7 days, so that pending maintenance can apply. Recurring schedules never notice, because every evening’s stop begins a fresh week. The failure mode is the manual, one-off stop: a cluster paused at the end of a project quietly returns the following week and bills until someone reads the invoice.
The storage meter does not participate
Cluster storage, automated backups and manual snapshots all bill at their normal rates while the instances are off. A cluster holding 200 GB keeps paying for 200 GB every night. The honest way to state the saving is instance-hours avoided, never a percentage of the cluster’s total monthly cost.
Morning reconnections
The cluster endpoints do not change across a stop and start, so no configuration needs updating. What does need attention is application behavior at 8am: connection pools that cached dead sockets overnight must re-establish, and drivers without retry logic will surface a burst of errors in the first seconds after start. Point the start cron far enough ahead of the first user that the cluster reports available first.
Long-running work and the cutoff
Anything mid-flight at the stop time (an index build, a large aggregation, a migration script) is interrupted. Schedule the stop after the nightly batch completes, or gate the batch on the schedule, rather than letting the two race each other.