Explanation
Why the waste happens and who it affects.
The feature is switched on only by setting the cluster's minimum capacity to 0 ACUs. Clusters created before the feature existed had a lowest possible minimum of 0.5 ACUs, and many templates still set 0.5 or more, so development, test, demo and internal clusters that sit idle overnight and at weekends keep billing their minimum capacity around the clock.
Setting the minimum to zero is not always enough. An instance will not pause while any user-initiated connection is open or while an RDS Proxy is attached, and the writer (with readers in failover tiers 0 and 1) stays awake when logical or binlog replication or a zero-ETL integration is enabled, when the cluster is the primary or a secondary of an Aurora global database, or when the cluster also contains provisioned instances. Idle IDE sessions, connection pools that hold connections open, and frequent application health-check queries are common reasons a cluster that looks configured for auto-pause never pauses.
Billing model
The pricing dimensions that drive this cost.
- Aurora capacity units
- Serverless v2 compute is billed per second in ACUs for the capacity each instance uses, never below the configured minimum while it is running
- Minimum capacity floor
- A minimum of 0.5 ACUs or more is billed continuously even when the database has no activity
- Paused instance
- An auto-paused instance has no instance charge and its ServerlessV2Usage metric is zero
- Cluster storage
- Aurora storage and other cluster-level charges continue to be billed while instances are paused
How to detect
5 checks to find it in your estate.
- List Serverless v2 clusters with describe-db-clusters and check ServerlessV2ScalingConfiguration; a MinCapacity above 0 with no SecondsUntilAutoPause means auto-pause is off
- For those clusters, look for long periods where ServerlessDatabaseCapacity sits at the minimum and DatabaseConnections is zero, which shows the time that could have been paused
- For clusters with MinCapacity 0, check how often the minimum of ServerlessDatabaseCapacity reaches zero; if it rarely does, review DatabaseConnections, ConnectionAttempts and the Aurora pause and resume activity log for the reason
- Check for blockers: an associated RDS Proxy, logical or binlog replication, zero-ETL integrations, global database membership, provisioned instances in the cluster, and reader instances in failover tiers 0 or 1
- Confirm the engine version supports 0 ACUs (Aurora PostgreSQL 16.3, 15.7, 14.12, 13.15 or later; Aurora MySQL 3.08.0 or later), and review Compute Optimizer idle recommendations for Aurora instances
How to fix
5 ways to remove the waste.
- Upgrade clusters on unsupported engine versions, then set MinCapacity to 0 with modify-db-cluster and choose a SecondsUntilAutoPause between 300 and 86,400 seconds that matches the idle pattern
- Close idle client sessions and tune connection pools so they release connections, and remove RDS Proxy from clusters that are meant to pause
- Set reader instances used only for read scaling to failover priority 2-15 so they can pause independently of the writer
- Make applications tolerate resume latency, which AWS describes as typically about 15 seconds and 30 seconds or more after a pause longer than 24 hours, with longer connection timeouts and retry logic
- Keep a nonzero minimum only where the workload cannot accept resume delays, and note that scheduled jobs such as pg_cron or the MySQL event scheduler do not wake a paused instance
Documentation
Vendor references for pricing and configuration.