# Using Aurora Serverless v2
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)
## 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. 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
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 [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-from-provisioned).
## 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.
+ **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 oFor example, with Aurora Serverless v2 you can use reader DB instances, global databases, AWS Identity and Access Management (IAM) database authentication, and Performance Insights.
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.
+ **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.
+ **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** – 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. 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
*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 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
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 [Converting a provisioned writer or reader to Aurora Serverless v2](aurora-serverless-v2-administration.md#aurora-serverless-v2-converting-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
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 (minimum and maximum) using this unit of measure. Aurora Serverless v2 offers capacity from 0 ACUs to 256 ACUs. With the minimum capacity of 0 ACUs, the cluster will scale to 0 when there is no workload running.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 |
Platform versions in Aurora Serverless v2 represent improvements in performance, scaling capabilities or features. Amazon Aurora automatically manages platform version assignments at the cluster level. All new clusters, database restores, and new clones launch with the latest platform version available in your AWS Region. When a new platform version becomes available, existing clusters on previous platform versions can be upgraded directly to the latest platform version by stopping and restarting the cluster or by using blue/green deployments. Amazon Aurora recommends upgrading to the latest platform version to benefit from all the latest improvements.
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 |
| 4 | 0-256 | Up to 30% improved performance compared to platform version 3 |
**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. Platform versions should not be confused with Aurora Serverless v1, which is a deprecated product with a different architecture.
Platform version 1, 2, and 3 are available in all regions where Aurora Serverless v2 is supported. Platform Version 4 is available in the following regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Spain), Europe (Stockholm), Europe (Zurich), South America (São Paulo), AWS GovCloud (US-East), and AWS GovCloud (US-West).
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
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.
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. 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).
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.
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
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. 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
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
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)
## 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**
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.
# Creating a DB cluster that uses Aurora Serverless v2
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
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`.
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
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
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)
+ [Checking the platform version for an existing Aurora Serverless v2 cluster](#aurora-serverless-v2-checking-platform-version)
+ [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
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.
**Important:** Once you upgrade to a newer platform version, you cannot downgrade to a previous version.
## Checking the capacity range for Aurora Serverless v2
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
}
]
]
```
## Checking the platform version for an existing Aurora Serverless v2 cluster
### Console
The platform version is displayed in the Instance Configuration section of the instance.
![\[Platform version in the Instance Configuration section.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-v2-platform-version.png)
### AWS CLI
You can use the `describe-db-clusters` command to check the platform version for existing cluster(s).
**Example**
```
1. aws rds describe-db-clusters \
2. --db-cluster-identifier mydbcluster
```
### Checking the default platform version
#### AWS CLI
You can use the `describe-serverless-v2-platform-versions` command to check the details of a platform version or to check the default platform version that you will get when you create a new cluster.
**Example**
```
1. $ aws rds describe-serverless-v2-platform-versions
2. {
3. "ServerlessV2PlatformVersions": [
4. {
5. "Engine": "aurora-postgresql",
6. "ServerlessV2PlatformVersion": "3",
7. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
8. "ServerlessV2FeatureSupport": {
9. "MinCapacity": 0
10. "MaxCapacity": 256
11. },
12. "Status": "available",
13. "IsDefault": True
14. },
15. ...
16. ]
17. }
18.
19. # describing the default platform version for an engine
20. $ aws rds describe-serverless-v2-platform-versions --engine aurora-postgresql --default-only
21. {
22. "ServerlessV2PlatformVersions": [
23. {
24. "Engine": "aurora-postgresql",
25. "ServerlessV2PlatformVersion": "3",
26. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
27. "ServerlessV2FeatureSupport": {
28. "MinCapacity": 0
29. "MaxCapacity": 256
30. },
31. "Status": "available",
32. "IsDefault": True
33. }
34. ]
35. }
```
### Checking for pending platform version upgrades
You can use the `describe-pending-maintenance-actions` command to check whether there are any pending platform version upgrades for your Aurora Serverless v2 DB clusters.
To check for pending upgrades on a specific cluster, use the `--resource-identifier` parameter to specify the Amazon Resource Name (ARN) of your DB cluster:
**Example**
```
1. aws rds describe-pending-maintenance-actions \
2. --resource-identifier arn:aws:rds:us-east-1:123456789012
3. :cluster:my-serverless-cluster
```
#### Scheduling a platform version upgrade
After you identify a pending platform version upgrade, you can use the `apply-pending-maintenance-action` command to schedule when the upgrade occurs.
To schedule a platform version upgrade, specify the following parameters:
+ `--resource-identifier` – The ARN of your Aurora Serverless v2 DB cluster
+ `--apply-action` – Use `serverless-platform-version-update` to specify a platform version upgrade
+ `--opt-in-type` – Choose when to apply the upgrade:
+ `immediate` – Apply the upgrade immediately
+ `next-maintenance` – Apply the upgrade during your next schedule
## 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
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 [Converting a provisioned writer or reader to Aurora Serverless v2](#aurora-serverless-v2-converting-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
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 [Converting a provisioned writer or reader to Aurora Serverless v2](#aurora-serverless-v2-converting-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
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
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
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.
### 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
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. 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
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.
**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
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
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
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
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. 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
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
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.
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
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.
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
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
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
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
+ 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
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
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)
### What happens when Aurora Serverless v2 instances pause
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
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
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
+ 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
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
+ 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.
## How Aurora Serverless v2 auto-pause works for different types of Aurora clusters
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
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
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
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
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
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
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
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
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
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
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
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 you are 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).