Scheduling Amazon RDS / Aurora Cluster
rds:StopDBClusterCan ZopNight schedule Amazon RDS / Aurora Cluster?
Aurora schedules use rds:StopDBCluster, which takes the writer and all readers down in one operation, since individual instances cannot stop. Global database members refuse the call entirely, AWS restarts any stopped cluster after 7 days, and Aurora's separately billed storage layer never pauses at all.
How the stop works
| Field | Value |
|---|---|
| Behaviour | cluster stopped via rds:StopDBCluster and started via rds:StartDBCluster 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
Cluster verbs, not instance verbs
Aurora refuses per-instance stops: rds:StopDBCluster and rds:StartDBCluster operate on the
whole topology. Writer and readers stop together, which means a three-reader cluster saves four
instances’ worth of compute per off-hour, and also means there is no configuration where a lone
reader stays up for overnight reporting. If a workload needs that, it needs a separate cluster.
Clusters that will not stop
Membership in an Aurora global database disqualifies a cluster from stopping: the cross-region replication contract requires it running. The same applies to other cross-region replication arrangements. A schedule attached to such a cluster fails at the first stop, so check the topology before wiring the cron rather than after the first failed night.
The restart you did not schedule
A stopped cluster is restarted by AWS after 7 days, for maintenance application. Recurring schedules are immune, because every stop opens a fresh 7-day window. The pattern to police is the project-paused cluster somebody stopped manually in March and rediscovered on the April invoice, running.
Aurora storage is its own bill
Aurora’s storage layer is distributed, separately metered and completely indifferent to the cluster’s state. Storage GB, I/O or the I/O-Optimized premium, backups and snapshots all bill through the night. On storage-heavy clusters the compute line the schedule saves can be the smaller of the two numbers, so do that arithmetic before promising a percentage.
Serverless v2 reframes the question
A Serverless v2 cluster idles at its configured minimum ACU rather than at zero (0.5 ACU at the floor), so an “idle” serverless cluster still bills every hour. Recent versions can auto-pause to zero after sustained inactivity, which suits spiky development use. A calendar stop still beats auto-pause when the quiet hours are known and long: the stop is deterministic, immune to a stray connection keeping the cluster scaled up all night.