Stop an Aurora DB Cluster on a Schedule

Aurora stops the whole cluster or nothing. Check the three topologies that refuse to stop before you automate it.

Aurora has no per-instance stop. stop-db-cluster takes every DB instance in the cluster down in one call: Aurora stops the replica instances first and the primary last, so the failover mechanism is not triggered. If you only want fewer instances running, delete replicas or move to a smaller instance class instead; AWS explicitly recommends that over stop and start for a cluster that must stay up.

Clusters that cannot be stopped

A cluster in an Aurora global database, unless it is the only cluster in that global database.
A cluster with a cross-Region read replica.
A cluster that is part of a blue/green deployment.

Aurora Serverless clusters can be stopped and started. Check the topology first:

aws rds describe-db-clusters \
  --db-cluster-identifier dev-aurora-pg \
  --query "DBClusters[0].{status:Status,engine:Engine,members:DBClusterMembers[].DBInstanceIdentifier,readReplicas:ReadReplicaIdentifiers}"

A non-empty readReplicas list pointing at another Region means the stop will be refused.

Permissions

rds:DescribeDBClusters, rds:StopDBCluster, rds:StartDBCluster. These accept the rds:cluster-tag/${TagKey} condition key, so a policy can restrict the stop to clusters tagged for development.

Stop it

Console: RDS, Databases, select the cluster, Actions, Stop temporarily, tick the acknowledgement that the cluster restarts automatically after 7 days, then Stop temporarily.

CLI:

aws rds stop-db-cluster --db-cluster-identifier dev-aurora-pg
aws rds describe-db-clusters --db-cluster-identifier dev-aurora-pg \
  --query "DBClusters[0].Status" --output text

Repeat the second command until it prints stopped.

Start it

aws rds start-db-cluster --db-cluster-identifier dev-aurora-pg
aws rds wait db-cluster-available --db-cluster-identifier dev-aurora-pg

Startup time depends on database size, instance classes and the state at shutdown. AWS says it can take minutes to hours, so trigger it well before the working day starts.

Seven days, then it starts itself

A cluster can stay stopped for up to seven days. After that Aurora starts it automatically to keep up with maintenance, and from that moment every instance bills instance-hours again. A nightly stop resets the clock every day. For a cluster parked over a long holiday, the stop has to be reissued at least once a week.

What you pay while it is stopped

Only cluster storage, manual snapshots and automated backup storage inside the retention window. There is no charge for DB instance hours, so the saving is the instance line for the hours the cluster is down; the storage line is unchanged.

What you cannot do while it is stopped

You cannot modify the cluster or its instances, add or remove instances, or delete a cluster that still has instances. You can run a point-in-time restore to any point in the backup retention window. Stopping also clears pending modifications other than parameter group changes, and scheduled maintenance is applied after the next start.

Confirm nothing restarted behind your back

aws rds describe-events --source-type db-cluster \
  --source-identifier dev-aurora-pg --duration 10080

This returns a week of cluster events (RDS keeps events for 14 days). An automatic start shows up here before it shows up on the bill.

Where ZopNight fits

ZopNight schedules use cron start and stop expressions in an IANA timezone, and a force-on or force-off override with an expiry covers the week someone needs the database outside the window. For which RDS cluster configurations ZopNight can act on, check the RDS and Aurora cluster scheduling page; for single instances see scheduling RDS DB instances.