# Scheduling 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.

Source: https://zop.dev/integrations/aws/documentdb/schedule
Updated: 2026-08-19

---

## 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.