RDS Aurora Serverless v2 cannot shrink to 0 ACU due to unknown process

Question

Q has sent me here after 1 hour of investigation.

AmazonQ:

> The fact that pg_stat_activity shows almost nothing active while CPU is at 11% indicates this is likely an Aurora infrastructure issue rather than a PostgreSQL application issue.

After a reboot, my Serverless v2 Postgres 16.6 Aurora database (1 read/write in the cluster) has a CPU of 11%. It never degrades (after hours). The total database size is roughly 500MB. Region: eu-west-2.

I've tried Performance Insights and apart from the load that it causes, there are no results in any of the tabs. pg_stat is empty (apart from the query used to read it).
The log content after the last reboot is:

```
 2025-08-15 12:43:26.307 GMT [52485] LOG: skipping missing configuration file "/rdsdbdata/config/recovery.conf"
2025-08-15 12:43:26.308 GMT [52485] LOG: skipping missing configuration file "/rdsdbdata/config/recovery.conf"
2025-08-15 12:43:26 UTC::@:[52485]:WARNING: invalid configuration parameter name "rds.babelfish_status", removing it
2025-08-15 12:43:26 UTC::@:[52485]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:26 UTC::@:[52485]:WARNING: invalid configuration parameter name "rds.adaptive_autovacuum", removing it
2025-08-15 12:43:26 UTC::@:[52485]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:26 UTC::@:[52485]:WARNING: invalid configuration parameter name "rds.csd_test_parameter_3", removing it
2025-08-15 12:43:26 UTC::@:[52485]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:26 UTC::@:[52485]:WARNING: invalid configuration parameter name "rds.enable_plan_management", removing it
2025-08-15 12:43:26 UTC::@:[52485]:DETAIL: "rds" is now a reserved prefix.
Postgres Shared Memory Value: 427819008 bytes
2025-08-15 12:43:29.127 GMT [579] LOG: skipping missing configuration file "/rdsdbdata/config/recovery.conf"
2025-08-15 12:43:29.127 GMT [579] LOG: skipping missing configuration file "/rdsdbdata/config/recovery.conf"
2025-08-15 12:43:29 UTC::@:[579]:WARNING: invalid configuration parameter name "rds.babelfish_status", removing it
2025-08-15 12:43:29 UTC::@:[579]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:29 UTC::@:[579]:WARNING: invalid configuration parameter name "rds.adaptive_autovacuum", removing it
2025-08-15 12:43:29 UTC::@:[579]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:29 UTC::@:[579]:WARNING: invalid configuration parameter name "rds.csd_test_parameter_3", removing it
2025-08-15 12:43:29 UTC::@:[579]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:29 UTC::@:[579]:WARNING: invalid configuration parameter name "rds.enable_plan_management", removing it
2025-08-15 12:43:29 UTC::@:[579]:DETAIL: "rds" is now a reserved prefix.
2025-08-15 12:43:29 UTC::@:[579]:LOG: Clean shutdown flag file does not exist
2025-08-15 12:43:29 UTC::@:[579]:LOG: Skipped resetting shared memory for Checkpointer data
2025-08-15 12:43:29 UTC::@:[579]:LOG: redirecting log output to logging collector process
2025-08-15 12:43:29 UTC::@:[579]:HINT: Future log output will appear in directory "/rdsdbdata/log/error".
```

Many thanks in advance.

Rob Lang · Accepted Answer

Custom parameter settings had logical replication switched on.

The bot's checklist:
* Check if you're using a supported version: 16.6  ✅
* Verify your minimum ACU setting is set to 0:  ✅
* Review any custom parameter settings: ❌ (see below)
* Check for background processes using pg_stat_activity (though you mentioned this is empty):  ✅
* Consider increasing the auto-pause timeout interval: 5 minutes was enough ✅

Our databases and parameter settings have been upgraded for many years, starting at Postgres 9. At some point during that upgrade process `rds.logical_replication` had been engaged with the following parameters:

* max_logical_replication_workers 110 
* max_replication_slots 110 
* max_wal_senders 115 
* max_worker_processes 115 
* rds.logical_replication 1

We do not use Postgres Logical Replication. You can see what custom parameters you have by going to RDS -> Parameter Groups -> Choose Group -> Click on "Source" column header until you Modified (might need to click twice to sort descending).
Using the default database parameters and rebooting the instance [WARNING DOWNTIME!] switched off the replication and now the ACU goes to 0.

re:Post Agent · Answer

Aurora Serverless v2 now supports scaling to 0 ACUs (automatic pause and resume), but there are several reasons why your database might not be scaling down as expected:

1. **Version Requirements**: The ability to scale to 0 ACUs is only supported in specific versions of Aurora PostgreSQL (13.15+, 14.12+, 15.7+, and 16.3+) and Aurora MySQL (3.08+). Make sure your database is running a supported version.

2. **Configuration**: You need to explicitly set the minimum capacity to 0 ACUs for your cluster. For existing clusters, you must update to a supported version and then modify this setting.

3. **Database Parameters**: Certain PostgreSQL DB parameters can prevent scaling down. For example, non-default values for parameters like `max_connections`, `max_locks_per_transaction`, or `track_activity_query_size` might prevent reaching the minimum ACU.

4. **Background Processes**: Internal operations such as PostgreSQL autovacuum or jobs scheduled through the `pg_cron` extension might be running. These processes can prevent the database from scaling down completely.

5. **Connection Activity**: Aurora begins pausing the instance only when the specified delay period passes with no connections to the instance. Any active connections will prevent scaling to 0.

6. **Specific Configurations**: Certain configurations prevent auto-pause, including when using logical replication, binlog replication, Amazon RDS Proxy, or when the cluster is part of an Aurora global database.

To troubleshoot:
- Check if you're using a supported version
- Verify your minimum ACU setting is set to 0
- Review any custom parameter settings
- Check for background processes using pg_stat_activity (though you mentioned this is empty)
- Consider increasing the auto-pause timeout interval

If all these are configured correctly and the issue persists, it might be an infrastructure issue as AmazonQ suggested, which would require AWS Support assistance.  
**Sources**  
[Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 | AWS Database Blog](https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/)  
[Amazon Aurora Serverless v2 supports scaling to zero capacity - AWS](https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-aurora-serverless-v2-scaling-zero-capacity/)  
[Understanding how certain database parameters impact scaling in Amazon Aurora Serverless v2 | AWS Database Blog](https://aws.amazon.com/blogs/database/understanding-how-certain-database-parameters-impact-scaling-in-amazon-aurora-serverless-v2/)  
[Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2 - Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html)

RDS Aurora Serverless v2 cannot shrink to 0 ACU due to unknown process

Add your answer

Relevant content