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

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

---

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