AWS Database Blog

Introducing scaling to 0 capacity with Amazon Aurora Serverless v2

Amazon Aurora Serverless v2 now supports scaling capacity down to 0 ACUs, enabling you to optimize costs during periods of database inactivity. Aurora Serverless is an on-demand, auto scaling configuration of Aurora that automatically adjusts your database capacity based on your workload requirements. Aurora Serverless measures database capacity in Aurora Capacity Units (ACUs) billed per second. 1 ACU has approximately 2 GiB of memory with corresponding CPU and networking, similar to that used in Aurora provisioned instances. With this new launch and recent launch of maximum capacity of 256 ACUs, your serverless instance can now scale between 0 ACUs and 256 ACUs.

In this post, we show you how to use automatic pause and resume capability with 0 ACUs to help you save cost during periods of database inactivity.

Solution Overview

With 0 ACUs, Aurora Serverless v2 DB instances can automatically pause after a period of inactivity. Aurora pauses an Aurora Serverless v2 instance if it doesn’t have connections initiated by user activity within the specified time period. For the paused duration, there are no charges for compute as the database is at 0 ACUs. You will be charged for storage during this time. When the first connection is requested, the database will automatically resume and scale to meet the application demand. It can take up to 15 seconds for the database to resume. After resuming, the database will be billed per ACU per second for compute.

Automatic pause and resume feature helps you manage costs for applications that don’t have a stringent service-level objective. For workloads, that can tolerate a resume time of approximately 15 seconds, you can use this feature in the following cases:

  • Clusters used for development and testing
  • Applications where a cold start is acceptable while the database resumes

Prerequisites

To follow along with this post, you should have the following:

  1. An AWS account
  2. Amazon Aurora PostgreSQL-Compatible Edition running:
    • version 16.3 and higher
    • version 15.7 and higher
    • version 14.12 and higher
    • version 13.15 and higher

Alternatively, you can also use Amazon Aurora MySQL-Compatible Edition running version 3.08.0 or higher

Set up

You can configure the automatic pause functionality when creating your database or by modifying an existing cluster.

The automatic pause is enabled by setting the minimum capacity of 0 ACUs and is configurable at the cluster level.

When you choose a minimum capacity of 0 ACUs, you can also specify the length of time for the instance to be idle (Period after inactivity) before it automatically pauses. You can specify between 300 seconds (5 minutes) and 86,400 seconds (24 hours) for the delay period with no database traffic before pause is initiated.

You can also create an Aurora cluster with the automatic pause feature enabled using the AWS Command Line Interface (AWS CLI). See the following code:

aws rds create-db-cluster \
--db-cluster-identifier my-serverless-v2-cluster \
--region us-east-1 \
--engine aurora-postgresql \
--engine-version 16.3 \
--serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \                           
--master-username myuser \
--manage-master-user-password

Setting the minimum capacity to 0.5 or greater disables the automatic pause feature.

Pause an Aurora Serverless v2 instance

When an Aurora Serverless v2 instance is automatically paused, the status of the instance is shown as Available, but the instance charges for that instance are put on hold. The ServerlessV2Usage metric in AWS Cost Explorer or the ACUUtilization metric in Amazon CloudWatch has a value of 0 while the instance is paused.

  • Aurora begins pausing the instance when the specified delay period passes with no connections to the instance, regardless of how many ACUs the instance has at the time
    When the instance is paused, it stops writing to the database log files. It also stops sending metrics to CloudWatch. The only metrics sent to CloudWatch while an instance is paused are CPUUtilization and ACUUtilization registering 0%, and 0 for ServerlessDatabaseCapacity.
    Additionally, Aurora doesn’t collect monitoring information for that instance through either Amazon RDS Performance Insights or Enhanced Monitoring.
  • Aurora emits cluster-level events when an Aurora Serverless v2 DB instance begins pausing, finishes pausing, and if the pause mechanism is interrupted or is unsuccessful.

There are some scenarios when an Aurora Serverless v2 instance doesn’t automatically pause:

  • If user-initiated connections are open, the instance doesn’t automatically pause
  • If an Aurora PostgreSQL cluster has logical replication enabled or an Aurora MySQL cluster that has binlog replication enabled, the writer instance doesn’t automatically pause.
  • If your Aurora cluster has an associated proxy through Amazon RDS Proxy, the proxy maintains an open connection to each DB instance in the cluster and the instance doesn’t automatically pause.
  • If your cluster is the primary cluster in an Aurora global database, Aurora doesn’t automatically pause the Aurora Serverless v2 writer instance.
  • If your cluster is the secondary cluster in an Aurora global database, Aurora doesn’t automatically pause the Aurora Serverless v2 reader instances

Resume a paused instance

