How Aurora Serverless works - Amazon Aurora

How Aurora Serverless works

Amazon Aurora offers two different DB engine modes aimed at two broadly different usage models. The provisioned DB engine mode is designed for predictable workloads. When you work with Aurora provisioned DB clusters, you choose your DB instance class size and several other configuration options. For example, you can create one or more 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. The provisioned model works well when you can adjust capacity in advance of expected consumption patterns.

The serverless DB engine mode is designed for a different usage pattern entirely. 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 websites with intermittent sales events, databases that produce reports when needed, development and testing environments, and new applications with uncertain requirements. 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.

By using Aurora Serverless, you can create a database endpoint without specifying the DB instance class size. You specify only the minimum and maximum range for the Aurora Serverless DB cluster's capacity. The Aurora Serverless database endpoint comprises a router fleet that supports continuous connections and distributes the workload among resources. Aurora Serverless scales the resources automatically based on your minimum and maximum capacity specifications. You don't need to change your database client application code to use the router fleet: Aurora Serverless manages the connections automatically. Scaling is fast thanks to a "warm" resources pool that's always ready to service requests. Storage and processing are separate, so your Aurora Serverless DB cluster can scale down to zero when it's finished processing workloads. When your Aurora Serverless DB cluster scales to zero, you're charged only for storage.

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 gibibytes (GiB) to 128 tebibytes (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 router 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 can also scale to zero capacity when there are no connections if you enable the pause-and-resume option for the DB cluster's capacity settings. For more information, see Automatic pause and resume for Aurora Serverless.

Aurora Serverless scales up when capacity constraints are seen in CPU or connections. 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.

Note

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

If Aurora Serverless can't find a scaling point, its behavior depends on the DB cluster's timeout action setting. Aurora Serverless can force the change, or it can keep its original capacity if Aurora Serverless can't find a scaling point before timing out. For more information, see Timeout action for capacity changes.

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.

During autoscaling, Aurora Serverless resets the EngineUptime metric. The reset metric value doesn't indicate any issues with seamless scaling and doesn't mean that any connections were dropped. For more information about metrics, see Monitoring Amazon Aurora DB cluster metrics.

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. When you select this option, the default inactivity time is five minutes, but you can change this value. This is an optional setting.

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.

When the DB cluster resumes activity, it has the same capacity as it had when Aurora paused the cluster. The number of ACUs depends on how much Aurora scaled the cluster up or down before pausing it.

Note

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

Timeout action for capacity changes

When your Aurora Serverless DB cluster needs to scale its capacity for the current workload, it first tries to find a scaling point for making the change. The scaling point is the point at which your Aurora Serverless DB cluster can safely start scaling to the resized capacity, without disrupting processing. To learn more about how Aurora Serverless finds a scaling point, see Autoscaling for Aurora Serverless.

If your Aurora Serverless DB cluster can't find a scaling point within 5 minutes, it times out. Aurora Serverless then takes the appropriate action based on your Aurora Serverless DB cluster's TimeoutAction setting, as follows:

  • Force the capacity change – If your Aurora Serverless DB cluster can't find a scaling point before timing out, the TimeoutAction value of ForceApplyCapacityChange causes Aurora Serverless to force the change. If Aurora Serverless is processing a transaction, the transaction is interrupted and displays the following message:

    ERROR 1105 (HY000): The last transaction was aborted due to Seamless Scaling. Please retry.

    You can resubmit the transaction as soon as your Aurora Serverless DB cluster is available.

  • Roll back the capacity change – If your Aurora Serverless DB cluster can't find the scaling point before timing out, the TimeoutAction value of RollbackCapacityChange causes Aurora Serverless to stop looking for a scaling point. Instead, your Aurora Serverless DB cluster remains at its original capacity.

You choose the timeout action when you create your Aurora Serverless DB using the AWS Management Console or the AWS CLI. For more information, see Creating an Aurora Serverless DB cluster.

Important

For clusters with many concurrent connections, the ForceApplyCapacityChange setting can result in dropped connections for long-running queries and temporary tables. We recommend you choose ForceApplyCapacityChange only if appropriate for your use case.

You can also modify the timeout action and other capacity settings at any time. For more information, see Modifying an Aurora Serverless DB cluster.

For an Aurora Serverless DB cluster that's already been configured, you can quickly obtain the settings by using the describe-db-clusters AWS CLI command. For example, if you have an Aurora Serverless DB cluster running in the US-East (Northern Virginia) Region, you could run the following command:

$ aws rds describe-db-clusters --region us-east-1

You'll see all details for the DB clusters associated with your AWS account displayed, including the ScalingConfigurationInfo as shown in the following output extract:

... "ScalingConfigurationInfo": { "MinCapacity": 2, "MaxCapacity": 32, "AutoPause": true, "SecondsUntilAutoPause": 1200, "TimeoutAction": "RollbackCapacityChange" }, ...

As shown in the example, the Aurora Serverless DB cluster as configured won't force the cluster to a new scaling point.

Aurora Serverless and parameter groups

When you create your Aurora Serverless DB cluster, you can create a single database instance using your chosen DB engine. Unlike Aurora provisioned DB clusters which can have multiple DB instances, Aurora Serverless has a single read/write DB instance that seamlessly scales as needed for the workload. In a provisioned Aurora DB cluster, each DB instance has an associated DB parameter group that can be configured differently from instance to instance. An Aurora DB cluster has its own set of parameters in its associated DB cluster parameter group. These two general types of parameter groups control different operational aspects, some cluster-wide, some per instance, for a provisioned Aurora DB clusters.

Because Aurora Serverless handles the DB instance capacity for you, parameter groups work differently for Aurora Serverless DB clusters. As it's processing your workloads and seamlessly scaling capacity, Aurora Serverless changes various parameters in its DB cluster parameter group as needed to work best for the increased or decreased capacity. That's why some of the default parameter values and other configuration details that you might use with other kinds of Aurora clusters don't apply for Aurora Serverless clusters.

Your Aurora Serverless DB cluster has an associated DB cluster parameter group only. Its DB cluster parameter group contains default values for any parameters that would typically be held in the DB parameter group of an Aurora provisioned DB cluster. You can't change the values of the default parameter groups of either type, nor can you change the values of the parameter group. However, you can create your own custom version of an Aurora DB cluster parameter group based on one of the provided DB cluster parameter groups and configure parameters as needed. You can do so as follows:

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

  2. Choose the Parameter groups menu.

  3. Choose Create parameter group to open the Parameter group details pane.

  4. Choose the appropriate default DB cluster group for the DB engine you want to use for your Aurora Serverless DB cluster. Be sure you choose the following options:

    1. For Parameter group family, choose the appropriate family for your chosen DB engine. Be sure your selection has the prefix aurora- in its name.

    2. For Type, choose DB Cluster Parameter Group.

    3. For Group name and Description, enter meaningful names for you or others who might need to work with your Aurora Serverless DB cluster and its parameters.

    4. Click Create. Your custom DB cluster parameter group is added to the list of Parameter groups available to your account in your AWS Region.

For example, the following screenshot shows an example of a DB cluster parameter group created for an Aurora PostgreSQL Serverless running any minor release in the Aurora PostgreSQL10.n family.

Creating a new DB cluster parameter group

You can now change values for the parameters contained in this custom DB cluster parameter group. After you're finished customizing, you can apply the parameter group to your existing Aurora Serverless DB clusters or use it when you're creating new Aurora Serverless DB clusters in the same Region.

With an Aurora MySQL Serverless DB cluster, changes to parameter values take effect for the following parameters. For all other configuration parameters, Aurora Serverless DB clusters use default values.

Parameter Description
character_set_server The server's default character set.
collation_server The server's default collation.
general_log Whether the general query log is enabled.
innodb_file_format Sets InnoDB Plug-in default file format. Allowed values Antelope, Barracuda.
innodb_file_per_table Use tablespaces or files for Innodb.
innodb_large_prefix Enables or disables Innodb Large Prefix for Keys.
innodb_lock_wait_timeout Timeout in seconds an innodb transaction may wait for a row lock before giving up.
innodb_monitor_disable Turns off one or more counters in the information_schema.innodb_metrics table.
innodb_monitor_enable Turns on one or more counters in the information_schema.innodb_metrics table.
innodb_monitor_reset Resets to zero the count value for one or more counters in the information_schema.innodb_metrics table.
innodb_monitor_reset_all Resets all values (minimum, maximum, and so on) for one or more counters in the information_schema.innodb_metrics table.
innodb_print_all_deadlocks Records information about all InnoDB deadlocks in Aurora error log.
lc_time_names Specifies the locale that controls the language used to display day and month names and abbreviations.
log_output Controls where to store query logs. Default is FILE. You can't change this value.
log_queries_not_using_indexes Logs queries that are expected to retrieve all rows to slow query log
log_warnings Controls whether to produce additional warning messages.
long_query_time Defines what MySQL considers long queries
lower_case_table_names Affects how the server handles identifier case sensitivity.
net_read_timeout The number of seconds to wait for more data from a TCP/IP connection before abandoning the read.
net_retry_count If a read on a communication port is interrupted, retry this many times before giving up.
net_write_timeout The number of seconds to wait on TCP/IP connections for a block to be written before abandoing the write.
server_audit_events If set it specifies the set of types of events to log.
server_audit_excl_users If not empty, it contains the list of users whose activity will not be logged.
server_audit_incl_users If not empty, it contains a comma-delimited list of users whose activity will be logged.
server_audit_logging Enables audit logging.
slow_query_log Enable or disable the slow query log.
sql_mode Current SQL Server Mode.
time_zone For changing time zone of db server locally.
tx_isolation Sets the default transaction isolation level.

For more information about Aurora parameter groups, see Working with DB parameter groups and DB cluster parameter groups.

To apply a change to a DB cluster parameter group on an active DB cluster, Aurora Serverless starts a seamless scale from its current capacity. If the Aurora Serverless DB cluster is paused, it resumes activity and starts scaling to apply the parameter changes. The scaling operation for a parameter group change uses the ForceApplyCapacityChange setting for its timeout action, which means that if the DB cluster can't find a scaling point before timing out, connections might be dropped. For more information, see Timeout action for capacity changes.

Obtaining Aurora Serverless parameter names and supported DB engines

You can obtain the parameter names and the supported engine mode for cluster-level parameters using the AWS CLI with the describe-engine-default-cluster-parameters command. Or you can invoke the DescribeEngineDefaultClusterParameters API operation. Following are examples of using the AWS CLI to obtain parameters from your Aurora MySQL Serverless or for your Aurora PostgreSQL Serverless DB clusters.

Example Aurora MySQL Serverless DB cluster

You can obtain the names of parameters available for your Aurora MySQL Serverless cluster with the following command. For Aurora MySQL 5.7, the default DB cluster parameter group is aurora5.6.

For Linux, macOS, or Unix:

aws rds describe-engine-default-cluster-parameters \ --db-parameter-group-family aurora5.6 \ --query 'EngineDefaults.Parameters[*].{ParameterName:ParameterName, \ SupportedEngineModes:SupportedEngineModes} \ | [?contains(SupportedEngineModes, `serverless`) == `true`] \ | [*].{param:ParameterName}' \ --output text

Example Aurora PostgreSQL Serverless DB cluster

You can obtain the names of parameters available for your Aurora PostgreSQL Serverless cluster with the following AWS CLI command. In this example, the default DB cluster parameter group being queried is aurora-postgresql10.

For Linux, macOS, or Unix:

aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql10 \ --query 'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | \ [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \ --output text

For more information about parameter groups, see Working with DB parameter groups and DB cluster parameter groups.

Aurora Serverless and maintenance

Maintenance for Aurora Serverless DB cluster, such as applying the latest features, fixes, and security updates, is performed automatically for you. Unlike provisioned Aurora DB clusters, Aurora Serverless doesn't have user-settable maintenance windows. However, it does have a maintenance window that you can view in the AWS Management Console in Maintenance & backups for your Aurora Serverless DB cluster. You'll find the date and time that maintenance might be performed and if any maintenance is pending for your Aurora Serverless DB cluster. For example:


              Maintenance window for an example Aurora Serverless DB cluster, not user settable, no pending maintenance

Whenever possible, Aurora Serverless performs maintenance in a non-disruptive manner. When maintenance is required, your Aurora Serverless DB cluster scales its capacity to handle the necessary operations. Before scaling, Aurora Serverless looks for a scaling point and it does so for up to seven days if necessary.

At the end of each day that Aurora Serverless can't find a scaling point, it creates a cluster event that notifies you of the pending maintenance and its need to scale to perform maintenance. The notification includes the date when the Aurora Serverless can force the DB cluster to scale.

Until that time, your Aurora Serverless DB cluster continues looking for a scaling point and behaves according to its TimeoutAction setting. That is, if it can't find a scaling point before timing out, it abandons the capacity change if it's configured to RollbackCapacityChange. Or it forces the change if it's set to ForceApplyCapacityChange. As with any change that's forced without an appropriate scaling point, this might interrupt your workload.

For more information, see Timeout action for capacity changes.

Aurora Serverless and failover

If the DB instance for an Aurora Serverless DB cluster becomes unavailable or the Availability Zone (AZ) it is in fails, Aurora recreates the DB instance in a different AZ. We refer to this capability as automatic multi-AZ failover.

This failover mechanism 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.

Because Aurora separates computation capacity and storage, the storage volume for the cluster is spread across multiple AZs. Your data remains available even if outages affect the DB instance or the associated AZ.

Aurora Serverless and snapshots

The cluster volume for an Aurora Serverless cluster is always encrypted. You can choose the encryption key, but you can't disable encryption. To copy or share a snapshot of an Aurora Serverless cluster, you encrypt the snapshot using your own AWS Key Management Service customer master key (CMK). For more information, see Copying a DB cluster snapshot . To learn more about encryption and Amazon Aurora, see Encrypting Amazon Aurora resources.