Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

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.

Region and version availability

Feature availability and support varies across specific versions of each Aurora database engine, and across Amazon Web Services 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.

The following example shows the Amazon CLI commands to confirm the exact DB engine values you can use with Aurora Serverless v2 for a specific Amazon Web Services 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 Amazon Web Services 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.5 Aurora capacity units (ACU) through 128 ACUs, in increments of 0.5 ACU. 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.

You can specify the minimum and maximum ACU values in the Amazon Web Services 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 Amazon 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. 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.

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:

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. For troubleshooting information if your database encounters out-of-memory errors due to a misconfigured capacity range, see Avoiding out-of-memory errors.

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

Some Aurora Serverless v2 aspects are different from Aurora Serverless v1

If you are an Aurora Serverless v1 user and this is your first time using Aurora Serverless v2, consult the differences between Aurora Serverless v2 and Aurora Serverless v1 requirements to understand how requirements are different between Aurora Serverless v1 and Aurora Serverless v2.