Amazon Aurora
User Guide for Aurora (API Version 2014-10-31)

How Aurora Serverless Works

When you work with Amazon Aurora without Aurora Serverless, you can choose your DB instance class size and create Aurora Replicas to increase read throughput. If your workload changes, you can modify the DB instance class size and change the number of Aurora Replicas. This model works well when the database workload is predictable, because you can adjust capacity manually based on the expected workload.

However, in some environments, workloads can be intermittent and unpredictable. There can be periods of heavy workloads that might last only a few minutes or hours, and also long periods of light activity, or even no activity. Some examples are retail websites with intermittent sales events, reporting databases that produce reports when needed, development and testing environments, and new applications with uncertain requirements. In these cases and many others, it can be difficult to configure the correct capacity at the right times. It can also result in higher costs when you pay for capacity that isn't used.

With Aurora Serverless, you can create a database endpoint without specifying the DB instance class size. You set the minimum and maximum capacity. With Aurora Serverless, the database endpoint connects to a proxy fleet that routes the workload to a fleet of resources that are automatically scaled. Because of the proxy fleet, connections are continuous as Aurora Serverless scales the resources automatically based on the minimum and maximum capacity specifications. Database client applications don't need to change to use the proxy fleet. Aurora Serverless manages the connections automatically. Scaling is rapid because it uses a pool of "warm" resources that are always ready to service requests. Storage and processing are separate, so you can scale down to zero processing and pay only for storage.

Aurora Serverless introduces a new serverless DB engine mode for Aurora DB clusters. Non-Serverless DB clusters use the provisioned DB engine mode.

Aurora Serverless Architecture

The following image provides an overview of the Aurora Serverless architecture.

                  Aurora Serverless Architecture

Instead of provisioning and managing database servers, you specify Aurora Capacity Units (ACUs). Each ACU is a combination of processing and memory capacity. Database storage automatically scales from 10 GiB to 64 TiB, the same as storage in a standard Aurora DB cluster.

You can specify the minimum and maximum ACU. The minimum Aurora capacity unit is the lowest ACU to which the DB cluster can scale down. The maximum Aurora capacity unit is the highest ACU to which the DB cluster can scale up. Based on your settings, Aurora Serverless automatically creates scaling rules for thresholds for CPU utilization, connections, and available memory.

Aurora Serverless manages the warm pool of resources in an AWS Region to minimize scaling time. When Aurora Serverless adds new resources to the Aurora DB cluster, it uses the proxy fleet to switch active client connections to the new resources. At any specific time, you are only charged for the ACUs that are being actively used in your Aurora DB cluster.

Autoscaling for Aurora Serverless

The capacity allocated to your Aurora Serverless DB cluster seamlessly scales up and down based on the load (the CPU utilization and number of connections) generated by your client application. It also scales to zero capacity when there are no connections for a 5-minute period.

Aurora Serverless scales up when capacity constraints are seen in CPU, connections, or memory. It also scales up when it detects performance issues that can be resolved by scaling up.

After scaling up, the cooldown period for scaling down is 15 minutes. After scaling down, the cooldown period for scaling down again is 310 seconds.


There is no cooldown period for scaling up. Aurora Serverless can scale up whenever necessary, including immediately after scaling up or scaling down.

A scaling point is a point in time at which the database can safely initiate the scaling operation. Under the following conditions, Aurora Serverless might not be able to find a scaling point:

  • Long-running queries or transactions are in progress

  • Temporary tables or table locks are in use

In these cases, Aurora Serverless continues to try to find a scaling point so that it can initiate the scaling operation.

You can see scaling events in the details for a DB cluster in the AWS Management Console. You can also monitor the current capacity allocated to the DB cluster by using the ServerlessDatabaseCapacity metric for Amazon CloudWatch.

Automatic Pause and Resume for Aurora Serverless

You can choose to pause your Aurora Serverless DB cluster after a given amount of time with no activity. You specify the amount of time with no activity before the DB cluster is paused. The default is five minutes. You can also disable pausing the DB cluster.

When the DB cluster is paused, no compute or memory activity occurs, and you are charged only for storage. If database connections are requested when an Aurora Serverless DB cluster is paused, the DB cluster automatically resumes and services the connection requests.


If a DB cluster is paused for more than seven days, the DB cluster might be backed up with a snapshot. In this case, the DB cluster is restored when there is a request to connect to it.

Aurora Serverless and DB Cluster Parameter Groups

There are some differences between the way DB cluster parameter groups work with provisioned and serverless DB clusters. With an Aurora Serverless DB cluster, you can only modify the following cluster-level parameters:

  • character_set_server

  • collation_server

  • lc_time_names

  • lower_case_table_names

  • time_zone

If you modify other cluster-level parameters, the changes have no effect, and the Aurora Serverless DB cluster uses the default values for these parameters. You can view the supported engine mode for cluster-level parameters by running the describe-engine-default-cluster-parameters command or the RDS API action DescribeEngineDefaultClusterParameters.


Instance-level parameters do not apply to Aurora Serverless.

When you modify a DB cluster parameter group that is associated with an Aurora Serverless DB cluster, the following applies:

  • When you change a cluster-level parameter that can be modified with Aurora Serverless and save the DB cluster parameter group, the change is applied immediately regardless of the following settings:

  • With Aurora Serverless, the DB cluster parameter group status of pending-reboot is ignored. An Aurora Serverless DB cluster applies changes to the DB cluster parameter group immediately without downtime.

  • To apply a change to a DB cluster parameter group, Aurora Serverless starts a seamless scale with the current capacity if the DB cluster is active, or resumes the DB cluster if it is paused.

For information about parameter groups, see Working with DB Parameter Groups and DB Cluster Parameter Groups.

Aurora Serverless and Failover

An Aurora Serverless DB cluster currently is created in a single Availability Zone (AZ). If that availability zone becomes unavailable, Aurora recreates the cluster in a different AZ.

An Aurora Provisioned cluster that is configured for fast failover recovers in approximately 60 seconds. Although Aurora Serverless does not support fast failover, it supports automatic multi-AZ failover. Failover for Aurora Serverless takes longer than for an Aurora Provisioned cluster. The Aurora Serverless failover time is currently undefined because it depends on demand and capacity availability in other AZs within the given AWS Region.

Aurora Serverless and Snapshots

The cluster volume for an Aurora Serverless cluster is always encrypted. You can choose the encryption key, but not turn off encryption. Therefore, you can't perform operations that aren't allowed for encrypted snapshots. For example, you can't copy snapshots of Aurora Serverless clusters to a different AWS Region.