# Aurora Serverless v2 Minimum Capacity Preventing Auto-Pause

Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/aurora-serverless-v2-minimum-capacity-preventing-auto-pause

Aurora Serverless v2 instances can scale down to zero ACUs and automatically pause when they have had no user-initiated connections for a configurable...

By: PointFive

Updated: 2026-09-28

[Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) 

The short version

Aurora Serverless v2 instances can scale down to zero ACUs and automatically pause when they have had no user-initiated connections for a configurable interval, and there is no instance charge while an instance is paused.

PointFive Research

Cloud cost research at PointFive

AWS service

[AWS Aurora](https://www.pointfive.co/efficiency-hub/cloud-services/aws-aurora)

Category

[Databases](https://www.pointfive.co/efficiency-hub/service-category/databases)

Reference

CER-0378

Type

Inefficient Configuration

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

- [Scaling to Zero ACUs with automatic pause and resume for Aurora serverless  docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html)

- [Amazon Aurora Pricing  aws.amazon.com](https://aws.amazon.com/rds/aurora/pricing/)

- [Viewing idle resource recommendations  docs.aws.amazon.com](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-idle-recommendations.html)

## Related inefficiencies

[Browse the library](https://www.pointfive.co/efficiency-hub)

- AWS Aurora  CER-0043

### [Suboptimal Storage Configuration for Aurora Cluster](https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-storage-configuration-for-aurora-cluster)

Many Aurora clusters default to using the Standard configuration, which charges separately for I/O operations. For workloads with frequent read and write activity, this can lead to unnecessarily high costs. Aurora I/O-Optimized eliminates...

Databases

- AWS Aurora  CER-0293

### [Automatic Restart of Stopped Aurora Clusters Causing Unintended Compute Charges](https://www.pointfive.co/efficiency-hub/inefficiencies/automatic-restart-of-stopped-aurora-clusters-causing-unintended-compute-charges)

Amazon Aurora database clusters are intentionally stopped to avoid compute costs but are automatically restarted by the service after the maximum allowed stop period. Once restarted, re-started database instances begin accruing...

Databases

- AWS Aurora  CER-0247

### [Misuse of Aurora Serverless for Steady-State Workloads](https://www.pointfive.co/efficiency-hub/inefficiencies/misuse-of-aurora-serverless-for-steady-state-workloads-6c2d9)

Aurora Serverless is designed for workloads with unpredictable or intermittent usage patterns that benefit from automatic scaling. However, when used for databases with constant load, the service's elasticity offers little advantage and...

Databases

---
Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.

