# Using Aurora Serverless v2
Using Aurora Serverless v2<a name="serverless_v2"></a><a name="asv2"></a>

 Aurora Serverless v2 is an on-demand, autoscaling configuration for Amazon Aurora. Aurora Serverless v2 helps to automate the processes of monitoring the workload and adjusting the capacity for your databases. Capacity is adjusted automatically based on application demand. You're charged only for the resources that your DB clusters consume. Thus, Aurora Serverless v2 can help you to stay within budget and avoid paying for computer resources that you don't use. 

 This type of automation is especially valuable for multitenant databases, distributed databases, development and test systems, and other environments with highly variable and unpredictable workloads. 

**Topics**
+ [

## Aurora Serverless v2 use cases
](#aurora-serverless-v2.use-cases)
+ [

## Advantages of Aurora Serverless v2
](#aurora-serverless-v2.advantages)
+ [

# How Aurora Serverless v2 works
](aurora-serverless-v2.how-it-works.md)
+ [

# Requirements and limitations for Aurora Serverless v2
](aurora-serverless-v2.requirements.md)
+ [

# Creating a DB cluster that uses Aurora Serverless v2
](aurora-serverless-v2.create.md)
+ [

# Managing Aurora Serverless v2 DB clusters
](aurora-serverless-v2-administration.md)
+ [

# Performance and scaling for Aurora Serverless v2
](aurora-serverless-v2.setting-capacity.md)
+ [

# Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2
](aurora-serverless-v2-auto-pause.md)
+ [

# Migrating to Aurora Serverless v2
](aurora-serverless-v2.upgrade.md)

## Aurora Serverless v2 use cases


Aurora Serverless v2 supports many types of database workloads. These range from development and testing environments, to websites and applications that have unpredictable workloads, to the most demanding, business-critical applications that require high scale and availability.

Aurora Serverless v2 is especially useful for the following use cases:
+  **Variable workloads** – You're running workloads that have sudden and unpredictable increases in activity. An example is a traffic site that sees a surge of activity when it starts raining. Another is an e-commerce site with increased traffic when you offer sales or special promotions. With Aurora Serverless v2, your database automatically scales capacity to meet the needs of the application's peak load and scales back down when the surge of activity is over. With Aurora Serverless v2, you no longer need to provision for peak or average capacity. You can specify an upper capacity limit to handle the worst-case situation, and that capacity isn't used unless it's needed. 

   The granularity of scaling in Aurora Serverless v2 helps you to match capacity closely to your database's needs. For a provisioned cluster, scaling up requires adding a whole new DB instance. For an Aurora Serverless v1 cluster, scaling up requires doubling the number of Aurora capacity units (ACUs) for the cluster, such as from 16 to 32 or 32 to 64. In contrast, Aurora Serverless v2 can add half an ACU when only a little more capacity is needed. It can add 0.5, 1, 1.5, 2, or additional half-ACUs based on the additional capacity needed to handle an increase in workload. And it can remove 0.5, 1, 1.5, 2, or additional half-ACUs when the workload decreases and that capacity is no longer needed. 
+  **Multi-tenant applications** – With Aurora Serverless v2, you don't have to individually manage database capacity for each application in your fleet. Aurora Serverless v2 manages individual database capacity for you. 

   You can create a cluster for each tenant. That way, you can use features such as cloning, snapshot restore, and Aurora global databases to enhance high availability and disaster recovery as appropriate for each tenant. 

   Each tenant might have specific busy and idle periods depending on the time of day, time of year, promotional events, and so on. Each cluster can have a wide capacity range. That way, clusters with low activity incur minimal DB instance charges. Any cluster can quickly scale up to handle periods of high activity. 
+  **New applications** – You're deploying a new application and you're unsure about the DB instance size you need. By using Aurora Serverless v2, you can set up a cluster with one or many DB instances and have the database autoscale to the capacity requirements of your application. 
+  **Mixed-use applications** – Suppose that you have an online transaction processing (OLTP) application, but you periodically experience spikes in query traffic. By specifying promotion tiers for the Aurora Serverless v2 DB instances in a cluster, you can configure your cluster so that the reader DB instances can scale independently of the writer DB instance to handle the additional load. When the usage spike subsides, the reader DB instances scale back down to match the capacity of the writer DB instance. 
+  **Capacity planning** – Suppose that you usually adjust your database capacity, or verify the optimal database capacity for your workload, by modifying the DB instance classes of all the DB instances in a cluster. With Aurora Serverless v2, you can avoid this administrative overhead. You can determine the appropriate minimum and maximum capacity by running the workload and checking how much the DB instances actually scale. 

   You can modify existing DB instances from provisioned to Aurora Serverless v2 or from Aurora Serverless v2 to provisioned. You don't need to create a new cluster or a new DB instance in such cases. 

   With an Aurora global database, you might not need as much capacity for the secondary clusters as in the primary cluster. You can use Aurora Serverless v2 DB instances in the secondary clusters. That way, the cluster capacity can scale up if a secondary region is promoted and takes over your application's workload. 
+ **Development and testing** – In addition to running your most demanding applications, you can also use Aurora Serverless v2 for development and testing environments. With Aurora Serverless v2, you can create DB instances with a low minimum capacity instead of using burstable db.t\$1 DB instance classes. You can set the maximum capacity high enough that those DB instances can still run substantial workloads without running low on memory. When the database isn't in use, all of the DB instances scale down to avoid unnecessary charges.
**Tip**  
 To make it convenient to use Aurora Serverless v2 in development and test environments, the AWS Management Console provides the **Easy create** shortcut when you create a new cluster. If you choose the **Dev/Test** option, Aurora creates a cluster with an Aurora Serverless v2 DB instance and a capacity range that's typical for a development and test system. 

### Using Aurora Serverless v2 for existing provisioned workloads
Converting provisioned workloads

 Suppose that you already have an Aurora application running on a provisioned cluster. You can check how the application would work with Aurora Serverless v2 by adding one or more Aurora Serverless v2 DB instances to the existing cluster as reader DB instances. You can check how often the reader DB instances scale up and down. You can use the Aurora failover mechanism to promote an Aurora Serverless v2 DB instance to be the writer and check how it handles the read/write workload. That way, you can switch over with minimal downtime and without changing the endpoint that your client applications use. For details on the procedure to convert existing clusters to Aurora Serverless v2, see [Migrating to Aurora Serverless v2](aurora-serverless-v2.upgrade.md). 

## Advantages of Aurora Serverless v2


 Aurora Serverless v2 is intended for variable or "spiky" workloads. With such unpredictable workloads, you might have difficulty planning when to change your database capacity. You might also have trouble making capacity changes quickly enough using the familiar mechanisms such as adding DB instances or changing DB instance classes. Aurora Serverless v2 provides the following advantages to help with such use cases: 
+  **Simpler capacity management than provisioned** – Aurora Serverless v2 reduces the effort for planning DB instance sizes and resizing DB instances as the workload changes. It also reduces the effort for maintaining consistent capacity for all the DB instances in a cluster. 
+  **Faster and easier scaling during periods of high activity** – Aurora Serverless v2 scales compute and memory capacity as needed, with no disruption to client transactions or your overall workload. The ability to use reader DB instances with Aurora Serverless v2 helps you to take advantage of horizontal scaling in addition to vertical scaling. The ability to use Aurora global databases means that you can spread your Aurora Serverless v2 read workload across multiple AWS Regions. This capability is more convenient than the scaling mechanisms for provisioned clusters. It's also faster and more granular than the scaling capabilities in Aurora Serverless v1. 
+  **Cost-effective during periods of low activity** – Aurora Serverless v2 helps you to avoid overprovisioning your DB instances. Aurora Serverless v2 adds resources in granular increments when DB instances scale up. You pay only for the database resources that you consume. Aurora Serverless v2 resource usage is measured on a per-second basis. That way, when a DB instance scales down, the reduced resource usage is registered right away. 
+  **Greater feature parity with provisioned** – You can use many Aurora features with Aurora Serverless v2 that aren't available for Aurora Serverless v1. For example, with Aurora Serverless v2 you can use reader DB instances, global databases, AWS Identity and Access Management (IAM) database authentication, and Performance Insights. You can also use many more configuration parameters than with Aurora Serverless v1. 

   In particular, with Aurora Serverless v2 you can take advantage of the following features from provisioned clusters: 
  + **Reader DB instances** – Aurora Serverless v2 can take advantage of reader DB instances to scale horizontally. When a cluster contains one or more reader DB instances, the cluster can fail over immediately in case of problems with the writer DB instance. This is a capability that isn't available with Aurora Serverless v1.
  +  **Multi-AZ clusters** – You can distribute the Aurora Serverless v2 DB instances of a cluster across multiple Availability Zones (AZs). Setting up a Multi-AZ cluster helps to ensure business continuity even in the rare case of issues that affect an entire AZ. This is a capability that isn't available with Aurora Serverless v1.
  + **Global databases** – You can use Aurora Serverless v2 in combination with Aurora global databases to create additional read-only copies of your cluster in other AWS Regions for disaster recovery purposes.
  + **RDS Proxy** – You can use Amazon RDS Proxy to allow your applications to pool and share database connections to improve their ability to scale.
+  **Faster, more granular, less disruptive scaling than Aurora Serverless v1** – Aurora Serverless v2 can scale up and down faster. Scaling can change capacity by as little as 0.5 ACUs, instead of doubling or halving the number of ACUs. Scaling typically happens with no pause in processing at all. Scaling doesn't involve an event that you have to be aware of, as with Aurora Serverless v1. Scaling can happen while SQL statements are running and transactions are open, without the need to wait for a quiet point. 

# How Aurora Serverless v2 works


The following overview describes how Aurora Serverless v2 works.

**Topics**
+ [Overview](#aurora-serverless-v2.architecture)
+ [Cluster configurations](#aurora-serverless-v2.how-it-works.cluster_topology)
+ [Capacity](#aurora-serverless-v2.how-it-works.capacity)
+ [Scaling](#aurora-serverless-v2.how-it-works.scaling)
+ [High availability](#aurora-serverless.ha)
+ [Storage](#aurora-serverless.storage)
+ [Configuration parameters](#aurora-serverless-v2.parameters)

## Aurora Serverless v2 overview
Overview

*Amazon Aurora Serverless v2* is suitable for the most demanding, highly variable workloads. For example, your database usage might be heavy for a short period of time, followed by long periods of light activity or no activity at all. Some examples are retail, gaming, or sports websites with periodic promotional events, and databases that produce reports when needed. Others are development and testing environments, and new applications where usage might ramp up quickly. For cases such as these and many others, configuring capacity correctly in advance isn't always possible with the provisioned model. It can also result in higher costs if you overprovision and have capacity that you don't use.

In contrast, *Aurora provisioned clusters* are suitable for steady workloads. With provisioned clusters, you choose a DB instance class that has a predefined amount of memory, CPU power, I/O bandwidth, and so on. If your workload changes, you manually modify the instance class of your writer and readers. The provisioned model works well when you can adjust capacity in advance of expected consumption patterns and it's acceptable to have brief outages while you change the instance class of the writer and readers in your cluster.

Aurora Serverless v2 is architected from the ground up to support serverless DB clusters that are instantly scalable. Aurora Serverless v2 is engineered to provide the same degree of security and isolation as with provisioned writers and readers. These aspects are crucial in multitenant serverless cloud environments. The dynamic scaling mechanism has very little overhead so that it can respond quickly to changes in the database workload. It's also powerful enough to meet dramatic increases in processing demand.

By using Aurora Serverless v2, you can create an Aurora DB cluster without being locked into a specific database capacity for each writer and reader. You specify the minimum and maximum capacity range. Aurora scales each Aurora Serverless v2 writer or reader in the cluster within that capacity range. By using a Multi-AZ cluster where each writer or reader can scale dynamically, you can take advantage of dynamic scaling and high availability.

Aurora Serverless v2 scales the database resources automatically based on your minimum and maximum capacity specifications. Scaling is fast because most scaling events operations keep the writer or reader on the same host. In the rare cases that an Aurora Serverless v2 writer or reader is moved from one host to another, Aurora Serverless v2 manages the connections automatically. You don't need to change your database client application code or your database connection strings.

With Aurora Serverless v2, as with provisioned clusters, storage capacity and compute capacity are separate. When we refer to Aurora Serverless v2 capacity and scaling, it's always compute capacity that's increasing or decreasing. Thus, your cluster can contain many terabytes of data even when the CPU and memory capacity scale down to low levels.

Instead of provisioning and managing database servers, you specify database capacity. For details about Aurora Serverless v2 capacity, see [Aurora Serverless v2 capacity](#aurora-serverless-v2.how-it-works.capacity). The actual capacity of each Aurora Serverless v2 writer or reader varies over time, depending on your workload. For details about that mechanism, see [Aurora Serverless v2 scaling](#aurora-serverless-v2.how-it-works.scaling).

**Important**  
With Aurora Serverless v1, your cluster has a single measure of compute capacity that can scale between the minimum and maximum capacity values. With Aurora Serverless v2, your cluster can contain readers in addition to the writer. Each Aurora Serverless v2 writer and reader can scale between the minimum and maximum capacity values. Thus, the total capacity of your Aurora Serverless v2 cluster depends on both the capacity range that you define for your DB cluster and the number of writers and readers in the cluster. At any specific time, you are only charged for the Aurora Serverless v2 capacity that is being actively used in your Aurora DB cluster.

## Configurations for Aurora DB clusters
Cluster configurations

For each of your Aurora DB clusters, you can choose any combination of Aurora Serverless v2 capacity, provisioned capacity, or both.

You can set up a cluster that contains both Aurora Serverless v2 and provisioned capacity, called a *mixed-configuration cluster*. For example, suppose that you need more read/write capacity than is available for an Aurora Serverless v2 writer. In this case, you can set up the cluster with a very large provisioned writer. In that case, you can still use Aurora Serverless v2 for the readers. Or suppose that the write workload for your cluster varies but the read workload is steady. In this case, you can set up your cluster with an Aurora Serverless v2 writer and one or more provisioned readers.

You can also set up a DB cluster where all the capacity is managed by Aurora Serverless v2. To do this, you can create a new cluster and use Aurora Serverless v2 from the start. Or you can replace all the provisioned capacity in an existing cluster with Aurora Serverless v2. For example, some of the upgrade paths from older engine versions require starting with a provisioned writer and replacing it with a Aurora Serverless v2 writer. For the procedures to create a new DB cluster with Aurora Serverless v2 or to switch an existing DB cluster to Aurora Serverless v2, see [Creating an Aurora Serverless v2 DB cluster](aurora-serverless-v2.create.md#aurora-serverless-v2.create-cluster) and [Switching from a provisioned cluster to Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned).

If you don't use Aurora Serverless v2 at all in a DB cluster, all the writers and readers in the DB cluster are *provisioned*. This is the oldest and most common kind of DB cluster that most users are familiar with. In fact, before Aurora Serverless, there wasn't a special name for this kind of Aurora DB cluster. Provisioned capacity is constant. The charges are relatively easy to forecast. However, you have to predict in advance how much capacity you need. In some cases, your predictions might be inaccurate or your capacity needs might change. In these cases, your DB cluster can become underprovisioned (slower than you want) or overprovisioned (more expensive than you want).

## Aurora Serverless v2 capacity
Capacity

The unit of measure for Aurora Serverless v2 is the *Aurora capacity unit (ACU)*. Aurora Serverless v2 capacity isn't tied to the DB instance classes that you use for provisioned clusters.

Each ACU is a combination of approximately 2 gibibytes (GiB) of memory, corresponding CPU, and networking. You specify the database capacity range using this unit of measure. The `ServerlessDatabaseCapacity` and `ACUUtilization` metrics help you to determine how much capacity your database is actually using and where that capacity falls within the specified range.

At any moment in time, each Aurora Serverless v2 DB writer or reader has a *capacity*. The capacity is represented as a floating-point number representing ACUs. The capacity increases or decreases whenever the writer or reader scales. This value is measured every second. For each DB cluster where you intend to use Aurora Serverless v2, you define a *capacity range*: the minimum and maximum capacity values that each Aurora Serverless v2 writer or reader can scale between. The capacity range is the same for each Aurora Serverless v2 writer or reader in a DB cluster. Each Aurora Serverless v2 writer or reader has its own capacity, falling somewhere in that range.

The following table shows the Aurora Serverless v2 capacity ranges and engine version support for Aurora MySQL and Aurora PostgreSQL.


| Capacity range (ACUs) | Aurora MySQL supported versions | Aurora PostgreSQL supported versions | 
| --- | --- | --- | 
| 0.5–128 | 3.02.0 and higher | 13.6 and higher, 14.3 and higher, 15.2 and higher, 16.1 and higher | 
| 0.5–256 | 3.06.0 and higher | 13.13 and higher, 14.10 and higher, 15.5 and higher, 16.1 and higher | 
| 0–256 | 3.08.0 and higher | 13.15 and higher, 14.12 and higher, 15.7 and higher, 16.3 and higher | 

The following table shows the Aurora Serverless v2 platform versions with their ACU ranges and performance characteristics.


| Aurora Serverless v2 platform version | ACU range | Performance | 
| --- | --- | --- | 
| 1 | 0–128 | Baseline performance | 
| 2 | 0–256 | Baseline performance | 
| 3 | 0–256 | Up to 30% improved performance compared to platform version 2 | 

**Note**  
The available scaling range for a given cluster is determined by both engine version and platform version. It is possible to have a more capable engine version running on a less capable platform version and vice-versa. The scaling range is determined by the lowest capable engine or platform version.

You can determine what platform version your cluster is running on in the Instance Configuration section of the AWS Management Console or through the API by viewing the `ServerlessV2PlatformVersion` for a [DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBCluster.html).

The smallest Aurora Serverless v2 capacity that you can define is 0 ACUs, for Aurora Serverless v2 versions that support the auto-pause feature. You can specify a higher number if it's less than or equal to the maximum capacity value. Setting the minimum capacity to a small number lets lightly loaded DB clusters consume minimal compute resources. At the same time, they stay ready to accept connections immediately and scale up when they become busy.

We recommend setting the minimum to a value that allows each DB writer or reader to hold the working set of the application in the buffer pool. That way, the contents of the buffer pool aren't discarded during idle periods. For all the considerations when choosing the minimum capacity value, see [Choosing the minimum Aurora Serverless v2 capacity setting for a cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations). For all the considerations when choosing the maximum capacity value, see [Choosing the maximum Aurora Serverless v2 capacity setting for a cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max_capacity_considerations).

Depending on how you configure the readers in a Multi-AZ deployment, their capacities can be tied to the capacity of the writer or independently. For details about how to do that, see [Aurora Serverless v2 scaling](#aurora-serverless-v2.how-it-works.scaling).

Monitoring Aurora Serverless v2 involves measuring the capacity values for the writer and readers in your DB cluster over time. If your database doesn't scale down to the minimum capacity, you can take actions such as adjusting the minimum and optimizing your database application. If your database consistently reaches its maximum capacity, you can take actions such as increasing the maximum. You can also optimize your database application and spread the query load across more readers.

The charges for Aurora Serverless v2 capacity are measured in terms of ACU-hours. For information about how Aurora Serverless v2 charges are calculated, see the [Aurora pricing page](https://aws.amazon.com/rds/aurora/pricing/).

Suppose that the total number of writers and readers in your cluster is *n*. In that case, the cluster consumes approximately `n x minimum ACUs` when you aren't running any database operations. Aurora itself might run monitoring or maintenance operations that cause some small amount of load. That cluster consumes no more than `n x maximum ACUs` when the database is running at full capacity.

For more details about choosing appropriate minimum and maximum ACU values, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). The minimum and maximum ACU values that you specify also affect the way some of the Aurora configuration parameters work for Aurora Serverless v2. For details about the interaction between the capacity range and configuration parameters, see [Working with parameter groups for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups).

## Aurora Serverless v2 scaling
Scaling

For each Aurora Serverless v2 writer or reader, Aurora continuously tracks utilization of resources such as CPU, memory, and network. These measurements collectively are called the *load*. The load includes the database operations performed by your application. It also includes background processing for the database server and Aurora administrative tasks. When capacity is constrained by any of these, Aurora Serverless v2 scales up. Aurora Serverless v2 also scales up when it detects performance issues that it can resolve by doing so. You can monitor resource utilization and how it affects Aurora Serverless v2 scaling by using the procedures in [Important Amazon CloudWatch metrics for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) and [Monitoring Aurora Serverless v2 performance with Performance Insights](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.performance-insights).

The load can vary across the writer and readers in your DB cluster. The writer handles all data definition language (DDL) statements, such as `CREATE TABLE`, `ALTER TABLE`, and `DROP TABLE`. The writer also handles all data manipulation language (DML) statements, such as `INSERT` and `UPDATE`. Readers can process read-only statements, such as `SELECT` queries.

*Scaling* is the operation that increases or decreases Aurora Serverless v2 capacity for your database. With Aurora Serverless v2, each writer and reader has its own current capacity value, measured in ACUs. Aurora Serverless v2 scales a writer or reader up to a higher capacity when its current capacity is too low to handle the load. It scales the writer or reader down to a lower capacity when its current capacity is higher than needed.

Unlike Aurora Serverless v1, which scales by doubling the capacity each time the DB cluster reaches a threshold, Aurora Serverless v2 can increase capacity incrementally. When your workload demand begins to reach the current database capacity of a writer or reader, Aurora Serverless v2 increases the number of ACUs for that writer or reader. Aurora Serverless v2 scales capacity in the increments required to provide the best performance for the resources consumed. Scaling happens in increments as small as 0.5 ACUs. The larger the current capacity, the larger the scaling increment and thus the faster scaling can happen.

Because Aurora Serverless v2 scaling is so frequent, granular, and nondisruptive, it doesn't cause discrete events in the AWS Management Console the way that Aurora Serverless v1 does. Instead, you can measure the Amazon CloudWatch metrics such as `ServerlessDatabaseCapacity` and `ACUUtilization` and track their minimum, maximum, and average values over time. To learn more about Aurora metrics, see [Monitoring metrics in an Amazon Aurora cluster](MonitoringAurora.md). For tips about monitoring Aurora Serverless v2, see [Important Amazon CloudWatch metrics for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring).

You can choose to make a reader scale at the same time as the associated writer, or independently from the writer. You do so by specifying the promotion tier for that reader.
+ Readers in promotion tiers 0 and 1 scale at the same time as the writer. That scaling behavior makes readers in priority tiers 0 and 1 ideal for availability. That's because they are always sized to the right capacity to take over the workload from the writer in case of failover.
+ Readers in promotion tiers 2–15 scale independently from the writer. Each reader remains within the minimum and maximum ACU values that you specified for your cluster. When a reader scales independently of the associated writer DB, it can become idle and scale down while the writer continues to process a high volume of transactions. It's still available as a failover target, if no other readers are available in lower promotion tiers. However, if it's promoted to be the writer, it might need to scale up to handle the full workload of the writer.

For details about promotion tiers, see [Choosing the promotion tier for an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).

The notions of scaling points and associated timeout periods from Aurora Serverless v1 don't apply in Aurora Serverless v2. Aurora Serverless v2 scaling can happen while database connections are open, while SQL transactions are in process, while tables are locked, and while temporary tables are in use. Aurora Serverless v2 doesn't wait for a quiet point to begin scaling. Scaling doesn't disrupt any database operations that are underway.

If your workload requires more read capacity than is available with a single writer and a single reader, you can add multiple Aurora Serverless v2 readers to the cluster. Each Aurora Serverless v2 reader can scale within the range of minimum and maximum capacity values that you specified for your DB cluster. You can use the cluster's reader endpoint to direct read-only sessions to the readers and reduce the load on the writer.

Whether Aurora Serverless v2 performs scaling, and how fast scaling occurs once it starts, also depends on the minimum and maximum ACU settings for the cluster. In addition, it depends on whether a reader is configured to scale along with the writer or independently from it. For details about the factors that affect Aurora Serverless v2 scaling, see [Performance and scaling for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md).

### Scaling to Zero


 In recent Aurora MySQL and Aurora PostgreSQL versions, Aurora Serverless v2 writers and readers can scale all the way down to zero ACUs. We refer to this capability as automatic pause and resume, or auto-pause. You can choose whether to allow this behavior by specifying a zero or nonzero value for the minimum capacity. You can also choose how long to wait before an Aurora Serverless v2 instance pauses. For information about which versions have this capability, see [Aurora Serverless v2 capacity](#aurora-serverless-v2.how-it-works.capacity). For information about how to use it effectively, see [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). 

 In older Aurora MySQL and Aurora PostgreSQL versions, idle Aurora Serverless v2 writers and readers can scale down to the minimum ACU value that you specified for the cluster, but not all the way to zero ACUs. In that case, zero ACUs isn't available as a choice when you set the capacity range. That behavior is different than Aurora Serverless v1, which can pause after a period of idleness, but then takes some time to resume when you open a new connection. 

 When your DB cluster with Aurora Serverless v2 capacity isn't needed for some time, you can also stop and start the entire cluster, the same as with provisioned DB clusters. This technique is most appropriate for development and test systems, where they might not be needed for many hours at a time, and the speed of resuming the cluster isn't crucial. The stop/start cluster feature is available for all Aurora Serverless v2 versions. For more information about that feature, see [Stopping and starting an Amazon Aurora DB cluster](aurora-cluster-stop-start.md). 

## Aurora Serverless v2 and high availability
High availability

The way to establish high availability for an Aurora DB cluster is to make it a Multi-AZ DB cluster. A *Multi-AZ Aurora DB cluster* has compute capacity available at all times in more than one Availability Zone (AZ). That configuration keeps your database up and running even in case of a significant outage. Aurora performs an automatic failover in case of an issue that affects the writer or even the entire AZ. With Aurora Serverless v2, you can choose for the standby compute capacity to scale up and down along with the capacity of the writer. That way, the compute capacity in the second AZ is ready to take over the current workload at any time. At the same time, the compute capacity in all AZs can scale down when the database is idle. For details about how Aurora works with AWS Regions and Availability Zones, see [High availability for Aurora DB instances](Concepts.AuroraHighAvailability.md#Concepts.AuroraHighAvailability.Instances).

The Aurora Serverless v2 Multi-AZ capability uses *readers* in addition to the writer. Support for readers is new for Aurora Serverless v2 compared to Aurora Serverless v1. You can add up to 15 Aurora Serverless v2 readers spread across 3 AZs to an Aurora DB cluster.

For business-critical applications that must remain available even in case of an issue that affects your entire cluster or the whole AWS Region, you can set up an Aurora global database. You can use Aurora Serverless v2 capacity in the secondary clusters so they're ready to take over during disaster recovery. They can also scale down when the database isn't busy. For details about Aurora global databases, see [Using Amazon Aurora Global Database](aurora-global-database.md).

Aurora Serverless v2 works like provisioned for failover and other high availability features. For more information, see [High availability for Amazon Aurora](Concepts.AuroraHighAvailability.md).

Suppose that you want to ensure maximum availability for your Aurora Serverless v2 cluster. You can create a reader in addition to the writer. If you assign the reader to promotion tier 0 or 1, whatever scaling happens for the writer also happens for the reader. That way, a reader with identical capacity is always ready to take over for the writer in case of a failover.

Suppose that you want to run quarterly reports for your business at the same time as your cluster continues to process transactions. If you add an Aurora Serverless v2 reader to the cluster and assign it to a promotion tier from 2 through 15, you can connect directly to that reader to run the reports. Depending on how memory-intensive and CPU-intensive the reporting queries are, that reader can scale up to accommodate the workload. It can then scale down again when the reports are finished.

## Aurora Serverless v2 and storage
Storage

The storage for each Aurora DB cluster consists of six copies of all your data, spread across three AZs. This built-in data replication applies regardless of whether your DB cluster includes any readers in addition to the writer. That way, your data is safe, even from issues that affect the compute capacity of the cluster.

Aurora Serverless v2 storage has the same reliability and durability characteristics as described in [Amazon Aurora storage](Aurora.Overview.StorageReliability.md). That's because the storage for Aurora DB clusters works the same whether the compute capacity uses Aurora Serverless v2 or provisioned.

## Configuration parameters for Aurora clusters
Configuration parameters

You can adjust all the same cluster and database configuration parameters for clusters with Aurora Serverless v2 capacity as for provisioned DB clusters. However, some capacity-related parameters are handled differently for Aurora Serverless v2. In a mixed-configuration cluster, the parameter values that you specify for those capacity-related parameters still apply to any provisioned writers and readers.

Almost all of the parameters work the same way for Aurora Serverless v2 writers and readers as for provisioned ones. The exceptions are some parameters that Aurora automatically adjusts during scaling, and some parameters that Aurora keeps at fixed values that depend on the maximum capacity setting.

For example, the amount of memory reserved for the buffer cache increases as a writer or reader scales up, and decreases as it scales down. That way, memory can be released when your database isn't busy. Conversely, Aurora automatically sets the maximum number of connections to a value that's appropriate based on the maximum capacity setting. That way, active connections aren't dropped if the load drops and Aurora Serverless v2 scales down. For information about how Aurora Serverless v2 handles specific parameters, see [Working with parameter groups for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups).

# Requirements and limitations for Aurora Serverless v2


When you create a cluster where you intend to use Aurora Serverless v2 DB instances, pay attention to the following requirements and limitations.

**Topics**
+ [

## Region and version availability
](#aurora-serverless-v2-Availability)
+ [

## Clusters that use Aurora Serverless v2 must have a capacity range specified
](#aurora-serverless-v2.requirements.capacity-range)
+ [

## Incompatible scaling configuration
](#aurora-serverless-v2.requirements.incompatible-scaling-config)
+ [

## Some provisioned features aren't supported in Aurora Serverless v2
](#aurora-serverless-v2.limitations)
+ [

## Some Aurora Serverless v2 aspects are different from Aurora Serverless v1
](#aurora-serverless-v2.requirements.v1-v2-differences)

## Region and version availability
Region and version availability

Feature availability and support varies across specific versions of each Aurora database engine, and across AWS Regions. For more information on version and Region availability with Aurora and Aurora Serverless v2, see [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md). 

The following example shows the AWS CLI commands to confirm the exact DB engine values you can use with Aurora Serverless v2 for a specific AWS Region. The `--db-instance-class` parameter for Aurora Serverless v2 is always `db.serverless`. The `--engine` parameter can be `aurora-mysql` or `aurora-postgresql`. Substitute the appropriate `--region` and `--engine` values to confirm the `--engine-version` values that you can use. If the command doesn't produce any output, Aurora Serverless v2 isn't available for that combination of AWS Region and DB engine.

```
aws rds describe-orderable-db-instance-options --engine aurora-mysql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text
```

## Clusters that use Aurora Serverless v2 must have a capacity range specified


An Aurora cluster must have a `ServerlessV2ScalingConfiguration` attribute before you can add any DB instances that use the `db.serverless` DB instance class. This attribute specifies the capacity range. Aurora Serverless v2 capacity ranges from a minimum of 0 Aurora capacity units (ACU) to a maximum of 256 ACUs, in increments of 0.5 ACU. The allowed minimum value depends on the Aurora version. Each ACU provides the equivalent of approximately 2 gibibytes (GiB) of RAM and associated CPU and networking. For details about how Aurora Serverless v2 uses the capacity range settings, see [How Aurora Serverless v2 works](aurora-serverless-v2.how-it-works.md).

For the allowed capacity ranges for various DB engine versions and platform versions, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). The available scaling range for a given cluster is influenced by both engine version and hardware (platform version).

You can specify the minimum and maximum ACU values in the AWS Management Console when you create a cluster and associated Aurora Serverless v2 DB instance. You can also specify the `--serverless-v2-scaling-configuration` option in the AWS CLI. Or you can specify the `ServerlessV2ScalingConfiguration` parameter with the Amazon RDS API. You can specify this attribute when you create a cluster or modify an existing cluster. For the procedures to set the capacity range, see [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). For a detailed discussion of how to pick minimum and maximum capacity values and how those settings affect some database parameters, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).

## Incompatible scaling configuration


When you modify your Aurora PostgreSQL cluster with a lower maximum capacity, each instance will be scaled down to match the new configuration. If Aurora detects that any of your instances are having trouble scaling down, it may cancel and roll back the scaling configuration update. As a result, the instances will scale back up to their previous configuration. This issue may occur if the new maximum capacity is insufficient to handle the current workload or if the custom parameters applied to the cluster's or instances' database parameter group are set too high. 

When the rollback starts, you will be notified via an Amazon RDS event containing information about instances that could not apply your desired scaling configuration. After the rollback completes, the scaling configuration's maximum capacity will return to its original higher value. Due to the roll back, you may observe that the Aurora Serverless database capacity across all of your cluster's instances may also increase, leading to higher costs.

For example, you have an Aurora PostgreSQL Aurora Serverless cluster with a single instance and the scaling configuration is set to `minCapacity=0.5`, `maxCapacity=128`, and `secondsUntilAutopause=null`. In addition, the database parameter `track_activity_query_size` is set to a custom value of 40960. If you then modify the cluster's scaling configuration to have a maximum capacity of 1 ACU, you may notice that after a couple of hours, the modification has not completed. The high value of the `track_activity_query_size` parameter requires more resources than the new maximum capacity can provide. As a result, even with no workload, the instance's `ServerlessDatabaseCapacity` cannot scale down to match the new maximum capacity of 1 ACU. Aurora Serverless v2 will then cancel the scaling configuration modification and will reapply the previous scaling configuration of `minCapacity=0.5`, `maxCapacity=128`, `secondsUntilAutopause=null`. The instance will then scale up to match the previous scaling configuration, ending the cluster's modification. An Amazon RDS event is published notifying you that an incompatible scaling configuration update was detected, canceled, and rolled back to the previous configuration.

### Issues and Remediations


**New scaling configuration is incompatible with workload**  <a name="aurora-serverless-v2.requirements.incompatible-scaling-config.workload"></a>
The new Aurora Serverless v2 scaling configuration's maximum capacity is too low to handle the current workload.  
Recommendations:  
+ Reduce your workload before reapplying the lower maximum capacity.
+ If reducing the workload is not an option, reevaluate the desired maximum capacity. To pick an appropriate maximum capacity, check the maximum `ServerlessDatabaseCapacity` CloudWatch metric for your Aurora PostgreSQL cluster before the scaling configuration update was cancelled and rolled back. Then set your new scaling configuration's maximum capacity to be at least the observed ServerlessDatabaseCapacity value. For more guidance on choosing a maximum capacity, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster).

**New scaling configuration is incompatible with custom database parameters**  
Your cluster's or instances' custom database parameter groups require additional resources that exceed the new scaling configuration's maximum capacity.  
Potential incompatible Aurora PostgreSQL database parameters:  
+ max\$1connections
+ track\$1activity\$1query\$1size
+ min\$1dynamic\$1shared\$1memory
Recommendations:  
+ To pick an appropriate database parameter value, check the default parameter values for each of the parameters listed above. If your configured value exceeds the default values, reduce the parameters to their default values before modifying the scaling configuration with the same reduced maximum capacity.
+ If reducing the database parameters is not an option, follow the same steps to pick an appropriate maximum capacity outlined above in: [New scaling configuration is incompatible with workload](#aurora-serverless-v2.requirements.incompatible-scaling-config.workload).

## Some provisioned features aren't supported in Aurora Serverless v2


The following features from Aurora provisioned DB instances currently aren't available for Amazon Aurora Serverless v2:
+ Database activity streams (DAS).
+ Cluster cache management for Aurora PostgreSQL. The `apg_ccm_enabled` configuration parameter doesn't apply to Aurora Serverless v2 DB instances.

Some Aurora features work with Aurora Serverless v2, but might cause issues if your capacity range is lower than needed for the memory requirements for those features with your specific workload. In that case, your database might not perform as well as usual, or might encounter out-of-memory errors. For recommendations about setting the appropriate capacity range, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). For troubleshooting information if your database encounters out-of-memory errors due to a misconfigured capacity range, see [Avoiding out-of-memory errors](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.setting-capacity.incompatible_parameters).

Aurora Auto Scaling isn't supported. This type of scaling adds new readers to handle additional read-intensive workload, based on CPU usage. However, scaling based on CPU usage isn't meaningful for Aurora Serverless v2. As an alternative, you can create Aurora Serverless v2 reader DB instances in advance and leave them scaled down to low capacity. That's a faster and less disruptive way to scale a cluster's read capacity than adding new DB instances dynamically.

## Some Aurora Serverless v2 aspects are different from Aurora Serverless v1


If you are an Aurora Serverless v1 user and this is your first time using Aurora Serverless v2, consult the [differences between Aurora Serverless v2 and Aurora Serverless v1 requirements](aurora-serverless-v2.upgrade.md#Serverless.v1-v2-requirements) to understand how requirements are different between Aurora Serverless v1 and Aurora Serverless v2.

# Creating a DB cluster that uses Aurora Serverless v2
Creating an Aurora Serverless v2 DB cluster

To create an Aurora cluster where you can add Aurora Serverless v2 DB instances, you follow the same procedure as in [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md). With Aurora Serverless v2, your clusters are interchangeable with provisioned clusters. You can have clusters where some DB instances use Aurora Serverless v2 and some DB instances are provisioned.

**Topics**
+ [

## Settings for Aurora Serverless v2 DB clusters
](#aurora-serverless-v2.create-settings)
+ [

## Creating an Aurora Serverless v2 DB cluster
](#aurora-serverless-v2.create-cluster)
+ [

## Creating an Aurora Serverless v2 writer DB instance
](#aurora-serverless-v2-adding-writer)

## Settings for Aurora Serverless v2 DB clusters
Settings

Make sure that the cluster's initial settings meet the requirements listed in [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md). Specify the following settings to make sure that you can add Aurora Serverless v2 DB instances to the cluster:

**AWS Region**  
Create the cluster in an AWS Region where Aurora Serverless v2 DB instances are available. For details about available Regions, see [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).

**DB engine version**  
Choose an engine version that's compatible with Aurora Serverless v2. For information about the Aurora Serverless v2 version requirements, see [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md).

**DB instance class**  
If you create a cluster using the AWS Management Console, you choose the DB instance class for the writer DB instance at the same time. Choose the **Serverless** DB instance class. When you choose that DB instance class, you also specify the capacity range for the writer DB instance. That same capacity range applies to all other Aurora Serverless v2 DB instances that you add to that cluster.  
If you don't see the **Serverless** choice for the DB instance class, make sure that you chose a DB engine version that's supported for [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).  
When you use the AWS CLI or the Amazon RDS API, the parameter that you specify for the DB instance class is `db.serverless`.

**Capacity range**  
Fill in the minimum and maximum Aurora capacity unit (ACU) values that apply to all the DB instances in the cluster. This option is available on both the **Create cluster** and **Add reader** console pages when you choose **Serverless** for the DB instance class.  
For the allowed capacity ranges for various DB engine versions, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).  
If you don't see the minimum and maximum ACU fields, make sure that you chose the **Serverless** DB instance class for the writer DB instance.

If you initially create the cluster with a provisioned DB instance, you don't specify the minimum and maximum ACUs. In that case you can modify the cluster afterward to add that setting. You can also add an Aurora Serverless v2 reader DB instance to the cluster. You specify the capacity range as part of that process.

Until you specify the capacity range for your cluster, you can't add any Aurora Serverless v2 DB instances to the cluster using the AWS CLI or RDS API. If you try to add a Aurora Serverless v2 DB instance, you get an error. In the AWS CLI or the RDS API procedures, the capacity range is represented by the `ServerlessV2ScalingConfiguration` attribute.

For clusters containing more than one reader DB instance, the failover priority of each Aurora Serverless v2 reader DB instance plays an important part in how that DB instance scales up and down. You can't specify the priority when you initially create the cluster. Keep this property in mind when you add a second or later reader DB instance to your cluster. For more information, see [Choosing the promotion tier for an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).

## Creating an Aurora Serverless v2 DB cluster


You can use the AWS Management Console, AWS CLI, or RDS API to create an Aurora Serverless v2 DB cluster.

### Console


**To create a cluster with an Aurora Serverless v2 writer**

1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the navigation pane, choose **Databases**.

1. Choose **Create database**. On the page that appears, choose the following options:
   + For **Engine type**, choose **Aurora (MySQL Compatible)** or **Aurora (PostgreSQL Compatible)**.
   + For **Version**, choose one of the supported versions for [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md).

1. For **DB instance class**, select **Serverless v2**.

1. For **Capacity range**, you can accept the default range. Or you can choose other values for minimum and maximum capacity units. You can choose from 0 ACUs minimum through 256 ACUs maximum, in increments of 0.5 ACU.

   For more information about Aurora Serverless v2 capacity units, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) and [Performance and scaling for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). 

    Depending on the engine and version that you choose, the upper limit might be 128 ACUs, the lower limit might be 0.5 ACUs, or both. For details about the limit for each combination of Aurora engine and version, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).   
![\[Instance configuration settings for Aurora Serverless v2.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_setting_incl_nonzero_minimum.png)

    Choosing a minimum capacity of 0 ACUs enables the Aurora Serverless v2 automatic pause and resume capability. In that case, you can make an additional choice of how long the Aurora Serverless v2 DB instances wait with no database connections before automatically pausing. For information about the automatic pause and resume capability, see [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md).   
![\[Capacity setting Aurora Serverless v2 when the lower limit is 0 ACUs.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_setting_incl_zero_minimum.png)

1. Choose any other DB cluster settings, as described in [Settings for Aurora DB clusters](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).

1. Choose **Create database** to create your Aurora DB cluster with an Aurora Serverless v2 DB instance as the writer instance, also known as the primary DB instance.

### CLI


To create a DB cluster that's compatible with Aurora Serverless v2 DB instances using the AWS CLI, you follow the CLI procedure in [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md). Include the following parameters in your `create-db-cluster` command:
+ --region *AWS\$1Region\$1where\$1Aurora Serverless v2\$1instances\$1are\$1available*
+ --engine-version *serverless\$1v2\$1compatible\$1engine\$1version*
+ --serverless-v2-scaling-configuration MinCapacity=*minimum\$1capacity*,MaxCapacity=*maximum\$1capacity* 

The following example shows the creation of an Aurora Serverless v2 DB cluster.

```
aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0.mysql_aurora.3.04.1 \
    --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=4 \
    --master-username myuser \
    --manage-master-user-password
```

**Note**  
When you create an Aurora Serverless v2 DB cluster using the AWS CLI, the engine mode appears in the output as `provisioned` rather than `serverless`. The `serverless` engine mode refers to Aurora Serverless v1.

This example specifies the `--manage-master-user-password` option to generate the administrative password and manage it in Secrets Manager. For more information, see [Password management with Amazon Aurora and AWS Secrets Manager](rds-secrets-manager.md). Alternatively, you can use the `--master-password` option to specify and manage the password yourself.

For information about the Aurora Serverless v2 version requirements, see [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md). For information about the allowed numbers for the capacity range and what those numbers represent, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) and [Performance and scaling for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). 

To verify whether an existing cluster has the capacity settings specified, check the output of the `describe-db-clusters` command for the `ServerlessV2ScalingConfiguration` attribute. That attribute looks similar to the following.

```
"ServerlessV2ScalingConfiguration": {
    "MinCapacity": 1.5,
    "MaxCapacity": 24.0
}
```

**Tip**  
If you don't specify the minimum and maximum ACUs when you create the cluster, you can use the `modify-db-cluster` command afterward to add that setting. Until you do, you can't add any Aurora Serverless v2 DB instances to the cluster. If you try to add a `db.serverless` DB instance, you get an error.

### API


To create a DB cluster that's compatible with Aurora Serverless v2 DB instances using the RDS API, you follow the API procedure in [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md). Choose the following settings. Make sure that your `CreateDBCluster` operation includes the following parameters:

```
EngineVersion serverless_v2_compatible_engine_version
ServerlessV2ScalingConfiguration with MinCapacity=minimum_capacity and MaxCapacity=maximum_capacity
```

For information about the Aurora Serverless v2 version requirements, see [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md). For information about the allowed numbers for the capacity range and what those numbers represent, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity) and [Performance and scaling for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). 

To check if an existing cluster has the capacity settings specified, check the output of the `DescribeDBClusters` operation for the `ServerlessV2ScalingConfiguration` attribute. That attribute looks similar to the following.

```
"ServerlessV2ScalingConfiguration": {
    "MinCapacity": 1.5,
    "MaxCapacity": 24.0
}
```

**Tip**  
If you don't specify the minimum and maximum ACUs when you create the cluster, you can use the `ModifyDBCluster` operation afterward to add that setting. Until you do, you can't add any Aurora Serverless v2 DB instances to the cluster. If you try to add a `db.serverless` DB instance, you get an error.

## Creating an Aurora Serverless v2 writer DB instance
Creating an Aurora Serverless v2 writer

 Although you specify the Aurora Serverless v2 capacity range when you create an Aurora cluster, you can choose whether to use Aurora Serverless v2 or provisioned for each DB instance in the cluster. To begin using Aurora Serverless v2 immediately in your DB cluster, add a writer DB instance that uses the `db.serverless` instance class. In the console, you typically make this choice as part of the workflow to create the DB cluster. Therefore, this procedure applies mostly when you do the setup through the CLI. 

### Console


When you create a DB cluster using the AWS Management Console, you specify the properties of the writer DB instance at the same time. To make the writer DB instance use Aurora Serverless v2, choose the **Serverless** DB instance class.

Then you set the capacity range for the cluster by specifying the minimum and maximum Aurora capacity unit (ACU) values. These minimum and maximum values apply to each Aurora Serverless v2 DB instance in the cluster. For that procedure and the significance of the minimum and maximum capacity settings, see [Creating an Aurora Serverless v2 DB cluster](#aurora-serverless-v2.create-cluster). 

If you don't create an Aurora Serverless v2 DB instance when you first create the cluster, you can add one or more Aurora Serverless v2 DB instances later. To do so, follow the procedures in [Adding an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader) and [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned). You specify the capacity range at the time that you add the first Aurora Serverless v2 DB instance to the cluster. You can change the capacity range later by following the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus).

### CLI


When you create a Aurora Serverless v2 DB cluster using the AWS CLI, you explicitly add the writer DB instance using the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) command. Include the following parameter:
+ `--db-instance-class db.serverless`

The following example shows the creation of an Aurora Serverless v2 writer DB instance.

```
aws rds create-db-instance \
    --db-cluster-identifier my-serverless-v2-cluster \
    --db-instance-identifier my-serverless-v2-instance \
    --db-instance-class db.serverless \
    --engine aurora-mysql
```

# Managing Aurora Serverless v2 DB clusters
Managing Aurora Serverless v2

With Aurora Serverless v2, your clusters are interchangeable with provisioned clusters. The Aurora Serverless v2 properties apply to one or more DB instances within a DB cluster. Thus, the procedures for creating clusters, modifying clusters, creating and restoring snapshots, and so on, are basically the same as for other kinds of Aurora clusters. For general procedures for managing Aurora clusters and DB instances, see [Managing an Amazon Aurora DB cluster](CHAP_Aurora.md).

In the following topics, you can learn about management considerations for clusters that contain Aurora Serverless v2 DB instances.

**Topics**
+ [

## Setting the Aurora Serverless v2 capacity range for a cluster
](#aurora-serverless-v2-setting-acus)
+ [

## Checking the capacity range for Aurora Serverless v2
](#aurora-serverless-v2-checking-capacity)
+ [

## Adding an Aurora Serverless v2 reader
](#aurora-serverless-v2-adding-reader)
+ [

## Converting a provisioned writer or reader to Aurora Serverless v2
](#aurora-serverless-v2-converting-from-provisioned)
+ [

## Converting an Aurora Serverless v2 writer or reader to provisioned
](#aurora-serverless-v2-converting-to-provisioned)
+ [

## Pausing Aurora Serverless v2 DB instances
](#pause-when-inactive)
+ [

## Choosing the promotion tier for an Aurora Serverless v2 reader
](#aurora-serverless-v2-choosing-promotion-tier)
+ [

## Using TLS/SSL with Aurora Serverless v2
](#aurora-serverless-v2.tls)
+ [

## Viewing Aurora Serverless v2 writers and readers
](#aurora-serverless-v2.viewing)
+ [

## Logging for Aurora Serverless v2
](#aurora-serverless-v2.logging)

## Setting the Aurora Serverless v2 capacity range for a cluster


To modify configuration parameters or other settings for clusters containing Aurora Serverless v2 DB instances, or the DB instances themselves, follow the same general procedures as for provisioned clusters. For details, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).

The most important setting that's unique to Aurora Serverless v2 is the capacity range. After you set the minimum and maximum Aurora capacity unit (ACU) values for an Aurora cluster, you don't need to actively adjust the capacity of the Aurora Serverless v2 DB instances in the cluster. Aurora does that for you. This setting is managed at the cluster level. The same minimum and maximum ACU values apply to each Aurora Serverless v2 DB instance in the cluster.

You can set the following specific values:
+ **Minimum ACUs** – The Aurora Serverless v2 DB instance can reduce capacity down to this number of ACUs.
+ **Maximum ACUs** – The Aurora Serverless v2 DB instance can increase capacity up to this number of ACUs.

The available capacity range for Aurora Serverless v2 is a function of both the DB engine version and the platform version. Newer DB engine versions allow a maximum capacity of 256 ACUs, a minimum capacity of 0 ACUs, or both. For the capacity ranges for various DB engine versions, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). 

 For the auto-pause and resume capability that's enabled by setting the minimum capacity to 0 ACUs, see [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). 

 For more information on making sure that your Aurora Serverless v2 DB clusters can scale up to 256 ACUs, see [Upgrading your Aurora Serverless v2 DB cluster to allow scaling to 256 ACUs](#setting-256-acus). 

**Note**  
When you modify the capacity range for an Aurora Serverless v2 DB cluster, the change takes place immediately, regardless of whether you choose to apply it immediately or during the next scheduled maintenance window.

In Aurora Serverless v2, you can't directly set the current capacity without modifying the capacity range, as capacity dynamically adjusts based on the workload within the specified range. However, you can influence the capacity indirectly in the following ways:
+ **Adjust the minimum capacity** – Temporarily lower the minimum capacity to reduce the baseline capacity when workloads are light.
+ **Pause scaling temporarily** – To fix the capacity at a specific value, set the minimum and maximum capacity to the same level.
+ **Scale proactive for bursting usage** – If you anticipate bursting workloads, increase the minimum capacity beforehand to maintain a higher baseline during periods of high activity.

For details about the effects of the capacity range and how to monitor and fine-tune it, see [Important Amazon CloudWatch metrics for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring) and [Performance and scaling for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md). Your goal is to make sure that the maximum capacity for the cluster is high enough to handle spikes in workload, and the minimum is low enough to minimize costs when the cluster isn't busy.

Suppose that you determine based on your monitoring that the ACU range for the cluster should be higher, lower, wider, or narrower. You can set the capacity of an Aurora cluster to a specific range of ACUs with the AWS Management Console, the AWS CLI, or the Amazon RDS API. This capacity range applies to every Aurora Serverless v2 DB instance in the cluster.

For example, suppose that your cluster has a capacity range of 1–16 ACUs and contains two Aurora Serverless v2 DB instances. Then the cluster as a whole consumes somewhere between 2 ACUs (when idle) and 32 ACUs (when fully utilized). If you change the capacity range from 8 to 40.5 ACUs, now the entire cluster consumes 16 ACUs when idle, and up to 81 ACUs when fully utilized.

Aurora automatically sets certain parameters for Aurora Serverless v2 DB instances to values that depend on the maximum ACU value in the capacity range. For the list of such parameters, see [Maximum connections for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). For static parameters that rely on this type of calculation, the value is evaluated again when you reboot the DB instance. Thus, you can update the value of such parameters by rebooting the DB instance after changing the capacity range. To check whether you need to reboot your DB instance to pick up such parameter changes, check the `ParameterApplyStatus` attribute of the DB instance. A value of `pending-reboot` indicates that rebooting will apply changes to some parameter values.

### Console


You can set the capacity range of a cluster that contains Aurora Serverless v2 DB instances with the AWS Management Console.

When you use the console, you set the capacity range for the cluster at the time that you add the first Aurora Serverless v2 DB instance to that cluster. You might do so when you choose the **Serverless v2** DB instance class for the writer DB instance when you create the cluster. Or you might do so when you choose the **Serverless** DB instance class when you add an Aurora Serverless v2 reader DB instance to the cluster. Or you might do so when you convert an existing provisioned DB instance in the cluster to the **Serverless** DB instance class. For the full versions of those procedures, see [Creating an Aurora Serverless v2 writer DB instance](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer), [Adding an Aurora Serverless v2 reader](#aurora-serverless-v2-adding-reader), and [Converting a provisioned writer or reader to Aurora Serverless v2](#aurora-serverless-v2-converting-from-provisioned).

Whatever capacity range that you set at the cluster level applies to all Aurora Serverless v2 DB instances in your cluster. The following image shows a cluster with multiple Aurora Serverless v2 reader DB instances. Each has an identical capacity range of 2–64 ACUs.

![\[Cluster with multiple Aurora Serverless v2 reader DB instances\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)


**To modify the capacity range of an Aurora Serverless v2 cluster**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the navigation pane, choose **Databases**.

1. Choose the cluster containing your Aurora Serverless v2 DB instances from the list. The cluster must already contain at least one Aurora Serverless v2 DB instance. Otherwise, Aurora doesn't show the **Capacity range** section.

1. For **Actions**, choose **Modify**.

1. In the **Capacity range** section, choose the following:

   1. Enter a value for **Minimum ACUs**. The console shows the allowed range of values. You can choose a minimum capacity from 0 to 256 ACUs. You can choose a maximum capacity from 1 to 256 ACUs. You can adjust the capacity values in increments of 0.5 ACU. The available capacity range depends on both your DB engine version and the platform version.

   1. Enter a value for **Maximum ACUs**. This value must be greater than or equal to **Minimum ACUs**. The console shows the allowed range of values. The following figure shows that choice.  
![\[Modifying the DB cluster capacity.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/sv2_capacity_settings_256_acus.png)

1. Choose **Continue**. The **Summary of modifications** page appears.

1. Choose **Apply immediately**.

   The capacity modification takes place immediately, regardless of whether you choose to apply it immediately or during the next scheduled maintenance window.

1. Choose **Modify cluster** to accept the summary of modifications. You can also choose **Back** to modify your changes or **Cancel** to discard your changes.

### AWS CLI


To set the capacity of a cluster where you intend to use Aurora Serverless v2 DB instances using the AWS CLI, run the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command. Specify the `--serverless-v2-scaling-configuration` option. The cluster might already contain one or more Aurora Serverless v2 DB instances, or you can add the DB instances later. Valid values for the `MinCapacity` and `MaxCapacity` fields include the following:
+ `0`, `0.5`, `1`, `1.5`, `2`, and so on, in steps of 0.5, up to a maximum of 256. The minimum ACU value of 0 is only available for the Aurora versions that support the auto-pause feature. 

The maximum available capacity depends on both your DB engine version and the platform version.

In this example, you set the ACU range of an Aurora DB cluster named `sample-cluster` to a minimum of `48.5` and a maximum of 64.

```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
  --serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64
```

The capacity modification takes place immediately, regardless of whether you choose to apply it immediately or during the next scheduled maintenance window.

After doing so, you can add Aurora Serverless v2 DB instances to the cluster and each new DB instance can scale between 48.5 and 64 ACUs. The new capacity range also applies to any Aurora Serverless v2 DB instances that were already in the cluster. The DB instances scale up or down if necessary to fall within the new capacity range.

For additional examples of setting the capacity range using the CLI, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). 

To modify the scaling configuration of an Aurora Serverless DB cluster using the AWS CLI, run the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command. Specify the `--serverless-v2-scaling-configuration` option to configure the minimum capacity and maximum capacity. Valid capacity values include the following:
+ Aurora MySQL: `0`, `0.5`, `1`, `1.5`, `2`, and so on, in increments of 0.5 ACUs up to a maximum of `256`.
+ Aurora PostgreSQL: `0`, `0.5`, `1`, `1.5`, `2`, and so on, in increments of 0.5 ACUs up to a maximum of `256`.
+  The minimum ACU value of 0 is only available for the Aurora versions that support the auto-pause feature. 

In the following example, you modify the scaling configuration of an Aurora Serverless v2 DB instance named `sample-instance` that's part of a cluster named `sample-cluster`.

For Linux, macOS, or Unix:

```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```

For Windows:

```
aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64
```

### RDS API


You can set the capacity of an Aurora DB instance with the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API operation. Specify the `ServerlessV2ScalingConfiguration` parameter. Valid values for the `MinCapacity` and `MaxCapacity` fields include the following:
+ `0`, `0.5`, `1`, `1.5`, `2`, and so on, in steps of 0.5, up to a maximum of 256. The minimum ACU value of 0 is only available for the Aurora versions that support the auto-pause feature. 

You can modify the scaling configuration of a cluster containing Aurora Serverless v2 DB instances with the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API operation. Specify the `ServerlessV2ScalingConfiguration` parameter to configure the minimum capacity and the maximum capacity. Valid capacity values include the following:
+ Aurora MySQL: `0`, `0.5`, `1`, `1.5`, `2`, and so on, in increments of 0.5 ACUs up to a maximum of `256`.
+ Aurora PostgreSQL: `0`, `0.5`, `1`, `1.5`, `2`, and so on, in increments of 0.5 ACUs up to a maximum of `256`.
+  The minimum ACU value of 0 is only available for the Aurora versions that support the auto-pause feature. 

The maximum available capacity depends on both your DB engine version and the platform version.

The capacity modification takes place immediately, regardless of whether you choose to apply it immediately or during the next scheduled maintenance window.

### Upgrading your Aurora Serverless v2 DB cluster to allow scaling to 256 ACUs
Upgrading to allow scaling to 256 ACUs

In some cases, when you try to scale your Aurora Serverless v2 DB cluster to capacities greater than 128 ACUs, you receive an error message. The error message tells you which instances are incompatible with the new scaling range. This highlights the important relationship between your capacity range, DB engine version, and platform version.

The inability to scale greater than 128 ACUs can happen for one of two reasons:
+ Older DB engine version – Upgrade the DB engine version to one that supports 256 ACUs. For more information, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity).
+ Older platform version – Upgrade the platform for your Aurora Serverless v2 DB cluster. You can do this in one of the following ways:
  + Stop and restart the DB cluster. When the cluster restarts, it will be on the latest platform version capable which may be capable of a higher ACU maximum.

    However, stopping and starting a DB cluster incurs some downtime, usually several minutes. For more information, see [Stopping and starting an Amazon Aurora DB cluster](aurora-cluster-stop-start.md).
  + Use a blue/green deployment. For more information, see [Overview of Amazon Aurora Blue/Green Deployments](blue-green-deployments-overview.md).

    1. Create a blue/green deployment. For more information, see [Creating a blue/green deployment in Amazon Aurora](blue-green-deployments-creating.md).

    1. Confirm that you can set the maximum capacity for the staging (green) environment to 256 ACUs.

    1. Switch over to the green environment. For more information, see [Switching a blue/green deployment in Amazon Aurora](blue-green-deployments-switching.md).

    1. Delete the original DB cluster.
**Note**  
If you maintain your database credentials in AWS Secrets Manager, you can't use blue/green deployments.  
Aurora Global Database doesn't support blue/green deployments.

## Checking the capacity range for Aurora Serverless v2
Checking the Aurora Serverless v2 capacity range

 The procedure to check the capacity range for your Aurora Serverless v2 cluster requires that you first set a capacity range. If you haven't done so, follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](#aurora-serverless-v2-setting-acus). 

 Whatever capacity range you set at the cluster level applies to all Aurora Serverless v2 DB instances in your cluster. The following image shows a cluster with multiple Aurora Serverless v2 DB instances. Each has an identical capacity range. 

![\[Cluster details for multiple Aurora Serverless v2 DB instances.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png)


 You can also view the details page for any Aurora Serverless v2 DB instance in the cluster. DB instances' capacity range appears on the **Configuration** tab. 

![\[Instance type section, part of DB instance configuration user interface\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)


 You can also see the current capacity range for the cluster on the **Modify** page for the cluster. At that point, you can change the capacity range. For all the ways that you can set or change the capacity range, see [Setting the Aurora Serverless v2 capacity range for a cluster](#aurora-serverless-v2-setting-acus). 

### Checking the current capacity range for an Aurora cluster


 You can check the capacity range that's configured for Aurora Serverless v2 DB instances in a cluster by examining the `ServerlessV2ScalingConfiguration` attribute for the cluster. The following AWS CLI example shows a cluster with a minimum capacity of 0.5 Aurora capacity units (ACUs) and a maximum capacity of 16 ACUs. 

```
$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
  --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
    [
        {
            "MinCapacity": 0.5,
            "MaxCapacity": 16.0
        }
    ]
]
```

## Adding an Aurora Serverless v2 reader
Adding an Aurora Serverless v2 reader

 To add an Aurora Serverless v2 reader DB instance to your cluster, you follow the same general procedure as in [Adding Aurora Replicas to a DB cluster](aurora-replicas-adding.md). Choose the **Serverless v2** instance class for the new DB instance. 

 If the reader DB instance is the first Aurora Serverless v2 DB instance in the cluster, you also choose the capacity range. This setting applies to this reader DB instance and to any other Aurora Serverless v2 DB instances that you add to the cluster. Each Aurora Serverless v2 DB instance can scale between the minimum and maximum ACU values. 

 If any other Aurora Serverless v2 instances already exist in the cluster, the **Add reader** dialog shows the current capacity range for the cluster. In that case, you can't change the capacity. The following image shows the report of the current cluster capacity. 

![\[Instance configuration user interface for Aurora Serverless v2.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)


 If you already added any Aurora Serverless v2 DB instances to the cluster, adding another Aurora Serverless v2 reader DB instance shows you the current capacity range. The following image shows those read-only controls. 

![\[Capacity settings for Aurora Serverless v2 shown in Add reader interface.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)


 If you want to change the capacity range for the cluster, follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](#aurora-serverless-v2-setting-acus). 

 For clusters containing more than one reader DB instance, the failover priority of each Aurora Serverless v2 reader DB instance plays an important part in how that DB instance scales up and down. You can't specify the priority when you initially create the cluster. Keep this property in mind when you add a second reader or later DB instance to your cluster. For more information, see [Choosing the promotion tier for an Aurora Serverless v2 reader](#aurora-serverless-v2-choosing-promotion-tier). 

 For other ways that you can see the current capacity range for a cluster, see [Checking the capacity range for Aurora Serverless v2](#aurora-serverless-v2-checking-capacity). 

## Converting a provisioned writer or reader to Aurora Serverless v2
Converting from provisioned to Aurora Serverless v2

 You can convert a provisioned DB instance to use Aurora Serverless v2. To do so, you follow the procedure in [Modifying a DB instance in a DB cluster](Aurora.Modifying.md#Aurora.Modifying.Instance). The cluster must meet the requirements in [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md). For example, Aurora Serverless v2 DB instances require that the cluster be running certain minimum engine versions. 

 Suppose that you are converting a running provisioned cluster to take advantage of Aurora Serverless v2. In that case, you can minimize downtime by converting a DB instance to Aurora Serverless v2 as the first step in the switchover process. For the full procedure, see [Switching from a provisioned cluster to Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned). 

 If the DB instance that you convert is the first Aurora Serverless v2 DB instance in the cluster, you choose the capacity range for the cluster as part of the **Modify** operation. This capacity range applies to each Aurora Serverless v2 DB instance that you add to the cluster. The following image shows the page where you specify the minimum and maximum Aurora capacity units (ACUs). 

![\[Instance configuration user interface\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png)


 For details about the significance of the capacity range, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). 

 If the cluster already contains one or more Aurora Serverless v2 DB instances, you see the existing capacity range during the **Modify** operation. The following image shows an example of that information panel. 

![\[Capacity range information panel\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png)


 If you want to change the capacity range for the cluster after you add more Aurora Serverless v2 DB instances, follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](#aurora-serverless-v2-setting-acus). 

## Converting an Aurora Serverless v2 writer or reader to provisioned
Converting from Aurora Serverless v2 to provisioned

 You can convert an Aurora Serverless v2 DB instance to a provisioned DB instance. To do so, you follow the procedure in [Modifying a DB instance in a DB cluster](Aurora.Modifying.md#Aurora.Modifying.Instance). Choose a DB instance class other than **Serverless**. 

 You might convert an Aurora Serverless v2 DB instance to provisioned if it needs a larger capacity than is available with the maximum Aurora capacity units (ACUs) of an Aurora Serverless v2 DB instance. For example, the largest db.r5 and db.r6g DB instance classes have a larger memory capacity than an Aurora Serverless v2 DB instance can scale to. 

**Tip**  
 Some of the older DB instance classes such as db.r3 and db.t2 aren't available for the Aurora versions that you use with Aurora Serverless v2. To see which DB instance classes you can use when converting an Aurora Serverless v2 DB instance to a provisioned one, see [Supported DB engines for DB instance classes](Concepts.DBInstanceClass.SupportAurora.md). 

 If you are converting the writer DB instance of your cluster from Aurora Serverless v2 to provisioned, you can follow the procedure in [Switching from a provisioned cluster to Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned) but in reverse. Switch one of the reader DB instances in the cluster from Aurora Serverless v2 to provisioned. Then perform a failover to make that provisioned DB instance into the writer. 

 Any capacity range that you previously specified for the cluster remains in place, even if all Aurora Serverless v2 DB instances are removed from the cluster. If you want to change the capacity range, you can modify the cluster, as explained in [Setting the Aurora Serverless v2 capacity range for a cluster](#aurora-serverless-v2-setting-acus). 

## Pausing Aurora Serverless v2 DB instances


 You can configure Aurora clusters to automatically pause and resume their Aurora Serverless v2 DB instances. For more information, see [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). 

## Choosing the promotion tier for an Aurora Serverless v2 reader
Choosing the promotion tier for an Aurora Serverless v2 reader

 For clusters containing multiple Aurora Serverless v2 DB instances or a mixture of provisioned and Aurora Serverless v2 DB instances, pay attention to the promotion tier setting for each Aurora Serverless v2 DB instance. This setting controls more behavior for Aurora Serverless v2 DB instances than for provisioned DB instances. 

 In the AWS Management Console, you specify this setting using the **Failover priority** choice under **Additional configuration** for the **Create database**, **Modify instance**, and **Add reader** pages. You see this property for existing DB instances in the optional **Priority tier** column on the **Databases** page. You can also see this property on the details page for a DB cluster or DB instance. 

 For provisioned DB instances, the choice of tier 0–15 determines only the order in which Aurora chooses which reader DB instance to promote to the writer during a failover operation. For Aurora Serverless v2 reader DB instances, the tier number also determines whether the DB instance scales up to match the capacity of the writer DB instance or scales independently based on its own workload. Aurora Serverless v2 reader DB instances in tier 0 or 1 are kept at a minimum capacity at least as high as the writer DB instance. That way, they are ready to take over from the writer DB instance in case of a failover. If the writer DB instance is a provisioned DB instance, Aurora estimates the equivalent Aurora Serverless v2 capacity. It uses that estimate as the minimum capacity for the Aurora Serverless v2 reader DB instance. 

 Aurora Serverless v2 reader DB instances in tiers 2–15 don't have the same constraint on their minimum capacity. When they are idle, they can scale down to the minimum Aurora capacity unit (ACU) value specified in the cluster's capacity range. 

 The following Linux AWS CLI example shows how to examine the promotion tiers of all the DB instances in your cluster. The final field includes a value of `True` for the writer DB instance and `False` for all the reader DB instances. 

```
$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
  --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
  --output text

1   instance-192  True
1   tier-01-4840  False
10  tier-10-7425  False
15  tier-15-6694  False
```

 The following Linux AWS CLI example shows how to change the promotion tier of a specific DB instance in your cluster. The commands first modify the DB instance with a new promotion tier. Then they wait for the DB instance to become available again and confirm the new promotion tier for the DB instance. 

```
$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
  --query '*[].[PromotionTier]' --output text
0
```

 For more guidance about specifying promotion tiers for different use cases, see [Aurora Serverless v2 scaling](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling). 

## Using TLS/SSL with Aurora Serverless v2
Using TLS/SSL with Aurora Serverless v2

 Aurora Serverless v2 can use the Transport Layer Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt communications between clients and your Aurora Serverless v2 DB instances. It supports TLS/SSL versions 1.0, 1.1, and 1.2. For general information about using TLS/SSL with Aurora, see [TLS connections to Aurora MySQL DB clusters](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). 

 To learn more about connecting to Aurora MySQL database with the MySQL client, see [Connecting to a DB instance running the MySQL database engine](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html). 

 Aurora Serverless v2 supports all TLS/SSL modes available to the MySQL client (`mysql`) and PostgreSQL client (`psql`), including those listed in the following table. 


|  Description of TLS/SSL mode  |  mysql  |  psql  | 
| --- | --- | --- | 
|   Connect without using TLS/SSL.   |   DISABLED   |   disable   | 
|   Try the connection using TLS/SSL first, but fall back to non-SSL if necessary.   |   PREFERRED   |   prefer (default)   | 
|   Enforce using TLS/SSL.   |   REQUIRED   |   require   | 
|   Enforce TLS/SSL and verify the certificate authority (CA).   |   VERIFY\$1CA   |   verify-ca   | 
|   Enforce TLS/SSL, verify the CA, and verify the CA hostname.   |   VERIFY\$1IDENTITY   |   verify-full   | 

 Aurora Serverless v2 uses wildcard certificates. If you specify the "verify CA" or the "verify CA and CA hostname" option when using TLS/SSL, first download the [Amazon root CA 1 trust store](https://www.amazontrust.com/repository/AmazonRootCA1.pem) from Amazon Trust Services. After doing so, you can identify this PEM-formatted file in your client command. To do so using the PostgreSQL client, do the following. 

For Linux, macOS, or Unix:

```
psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'
```

 To learn more about working with the Aurora PostgreSQL database using the Postgres client, see [Connecting to a DB instance running the PostgreSQL database engine](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html). 

 For more information about connecting to Aurora DB clusters in general, see [Connecting to an Amazon Aurora DB cluster](Aurora.Connecting.md). 

### Supported cipher suites for connections to Aurora Serverless v2 DB clusters


By using configurable cipher suites, you can have more control over the security of your database connections. You can specify a list of cipher suites that you want to allow to secure client TLS/SSL connections to your database. With configurable cipher suites, you can control the connection encryption that your database server accepts. Doing this prevents the use of ciphers that aren't secure or that are no longer used.

Aurora Serverless v2 DB clusters that are based on Aurora MySQL support the same cipher suites as Aurora MySQL provisioned DB clusters. For information about these cipher suites, see [Configuring cipher suites for connections to Aurora MySQL DB clusters](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).

Aurora Serverless v2 DB clusters that are based on Aurora PostgreSQL support the same cipher suites as Aurora PostgreSQL provisioned DB clusters. For information about these cipher suites, see [Configuring cipher suites for connections to Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites).

## Viewing Aurora Serverless v2 writers and readers
Viewing Aurora Serverless v2 writers and readers

 You can view the details of Aurora Serverless v2 DB instances in the same way that you do for provisioned DB instances. To do so, follow the general procedure from [Viewing an Amazon Aurora DB cluster](accessing-monitoring.md#Aurora.Viewing). A cluster might contain all Aurora Serverless v2 DB instances, all provisioned DB instances, or some of each. 

 After you create one or more Aurora Serverless v2 DB instances, you can view which DB instances are type **Serverless** and which are type **Instance**. You can also view the minimum and maximum Aurora capacity units (ACUs) that the Aurora Serverless v2 DB instance can use. Each ACU is a combination of processing (CPU) and memory (RAM) capacity. This capacity range applies to each Aurora Serverless v2 DB instance in the cluster. For the procedure to check the capacity range of a cluster or any Aurora Serverless v2 DB instance in the cluster, see [Checking the capacity range for Aurora Serverless v2](#aurora-serverless-v2-checking-capacity). 

 In the AWS Management Console, Aurora Serverless v2 DB instances are marked under the **Size** column in the **Databases** page. Provisioned DB instances show the name of a DB instance class such as r6g.xlarge. The Aurora Serverless DB instances show **Serverless** for the DB instance class, along with the DB instance's minimum and maximum capacity. For example, you might see **Serverless v2 (4–64 ACUs)** or **Serverless v2 (1–40 ACUs)**. 

 You can find the same information on the **Configuration** tab for each Aurora Serverless v2 DB instance in the console. For example, you might see an **Instance type** section such as the following. Here, the **Instance type** value is **Serverless v2**, the **Minimum capacity** value is **2 ACUs (4 GiB)**, and the **Maximum capacity** value is **64 ACUs (128 GiB)**. 

![\[Instance type section, part of DB instance configuration user interface\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png)


 You can monitor the capacity of each Aurora Serverless v2 DB instance over time. That way, you can check the minimum, maximum, and average ACUs consumed by each DB instance. You can also check how close the DB instance came to its minimum or maximum capacity. To see such details in the AWS Management Console, examine the graphs of Amazon CloudWatch metrics on the **Monitoring** tab for the DB instance. For information about the metrics to watch and how to interpret them, see [Important Amazon CloudWatch metrics for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring). 

## Logging for Aurora Serverless v2


 To turn on database logging, you specify the logs to enable using configuration parameters in your custom parameter group. 

 For Aurora MySQL, you can enable the following logs. 


|  Aurora MySQL  |  Description  | 
| --- | --- | 
|   `general_log`   |   Creates the general log. Set to 1 to turn on. Default is off (0).   | 
|   `log_queries_not_using_indexes`   |   Logs any queries to the slow query log that don't use an index. Default is off (0). Set to 1 to turn on this log.   | 
|   `long_query_time`   |   Prevents fast-running queries from being logged in the slow query log. Can be set to a float between 0 and 31536000. Default is 0 (not active).   | 
|   `server_audit_events`   |   The list of events to capture in the logs. Supported values are `CONNECT`, `QUERY`, `QUERY_DCL`, `QUERY_DDL`, `QUERY_DML`, and `TABLE`.   | 
|   `server_audit_logging`   |   Set to 1 to turn on server audit logging. If you turn this on, you can specify the audit events to send to CloudWatch by listing them in the `server_audit_events` parameter.   | 
|   `slow_query_log`   |   Creates a slow query log. Set to 1 to turn on the slow query log. Default is off (0).   | 

 For more information, see [Using Advanced Auditing with an Amazon Aurora MySQL DB cluster](AuroraMySQL.Auditing.md). 

 For Aurora PostgreSQL, you can enable the following logs on your Aurora Serverless v2 DB instances. 


|  Aurora PostgreSQL  |  Description  | 
| --- | --- | 
|   `log_connections`   |   Logs each successful connection.   | 
|   `log_disconnections`   |   Logs end of a session including duration.   | 
|   `log_lock_waits`   |   Default is 0 (off). Set to 1 to log lock waits.   | 
|   `log_min_duration_statement`   |   The minimum duration (in milliseconds) for a statement to run before it's logged.   | 
|   `log_min_messages`   |  Sets the message levels that are logged. Supported values are debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. To log performance data to the postgres log, set the value to debug1.  | 
|   `log_temp_files`   |   Logs the use of temporary files that are above the specified kilobytes (kB).   | 
|   `log_statement`   |   Controls the specific SQL statements that get logged. Supported values are `none`, `ddl`, `mod`, and `all`. Default is `none`.   | 

**Topics**
+ [

### Logging with Amazon CloudWatch
](#aurora-serverless-v2.how-it-works.logging)
+ [

### Viewing Aurora Serverless v2 logs in Amazon CloudWatch
](#aurora-serverless-v2.logging.monitoring)
+ [

### Monitoring capacity with Amazon CloudWatch
](#aurora-serverless-v2.how-it-works.logging.monitoring)
+ [

### Monitoring Aurora Serverless v2 pause and resume activity
](#autopause-logging-instance-log)

### Logging with Amazon CloudWatch


 After you use the procedure in [Logging for Aurora Serverless v2](#aurora-serverless-v2.logging) to choose which database logs to turn on, you can choose which logs to upload ("publish") to Amazon CloudWatch. 

 You can use Amazon CloudWatch to analyze log data, create alarms, and view metrics. By default, error logs for Aurora Serverless v2 are enabled and automatically uploaded to CloudWatch. You can also upload other logs from Aurora Serverless v2 DB instances to CloudWatch. 

 Then you choose which of those logs to upload to CloudWatch, by using the **Log exports** settings in the AWS Management Console or the `--enable-cloudwatch-logs-exports` option in the AWS CLI. 

 You can choose which of your Aurora Serverless v2 logs to upload to CloudWatch. For more information, see [Using Advanced Auditing with an Amazon Aurora MySQL DB cluster](AuroraMySQL.Auditing.md). 

 As with any type of Aurora DB cluster, you can't modify the default DB cluster parameter group. Instead, create your own DB cluster parameter group based on a default parameter for your DB cluster and engine type. We recommend that you create your custom DB cluster parameter group before creating your Aurora Serverless v2 DB cluster, so that it's available to choose when you create a database on the console. 

**Note**  
 For Aurora Serverless v2, you can create both DB cluster and DB parameter groups. This contrasts with Aurora Serverless v1, where you can only create DB cluster parameter groups. 

### Viewing Aurora Serverless v2 logs in Amazon CloudWatch


 After you use the procedure in [Logging with Amazon CloudWatch](#aurora-serverless-v2.how-it-works.logging) to choose which database logs to turn on, you can view the contents of the logs. 

 For more information on using CloudWatch with Aurora MySQL and Aurora PostgreSQL logs, see [Monitoring log events in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor) and [Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). 

**To view logs for your Aurora Serverless v2 DB cluster**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1.  Choose your AWS Region. 

1.  Choose **Log groups**. 

1.  Choose your Aurora Serverless v2 DB cluster log from the list. The log naming pattern is as follows. 

   ```
   /aws/rds/cluster/cluster-name/log_type
   ```

**Note**  
 For Aurora MySQL–compatible Aurora Serverless v2 DB clusters, the error log includes buffer pool scaling events even when there are no errors. 

### Monitoring capacity with Amazon CloudWatch


 With Aurora Serverless v2, you can use CloudWatch to to monitor the capacity and utilization of all the Aurora Serverless v2 DB instances in your cluster. You can view instance-level metrics to check the capacity of each Aurora Serverless v2 DB instance as it scales up and down. You can also compare the capacity-related metrics to other metrics to see how changes in workloads affect resource consumption. For example, you can compare `ServerlessDatabaseCapacity` to `DatabaseUsedMemory`, `DatabaseConnections`, and `DMLThroughput` to assess how your DB cluster is responding during operations. For details about the capacity-related metrics that apply to Aurora Serverless v2, see [Important Amazon CloudWatch metrics for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring). 

**To monitor your Aurora Serverless v2 DB cluster's capacity**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1.  Choose **Metrics**. All available metrics appear as cards in the console, grouped by service name. 

1.  Choose **RDS**. 

1.  (Optional) Use the **Search** box to find the metrics that are especially important for Aurora Serverless v2: `ServerlessDatabaseCapacity`, `ACUUtilization`, `CPUUtilization`, and `FreeableMemory`. 

 We recommend that you set up a CloudWatch dashboard to monitor your Aurora Serverless v2 DB cluster capacity using the capacity-related metrics. To learn how, see [Building dashboards with CloudWatch](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html). 

 To learn more about using Amazon CloudWatch with Amazon Aurora, see [Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). 

### Monitoring Aurora Serverless v2 pause and resume activity


 Aurora writes a separate log file for Aurora Serverless v2 DB instances with auto-pause enabled. Aurora writes to the log for each 10-minute interval that the instance isn't paused. Aurora retains up to seven of these logs, rotated daily. The current log file is named `instance.log`, and older logs are named using the pattern `instance.YYYY-MM-DD.N.log`. 

 This log is enabled by default for Aurora Serverless v2 DB instances with auto-pause enabled. You can view the contents of this log in the AWS Management Console or by using the AWS CLI or RDSP API. Currently, you can't upload this log to CloudWatch. 

 The events listed in [DB instance events](USER_Events.Messages.md#USER_Events.Messages.instance) provide a high-level overview of pause and resume activity, such as the following: 
+  When the instance begins to pause, and when it finishes pausing. 
+  When the instance begins to resume, and when it finishes resuming. 
+  Cases where the instance attempted to pause, but some condition prevented it from pausing. 

 The `instance.log` provides more granular detail about the reasons why an Aurora Serverless v2 instance might or might not be able to pause. 

 The log might indicate that an instance resumed for different reasons: 
+  **user activity**: A database connection request. This could be from an interactive client session, an RDS Data API call, or a request to download logs from the instance. 
+  **background activity**: A broad category that includes all the reasons why Aurora resumes an instance. For example, when a connection request to a reader instance causes the writer instance to resume, the log for the reader indicates user activity, while the log for the writer classifies that resume request as background activity. For the reasons why Aurora might resume an instance other than a user connection request, see [Resuming an auto-paused Aurora Serverless v2 instance](aurora-serverless-v2-auto-pause.md#auto-pause-waking). 

 When Aurora isn't aware of any conditions that would prevent the instance from pausing when the auto-pause interval expires, it periodically writes an informational message to the log. For clusters with only a single DB instance, the log contains this message: 

```
[INFO] No auto-pause blockers registered since time
```

 For clusters with multiple DB instances, the message is slightly different. That's because a writer might be unable to pause due to activity on any of the reader instances. If the activity on the reader finishes before the auto-pause interval expires on the writer, the writer is able to pause at the expected time. 

```
[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.
```

 If a pause operation starts, but a new database connection request arrives before the instance finishes pausing, the log contains this message: 

```
[INFO] Unable to pause database due to a new database activity
```

 If Aurora becomes aware of any conditions that definitely prevent the instance from pausing, the log contains this message that lists all such conditions: 

```
[INFO] Auto-pause blockers registered since time: list_of_conditions
```

 That way, Aurora doesn't prevent you from turning on replication, zero-ETL integration, Aurora Global Database, and so on in combination with the auto-pause feature. The log informs you when the use of such features might prevent auto-pause from taking effect. 

 The following are reasons why an Aurora Serverless v2 instance might exceed the auto-pause timeout interval, but be prevented from pausing: 
+  **database activity before auto-pause timeout**: The DB instance received a connection request before the timeout interval expired. 
+  **member of global database**: If the DB cluster is part of an Aurora global database, the Aurora Serverless v2 instances in the cluster don't pause. A cluster can change from a standalone cluster to a global database cluster. Thus, instances that formerly auto-paused might stop pausing, and report this reason in the log. Once a cluster becomes a member of a global database, it doesn't revert to a standalone cluster until you explicitly detach it. The primary cluster is still considered part of the global database even if you detach all of the secondary clusters. 
+  **replication capability configured**: The writer DB instance has engine-specific replication enabled, either binlog replication for MySQL or logical replication for PostgreSQL. This condition could also be caused by using another Aurora feature that requires turning on replication, such as zero-ETL integrations or Database Activity Streams (DAS). 
+  **continuous backup lag**: If the Aurora storage system hasn't finished applying the storage changes up to the current point in time, the writer instance doesn't pause until it catches up. This condition only affects the writer instance, and is expected to be relatively brief. 
+  **service or customer maintenance action**: If a maintenance operation starts, the DB instance won't pause again until that operation finishes. This condition includes a wide variety of operations that might be started by you or by Aurora, such as upgrades, cloning, changing configuration settings, upgrades, downloading log files, and so on. This event also happens when you request to delete an instance, and Aurora briefly resumes the instance as part of the deletion mechanism. 
+  **transient communication issue**: If Aurora can't determine whether the scaling configuration currently has a minimum capacity setting of zero ACUs, it doesn't pause the instance. This is expected to be a very rare occurrence. 

# Performance and scaling for Aurora Serverless v2
<a name="scaling"></a>

 The following procedures and examples show how you can set the capacity range for Aurora Serverless v2 clusters and their associated DB instances. You can also use procedures following to monitor how busy your DB instances are. Then you can use your findings to determine if you need to adjust the capacity range upward or downward. 

 Before you use these procedures, make sure that you are familiar with how Aurora Serverless v2 scaling works. The scaling mechanism is different than in Aurora Serverless v1. For details, see [Aurora Serverless v2 scaling](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling). 

**Contents**
+ [

## Choosing the Aurora Serverless v2 capacity range for an Aurora cluster
](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)
  + [

### Choosing the minimum Aurora Serverless v2 capacity setting for a cluster
](#aurora-serverless-v2.min_capacity_considerations)
  + [

### Choosing the maximum Aurora Serverless v2 capacity setting for a cluster
](#aurora-serverless-v2.max_capacity_considerations)
  + [

### Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster
](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams)
  + [

### Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster
](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg)
+ [

## Working with parameter groups for Aurora Serverless v2
](#aurora-serverless-v2.parameter-groups)
  + [

### Default parameter values
](#aurora-serverless-v2.parameter-groups-defaults)
  + [

### Maximum connections for Aurora Serverless v2
](#aurora-serverless-v2.max-connections)
  + [

### Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down
](#aurora-serverless-v2.parameters-based-on-scaling)
  + [

### Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity
](#aurora-serverless-v2.parameters-based-on-max-capacity)
+ [

## Avoiding out-of-memory errors
](#aurora-serverless-v2.setting-capacity.incompatible_parameters)
+ [

## Important Amazon CloudWatch metrics for Aurora Serverless v2
](#aurora-serverless-v2.viewing.monitoring)
  + [

### How Aurora Serverless v2 metrics apply to your AWS bill
](#aurora-serverless-v2-billing)
  + [

### Examples of CloudWatch commands for Aurora Serverless v2 metrics
](#aurora-serverless-v2-cw-examples)
+ [

## Monitoring Aurora Serverless v2 performance with Performance Insights
](#aurora-serverless-v2.viewing.performance-insights)
+ [

## Troubleshooting Aurora Serverless v2 capacity issues
](#aurora-serverless-v2.troubleshooting)

## Choosing the Aurora Serverless v2 capacity range for an Aurora cluster
Choosing the capacity range

 With Aurora Serverless v2 DB instances, you set the capacity range that applies to all the DB instances in your DB cluster at the same time that you add the first Aurora Serverless v2 DB instance to the DB cluster. For the procedure to do so, see [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). 

 You can also change the capacity range for an existing cluster. The following sections discuss in more detail how to choose appropriate minimum and maximum values and what happens when you make a change to the capacity range. For example, changing the capacity range can modify the default values of some configuration parameters. Applying all the parameter changes can require rebooting each Aurora Serverless v2 DB instance. 

**Topics**
+ [

### Choosing the minimum Aurora Serverless v2 capacity setting for a cluster
](#aurora-serverless-v2.min_capacity_considerations)
+ [

### Choosing the maximum Aurora Serverless v2 capacity setting for a cluster
](#aurora-serverless-v2.max_capacity_considerations)
+ [

### Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster
](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams)
+ [

### Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster
](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg)

### Choosing the minimum Aurora Serverless v2 capacity setting for a cluster


 It's tempting to always choose 0.5 for the minimum Aurora Serverless v2 capacity setting. That value allows the DB instance to scale down to the smallest capacity when it's completely idle, while remaining active. You can also enable automatic pause behavior by specifying a minimum capacity of 0 ACUs, as explained in [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). However, depending on how you use that cluster and the other settings that you configure, a different minimum capacity might be the most effective. Consider the following factors when choosing the minimum capacity setting: 
+  The scaling rate for an Aurora Serverless v2 DB instance depends on its current capacity. The higher the current capacity, the faster it can scale up. If you need the DB instance to quickly scale up to a very high capacity, consider setting the minimum capacity to a value where the scaling rate meets your requirement. 
+  If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to make a rough estimate of the equivalent Aurora Serverless v2 capacity range. To determine the memory size to use in times of low traffic, consult [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md). 

   For example, suppose that you use the db.r6g.xlarge DB instance class when your cluster has a low workload. That DB instance class has 32 GiB of memory. Thus, you can specify a minimum Aurora capacity unit (ACU) setting of 16 to set up an Aurora Serverless v2 DB instance that can scale down to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat lower value to let the DB instance scale down further in case your db.r6g.xlarge DB instance was sometimes underutilized. 
+  If your application works most efficiently when the DB instances have a certain amount of data in the buffer cache, consider specifying a minimum ACU setting where the memory is large enough to hold the frequently accessed data. Otherwise, some data is evicted from the buffer cache when the Aurora Serverless v2 DB instances scale down to a lower memory size. Then when the DB instances scale back up, the information is read back into the buffer cache over time. If the amount of I/O to bring the data back into the buffer cache is substantial, it might be more effective to choose a higher minimum ACU value. 
+  If your Aurora Serverless v2 DB instances run most of the time at a particular capacity, consider specifying a minimum capacity setting that's lower than that baseline, but not too much lower. Aurora Serverless v2 DB instances can most effectively estimate how much and how fast to scale up when the current capacity isn't drastically lower than the required capacity. 
+  If your provisioned workload has memory requirements that are too high for small DB instance classes such as T3 or T4g, choose a minimum ACU setting that provides memory comparable to an R5 or R6g DB instance. 

   In particular, we recommend the following minimum capacity for use with the specified features (these recommendations are subject to change): 
  + Performance Insights – 2 ACUs
  + Aurora global databases – 8 ACUs (applies only to the primary AWS Region)
+ In Aurora, replication occurs at the storage layer, so reader capacity doesn't directly affect replication. However, for Aurora Serverless v2 reader DB instances that scale independently, make sure that the minimum capacity is sufficient to handle workloads during write-intensive periods to avoid query latency. If reader DB instances in promotion tiers 2–15 experience performance issues, consider increasing the cluster's minimum capacity. For details on choosing whether reader DB instances scale along with the writer or independently, see [Choosing the promotion tier for an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
+ If you have a DB cluster with Aurora Serverless v2 reader DB instances, the readers don't scale along with the writer DB instance when the promotion tier of the readers isn't 0 or 1. In that case, setting a low minimum capacity can result in excessive replication lag. That's because the readers might not have enough capacity to apply changes from the writer when the database is busy. We recommend that you set the minimum capacity to a value that represents a comparable amount of memory and CPU to the writer DB instance.
+ The value of the `max_connections` parameter for Aurora Serverless v2DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000.

  If you intend to use the Aurora PostgreSQL cluster for a high-connection workload, consider using a minimum ACU setting of 1 or higher. For details about how Aurora Serverless v2 handles the `max_connections` configuration parameter, see [Maximum connections for Aurora Serverless v2](#aurora-serverless-v2.max-connections).
+  The time it takes for an Aurora Serverless v2 DB instance to scale from its minimum capacity to its maximum capacity depends on the difference between its minimum and maximum ACU values. When the current capacity of the DB instance is large, Aurora Serverless v2 scales up in larger increments than when the DB instance starts from a small capacity. Thus, if you specify a relatively large maximum capacity and the DB instance spends most of its time near that capacity, consider increasing the minimum ACU setting. That way, an idle DB instance can scale back up to maximum capacity more quickly. 

### Choosing the maximum Aurora Serverless v2 capacity setting for a cluster


 It's tempting to always choose some high value for the maximum Aurora Serverless v2 capacity setting. A large maximum capacity allows the DB instance to scale up the most when it's running an intensive workload. A low value avoids the possibility of unexpected charges. Depending on how you use that cluster and the other settings that you configure, the most effective value might be higher or lower than you originally thought. Consider the following factors when choosing the maximum capacity setting: 
+  The maximum capacity must be at least as high as the minimum capacity. You can set the minimum and maximum capacity to be identical. However, in that case the capacity never scales up or down. Thus, using identical values for minimum and maximum capacity isn't appropriate outside of testing situations. 
+  The maximum capacity must be higher than 0.5 ACUs. You can set the minimum and maximum capacity to be the same in most cases. However, you can't specify 0.5 for both the minimum and maximum. Use a value of 1 or higher for the maximum capacity. 
+  If you typically modify the DB instance class of your DB instances in anticipation of especially high or low workload, you can use that experience to estimate the equivalent Aurora Serverless v2 capacity range. To determine the memory size to use in times of high traffic, consult [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md). 

   For example, suppose that you use the db.r6g.4xlarge DB instance class when your cluster has a high workload. That DB instance class has 128 GiB of memory. Thus, you can specify a maximum ACU setting of 64 to set up an Aurora Serverless v2 DB instance that can scale up to approximately that same capacity. That's because each ACU corresponds to approximately 2 GiB of memory. You might specify a somewhat higher value to let the DB instance scale up farther in case your db.r6g.4xlarge DB instance sometimes doesn't have enough capacity to handle the workload effectively. 
+  If you have a budgetary cap on your database usage, choose a value that stays within that cap even if all your Aurora Serverless v2 DB instances run at maximum capacity all the time. Remember that when you have *n* Aurora Serverless v2 DB instances in your cluster, the theoretical maximum Aurora Serverless v2 capacity that the cluster can consume at any moment is *n* times the maximum ACU setting for the cluster. (The actual amount consumed might be less, for example if some readers scale independently from the writer.) 
+  If you make use of Aurora Serverless v2 reader DB instances to offload some of the read-only workload from the writer DB instance, you might be able to choose a lower maximum capacity setting. You do this to reflect that each reader DB instance doesn't need to scale as high as if the cluster contains only a single DB instance. 
+  Suppose that you want to protect against excessive usage due to misconfigured database parameters or inefficient queries in your application. In that case, you might avoid accidental overuse by choosing a maximum capacity setting that's lower than the absolute highest that you could set. 
+  If spikes due to real user activity are rare but do happen, you can take those occasions into account when choosing the maximum capacity setting. If the priority is for the application to keep running with full performance and scalability, you can specify a maximum capacity setting that's higher than you observe in normal usage. If it's OK for the application to run with reduced throughput during very extreme spikes in activity, you can choose a slightly lower maximum capacity setting. Make sure that you choose a setting that still has enough memory and CPU resources to keep the application running. 
+  If you turn on settings in your cluster that increase the memory usage for each DB instance, take that memory into account when deciding on the maximum ACU value. Such settings include those for Performance Insights, Aurora MySQL parallel queries, Aurora MySQL performance schema, and Aurora MySQL binary log replication. Make sure that the maximum ACU value allows the Aurora Serverless v2 DB instances to scale up enough to handle the workload when those feature are being used. For information about troubleshooting problems caused by the combination of a low maximum ACU setting and Aurora features that impose memory overhead, see [Avoiding out-of-memory errors](#aurora-serverless-v2.setting-capacity.incompatible_parameters). 

### Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster


 The following AWS CLI example shows how to update the ACU range for Aurora Serverless v2 DB instances in an existing Aurora MySQL cluster. Initially, the capacity range for the cluster is 8–32 ACUs.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}
```

The DB instance is idle and scaled down to 8 ACUs. The following capacity-related settings apply to the DB instance at this point. To represent the size of the buffer pool in easily readable units, we divide it by 2 to the power of 30, yielding a measurement in gibibytes (GiB). That's because memory-related measurements for Aurora use units based on powers of 2, not powers of 10.

```
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                9294577664 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|   8.65625 |
+-----------+
1 row in set (0.00 sec)
```

Next, we change the capacity range for the cluster. After the `modify-db-cluster` command finishes, the ACU range for the cluster is 12.5–80.

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}
```

Changing the capacity range caused changes to the default values of some configuration parameters. Aurora can apply some of those new defaults immediately. However, some of the parameter changes take effect only after a reboot. The `pending-reboot` status indicates that a reboot is needed to apply some parameter changes.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}
```

At this point, the cluster is idle and the DB instance `serverless-v2-instance-1` is consuming 12.5 ACUs. The `innodb_buffer_pool_size` parameter is already adjusted based on the current capacity of the DB instance. The `max_connections` parameter still reflects the value from the former maximum capacity. Resetting that value requires rebooting the DB instance.

**Note**  
If you set the `max_connections` parameter directly in a custom DB parameter group, no reboot is required.

```
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               15572402176 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes     |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)
```

Now we reboot the DB instance and wait for it to become available again.

```
aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1
```

The `pending-reboot` status is cleared. The value `in-sync` confirms that Aurora has applied all the pending parameter changes.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}
```

The `innodb_buffer_pool_size` parameter has increased to its final size for an idle DB instance. The `max_connections` parameter has increased to reflect a value derived from the maximum ACU value. The formula that Aurora uses for `max_connections` causes an increase of 1,000 when the memory size doubles.

```
mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               16139681792 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|  15.03125 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              4000 |
+-------------------+
1 row in set (0.00 sec)
```

We set the capacity range to 0.5–128 ACUs, and reboot the DB instance. Now the idle DB instance has a buffer cache size that's less than 1 GiB, so we measure it in mebibytes (MiB). The `max_connections` value of 5000 is derived from the memory size of the maximum capacity setting.

```
mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
|       672 |              5000 |
+-----------+-------------------+
1 row in set (0.00 sec)
```

### Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster


The following CLI examples show how to update the ACU range for Aurora Serverless v2 DB instances in an existing Aurora PostgreSQL cluster.

1. The capacity range for the cluster starts at 0.5–1 ACU.

1. Change the capacity range to 8–32 ACUs.

1. Change the capacity range to 12.5–80 ACUs.

1. Change the capacity range to 0.5–128 ACUs.

1. Return the capacity to its initial range of 0.5–1 ACU.

The following figure shows the capacity changes in Amazon CloudWatch.

![\[CloudWatch graph of Aurora Serverless v2 capacity changes\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/sv2-apg-scaling-example.png)


The DB instance is idle and scaled down to 0.5 ACUs. The following capacity-related settings apply to the DB instance at this point.

```
postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)
```

Next, we change the capacity range for the cluster. After the `modify-db-cluster` command finishes, the ACU range for the cluster is 8.0–32.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}
```

Changing the capacity range causes changes to the default values of some configuration parameters. Aurora can apply some of those new defaults immediately. However, some of the parameter changes take effect only after a reboot. The `pending-reboot` status indicates that you need a reboot to apply some parameter changes.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}
```

At this point, the cluster is idle and the DB instance `serverless-v2-instance-1` is consuming 8.0 ACUs. The `shared_buffers` parameter is already adjusted based on the current capacity of the DB instance. The `max_connections` parameter still reflects the value from the former maximum capacity. Resetting that value requires rebooting the DB instance.

**Note**  
If you set the `max_connections` parameter directly in a custom DB parameter group, no reboot is required.

```
postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)
```

We reboot the DB instance and wait for it to become available again.

```
aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1
```

Now that the DB instance is rebooted, the `pending-reboot` status is cleared. The value `in-sync` confirms that Aurora has applied all the pending parameter changes.

```
aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}
```

After rebooting, `max_connections` shows the value from the new maximum capacity.

```
postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)
```

Next, we change the capacity range for the cluster to 12.5–80 ACUs.

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}
```

At this point, the cluster is idle and the DB instance `serverless-v2-instance-1` is consuming 12.5 ACUs. The `shared_buffers` parameter is already adjusted based on the current capacity of the DB instance. The `max_connections` value is still 5000.

```
postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)
```

We reboot again, but the parameter values stay the same. This is because `max_connections` has a maximum value of 5000 for an Aurora Serverless v2 DB cluster running Aurora PostgreSQL.

```
postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)
```

Now we set the capacity range from 0.5 to 128 ACUs. The DB cluster scales down to 10 ACUs, then to 2. We reboot the DB instance.

```
postgres=> show max_connections;
 max_connections
-----------------
 2000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)
```

The `max_connections` value for Aurora Serverless v2 DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000.

Now we return the capacity to its initial range of 0.5–1 ACU and reboot the DB instance. The `max_connections` parameter has returned to its original value.

```
postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)
```

## Working with parameter groups for Aurora Serverless v2


 When you create your Aurora Serverless v2 DB cluster, you choose a specific Aurora DB engine and an associated DB cluster parameter group. If you aren't familiar with how Aurora uses parameter groups to apply configuration settings consistently across clusters, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md). All of those procedures for creating, modifying, applying, and other actions for parameter groups apply to Aurora Serverless v2. 

 The parameter group feature works generally the same between provisioned clusters and clusters containing Aurora Serverless v2 DB instances: 
+  The default parameter values for all DB instances in the cluster are defined by the cluster parameter group. 
+  You can override some parameters for specific DB instances by specifying a custom DB parameter group for those DB instances. You might do so during debugging or performance tuning for specific DB instances. For example, suppose that you have a cluster containing some Aurora Serverless v2 DB instances and some provisioned DB instances. In this case, you might specify some different parameters for the provisioned DB instances by using a custom DB parameter group. 
+  For Aurora Serverless v2, you can use all the parameters that have the value `provisioned` in the `SupportedEngineModes` attribute in the parameter group. In Aurora Serverless v1, you can only use the subset of parameters that have `serverless` in the `SupportedEngineModes` attribute. 

**Topics**
+ [

### Default parameter values
](#aurora-serverless-v2.parameter-groups-defaults)
+ [

### Maximum connections for Aurora Serverless v2
](#aurora-serverless-v2.max-connections)
+ [

### Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down
](#aurora-serverless-v2.parameters-based-on-scaling)
+ [

### Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity
](#aurora-serverless-v2.parameters-based-on-max-capacity)

### Default parameter values


 The crucial difference between provisioned DB instances and Aurora Serverless v2 DB instances is that Aurora overrides any custom parameter values for certain parameters that are related to DB instance capacity. The custom parameter values still apply to any provisioned DB instances in your cluster. For more details about how Aurora Serverless v2 DB instances interpret the parameters from Aurora parameter groups, see [Configuration parameters for Aurora clusters](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.parameters). For the specific parameters that Aurora Serverless v2 overrides, see [Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down](#aurora-serverless-v2.parameters-based-on-scaling) and [Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity](#aurora-serverless-v2.parameters-based-on-max-capacity). 

 You can get a list of default values for the default parameter groups for the various Aurora DB engines by using the [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) CLI command and querying the AWS Region. The following are values that you can use for the `--db-parameter-group-family` and `-db-parameter-group-name` options for engine versions that are compatible with Aurora Serverless v2. 


|  Database engine and version  |  Parameter group family  |  Default parameter group name  | 
| --- | --- | --- | 
|  Aurora MySQL version 3  |  `aurora-mysql8.0`  |  `default.aurora-mysql8.0`  | 
|  Aurora PostgreSQL version 13.x  |  `aurora-postgresql13`  |  `default.aurora-postgresql13`  | 
|  Aurora PostgreSQL version 14.x  |  `aurora-postgresql14`  |  `default.aurora-postgresql14`  | 
|  Aurora PostgreSQL version 15.x  |  `aurora-postgresql15`  |  `default.aurora-postgresql15`  | 
|  Aurora PostgreSQL version 16.x  |  `aurora-postgresql16`  |  `default.aurora-postgresql16`  | 
|  Aurora PostgreSQL version 17.x  |  `aurora-postgresql17`  |  `default.aurora-postgresql17`  | 

 The following example gets a list of parameters from the default DB cluster group for Aurora MySQL version 3 and Aurora PostgreSQL 13. Those are the Aurora MySQL and Aurora PostgreSQL versions that you use with Aurora Serverless v2. 

For Linux, macOS, or Unix:

```
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-mysql8.0 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-postgresql13 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text
```

For Windows:

```
aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-mysql8.0 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-postgresql13 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text
```

### Maximum connections for Aurora Serverless v2
Aurora Serverless v2 maximum connections

For both Aurora MySQL and Aurora PostgreSQL, Aurora Serverless v2 DB instances hold the `max_connections` parameter constant so that connections aren't dropped when the DB instance scales down. The default value for this parameter is derived from a formula based on the memory size of the DB instance. For details about the formula and the default values for provisioned DB instance classes, see [Maximum connections to an Aurora MySQL DB instance](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) and [Maximum connections to an Aurora PostgreSQL DB instance](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections).

When Aurora Serverless v2 evaluates the formula, it uses the memory size based on the maximum Aurora capacity units (ACUs) for the DB instance, not the current ACU value. If you change the default value, we recommend using a variation of the formula instead of specifying a constant value. That way, Aurora Serverless v2 can use an appropriate setting based on the maximum capacity.

When you change the maximum capacity of an Aurora Serverless v2 DB cluster, you have to reboot the Aurora Serverless v2 DB instances to update the `max_connections` value. This is because `max_connections` is a static parameter for Aurora Serverless v2.

The following table shows the default values for `max_connections` for Aurora Serverless v2 based on the maximum ACU value.


| Maximum ACUs | Default maximum connections on Aurora MySQL | Default maximum connections on Aurora PostgreSQL | 
| --- | --- | --- | 
| 1 | 90 | 189 | 
| 4 | 135 | 823 | 
| 8 | 1,000 | 1,669 | 
| 16 | 2,000 | 3,360 | 
| 32 | 3,000 | 5,000 | 
| 64 | 4,000 | 5,000 | 
| 128 | 5,000 | 5,000 | 
| 192 | 6,000 | 5,000 | 
| 256 | 6,000 | 5,000 | 

**Note**  
The `max_connections` value for Aurora Serverless v2DB instances is based on the memory size derived from the maximum ACUs. However, when you specify a minimum capacity of 0 or 0.5 ACUs on PostgreSQL-compatible DB instances, the maximum value of `max_connections` is capped at 2,000.

For specific examples showing how `max_connections` changes with the maximum ACU value, see [Example: Change the Aurora Serverless v2 capacity range of an Aurora MySQL cluster](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-ams) and [Example: Change the Aurora Serverless v2 capacity range of an Aurora PostgreSQL cluster](#aurora-serverless-v2-examples-setting-capacity-range-walkthrough-apg).

### Parameters that Aurora adjusts as Aurora Serverless v2 scales up and down
Parameters adjusted by Aurora Serverless v2 scaling

 During autoscaling, Aurora Serverless v2 needs to be able to change parameters for each DB instance to work best for the increased or decreased capacity. Thus, you can't override some parameters related to capacity. For some parameters that you can override, avoid hardcoding fixed values. The following considerations apply to these settings that are related to capacity. 

 For Aurora MySQL, Aurora Serverless v2 resizes some parameters dynamically during scaling. For the following parameters, Aurora Serverless v2 doesn't use any custom parameter values that you specify: 
+  `innodb_buffer_pool_size` 
+  `innodb_purge_threads` 
+  `table_definition_cache` 
+  `table_open_cache` 

 For Aurora PostgreSQL, Aurora Serverless v2 resizes the following parameter dynamically during scaling. For the following parameters, Aurora Serverless v2 doesn't use any custom parameter values that you specify: 
+  `shared_buffers` 

 For all parameters other than those listed here, Aurora Serverless v2 DB instances work the same as provisioned DB instances. The default parameter value is inherited from the cluster parameter group. You can modify the default for the whole cluster by using a custom cluster parameter group. Or you can modify the default for certain DB instances by using a custom DB parameter group. Dynamic parameters are updated immediately. Changes to static parameters only take effect after you reboot the DB instance.

### Parameters that Aurora computes based on Aurora Serverless v2 maximum capacity
Parameters based on Aurora Serverless v2 maximum capacity

For the following parameters, Aurora PostgreSQL uses default values that are derived from the memory size based on the maximum ACU setting, the same as with `max_connections`:
+ `autovacuum_max_workers`
+ `autovacuum_vacuum_cost_limit`
+ `autovacuum_work_mem`
+ `effective_cache_size`
+ `maintenance_work_mem`

## Avoiding out-of-memory errors


 If one of your Aurora Serverless v2 DB instances consistently reaches the limit of its maximum capacity, Aurora indicates this condition by setting the DB instance to a status of `incompatible-parameters`. While the DB instance has the `incompatible-parameters` status, some operations are blocked. For example, you can't upgrade the engine version. 

 Typically, your DB instance goes into this status when it restarts frequently due to out-of-memory errors. Aurora records an event when this type of restart happens. You can view the event by following the procedure in [Viewing Amazon RDS events](USER_ListEvents.md). Unusually high memory usage can happen because of overhead from turning on settings such as Performance Insights and IAM authentication. It can also come from a heavy workload on your DB instance or from managing the metadata associated with a large number of schema objects. 

 If the memory pressure becomes lower so that the DB instance doesn't reach its maximum capacity very often, Aurora automatically changes the DB instance status back to `available`. 

 To recover from this condition, you can take some or all of the following actions: 
+  Increase the lower limit on capacity for Aurora Serverless v2 DB instances by changing the minimum Aurora capacity unit (ACU) value for the cluster. Doing so avoids issues where an idle database scales down to a capacity with less memory than is needed for the features that are turned on in your cluster. After changing the ACU settings for the cluster, reboot the Aurora Serverless v2 DB instance. Doing so evaluates whether Aurora can reset the status back to `available`. 
+  Increase the upper limit on capacity for Aurora Serverless v2 DB instances by changing the maximum ACU value for the cluster. Doing so avoids issues where a busy database can't scale up to a capacity with enough memory for the features that are turned on in your cluster and the database workload. After changing the ACU settings for the cluster, reboot the Aurora Serverless v2 DB instance. Doing so evaluates whether Aurora can reset the status back to `available`. 
+  Turn off configuration settings that require memory overhead. For example, suppose that you have features such as AWS Identity and Access Management (IAM), Performance Insights, or Aurora MySQL binary log replication turned on but don't use them. If so, you can turn them off. Or you can adjust the minimum and maximum capacity values for the cluster higher to account for the memory used by those features. For guidelines about choosing minimum and maximum capacity settings, see [Choosing the Aurora Serverless v2 capacity range for an Aurora cluster](#aurora-serverless-v2-examples-setting-capacity-range-for-cluster). 
+  Reduce the workload on the DB instance. For example, you can add reader DB instances to the cluster to spread the load from read-only queries across more DB instances. 
+  Tune the SQL code used by your application to use fewer resources. For example, you can examine your query plans, check the slow query log, or adjust the indexes on your tables. You can also perform other traditional kinds of SQL tuning. 

## Important Amazon CloudWatch metrics for Aurora Serverless v2
Important CloudWatch metrics

 To get started with Amazon CloudWatch for your Aurora Serverless v2 DB instance, see [Viewing Aurora Serverless v2 logs in Amazon CloudWatch](aurora-serverless-v2-administration.md#aurora-serverless-v2.logging.monitoring). To learn more about how to monitor Aurora DB clusters through CloudWatch, see [Monitoring log events in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor). 

 You can view your Aurora Serverless v2 DB instances in CloudWatch to monitor the capacity consumed by each DB instance with the `ServerlessDatabaseCapacity` metric. You can also monitor all of the standard Aurora CloudWatch metrics, such as `DatabaseConnections` and `Queries`. For the full list of CloudWatch metrics that you can monitor for Aurora, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). The metrics are divided into cluster-level and instance-level metrics, in [Cluster-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters) and [Instance-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). 

 The following CloudWatch instance-level metrics are important to monitor for you to understand how your Aurora Serverless v2 DB instances are scaling up and down. All of these metrics are calculated every second. That way, you can monitor the current status of your Aurora Serverless v2 DB instances. You can set alarms to notify you if any Aurora Serverless v2 DB instance approaches a threshold for metrics related to capacity. You can determine if the minimum and maximum capacity settings are appropriate, or if you need to adjust them. You can determine where to focus your efforts for optimizing the efficiency of your database. 
+  `ServerlessDatabaseCapacity`. As an instance-level metric, it reports the number of ACUs represented by the current DB instance capacity. As a cluster-level metric, it represents the average of the `ServerlessDatabaseCapacity` values of all the Aurora Serverless v2 DB instances in the cluster. This metric is only a cluster-level metric in Aurora Serverless v1. In Aurora Serverless v2, it's available at the DB instance level and at the cluster level. 
+  `ACUUtilization`. This metric is new in Aurora Serverless v2. This value is represented as a percentage. It's calculated as the value of the `ServerlessDatabaseCapacity` metric divided by the maximum ACU value of the DB cluster. Consider the following guidelines to interpret this metric and take action: 
  +  If this metric approaches a value of `100.0`, the DB instance has scaled up as high as it can. Consider increasing the maximum ACU setting for the cluster. That way, both writer and reader DB instances can scale to a higher capacity. 
  +  Suppose that a read-only workload causes a reader DB instance to approach an `ACUUtilization` of `100.0`, while the writer DB instance isn't close to its maximum capacity. In that case, consider adding additional reader DB instances to the cluster. That way, you can spread the read-only part of the workload spread across more DB instances, reducing the load on each reader DB instance. 
  +  Suppose that you are running a production application, where performance and scalability are the primary considerations. In that case, you can set the maximum ACU value for the cluster to a high number. Your goal is for the `ACUUtilization` metric to always be below `100.0`. With a high maximum ACU value, you can be confident that there's enough room in case there are unexpected spikes in database activity. You are only charged for the database capacity that's actually consumed. 
+  `CPUUtilization`. This metric is interpreted differently in Aurora Serverless v2 than in provisioned DB instances. For Aurora Serverless v2, this value is a percentage that's calculated as the amount of CPU currently being used divided by the CPU capacity that's available under the maximum ACU value of the DB cluster. Aurora monitors this value automatically and scales up your Aurora Serverless v2 DB instance when the DB instance consistently uses a high proportion of its CPU capacity. 

   If this metric approaches a value of `100.0`, the DB instance has reached its maximum CPU capacity. Consider increasing the maximum ACU setting for the cluster. If this metric approaches a value of `100.0` on a reader DB instance, consider adding additional reader DB instances to the cluster. That way, you can spread the read-only part of the workload spread across more DB instances, reducing the load on each reader DB instance. 
+  `FreeableMemory`. This value represents the amount of unused memory that is available when the Aurora Serverless v2 DB instance is scaled to its maximum capacity. For every ACU that the current capacity is below the maximum capacity, this value increases by approximately 2 GiB. Thus, this metric doesn't approach zero until the DB instance is scaled up as high as it can. 

   If this metric approaches a value of `0`, the DB instance has scaled up as much as it can and is nearing the limit of its available memory. Consider increasing the maximum ACU setting for the cluster. If this metric approaches a value of `0` on a reader DB instance, consider adding additional reader DB instances to the cluster. That way, the read-only part of the workload can be spread across more DB instances, reducing the memory usage on each reader DB instance. 
+  `TempStorageIOPS`. The number of IOPS done on local storage attached to the DB instance. It includes the IOPS for both reads and writes. This metric represents a count and is measured once per second. This is a new metric for Aurora Serverless v2. For details, see [Instance-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). 
+  `TempStorageThroughput`. The amount of data transferred to and from local storage associated with the DB instance. This metric represents bytes and is measured once per second. This is a new metric for Aurora Serverless v2. For details, see [Instance-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). 

 Typically, most scaling up for Aurora Serverless v2 DB instances is caused by memory usage and CPU activity. The `TempStorageIOPS` and `TempStorageThroughput` metrics can help you to diagnose the rare cases where network activity for transfers between your DB instance and local storage devices is responsible for unexpected capacity increases. To monitor other network activity, you can use these existing metrics: 
+  `NetworkReceiveThroughput` 
+  `NetworkThroughput` 
+  `NetworkTransmitThroughput` 
+  `StorageNetworkReceiveThroughput` 
+  `StorageNetworkThroughput` 
+  `StorageNetworkTransmitThroughput` 

You can have Aurora publish some or all database logs to Amazon CloudWatch Logs. For instructions, see the following depending on your database engine:
+ [Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
+ [Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)

### How Aurora Serverless v2 metrics apply to your AWS bill


 The Aurora Serverless v2 charges on your AWS bill are calculated based on the same `ServerlessDatabaseCapacity` metric that you can monitor. The billing mechanism can differ from the computed CloudWatch average for this metric in cases where you use Aurora Serverless v2 capacity for only part of an hour. It can also differ if system issues make the CloudWatch metric unavailable for brief periods. Thus, you might see a slightly different value of ACU-hours on your bill than if you compute the number yourself from the `ServerlessDatabaseCapacity` average value. 

### Examples of CloudWatch commands for Aurora Serverless v2 metrics


 The following AWS CLI examples demonstrate how you can monitor the most important CloudWatch metrics related to Aurora Serverless v2. In each case, replace the `Value=` string for the `--dimensions` parameter with the identifier of your own Aurora Serverless v2 DB instance. 

 The following Linux example displays the minimum, maximum, and average capacity values for a DB instance, measured every 10 minutes over one hour. The Linux `date` command specifies the start and end times relative to the current date and time. The `sort_by` function in the `--query` parameter sorts the results chronologically based on the `Timestamp` field. 

```
aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```

 The following Linux examples demonstrate monitoring the capacity of each DB instance in a cluster. They measure the minimum, maximum, and average capacity utilization of each DB instance. The measurements are taken once each hour over a three-hour period. These examples use the `ACUUtilization` metric representing a percentage of the upper limit on ACUs, instead of `ServerlessDatabaseCapacity` representing a fixed number of ACUs. That way, you don't need to know the actual numbers for the minimum and maximum ACU values in the capacity range. You can see percentages ranging from 0 to 100. 

```
aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```

 The following Linux example does similar measurements as the previous ones. In this case, the measurements are for the `CPUUtilization` metric. The measurements are taken every 10 minutes over a 1-hour period. The numbers represent the percentage of available CPU used, based on the CPU resources available to the maximum capacity setting for the DB instance. 

```
aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```

 The following Linux example does similar measurements as the previous ones. In this case, the measurements are for the `FreeableMemory` metric. The measurements are taken every 10 minutes over a 1-hour period. 

```
aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table
```

## Monitoring Aurora Serverless v2 performance with Performance Insights


 You can use Performance Insights to monitor the performance of Aurora Serverless v2 DB instances. For Performance Insights procedures, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md). 

 The following new Performance Insights counters apply to Aurora Serverless v2 DB instances: 
+  `os.general.serverlessDatabaseCapacity` – The current capacity of the DB instance in ACUs. The value corresponds to the `ServerlessDatabaseCapacity` CloudWatch metric for the DB instance. 
+  `os.general.acuUtilization` – The percentage of current capacity out of the maximum configured capacity. The value corresponds to the `ACUUtilization` CloudWatch metric for the DB instance. 
+  `os.general.maxConfiguredAcu` – The maximum capacity that you configured for this Aurora Serverless v2 DB instance. It's measured in ACUs. 
+  `os.general.minConfiguredAcu` – The minimum capacity that you configured for this Aurora Serverless v2 DB instance. It's measured in ACUs 

 For the full list of Performance Insights counters, see [Performance Insights counter metrics](USER_PerfInsights_Counters.md). 

 When `vCPU` values are shown for an Aurora Serverless v2 DB instance in Performance Insights, those values represent estimates based on the ACU value for the DB instance. At the default interval of one minute, any fractional vCPU values are rounded up to the nearest whole number. For longer intervals, the vCPU value shown is the average of the integer vCPU values for each minute. 

## Troubleshooting Aurora Serverless v2 capacity issues


In some cases, Aurora Serverless v2 doesn't scale down to the minimum capacity, even with no load on the database. This can happen for the following reasons:
+ Certain features can increase resource usage and prevent the database from scaling down to minimum capacity. These features include the following:
  + Aurora global databases
  + Exporting CloudWatch Logs
  + Enabling `pg_audit` on Aurora PostgreSQL–compatible DB clusters
  + Enhanced Monitoring
  + Performance Insights

  For more information, see [Choosing the minimum Aurora Serverless v2 capacity setting for a cluster](#aurora-serverless-v2.min_capacity_considerations).
+ If a reader instance isn't scaling down to the minimum and stays at the same or higher capacity than the writer instance, then check the priority tier of the reader instance. Aurora Serverless v2 reader DB instances in tier 0 or 1 are kept at a minimum capacity at least as high as the writer DB instance. Change the priority tier of the reader to 2 or higher so that it scales up and down independently of the writer. For more information, see [Choosing the promotion tier for an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier).
+ Set any database parameters that impact the size of shared memory to their default values. Setting a value higher than the default increases the shared memory requirement and prevents the database from scaling down to the minimum capacity. Examples are `max_connections` and `max_locks_per_transaction`.
**Note**  
Updating shared memory parameters requires a database restart for the changes to take effect.
+ Heavy database workloads can increase resource usage.
+ Large database volumes can increase resource usage.

  Amazon Aurora uses memory and CPU resources for DB cluster management. Aurora requires more CPU and memory to manage DB clusters with larger database volumes. If your cluster’s minimum capacity is less than the minimum required for cluster management, your cluster won't scale down to the minimum capacity.
+ Background processes, such as purge, can also increase resource usage.
+ Platform version limitations can affect scaling capabilities. The available scaling range for a given cluster is influenced by both engine version and hardware (platform version). It is possible to have a more capable engine version running on a less capable platform version and vice-versa.

If the database still doesn't scale down to the minimum capacity configured, then stop and restart the database to reclaim any memory fragments that might have built up over time. Stopping and starting a database results in downtime, so we recommend doing this sparingly.

# Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2
Scaling to 0 ACUs with auto-pause and resume<a name="auto-pause"></a><a name="autopause"></a>

 You can specify that Aurora Serverless v2 DB instances scale down to zero ACUs and automatically pause, if they don't have any connections initiated by user activity within a specified time period. You do so by specifying a minimum ACU value of zero for your DB cluster. You aren't charged for instance capacity while an instance is in the paused state. Enabling the automatic pause and resume feature (auto-pause) for Aurora clusters that are lightly used or have extended periods of inactivity can help you to manage costs for your database fleet. 

**Note**  
 The auto-pause feature is available for Aurora Serverless v2 with both Aurora PostgreSQL and Aurora MySQL. You might need to upgrade your Aurora database engine version to take advantage of this feature. For the engine versions where a minimum capacity of 0 ACUs is available, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). 

**Topics**
+ [Overview of auto-pause](#auto-pause-overview)
+ [Prerequisites and Limitations](#auto-pause-prereqs)
+ [Turning auto-pause on and off](#auto-pause-enabling-disabling)
+ [How auto-pause works](#auto-pause-how-it-works)
+ [Auto-pause and Aurora cluster configurations](#auto-pause-topology)
+ [Monitoring auto-pause](#auto-pause-monitoring)
+ [Troubleshooting for auto-pause](#auto-pause-troubleshooting)
+ [Application design for auto-pause](#auto-pause-applications)

## Overview of the Aurora Serverless v2 auto-pause feature
Overview of auto-pause

 Aurora Serverless v2 DB instances can automatically pause after a period with no user connections, and automatically resume when a connection request arrives. The Aurora Serverless v2 automatic pause/resume feature helps to manage costs for systems that don't have a stringent service level objective (SLO). For example, you might enable this feature for clusters used for development and testing, or for internal applications where a brief pause is acceptable while the database resumes. If your workload has periods of inactivity and can tolerate slight delays in connecting while the instance resumes, consider using auto-pause with your Aurora Serverless v2 instances to reduce costs. 

 You control this behavior by specifying whether the Aurora Serverless v2 DB instances in a cluster can automatically pause or not, and how long each instance must be idle before it pauses. To enable the auto-pause behavior for all the Aurora Serverless v2 DB instances in an Aurora cluster, you set the minimum capacity value for the cluster to zero ACUs. 

 If you formerly took advantage of the Aurora Serverless v1 feature that scaled to zero ACUs after a period of inactivity, you can upgrade to Aurora Serverless v2 and use its corresponding auto-pause feature. 

 The cost-savings benefits of the auto-pause feature are similar to using the stop/start cluster feature. Auto-pause for Aurora Serverless v2 has the additional benefits of a faster resume than starting a stopped cluster, and automating the process of determining when to pause and resume each DB instance. 

 The auto-pause feature also provides additional granularity in controlling costs for compute resources within your cluster. You can enable some reader instances to pause even while the writer instance and other readers in the cluster remain active at all times. You do so by assigning the reader instances that can pause independently of other instances a failover priority in the range 2-15. 

 The writer instances and all reader instances with failover priority 0 and 1 always pause and resume at the same time. Thus, the instances in this group pause after none of them have any connections for the specified time interval. 

 Aurora DB clusters can contain a combination of writer and reader DB instances and provisioned and Aurora Serverless v2 DB instances. Therefore, to use this feature effectively, it's helpful to understand the following aspects of the auto-pause mechanism: 
+  The circumstances when a DB instance might automatically pause. 
+  When a DB instance might be prevented from pausing. For example, enabling some Aurora features or performing certain kinds of operations on the cluster might prevent instances from pausing, even without any connections to those instances. 
+  The consequences for monitoring and billing while an instance is paused. 
+  What actions cause a DB instance to resume processing. 
+  How the capacity of a DB instance changes around the time of the pause and resume events. 
+  How to control the idle interval before a DB instance pauses. 
+  How to code application logic to handle the period while a DB instance is resuming processing. 

## Prerequisites and Limitations for the Aurora Serverless v2 auto-pause feature
Prerequisites and Limitations

 Before using the auto-pause feature, check which engine versions to use. Also, check whether auto-pause works in combination with the other Aurora features you intend to use. You can't turn on auto-pause if you're using an engine version that doesn't support it. For incompatible features, you won't get any error if you use them in combination with auto-pause. If the cluster is using any incompatible features or settings, the Aurora Serverless v2 instances won't automatically pause. 
+  If you're using Aurora PostgreSQL, the database engine must be running at least version 16.3, 15.7, 14.12, or 13.15. 
+  If you're using Aurora MySQL, the database engine must be running version 3.08.0 or higher. 
+  For the full list of engine versions and AWS Regions where this feature is available, see [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md). 
+  When an Aurora Serverless v2 instance resumes, its capacity might be lower than it was when the instance was paused. For details, see [Differences in auto-pause behavior between Aurora Serverless v2 and Aurora Serverless v1](#auto-pause-differences). 

 Certain conditions or settings prevent Aurora Serverless v2 instances from automatically pausing. For more information, see [Situations where Aurora Serverless v2 doesn't auto-pause](#auto-pause-whynot). 

## Turning the auto-pause feature on and off
Turning auto-pause on and off

 You can turn the auto-pause feature on and off at the cluster level. To do so, you use the same procedures as when you adjust the minimum and maximum capacity for the cluster. The auto-pause feature is represented by a minimum capacity of 0 ACUs. 

**Topics**
+ [Turning on auto-pause](#auto-pause-enabling)
+ [Auto-pause timeout interval](#auto-pause-timeout)
+ [Resuming an instance](#auto-pause-waking)
+ [Turning off auto-pause](#auto-pause-disabling)

### Turning on auto-pause for Aurora Serverless v2 instances in a cluster
Turning on auto-pause

 Follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). For the minimum capacity, choose 0 ACUs. When you choose a minimum capacity of 0 ACUs, you can also specify the length of time for the instance to be idle before it's automatically paused. 

 The following CLI example shows how you might create an Aurora cluster with the auto-pause feature enabled and the auto-pause interval set to ten minutes (600 seconds). 

```
aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password
```

 The following CLI example shows how you might turn on the auto-pause feature for an existing Aurora cluster. This example sets the auto-pause interval to one hour (3600 seconds). 

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}
```

### Configurable Aurora Serverless v2 auto-pause timeout interval
Auto-pause timeout interval

 The timeout interval is represented in the `ServerlessV2ScalingConfiguration` attribute of your Aurora cluster. You can specify this interval in the AWS Management Console when creating or modifying an Aurora cluster, if the minimum capacity is set to zero ACUs. You can specify it in the AWS CLI by using the `--serverless-v2-scaling-configuration` parameter when creating or modifying an Aurora cluster. You can specify it in the RDS API by using the `ServerlessV2ScalingConfiguration` parameter when creating or modifying an Aurora cluster. 

 The minimum interval that you can set is 300 seconds (five minutes). That's the default if you don't specify an interval. The maximum interval that you can set is 86,400 seconds (one day). 

 Suppose that you turn off the auto-pause feature for a cluster by changing the cluster's minimum capacity to a nonzero value. In that case, the interval property is removed from the `ServerlessV2ScalingConfiguration` attribute. The absence of that property provides an extra confirmation that the auto-pause feature is turned off for that cluster. If you later turn auto-pause back on, you can specify any custom interval again at that time. 

### Resuming an auto-paused Aurora Serverless v2 instance
Resuming an instance
+  When you connect to a paused Aurora Serverless v2 instance, it automatically resumes and accepts the connection. 
+  A connection attempt that doesn't include valid credentials still causes the DB instance to resume. 
+  If you connect through the writer endpoint, Aurora resumes the writer DB instance if it's auto-paused. At the same time, Aurora resumes any auto-paused reader instances that have failover priority 0 or 1, meaning their capacity is tied to the capacity of the writer instance. 
+  If you connect through the reader endpoint, Aurora chooses a reader instance randomly. If that reader instance is paused, Aurora resumes it. Aurora also resumes the writer instance first, because the writer instance must always be active if any reader instances are active. When Aurora resumes that writer instance, that also causes any reader instances in failover promotion tiers zero and one to resume. 
+  If you send a request to your cluster through the RDS Data API, Aurora resumes the writer instance if it's paused. Then Aurora processes the Data API request. 
+  When you change the value of a configuration parameter in a DB cluster parameter group, Aurora automatically resumes any paused Aurora Serverless v2 instances in all clusters that use that cluster parameter group. Similarly, when you change a parameter value in a DB parameter group, Aurora automatically resumes any paused Aurora Serverless v2 instances that use that DB parameter group. The same automatic resume behavior applies when you modify a cluster to assign a different cluster parameter group, or when you modify an instance to assign a different DB parameter group. 
+  Performing a backtrack request automatically resumes the Aurora Serverless v2 writer instance if it's paused. Aurora processes the backtrack request after the writer instance resumes. You can backtrack to a time during which an Aurora Serverless v2 instance was paused. 
+  Taking a cluster snapshot or deleting a snapshot doesn't cause any Aurora Serverless v2 instances to resume. 
+  Creating an Aurora clone causes Aurora to resume the writer instance of the cluster that's being cloned. 
+  If a paused instance receives a large number of connection requests before it finishes resuming, some sessions might be unable to connect. We recommend implementing retry logic for connections to Aurora clusters that have some Aurora Serverless v2 instances with auto-pause enabled. For example, you might retry any failed connection three times. 
+  Aurora can perform some types of minor internal maintenance without waking up an instance. However, some types of maintenance that happen during the cluster's maintenance window do require Aurora to resume the instance. When the maintenance is finished, the instance is automatically paused again if there's no more activity after the specified interval. 
**Note**  
 Aurora doesn't automatically resume a paused instance for engine-specific scheduled jobs, such as those in the PostgreSQL `pg_cron` extension or the MySQL event scheduler. To ensure that such jobs run, initiate a connection manually to the instance before the scheduled time. Aurora doesn't queue any jobs where the scheduled time occurs while the DB instance is paused. Such jobs are skipped when the instance resumes later. 
+  If the Aurora cluster undergoes a failover while an Aurora Serverless v2 instance is auto-paused, Aurora might resume an instance and then promote that instance to be the writer. The same might happen if one or more DB instances are removed from the cluster while an instance is paused. In this case, the instance becomes the writer immediately when it's resumed. 
+  Operations that change properties of the cluster also cause any auto-paused Aurora Serverless v2 instances to resume. For example, an auto-paused instance resumes for operations such as the following: 
  +  Changing the scaling range of the cluster. 
  +  Upgrading the engine version of the cluster. 
  +  Describing or downloading log files from a paused instance. You can examine historical log data from paused instances by enabling log uploads to CloudWatch and analyzing the logs through CloudWatch. 

### Turning off auto-pause for Aurora Serverless v2 instances in a cluster
Turning off auto-pause

 Follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus). For the minimum capacity, choose a value of 0.5 or greater. When you turn off the auto-pause feature, the interval for the instance to be idle is reset. If you turn auto-pause on again, you specify a new timeout interval. 

 The following CLI example shows how you might turn off the auto-pause feature for an existing Aurora cluster. The `describe-db-clusters` output shows that the `SecondsUntilAutoPause` attribute is removed when the minimum capacity is set to a nonzero value. 

```
aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}
```

## How the Aurora Serverless v2 auto-pause feature works
How auto-pause works

 You can use the following information to plan your usage of the auto-pause feature. Understanding the circumstances where instances pause, resume, or stay active can help you balance the tradeoffs between availability, responsiveness, and cost savings. 

**Topics**
+ [How auto-pause works](#auto-pause-pausing)
+ [How auto-resume works](#auto-pause-resuming)
+ [CPU billing](#auto-pause-billing)
+ [Conditions that prevent auto-pause](#auto-pause-whynot)
+ [Comparison with cluster stop/start](#auto-pause-stop-start)
+ [Maintenance and upgrades](#auto-pause-maintenance)
+ [Comparison with Aurora Serverless v1](#auto-pause-differences)

### What happens when Aurora Serverless v2 instances pause
How auto-pause works

 When an Aurora Serverless v2 DB instance pauses after a period with no connections: 
+  Aurora begins pausing the instance after the specified interval elapses with no connections to the instance, regardless of how many ACUs the instance has at the time. 
+  The pause mechanism isn't instantaneous. An Aurora Serverless v2 instance that's about to be auto-paused might wait briefly to catch up with all the changes to Aurora storage. 
+  The instance charges for that instance are put on hold. The `ServerlessV2Usage` metric has a value of 0 while the instance is paused. 
+  The status value for the instance doesn't change. The status is still shown as "available". 
+  The instance stops writing to the database log files. It stops sending metrics to CloudWatch, other than registering zero percent for `CPUUtilization` and `ACUUtilization`, and zero for `ServerlessDatabaseCapacity`. 
+  Aurora emits events when an Aurora Serverless v2 DB instance begins pausing, finishes pausing, and if the pause mechanism is interrupted or is unsuccessful. For details about these events, see [DB instance events](USER_Events.Messages.md#USER_Events.Messages.instance). 

### What happens when auto-paused Aurora Serverless v2 instances resume
How auto-resume works

 When an Aurora Serverless v2 DB instance resumes after being automatically paused, the following conditions apply: 
+  Any parameter changes that are in `pending-reboot` changes are applied when the instance resumes. 
+  Aurora emits instance-level events when each Aurora Serverless v2 DB instance begins resuming, finishes resuming, and if the instance can't resume for some reason. For details about these events, see [DB instance events](USER_Events.Messages.md#USER_Events.Messages.instance). 
+  Any requested connections are established after the DB instance finishes resuming. Because the typical time to resume might be approximately 15 seconds, we recommend that you adjust any client timeout settings to be longer than 15 seconds. For example, in your JDBC driver settings you might adjust the values for the `connectTimeout` and `sslResponseTimeout` settings to be longer than 15 seconds. 

**Note**  
 If an Aurora Serverless v2 instance remains paused more than 24 hours, Aurora can put the instance into a deeper sleep that takes longer to resume. In that case, the resume time can be 30 seconds or longer, roughly equivalent to doing a reboot of the instance. If your database has periods of inactivity that last longer than a day, we recommend setting connection timeouts to 30 seconds or more. 

### How instance billing works for auto-paused Aurora Serverless v2 clusters
CPU billing

 While an Aurora Serverless v2 instance is auto-paused, its instance charge is zero. The `ServerlessV2Usage` metric is zero during that period. AWS still charges for Aurora storage and other aspects of the cluster that aren't tied to that specific DB instance. 

### Situations where Aurora Serverless v2 doesn't auto-pause
Conditions that prevent auto-pause
+  If the minimum capacity value for your DB cluster is higher than zero ACUs, the Aurora Serverless v2 instances in the cluster don't automatically pause. If you have existing clusters with Aurora Serverless v2 instances from before the auto-pause feature was available, the lowest minimum capacity setting was 0.5 ACUs. To use the auto-pause feature with such clusters, modify the minimum capacity setting to zero ACUs. 
+  If any user-initiated connections are open to an Aurora Serverless v2 instance, the instance won't pause. The instance also won't pause while activities such as patching and upgrades are in progress. Administrative connections that Aurora uses for health checks aren't counted as activity and don't prevent the instance from pausing. 
+  In an Aurora PostgreSQL cluster has logical replication enabled, or an Aurora MySQL cluster that has binlog replication enabled, the writer instance and any reader instances in failover promotion tiers zero and one don't automatically pause. Aurora performs a constant minimal amount of activity for checking the health of the replication connection. 

   For clusters with replication enabled, you can still have Aurora reader instances in the source cluster that auto-pause. To do so, set their failover priority to a value other than zero or one. That way, they can be paused independently of the writer instance. 
+  If your Aurora cluster has an associated RDS Proxy, the proxy maintains an open connection to each DB instance in the cluster. Thus, any Aurora Serverless v2 instances in such a cluster won'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. That's because a constant level of activity is needed on the writer instance to manage the other clusters in the global database. Because the writer instance remains active, any Aurora Serverless v2 reader instances with failover priority zero or one also don't auto-pause. 
+  Aurora Serverless v2 instances in the secondary clusters of an Aurora Global Database don't automatically pause. If a DB cluster is promoted to a standalone cluster, then the auto-pause feature becomes effective if all the other conditions are met. 
+  In a cluster with an associated zero-ETL integration to Redshift, the writer instance and any reader instances in failover promotion tiers zero and one don't automatically pause. 
+  In addition to activity on the main database port for the instance, if an Aurora PostgreSQL instance has the Babelfish feature enabled, any connections and activity on the T-SQL port prevent the instance from being auto-paused. 

### How auto-pause works with the cluster stop/start feature
Comparison with cluster stop/start

 You can stop and start an Aurora cluster when the auto-pause feature is enabled. It doesn't matter if some instances are paused. When you start the cluster again, any paused Aurora Serverless v2 instances are automatically resumed. 

 While an Aurora cluster is stopped, any paused Aurora Serverless v2 instances don't automatically resume based on attempts to connect. Once the cluster is started again, the usual mechanisms for pausing and resuming Aurora Serverless v2 instances apply. 

### How maintenance and upgrades work for auto-paused Aurora Serverless v2 clusters
Maintenance and upgrades
+  While an Aurora Serverless v2 instance is auto-paused, if you attempt to upgrade the Aurora cluster, Aurora resumes the instance and upgrades it. 
+  Aurora periodically resumes any auto-paused Aurora Serverless v2 instances to perform maintenance such as minor version upgrades and changes to properties such as parameter groups. 
+  After an Aurora Serverless v2 instance wakes up for an administrative operation such as an upgrade or applying maintenance, Aurora waits at least 20 minutes before pausing that instance again. That's to allow any background operations to finish. The twenty-minute period also avoids pausing and resuming the instance multiple times if the instance undergoes multiple administrative operations in succession. 

### Differences in auto-pause behavior between Aurora Serverless v2 and Aurora Serverless v1
Comparison with Aurora Serverless v1
+  The resumption time is improved in Aurora Serverless v2 compared with Aurora Serverless v1. The time to resume is typically approximately 15 seconds if the instance was paused for less than 24 hours. If the instance is paused for longer than 24 hours, the resume time might be longer. 
+  The way that Aurora Serverless v2 applies to multi-AZ clusters means that some DB instances in the cluster might be paused while others are active. The writer instance resumes whenever any reader is running, because the writer is needed to coordinate certain activities within the cluster. Because Aurora Serverless v1 doesn't use reader instances, the entire cluster would always be paused or be active. 
+  When the reader endpoint randomly picks a reader instance to connect to, that reader instance might already be active or might be auto-paused. Thus, the time to access the reader instance might vary and be harder to predict. Multi-AZ clusters that use Aurora Serverless v2 and auto-pause therefore might benefit from setting up custom endpoints for specific read-only use cases, instead of directing all read-only sessions to the reader endpoint. 
+  Aurora Serverless v2 instances undergo maintenance operations with the same frequency as provisioned instances do. Because Aurora automatically resumes instances when such maintenance is needed, you might find that Aurora Serverless v2 instances resume more frequently than Aurora Serverless v1 clusters did. 

## How Aurora Serverless v2 auto-pause works for different types of Aurora clusters
Auto-pause and Aurora cluster configurations

 The considerations for the auto-pause feature depend on how many instances are in your Aurora cluster, the failover promotion tiers of the reader instances, and whether all the instances are Aurora Serverless v2 or a combination of Aurora Serverless v2 and provisioned. 

**Topics**
+ [Aurora cluster layouts](#auto-pause-recommended-layouts)
+ [Auto-pause for the writer instance](#auto-pause-writer)
+ [Auto-pause for multi-AZ clusters and reader instances](#auto-pause-multi-az)
+ [Auto-pause for mixed clusters](#auto-pause-provisioned)

### Recommended Aurora cluster layouts when using auto-pause
Aurora cluster layouts

 When the auto-pause feature is enabled, you can arrange your Aurora cluster for the right balance of high availability, fast response, and scalability to suit your use case. You do so by choosing the combination of Aurora Serverless v2 instances, provisioned instances, and failover promotion tiers for the DB instances in your cluster. 

 The following types of configurations demonstrate different tradeoffs between high availability and cost optimization for your cluster: 
+  For a development and test system, you can set up a single-AZ DB cluster with an Aurora Serverless v2 DB instance. The single instance serves all read and write requests. When the cluster isn't used for significant intervals of time, the DB instance pauses. At that point, the DB compute costs for your cluster are also paused. 
+  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. Set the reader instance to failover priority zero or one, so that the writer and reader instance both pause and resume at the same time. Now you get the benefit of fast failover while the cluster is active. When the cluster remains idle for longer than the auto-pause threshold, the DB instance charges for both of the instances are paused. When the cluster resumes processing, the first database session takes a brief time to connect. 
+  Suppose your cluster is constantly active with some minimal amount of activity, and requires fast response for any connection. In that case, you can create a cluster with more than one Aurora Serverless v2 reader instance, and decouple the capacities of some reader instances from the writer. Specify failover priority zero or one for the writer instance and one reader instance. Specify a priority greater than one for the other reader instances. That way, the reader instances in the higher priority tiers can auto-pause, even while the writer and one of the readers remain active. 

   In this case, you can employ some other techniques to ensure that the cluster stays continuously available while still scaling down to a low capacity during idle periods: 
  +  You can use provisioned instances for the writer and the priority 0 or 1 reader. That way, two DB instances never auto-pause and are always available to serve database traffic and to perform failovers. 
  +  You can set up a custom endpoint that includes the Aurora Serverless v2 instances in the higher priority tiers, but not the writer or the promotion tier 0 or 1 readers. That way, you can direct read-only sessions that aren't sensitive to latency to the readers that might be auto-paused. You can avoid using the reader endpoint for such requests, because Aurora might direct reader endpoint connections to the always-awake reader instance, or to one of the auto-paused instances. Using the custom endpoint lets you direct connections to different groups of instances based on your preference for fast response or extra scaling capacity. 

### How Aurora Serverless v2 auto-pause works for the writer instance in a DB cluster
Auto-pause for the writer instance

 When an Aurora DB cluster contains only a single DB instance, the mechanism for auto-pausing and resuming the DB instance is straightforward. It depends only on activity on the writer instance. You might have such a configuration for clusters used for development and testing, or for running applications where high availability isn't crucial. Note that in a single-instance cluster, Aurora directs connections through the reader endpoint to the writer DB instance. Thus, for a single-instance DB cluster, attempting to connect to the reader endpoint causes the auto-paused writer DB instance to resume. 

 The following additional factors apply to Aurora clusters with multiple DB instances: 
+  Within an Aurora DB cluster, the writer DB instance is typically accessed frequently. Therefore, you might find that the writer DB instance remains active even while one or more of the reader DB instances automatically pauses. 
+  Certain activities on the reader DB instances require that writer DB instance to be available. Therefore, the writer DB instances can't be paused until all the reader instances are also paused. Resuming any reader instance automatically resumes the writer instance, even if your application isn't accessing the writer instance directly. 
+  Aurora Serverless v2 reader instances in failover promotion tiers zero and one scale to keep their capacity in synch with the writer instance. Thus, when an Aurora Serverless v2 writer instance resumes, so do any Aurora Serverless v2 reader instances that are in promotion tiers zero or one. 

### How Aurora Serverless v2 auto-pause works for multi-AZ clusters
Auto-pause for multi-AZ clusters and reader instances

 Within an Aurora DB cluster containing both a writer and one or more reader DB instances, some Aurora Serverless v2 DB instances might be paused while other DB instances are active. The writer instance and any reader instances with failover priority 0 and 1 always pause and resume all at the same time. Reader instances with priority other than 0 or 1 can pause and resume independently of the other instances. 

 When you use this feature for clusters with multiple reader instances, you can manage costs without sacrificing high availability. The writer instance and another one or two reader instances can remain active at all times, while additional reader instances can pause when they're not needed to handle high-volume read traffic. 

 Whether a reader instance can automatically pause depends on whether its capacity can scale independently, or whether the capacity is tied to that of the writer DB instance. That scaling property depends on the failover priority of the reader DB instance. When the priority of the reader is zero or one, the capacity of the reader tracks the capacity of the writer DB instance. Therefore, to allow reader DB instances to automatically pause in the broadest range of situations, set their priority to a value higher than one. 

 The time to resume a reader instance might be slightly longer than to resume a writer instance. For the fastest response if instances might be paused, connect to the cluster endpoint. 

### How Aurora Serverless v2 auto-pause works for clusters with provisioned instances
Auto-pause for mixed clusters

 Any provisioned DB instances in your Aurora DB cluster won't automatically pause. Only Aurora Serverless v2 DB instances, with the `db.serverless` instance class, can use the auto-pause feature. 

 When your Aurora cluster contains any provisioned DB instances, any Aurora Serverless v2 writer instance doesn't automatically pause. That's because of the requirement that the writer instance remains available while any reader instances are active. The fact that the Aurora Serverless v2 writer remains active also means that any Aurora Serverless v2 reader instances with failover priority 0 and 1 won't auto-pause in a hybrid cluster containing any provisioned instances. 

## Monitoring Aurora clusters that use auto-pause
Monitoring auto-pause

 To monitor Aurora, you should already be familiar with the monitoring procedures in [Monitoring Amazon Aurora metrics with Amazon CloudWatch](monitoring-cloudwatch.md) and the CloudWatch metrics listed in [Metrics reference for Amazon Aurora](metrics-reference.md). Be aware that there are some special considerations when you monitor Aurora clusters that use the auto-pause feature: 
+  There can be periods of time when Aurora Serverless v2 instances aren't recording log data and most metrics because the instances are paused. The only metrics sent to CloudWatch while an instance is paused are zero percent for `CPUUtilization` and `ACUUtilization`, and zero for `ServerlessDatabaseCapacity`. 
+  You can check whether Aurora Serverless v2 instances are pausing more or less frequently than you expect. To do so, check how often the `ServerlessDatabaseCapacity` metric changes from a nonzero value to zero, and how long it stays zero. If the instances don't remain paused as long as you expect, you don't save as much as you could on costs. If the instances pause and resume more frequently than you intend, your cluster might have unnecessary latency when responding to connection requests. For information about the factors that affect whether and how often Aurora Serverless v2 instances can pause, see [Prerequisites and Limitations for the Aurora Serverless v2 auto-pause feature](#auto-pause-prereqs), [Situations where Aurora Serverless v2 doesn't auto-pause](#auto-pause-whynot), and [Troubleshooting for Aurora Serverless v2 auto-pause](#auto-pause-troubleshooting). 
+  You can also examine a log file that records automatic pause and resume operations for an Aurora Serverless v2 instance. If an instance didn't pause after the timeout interval expired, this log file also includes the reason why auto-pause didn't happen. For more information, see [Monitoring Aurora Serverless v2 pause and resume activity](aurora-serverless-v2-administration.md#autopause-logging-instance-log). 

**Topics**
+ [Checking for paused instances](#auto-pause-status)
+ [Auto-pause and auto-resume events](#auto-pause-events)
+ [Performance Insights and Enhanced Monitoring](#auto-pause-pi-em)
+ [Aurora metrics](#auto-pause-metrics)

### Checking if an Aurora Serverless v2 instance is paused
Checking for paused instances

 To determine whether an Aurora Serverless v2 instance is in the paused state, you can observe the `ACUUtilization` metric for the instance. That metric has a value of zero while the instance is paused. 

 While an Aurora Serverless v2 instance is paused, its status value is still listed as **Available**. The same applies while a paused Aurora Serverless v2 instance is in the process of resuming. That's because you can successfully connect to such an instance, even if the connection experiences a slight delay. 

 Any metrics related to the availability of Aurora instances consider the period while the instance is paused as time that the instance was available. 

### Events for auto-pause and auto-resume operations
Auto-pause and auto-resume events

 Aurora emits events for Aurora Serverless v2 instances when auto-pause and auto-resume operations start, finish, or are cancelled. The events related to the auto-pause feature are `RDS-EVENT-0370` through `RDS-EVENT-0374`. For details about these events, see [DB instance events](USER_Events.Messages.md#USER_Events.Messages.instance). 

### How auto-pause works with Performance Insights and Enhanced Monitoring
Performance Insights and Enhanced Monitoring

 While an Aurora Serverless v2 instance is paused, Aurora doesn't collect monitoring information for that instance through either Performance Insights or Enhanced Monitoring. When the instance is resumed, there might be a brief delay before Aurora resumes collecting such monitoring information. 

### How the Aurora Serverless v2 auto-pause feature interacts with Aurora metrics
Aurora metrics

 While an Aurora Serverless v2 instance is paused, it doesn't emit most CloudWatch metrics or write any information to its database logs. The only metrics sent to CloudWatch while an instance is paused are zero percent for `CPUUtilization` and `ACUUtilization`, and zero for `ServerlessDatabaseCapacity`. 

 When CloudWatch is computing statistics related to instance or cluster availability and uptime, Aurora Serverless v2 instances are considered to be available during the time that they're paused. 

 When you initiate an AWS CLI or RDS API action to describe or download the logs for a paused Aurora Serverless v2 instance, the instance resumes automatically to make the log information available. 

#### Example of CloudWatch metrics


 The following AWS CLI examples show how you might observe the capacity of an instance changing over time. During the time period, the instance auto-pauses and then resumes. While it's paused, the `ServerlessDatabaseCapacity` metric reports a value of zero. To determine whether the instance was paused at any point during the time period, we check if the minimum capacity during that time period was zero. 

 The following Linux example represents an Aurora Serverless v2 instance that has been automatically paused for some time. We sample the `ServerlessDatabaseCapacity` each minute, over a period of three minutes. The minimum ACU value of 0.0 confirms that the instance was paused at some point during each minute. 

```
$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
```

 Next, we attempt to make a connection to the paused Aurora Serverless v2 instance. In this example, we intentionally use an incorrect password so that the connection attempt doesn't succeed. Despite the failure, the connection attempt causes Aurora to resume the paused instance. 

```
$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)
```

 The following Linux example demonstrates that the paused instance resumed, remained idle for approximately five minutes, and then went back into its paused state. The instance resumed at a capacity of 2.0 ACUs. Then it scaled up slightly, for example to perform some internal cleanup. Because it didn't receive any user connection attempts within the five-minute timeout period, it went from 4.0 ACUs directly into the paused state. 

```
$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None
```

 If the report was intended to show how quickly the instance scaled up to handle the workload, we might specify `Maximum` for the statistic instead of `Minimum`. For capacity planning and cost estimation, we might specify a longer time period and use the `Average` statistic. That way, we could determine typical capacity values during periods of high activity, low activity, and paused state. To examine behavior during the precise times around pausing and resuming, we might specify a period of one second and examine a shorter time interval. The timestamp values in the output, such as `2024-08-02T22:13:00+00:00`, demonstrate the format to specify precise parameters for the `--start-time` and `--end-time` options. 

## Troubleshooting for Aurora Serverless v2 auto-pause
Troubleshooting for auto-pause

 If you find that Aurora Serverless v2 instances aren't pausing as often as you expect, check for the following possible causes: 
+  Confirm that the Aurora version you're running does support a minimum capacity of zero ACUs. For the capacity ranges of different Aurora versions, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). 
+  Confirm that the minimum capacity value for the cluster is set to zero ACUs. 
+  Confirm that the instance in question is actually using the Aurora Serverless v2 instance class `db.serverless`, not one of the provisioned instance classes. 
+  Confirm that the cluster isn't using any of the incompatible features or settings from [Prerequisites and Limitations for the Aurora Serverless v2 auto-pause feature](#auto-pause-prereqs). 
+  Examine the log file showing when Aurora Serverless v2 instances were paused, resumed, or Aurora wasn't able to pause or resume an instance for some reason. For more information, see [Monitoring Aurora Serverless v2 pause and resume activity](aurora-serverless-v2-administration.md#autopause-logging-instance-log). 
+  Check if any clients or applications are keeping connections open for long periods of time. Conversely, check if any applications that use RDS Data API or Lambda functions are sending frequent requests so that the instance is never idle long enough to pause. You can examine the CloudWatch metrics such as `ConnectionAttempts` and `DatabaseConnections`. For more information, see [Instance-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). 
+  If a reader instance rarely if ever pauses, check its failover priority. If the reader is used for read scaling and not as a standby in case of failover, set it to a priority in the range 2-15. 
+  If the writer instance rarely if ever pauses, check your usage of the reader instances. The writer can only pause if the entire cluster is idle. That's because a connection to any reader instance causes the writer to resume. 
+  If your application receives timeouts during connection requests while Aurora Serverless v2 instances are resuming, consider lengthening the timeout interval used by your application code or the underlying database framework. Longer connection timeouts reduce the possibility of failed connections while Aurora Serverless v2 instances are resuming. However, the longer timeouts can also make your application slower to detect availability issues in your cluster. 

   Conversely, consider lengthening the auto-pause interval so that applications don't encounter paused instances as often. 

   If there isn't a logical balance between the auto-pause behavior and cluster responsiveness for your application, that cluster might not be a good candidate for using the auto-pause feature. 
+  If you estimate how long your Aurora Serverless v2 instances will be paused, be aware that there are factors that make it impractical to make precise predictions. 
  +  Instances might resume periodically to perform maintenance, minor version upgrades, or apply changes to parameter groups. 
  +  For multi-AZ clusters, there are situations where resuming one instance causes other instances to resume also. Resuming any reader always causes the writer to resume. Resuming the writer always causes any readers with failover priority 0 and 1 to resume. 

   We recommend measuring the actual paused time over a period of several days, with a realistic workload. Then use those measurements to set a baseline for what proportion of time you can expect an instance to be paused. 
+  You might find that internal operations such as MySQL purge, MySQL event scheduler, PostgreSQL autovacuum, or PostgreSQL jobs scheduled through the `pg_cron` extension aren't running or aren't completing. The instance doesn't automatically resume to perform such operations that don't involve a user connection to the database. If such internal operations are underway when the auto-pause timeout expires, maintenance tasks such as MySQL purge and PostgreSQL autovacuum are canceled. Scheduled jobs from the MySQL event scheduler or the PostgreSQL `pg_cron` extension are also canceled if they're in progress when Aurora initiates the pause operation. 

   If you need to ensure that the instance is periodically awake to perform scheduled operations, you can initiate a connection to resume the instance before the start time of the job. You can also increase the auto-pause timeout interval so that operations such as autovacuum can run for longer after user activity is finished. You can also use mechanisms such as Lambda functions to perform database operations on a schedule, in a way that automatically resumes the instance if necessary. 

## Application design considerations for the Aurora Serverless v2 auto-pause feature
Application design for auto-pause

 When an Aurora Serverless v2 DB instance resumes after being automatically paused, it begins with a relatively small capacity and scales up from there. This starting capacity applies even if the DB instance had some higher capacity immediately before it was automatically paused. 

 Use this feature with applications that can tolerate an interval of approximately 15 seconds while establishing a connection. That accounts for the typical case where an Aurora Serverless v2 instance resumes due to one or a small number of incoming connections. If the instance is paused for longer than 24 hours, the time to resume might be longer. 

 If your application was already using Aurora Serverless v1 and its automatic pause feature, you might already have such timeout intervals in place for connection attempts. If you are already using Aurora Serverless v2 in combination with the Aurora stop/start cluster feature, the resumption time for auto-paused Aurora Serverless v2 instances is typically much shorter than the time to start a cluster that's stopped. 

 When coding connection logic in your application, retry the connection if the first attempt return an error that has a transient cause. (If the error is due to authentication failure, correct the credentials before retrying.) An error that happens immediately after resuming might be a timeout, or some error related to database limits. Retrying can handle issues in the rarer case where an Aurora Serverless v2 instance is resumed due to a high number of simultaneous connection requests. In that case, some connections might take longer than usual to be processed, or might exceed the limit of simultaneous connections on the first attempt. 

 During application development and debugging, don't leave client sessions or programming tools with connections open to the database. Aurora won't pause an instance if there are any user-initiated connections open, regardless of whether the connections aren't running any SQL statements or transactions. When one Aurora Serverless v2 instance in an Aurora cluster can't pause, other instances in the cluster might also be prevented from pausing. For more information, see [Situations where Aurora Serverless v2 doesn't auto-pause](#auto-pause-whynot). 

 Aurora emits events when an Aurora Serverless v2 DB instance begins resuming, finishes resuming, and if the instance can't resume for some reason. For details about these events, see [DB instance events](USER_Events.Messages.md#USER_Events.Messages.instance). 

# Migrating to Aurora Serverless v2


To convert an existing DB cluster to use Aurora Serverless v2, you can do the following:
+ Upgrade from a provisioned Aurora DB cluster.
+ Upgrade from an Aurora Serverless v1 cluster.
+ Migrate from an on-premises database to an Aurora Serverless v2 cluster.

When your upgraded cluster is running the appropriate engine version as listed in [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md), you can begin adding Aurora Serverless v2 DB instances to it. The first DB instance that you add to the upgraded cluster must be a provisioned DB instance. Then you can switch over the processing for the write workload, the read workload, or both to the Aurora Serverless v2 DB instances.

**Contents**
+ [

## Upgrading or switching existing clusters to use Aurora Serverless v2
](#aurora-serverless-v2.getting-started-general-procedure)
  + [

### Upgrade paths for MySQL-compatible clusters to use Aurora Serverless v2
](#serverless-v2-upgrade-paths-ams)
  + [

### Upgrade paths for PostgreSQL-compatible clusters to use Aurora Serverless v2
](#serverless-v2-upgrade-paths-apg)
+ [

## Switching from a provisioned cluster to Aurora Serverless v2
](#aurora-serverless-v2.switch-from-provisioned)
+ [

## Comparison of Aurora Serverless v2 and Aurora Serverless v1
](#aurora-serverless.comparison)
  + [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 requirements
](#aurora-serverless.comparison-requirements)
  + [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 scaling and availability
](#aurora-serverless.comparison-scaling)
  + [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 feature support
](#aurora-serverless.comparison-features)
  + [

### Adapting Aurora Serverless v1 use cases to Aurora Serverless v2
](#aurora-serverless.comparison-approaches)
+ [

## Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2
](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure)
  + [

### Aurora MySQL–compatible DB clusters
](#sv1-to-sv2-ams)
  + [

### Aurora PostgreSQL–compatible DB clusters
](#sv1-to-sv2-apg)
+ [

## Migrating from an on-premises database to Aurora Serverless v2
](#aurora-serverless-v2.migrate-from-on-prem)

**Note**  
These topics describe how to convert an existing DB cluster. For information on creating a new Aurora Serverless v2 DB cluster, see [Creating a DB cluster that uses Aurora Serverless v2](aurora-serverless-v2.create.md).

## Upgrading or switching existing clusters to use Aurora Serverless v2
Using Aurora Serverless v2 with an existing cluster

If your provisioned cluster has an engine version that supports Aurora Serverless v2, switching to Aurora Serverless v2 doesn't require an upgrade. In that case, you can add Aurora Serverless v2 DB instances to your original cluster. You can switch the cluster to use all Aurora Serverless v2 DB instances. You can also use a combination of Aurora Serverless v2 and provisioned DB instances in the same DB cluster. For the Aurora engine versions that support Aurora Serverless v2, see [Supported Regions and Aurora DB engines for Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md). 

If you're running a lower engine version that doesn't support Aurora Serverless v2, you take these general steps:

1. Upgrade the cluster. 

1. Create a provisioned writer DB instance for the upgraded cluster.

1. Modify the cluster to use Aurora Serverless v2 DB instances.

**Important**  
When you perform a major version upgrade to an Aurora Serverless v2-compatible version by using snapshot restore or cloning, the first DB instance that you add to the new cluster must be a provisioned DB instance. This addition starts the final stage of the upgrade process.  
Until that final stage happens, the cluster doesn't have the infrastructure that's required for Aurora Serverless v2 support. Thus, these upgraded clusters always start with a provisioned writer DB instance. Then you can convert or fail over the provisioned DB instance to an Aurora Serverless v2 one.

Upgrading from Aurora Serverless v1 to Aurora Serverless v2 involves creating a provisioned cluster as an intermediate step. Then you perform the same upgrade steps as when you start with a provisioned cluster.

### Upgrade paths for MySQL-compatible clusters to use Aurora Serverless v2


If your original cluster is running Aurora MySQL, choose the appropriate procedure depending on the engine version and engine mode of your cluster.


| If your original Aurora MySQL cluster is this | Do this to switch to Aurora Serverless v2 | 
| --- | --- | 
| Provisioned cluster running Aurora MySQL version 3, compatible with MySQL 8.0 |  This is the final stage for all conversions from existing Aurora MySQL clusters. If necessary, perform a minor version upgrade to version 3.02.0 or higher. Use a provisioned DB instance for the writer DB instance. Add one Aurora Serverless v2 reader DB instance. Perform a failover to make that the writer DB instance. (Optional) Convert other provisioned DB instances in the cluster to Aurora Serverless v2. Or add new Aurora Serverless v2 DB instances and remove the provisioned DB instances. For the full procedure and examples, see [Switching from a provisioned cluster to Aurora Serverless v2](#aurora-serverless-v2.switch-from-provisioned).  | 
| Provisioned cluster running Aurora MySQL version 2, compatible with MySQL 5.7 | Perform a major version upgrade to Aurora MySQL version 3.02.0 or higher. Then follow the procedure for Aurora MySQL version 3 to switch the cluster to use Aurora Serverless v2 DB instances. | 
| Aurora Serverless v1 cluster running Aurora MySQL version 2, compatible with MySQL 5.7 |  To help plan your conversion from Aurora Serverless v1, consult [Comparison of Aurora Serverless v2 and Aurora Serverless v1](#aurora-serverless.comparison) first. Then follow the procedure in [Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure).  | 

### Upgrade paths for PostgreSQL-compatible clusters to use Aurora Serverless v2


If your original cluster is running Aurora PostgreSQL, choose the appropriate procedure depending on the engine version and engine mode of your cluster.


| If your original Aurora PostgreSQL cluster is this | Do this to switch to Aurora Serverless v2 | 
| --- | --- | 
| Provisioned cluster running Aurora PostgreSQL version 13 |  This is the final stage for all conversions from existing Aurora PostgreSQL clusters. If necessary, perform a minor version upgrade to version 13.6 or higher. Add one provisioned DB instance for the writer DB instance. Add one Aurora Serverless v2 reader DB instance. Perform a failover to make that Aurora Serverless v2 instance the writer DB instance. (Optional) Convert other provisioned DB instances in the cluster to Aurora Serverless v2. Or add new Aurora Serverless v2 DB instances and remove the provisioned DB instances. For the full procedure and examples, see [Switching from a provisioned cluster to Aurora Serverless v2](#aurora-serverless-v2.switch-from-provisioned).  | 
| Provisioned cluster running Aurora PostgreSQL version 11 or 12 | Perform a major version upgrade to Aurora PostgreSQL version 13.6 or higher. Then follow the procedure for Aurora PostgreSQL version 13 to switch the cluster to use Aurora Serverless v2 DB instances. | 
| Aurora Serverless v1 cluster running Aurora PostgreSQL version 11 or 13 |  To help plan your conversion from Aurora Serverless v1, consult [Comparison of Aurora Serverless v2 and Aurora Serverless v1](#aurora-serverless.comparison) first. Then follow the procedure in [Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure).  | 

## Switching from a provisioned cluster to Aurora Serverless v2
Switching from a provisioned cluster

 To switch a provisioned cluster to use Aurora Serverless v2, follow these steps: 

1. Check if the provisioned cluster needs to be upgraded to be used with Aurora Serverless v2 DB instances. For the Aurora versions that are compatible with Aurora Serverless v2, see [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md).

   If the provisioned cluster is running an engine version that isn't available for Aurora Serverless v2, upgrade the engine version of the cluster:
   + If you have a MySQL 5.7–compatible provisioned cluster, follow the upgrade instructions for Aurora MySQL version 3. Use the procedures in [How to perform an in-place upgrade](AuroraMySQL.Upgrading.Procedure.md).
   + If you have a PostgreSQL-compatible provisioned cluster running PostgreSQL version 11 or 12, follow the upgrade instructions for Aurora PostgreSQL version 13. Use the procedures in [Performing a major version upgrade](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).

1. Configure any other cluster properties to match the Aurora Serverless v2 requirements from [Requirements and limitations for Aurora Serverless v2](aurora-serverless-v2.requirements.md).

1. Configure the scaling configuration for the cluster. Follow the procedure in [Setting the Aurora Serverless v2 capacity range for a cluster](aurora-serverless-v2-administration.md#aurora-serverless-v2-setting-acus).

1. Add one or more Aurora Serverless v2 DB instances to the cluster. Follow the general procedure in [Adding Aurora Replicas to a DB cluster](aurora-replicas-adding.md). For each new DB instance, specify the special DB instance class name **Serverless** in the AWS Management Console, or `db.serverless` in the AWS CLI or Amazon RDS API.

   In some cases, you might already have one or more provisioned reader DB instances in the cluster. If so, you can convert one of the readers to an Aurora Serverless v2 DB instance instead of creating a new DB instance. To do so, follow the procedure in [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).

1. Perform a failover operation to make one of the Aurora Serverless v2 DB instances the writer DB instance for the cluster. 

1. (Optional) Convert any provisioned DB instances to Aurora Serverless v2, or remove them from the cluster. Follow the general procedure in [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned) or [Deleting a DB instance from an Aurora DB cluster](USER_DeleteCluster.md#USER_DeleteInstance).
**Tip**  
Removing the provisioned DB instances isn't mandatory. You can set up a cluster containing both Aurora Serverless v2 and provisioned DB instances. However, until you are familiar with the performance and scaling characteristics of Aurora Serverless v2 DB instances, we recommend that you configure your clusters with DB instances all of the same type.

The following AWS CLI example shows the switchover process using a provisioned cluster that's running Aurora MySQL version 3.02.0. The cluster is named `mysql-80`. The cluster starts with two provisioned DB instances named `provisioned-instance-1` and `provisioned-instance-2`, a writer and a reader. They both use the `db.r6g.large` DB instance class.

```
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large
```

 We create a table with some data. That way, we can confirm that the data and operation of the cluster are the same before and after the switchover. 

```
mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)
```

First, we add a capacity range to the cluster. Otherwise, we get an error when adding any Aurora Serverless v2 DB instances to the cluster. If we use the AWS Management Console for this procedure, that step is automatic when we add the first Aurora Serverless v2 DB instance.

```
$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}
```

We create two Aurora Serverless v2 readers to take the place of the original DB instances. We do so by specifying the `db.serverless` DB instance class for the new DB instances.

```
$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2
```

We perform a failover to make one of the Aurora Serverless v2 DB instances the new writer for the cluster.

```
$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}
```

It takes a few seconds for that change to take effect. At that point, we have an Aurora Serverless v2 writer and an Aurora Serverless v2 reader. Thus, we don't need either of the original provisioned DB instances.

```
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False
```

The last step in the switchover procedure is to delete both of the provisioned DB instances.

```
$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}
```

As a final check, we confirm that the original table is accessible and writeable from the Aurora Serverless v2 writer DB instance.

```
mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)
```

 We also connect to the Aurora Serverless v2 reader DB instance and confirm that the newly written data is available there too. 

```
mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)
```

## Comparison of Aurora Serverless v2 and Aurora Serverless v1


If you are already using Aurora Serverless v1, you can learn the major differences between Aurora Serverless v1 and Aurora Serverless v2. The architectural differences, such as support for reader DB instances, open up new types of use cases.

You can use the following tables to help understand the most important differences between Aurora Serverless v2 and Aurora Serverless v1.

**Topics**
+ [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 requirements
](#aurora-serverless.comparison-requirements)
+ [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 scaling and availability
](#aurora-serverless.comparison-scaling)
+ [

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 feature support
](#aurora-serverless.comparison-features)
+ [

### Adapting Aurora Serverless v1 use cases to Aurora Serverless v2
](#aurora-serverless.comparison-approaches)

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 requirements


The following table summarizes the different requirements to run your database using Aurora Serverless v2 or Aurora Serverless v1. Aurora Serverless v2 offers higher versions of the Aurora MySQL and Aurora PostgreSQL DB engines than Aurora Serverless v1 does.


| Feature | Aurora Serverless v2 requirement | Aurora Serverless v1 requirement | 
| --- | --- | --- | 
|  DB engines  |  Aurora MySQL, Aurora PostgreSQL  |  Aurora MySQL, Aurora PostgreSQL  | 
|  Supported Aurora MySQL versions  | See [Aurora Serverless v2 with Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy). | See [Aurora Serverless v1 with Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy). | 
|  Supported Aurora PostgreSQL versions  | See [Aurora Serverless v2 with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg). | See [Aurora Serverless v1 with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.apg). | 
| Upgrading a DB cluster |  Similarly to provisioned DB clusters, you can perform upgrades manually without waiting for Aurora to upgrade the DB cluster for you. For more information, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).  To perform a major version upgrade from 13.x to 14.x or 15.x for an Aurora PostgreSQL–compatible DB cluster, the maximum capacity of your cluster must be at least 2 ACUs.   |  Minor version upgrades are applied automatically as they become available. For more information, see [Aurora Serverless v1 and Aurora database engine versions](aurora-serverless.relnotes.md). You can perform major version upgrades manually. For more information, see [Modifying an Aurora Serverless v1 DB cluster](aurora-serverless.modifying.md).  | 
| Converting from provisioned DB cluster |  You can use the following methods: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html)  |  Restore snapshot of provisioned cluster to create new Aurora Serverless v1 cluster.  | 
| Converting from Aurora Serverless v1 cluster | Follow the procedure in [Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2](#aurora-serverless-v2.upgrade-from-serverless-v1-procedure). | Not applicable | 
| Available DB instance classes | The special DB instance class db.serverless. In the AWS Management Console, it's labeled as Serverless. | Not applicable. Aurora Serverless v1 uses the serverless engine mode. | 
|  Port  |  Any port that's compatible with MySQL or PostgreSQL  |  Default MySQL or PostgreSQL port only  | 
|  Public IP address allowed?  |  Yes  |  No  | 
|  Virtual private cloud (VPC) required?  | Yes |  Yes. Each Aurora Serverless v1 cluster consumes 2 interface and Gateway Load Balancer endpoints allocated to your VPC.  | 

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 scaling and availability


 The following table summarizes differences between Aurora Serverless v2 and Aurora Serverless v1 for scalability and availability. 

 Aurora Serverless v2 scaling is more responsive, more granular, and less disruptive than the scaling in Aurora Serverless v1. Aurora Serverless v2 can scale both by changing the size of the DB instance and by adding more DB instances to the DB cluster. It can also scale by adding clusters in other AWS Regions to an Aurora global database. In contrast, Aurora Serverless v1 only scales by increasing or decreasing the capacity of the writer. All the compute for an Aurora Serverless v1 cluster runs in a single Availability Zone and a single AWS Region. 


| Scaling and high availability feature |  Aurora Serverless v2 behavior |  Aurora Serverless v1 behavior | 
| --- | --- | --- | 
|  Minimum Aurora capacity units (ACUs) (Aurora MySQL)  |  0.5 when the cluster is running, 0 when the cluster is paused.  |  1 when the cluster is running, 0 when the cluster is paused.  | 
|  Minimum ACUs (Aurora PostgreSQL)  |  0.5 when the cluster is running, 0 when the cluster is paused.  |  2 when the cluster is running, 0 when the cluster is paused.  | 
| Maximum ACUs (Aurora MySQL) | 256 | 256 | 
| Maximum ACUs (Aurora PostgreSQL) | 256 | 384 | 
|  Stopping a cluster  |  You can manually stop and start the cluster by using [the same cluster stop and start feature](aurora-cluster-stop-start.md) as provisioned clusters.  |  The cluster pauses automatically after a timeout. It takes some time to become available when activity resumes.  | 
|  Scaling for DB instances  | Scale up and down with minimum increment of 0.5 ACUs. | Scale up and down by doubling or halving the ACUs. | 
|  Number of DB instances  |  Same as a provisioned cluster: 1 writer DB instance, up to 15 reader DB instances.  |  1 DB instance handling both reads and writes.  | 
|  Scaling can happen while SQL statements are running?  |  Yes. Aurora Serverless v2 doesn't require waiting for a quiet point.  |  No. For example, scaling waits for completion of long-running transactions, temporary tables, and table locks.  | 
|  Reader DB instances scale along with writer  | Optional | Not applicable | 
|  Maximum storage  | 128 TiB | 128 TiB | 
|  Buffer cache preserved when scaling  |  Yes. Buffer cache is resized dynamically.  |  No. Buffer cache is rewarmed after scaling.  | 
|  Failover  |  Yes, same as for provisioned clusters.  |  Best effort only, subject to capacity availability. Slower than in Aurora Serverless v2.  | 
|  Multi-AZ capability  |  Yes, same as for provisioned. A Multi-AZ cluster requires a reader DB instance in a second Availability Zone (AZ). For a Multi-AZ cluster, Aurora performs Multi-AZ failover in case of an AZ failure.  |  Aurora Serverless v1 clusters run all their compute in a single AZ. Recovery in case of AZ failure is best effort only and subject to capacity availability.  | 
|  Aurora global databases  |  Yes  |  No  | 
|  Scaling based on memory pressure  |  Yes  |  No  | 
|  Scaling based on CPU load  |  Yes  |  Yes  | 
|  Scaling based on network traffic  |  Yes, based on memory and CPU overhead of network traffic. The max\$1connections parameter remains constant to avoid dropping connections when scaling down.  |  Yes, based on number of connections.  | 
|  Timeout action for scaling events  |  No  |  Yes  | 
|  Adding new DB instances to cluster through AWS Auto Scaling  |  Not applicable. You can create Aurora Serverless v2 reader DB instances in promotion tiers 2–15 and leave them scaled down to low capacity.  |  No. Reader DB instances aren't available.  | 

### Comparison of Aurora Serverless v2 and Aurora Serverless v1 feature support


 The following table summarizes these: 
+  Features that are available in Aurora Serverless v2 but not Aurora Serverless v1 
+  Features that work differently between Aurora Serverless v1 and Aurora Serverless v2 
+  Features that aren't currently available in Aurora Serverless v2 

 Aurora Serverless v2 includes many features from provisioned clusters that aren't available for Aurora Serverless v1. 


| Feature | Aurora Serverless v2 support | Aurora Serverless v1 support | 
| --- | --- | --- | 
| Cluster topology | Aurora Serverless v2 is a property of individual DB instances. A cluster can contain multiple Aurora Serverless v2 DB instances, or a combination of Aurora Serverless v2 and provisioned DB instances. | Aurora Serverless v1 clusters don't use the notion of DB instances. You can't change the Aurora Serverless v1 property after you create the cluster. | 
| Configuration parameters | Almost all the same parameters can be modified as in provisioned clusters. For details, see [Working with parameter groups for Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups). | Only a subset of parameters can be modified. | 
| Parameter groups | Cluster parameter group and DB parameter groups. Parameters with provisioned value in SupportedEngineModes attribute are available. That's many more parameters than in Aurora Serverless v1. | Cluster parameter group only. Parameters with serverless value in SupportedEngineModes attribute are available. | 
| Encryption for cluster volume | Optional | Required. The limitations in [Limitations of Amazon Aurora encrypted DB clusters](Overview.Encryption.md#Overview.Encryption.Limitations) apply to all Aurora Serverless v1 clusters. | 
| Cross-Region snapshots | Yes | Snapshot must be encrypted with your own AWS Key Management Service (AWS KMS) key. | 
| Automated backups retained after DB cluster deletion | Yes | No | 
| TLS/SSL | Yes. The support is the same as for provisioned clusters. For usage information, see [Using TLS/SSL with Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2.tls). | Yes. There are some differences from TLS support for provisioned clusters. For usage information, see [Using TLS/SSL with Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls). | 
| Cloning | Only from and to DB engine versions that are compatible with Aurora Serverless v2. You can't use cloning to upgrade from Aurora Serverless v1 or from an earlier version of a provisioned cluster. | Only from and to DB engine versions that are compatible with Aurora Serverless v1. | 
| Integration with Amazon S3 | Yes | Yes | 
| Integration with AWS Secrets Manager | Yes | No | 
| Exporting DB cluster snapshots to S3 | Yes | No | 
| Associating an IAM role | Yes | No | 
| Uploading logs to Amazon CloudWatch | Optional. You choose which logs to turn on and which logs to upload to CloudWatch. | All logs that are turned on are uploaded to CloudWatch automatically. | 
| Data API available | Yes | Yes | 
| Query editor available | Yes | Yes | 
| Performance Insights | Yes | No | 
| Amazon RDS Proxy available | Yes | No | 
| Babelfish for Aurora PostgreSQL available | Yes. Supported for Aurora PostgreSQL versions that are compatible with both Babelfish and Aurora Serverless v2. | No | 

### Adapting Aurora Serverless v1 use cases to Aurora Serverless v2


Depending on your use case for Aurora Serverless v1, you might adapt that approach to take advantage of Aurora Serverless v2 features as follows.

Suppose that you have an Aurora Serverless v1 cluster that is lightly loaded and your priority is maintaining continuous availability while minimizing costs. With Aurora Serverless v2, you can configure a smaller minimum ACU setting of 0.5, compared with a minimum of 1 ACU for Aurora Serverless v1. You can increase availability by creating a Multi-AZ configuration, with the reader DB instance also having a minimum of 0.5 ACUs.

Suppose that you have an Aurora Serverless v1 cluster that you use in a development and test scenario. In this case, cost is also a high priority but the cluster doesn't need to be available at all times. Aurora Serverless v2 can automatically pause each instance when it's completely idle. You do so by specifying a minimum capacity of 0 ACUs for the cluster, as explained in [Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2](aurora-serverless-v2-auto-pause.md). You can also manually stop the cluster when it's not needed, and start it when it's time for the next test or development cycle.

Suppose that you have an Aurora Serverless v1 cluster with a heavy workload. An equivalent cluster using Aurora Serverless v2 can scale with more granularity. For example, Aurora Serverless v1 scales by doubling the capacity, for example from 64 to 128 ACUs. In contrast, your Aurora Serverless v2 DB instance can scale in 0.5-ACU increments.

Suppose that your workload requires a higher total capacity than is available in Aurora Serverless v1. You can use multiple Aurora Serverless v2 reader DB instances to offload the read-intensive parts of the workload from the writer DB instance. You can also divide the read-intensive workload among multiple reader DB instances.

For a write-intensive workload, you might configure the cluster with a large provisioned DB instance as the writer. You might do so alongside one or more Aurora Serverless v2 reader DB instances.

## Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2
Upgrading from Aurora Serverless v1 to Aurora Serverless v2

**Important**  
AWS has [ announced the end-of-life date for Aurora Serverless v1: March 31st, 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). All Aurora Serverless v1 clusters that are not migrated by March 31, 2025 will be migrated to Aurora Serverless v2 during the maintenance window. If the upgrade fails, Amazon Aurora converts the Serverless v1 cluster to a provisioned cluster with the equivalent engine version during the maintenance window. If applicable, Amazon Aurora will enroll the converted provisioned cluster in Amazon RDS Extended Support. For more information, see [Amazon RDS Extended Support with Amazon Aurora](extended-support.md).

The process of upgrading a DB cluster from Aurora Serverless v1 to Aurora Serverless v2 has multiple steps. That's because you can't convert directly from Aurora Serverless v1 to Aurora Serverless v2. There's always an intermediate step that involves converting the Aurora Serverless v1 DB cluster to a provisioned cluster.

### Aurora MySQL–compatible DB clusters


You can convert your Aurora Serverless v1 DB cluster to a provisioned DB cluster, then use a blue/green deployment to upgrade it and convert it to an Aurora Serverless v2 DB cluster. We recommend this procedure for production environments. For more information, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md).

**To use a blue/green deployment to upgrade an Aurora Serverless v1 cluster running Aurora MySQL version 2 (MySQL 5.7–compatible)**

1. Convert the Aurora Serverless v1 DB cluster to a provisioned Aurora MySQL version 2 cluster. Follow the procedure in [Converting from Aurora Serverless v1 to provisioned](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).

1. Create a blue/green deployment. Follow the procedure in [Creating a blue/green deployment in Amazon Aurora](blue-green-deployments-creating.md).

1. Choose an Aurora MySQL version for the green cluster that's compatible with Aurora Serverless v2, for example 3.04.1.

   For compatible versions, see [Aurora Serverless v2 with Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy).

1. Modify the writer DB instance of the green cluster to use the **Serverless v2** (db.serverless) DB instance class.

   For details, see [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).

1. When your upgraded Aurora Serverless v2 DB cluster is available, switch over from the blue cluster to the green cluster.

### Aurora PostgreSQL–compatible DB clusters


You can convert your Aurora Serverless v1 DB cluster to a provisioned DB cluster, then use a blue/green deployment to upgrade it and convert it to an Aurora Serverless v2 DB cluster. We recommend this procedure for production environments. For more information, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md).

**To use a blue/green deployment to upgrade an Aurora Serverless v1 cluster running Aurora PostgreSQL version 11**

1. Convert the Aurora Serverless v1 DB cluster to a provisioned Aurora PostgreSQL cluster. Follow the procedure in [Converting from Aurora Serverless v1 to provisioned](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).

1. Create a blue/green deployment. Follow the procedure in [Creating a blue/green deployment in Amazon Aurora](blue-green-deployments-creating.md).

1. Choose an Aurora PostgreSQL version for the green cluster that's compatible with Aurora Serverless v2, for example 15.3.

   For compatible versions, see [Aurora Serverless v2 with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg).

1. Modify the writer DB instance of the green cluster to use the **Serverless v2** (db.serverless) DB instance class.

   For details, see [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).

1. When your upgraded Aurora Serverless v2 DB cluster is available, switch over from the blue cluster to the green cluster.

You can also upgrade your Aurora Serverless v1 DB cluster directly from Aurora PostgreSQL version 11 to version 13, convert it to a provisioned DB cluster, and then convert the provisioned cluster to an Aurora Serverless v2 DB cluster.

**To upgrade, then convert an Aurora Serverless v1 cluster running Aurora PostgreSQL version 11**

1. Convert the Aurora Serverless v1 DB cluster to a provisioned Aurora PostgreSQL cluster. Follow the procedure in [Converting from Aurora Serverless v1 to provisioned](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).

1. Upgrade the Aurora Serverless v1 cluster to an Aurora PostgreSQL version 13 version that's compatible with Aurora Serverless v2, for example, 13.12. Follow the procedure in [Upgrading the major version](aurora-serverless.modifying.md#aurora-serverless.modifying.upgrade).

   For compatible versions, see [Aurora Serverless v2 with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg).

1. Add an Aurora Serverless v2 reader DB instance to the cluster. For more information, see [Adding an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader).

1. Fail over to the Aurora Serverless v2 DB instance:

   1. Select the writer DB instance of the DB cluster.

   1. For **Actions**, choose **Failover**.

   1. On the confirmation page, choose **Failover**.

For Aurora Serverless v1 DB clusters running Aurora PostgreSQL version 13, you convert the Aurora Serverless v1 cluster to a provisioned DB cluster, and then convert the provisioned cluster to an Aurora Serverless v2 DB cluster.

**To upgrade an Aurora Serverless v1 cluster running Aurora PostgreSQL version 13**

1. Convert the Aurora Serverless v1 DB cluster to a provisioned Aurora PostgreSQL cluster. Follow the procedure in [Converting from Aurora Serverless v1 to provisioned](aurora-serverless.modifying.md#aurora-serverless.modifying.convert).

1. Add an Aurora Serverless v2 reader DB instance to the cluster. For more information, see [Adding an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader).

1. Fail over to the Aurora Serverless v2 DB instance:

   1. Select the writer DB instance of the DB cluster.

   1. For **Actions**, choose **Failover**.

   1. On the confirmation page, choose **Failover**.

1. Remove the reader instance.

## Migrating from an on-premises database to Aurora Serverless v2


You can migrate your on-premises databases to Aurora Serverless v2, just as with provisioned Aurora MySQL and Aurora PostgreSQL.
+ For MySQL databases, you can use the `mysqldump` command. For more information, see [Importing data to an Amazon RDS for MySQL database with reduced downtime](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) in the *Amazon Relational Database Service User Guide*.
+ For PostgreSQL databases, you can use the `pg_dump` and `pg_restore` commands. For more information, see the blog post [Best practices for migrating PostgreSQL databases to Amazon RDS and Amazon Aurora](https://aws.amazon.com/blogs/database/best-practices-for-migrating-postgresql-databases-to-amazon-rds-and-amazon-aurora/).