Provisioned dev and test Aurora clusters idle off-hours that could be stopped on a schedule

Stopped Aurora clusters bill storage, not instances

Aurora lets you stop a whole DB cluster in one action. According to the stop and start documentation, while a cluster is stopped you are charged only for cluster storage, manual snapshots and automated backup storage within the retention window, not for DB instance hours. The same page limits a stop to seven days, after which Aurora starts the cluster again on its own.

For a development cluster that nobody touches at night or at weekends, the instance hours in those windows are the recoverable cost.

Checking your provisioned clusters

aws rds describe-db-clusters \
  --query 'DBClusters[?EngineMode==`provisioned`].[DBClusterIdentifier,Engine,Status,DBClusterMembers[0].DBInstanceIdentifier]' \
  --output table

aws rds describe-db-instances \
  --query 'DBInstances[?DBClusterIdentifier==`dev-orders`].[DBInstanceIdentifier,DBInstanceClass]'

Then compare the members’ DatabaseConnections and CPUUtilization across a week to see the quiet hours.

Conditions for a schedule finding

• The cluster status is available. A stopped or transitional cluster is skipped because its pricing baseline is wrong until it is running again.
• It runs in provisioned mode and is not already Aurora Serverless v2, which scales down on its own.
• Its name matches a dev or test pattern (dev, test, qa, staging, sandbox) and not a production one.
• ZopNight has a measured weekly usage pattern for the cluster with an idle share above zero.
• The cluster’s member instances are known and priced.

When no schedule is suggested

With no measured pattern, no idle time or unpriced members, the rule is silent. It never applies a standard evening-and-weekend assumption and never shows a $0 recommendation.

Member compute times the idle share

saving = monthly compute of member DB instances x idle share (capped at 1)

Aurora prices a provisioned cluster’s storage separately from its instances, and storage keeps billing while the cluster is stopped, so it is excluded. The cap stops a malformed idle value from claiming more than the compute that a stop can remove.

Stopping and starting the cluster on a schedule

1. Review the suggested start, stop and time zone, then apply the schedule from ZopNight so the cluster stops and starts automatically.
2. To test manually: aws rds stop-db-cluster --db-cluster-identifier dev-orders and aws rds start-db-cluster --db-cluster-identifier dev-orders.
3. For bursty workloads, consider Aurora Serverless v2 instead. Its capacity range can go down to 0 ACUs on versions that support auto-pause.