When the auto-pause feature is enabled, the Aurora Serverless v2 instance automatically resumes under the following conditions:

  • When the cluster is not stopped and you connect to a paused Aurora Serverless v2 instance, the instance automatically resumes regardless of if that connection was a failed or successful connection attempt.
  • Whenever a writer instance is automatically resumed, the reader instance with a failover tier of 0 and 1 is also resumed. A writer instance will automatically resume when you connect to it, send a request to your cluster using the RDS Data API, or modify an instance.
  • When you connect to a reader endpoint and the reader instance it connects to is paused, the following instances are also resumed:
    • The writer instance
    • Reader instance
    • Other reader instances with a failover tier of 0 and 1
  • When you perform a backtrack request in Aurora MySQL-Compatible, the instance resumes.
  • When you create an Aurora clone, the instance automatically resumes.
  • When a maintenance task needs to be performed during the maintenance window, the instance automatically resumes.
  • When the cluster undergoes a failover to a paused Aurora Serverless v2 instance, the instance automatically resumes.
  • When you change the properties of the cluster, for example:
    • Change the value of a parameter in a DB cluster parameter group
    • Change the value of a parameter in a DB instance parameter group
    • Change the scaling range of the cluster
    • Upgrade the engine version of the cluster
    • Describe or download log files from a paused Aurora Serverless v2 instance
    • Enable or disable Performance Insights
  • Aurora emits cluster-level events when each Aurora Serverless v2 DB instance begins resuming and finishes resuming.

When an Aurora Serverless v2 instance resumes, it doesn’t resume at the same ACU that it was at before it was automatically paused. Once the instance is resumed, it scales up based on the demand of the workload.

Requested connections are established after the DB instance finishes resuming. It takes less than 15 seconds to resume so we recommend that you adjust the client timeout settings (connectTimeout and sslResponseTimeout) to be longer than 15 seconds. We also recommend implementing retry logic for connections to Aurora clusters that have Aurora Serverless v2 instances with the automatic pause and resume capabilities.

Deployment patterns

You can set up different cluster configurations with Aurora Serverless v2 with automatic pause and resume capability enabled based on the high availability, fast response, and scalability requirements of your use case. In this section, we discuss some possible cluster configurations.

For development and test environment, you can set up a single-AZ DB cluster with an Aurora Serverless v2 DB instance. The single instance serves the read and write requests. When there are zero connections to the cluster, the DB instance automatically pauses. At that point, the DB instance compute costs for your cluster are also paused. You are still charged for storage.

For a system running an application where high availability is a priority, but the cluster still has periods where it’s entirely idle, you can set up a multi-AZ cluster where both the writer and reader DB instances are Aurora Serverless v2 with minimum ACU of 0. Set the reader failover tier to be 0 so that the reader follows the capacity of the writer instance.

You might have a system in which your cluster is constantly active with some minimal amount of activity, and requires a faster response for database connection. You can set up a custom endpoint that includes Aurora Serverless v2 instances with higher failover promotion tiers. This allows you to direct read-only sessions that aren’t sensitive to latency to the readers that can be paused automatically. Since there is minimal activity at all times for the writer, the writer and reader with failover priority zero won’t be automatically paused.

You can also use provisioned instances for the writer instance and failover priority 0 or 1 reader instance so it is never paused and is always available to serve database traffic and to perform failovers. This configuration also allows you to manage costs and have the additional reader instances that can be automatically paused depending on the read traffic.

Considerations

Consider the following when using 0 ACUs for minimum capacity to enable automatic pause and resume capability for Aurora Serverless v2:

  • The reader instances with failover priority 0 and 1 follow the behavior of the writer instance. If the writer pauses automatically, these readers will also pause. Similarly, if a paused writer resumes automatically, these readers will also resume.
  • Aurora Serverless v2 instances in the secondary clusters of an Aurora global database don’t automatically pause. In the primary cluster, the writer instance doesn’t pause, but reader instances in failover promotion tiers 2–15 can automatically pause if there are no connections.
  • Instances that are part of a cluster with an associated zero-ETL integration to Amazon Redshift don’t automatically pause.
  • Aurora Serverless v2 doesn’t automatically resume a paused instance for engine-specific scheduled jobs, such as those in the PostgreSQL autovacuum, the PostgreSQL pg_cron extension, or the MySQL event scheduler.
  • When the reader endpoint randomly picks a reader instance to connect to, that reader instance might already be active or might be paused. Therefore, the time to access the reader instance might vary and be harder to predict. Multi-AZ clusters that use Aurora Serverless v2 and the automatic pause capability might benefit from setting up custom endpoints for specific read-only use cases, instead of directing all read-only sessions to the reader endpoint.

Conclusion

In this post, we discussed how to enable the automatic pause and resume capability by setting minimum capacity to 0 ACUs in Aurora Serverless v2, which allows you to save on cost during periods of database inactivity. We discussed the criteria that allow an instance to automatically pause or resume, as well as factors that can prevent an instance from scaling down to 0 ACUs.

To learn more about the auto-pause feature in Aurora Serverless v2, refer to Automatic pause and resume for Aurora Serverless v2 documentation.

About the authors

Jason Pedreza is a Senior Database Specialist Solutions Architect at AWS with experience handling petabytes of data. He specializes in managed PostgreSQL and helps customers build scalable database solutions.

Anum Jang Sher is a product manager on the Amazon Aurora team. She is passionate about building delightful customer experiences for scalable, cost-effective, and highly available database solutions. In her current role, she is committed to understanding customer needs and translating them into innovative features to enhance Amazon Aurora.