Amazon Aurora
User Guide for Aurora

How Aurora Serverless Works

When you work with Amazon Aurora without Aurora Serverless (provisioned DB clusters), 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.

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

In these cases, Aurora Serverless continues to try to find a scaling point so that it can initiate the scaling operation. It does this for as long as it determines that the DB cluster should be scaled.

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. 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.

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, the DB cluster is restored when there is a request to connect to it.

Timeout Action for Capacity Changes

You can change the capacity of an Aurora Serverless DB cluster. When you change the capacity, Aurora Serverless tries to find a scaling point for the change. If Aurora Serverless can't find a scaling point, it times out. You can specify one of the following actions to take when a capacity change times out:

  • Force the capacity change – Set the capacity to the specified value as soon as possible.

  • Roll back the capacity change – Cancel the capacity change.

Important

If you force the capacity change, connections that prevent Aurora Serverless from finding a scaling point might be dropped.

For information about changing the capacity, see Modifying an Aurora Serverless DB Cluster.

Aurora Serverless and Parameter Groups

Parameter groups work differently for Serverless DB clusters than for provisioned DB clusters. In particular, the DB instances in an Aurora Serverless cluster only have associated DB cluster parameter groups, not DB parameter groups. Serverless clusters rely on DB cluster parameter groups because DB instances are not permanently associated with Aurora Serverless clusters. Aurora adds and removes DB instances automatically as needed.

To customize configuration settings for an Aurora Serverless cluster, you can define your own DB cluster parameter group and modify the parameters it contains. You can modify both cluster-level parameters, and parameters that apply at the instance level in other kinds of Aurora clusters. However, when you modify a DB cluster parameter group that's associated with an Aurora Serverless DB cluster, modifications apply differently than for other DB cluster parameter groups.

When you save changes to a DB cluster parameter group for an Aurora Serverless DB cluster, changes are applied immediately. In doing so, Aurora Serverless ignores the following settings:

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. It resumes the DB cluster if it's paused.

Important

Aurora performs the seamless scaling operation for a parameter group change with the force-apply-capacity-change option. If a scaling point can't be found, connections that prevent Aurora Serverless from finding a scaling point might be dropped.

To view the supported engine mode for cluster-level parameters, run the describe-engine-default-cluster-parameters command or the RDS API operation DescribeEngineDefaultClusterParameters. For example, the following Linux command extracts the names of parameters that you can set for Aurora MySQL Serverless clusters, from an aurora5.6 default DB cluster parameter group.

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

the following Linux command extracts the names of parameters that you can set for Aurora PostgreSQL Serverless clusters, from a aurora-postgresql10 default DB cluster parameter group.

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

The following Linux command extracts the names of parameters that you can set for Serverless clusters from a DB cluster parameter group that you created.

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name my_cluster_param_group_name \ --query '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.

With an Aurora MySQL Serverless DB cluster, you can modify only the following parameters. For all other configuration parameters, Aurora MySQL Serverless clusters use the default values.

  • character_set_server.

  • collation_server.

  • general_log. This setting was formerly only in the DB instance parameter group.

  • innodb_file_format. This setting was formerly only in the DB instance parameter group.

  • innodb_file_per_table.

  • innodb_large_prefix. This setting was formerly only in the DB instance parameter group.

  • innodb_lock_wait_timeout. This setting was formerly only in the DB instance parameter group.

  • innodb_monitor_disable. This setting was formerly only in the DB instance parameter group.

  • innodb_monitor_enable. This setting was formerly only in the DB instance parameter group.

  • innodb_monitor_reset. This setting was formerly only in the DB instance parameter group.

  • innodb_monitor_reset_all. This setting was formerly only in the DB instance parameter group.

  • innodb_print_all_deadlocks. This setting was formerly only in the DB instance parameter group.

  • lc_time_names.

  • log_output. This setting was formerly only in the DB instance parameter group. This setting has a default value of FILE. You can't change this value.

  • log_queries_not_using_indexes. This setting was formerly only in the DB instance parameter group.

  • log_warnings. This setting was formerly only in the DB instance parameter group.

  • long_query_time. This setting was formerly only in the DB instance parameter group.

  • lower_case_table_names.

  • net_read_timeout. This setting was formerly only in the DB instance parameter group.

  • net_retry_count. This setting was formerly only in the DB instance parameter group.

  • net_write_timeout. This setting was formerly only in the DB instance parameter group.

  • server_audit_logging.

  • server_audit_events.

  • server_audit_excl_users.

  • server_audit_incl_users.

  • slow_query_log. This setting was formerly only in the DB instance parameter group.

  • sql_mode. This setting was formerly only in the DB instance parameter group.

  • time_zone.

  • tx_isolation. This setting was formerly only in the DB instance parameter group.

Aurora Serverless and Maintenance

Aurora Serverless performs regular maintenance so that your DB cluster has the latest features, fixes, and security updates. Aurora Serverless performs maintenance in a non-disruptive manner whenever possible. If long-running transactions are in progress, or temporary tables or table locks are in use, maintenance might cause actively used connections to drop momentarily.

To apply maintenance, Aurora Serverless must find a scaling point. For more information about scaling points, see Autoscaling for Aurora Serverless.

If there is maintenance required for an Aurora Serverless DB cluster, the DB cluster attempts to find a scaling point to apply the maintenance for one day. If after a day no scaling point can be found, Aurora Serverless creates a scaling event to notify you that it must scale to apply maintenance. The notification includes the amount of time you have to force the scaling of your DB cluster. After you get this notification, you can control the time of the scaling, and the associated maintenance is applied at that time. Aurora Serverless tries to apply maintenance seamlessly for the amount of time specified in the event. After that time period has elapsed, Aurora Serverless drops connections to apply maintenance.

Note

Maintenance windows don't apply to Aurora Serverless.

Aurora Serverless and Failover

The DB instance for an Aurora Serverless DB cluster currently is created in a single Availability Zone (AZ). If the DB instance or the AZ becomes unavailable, 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 not turn off encryption. To copy or share a snapshot of an Aurora Serverless cluster, you encrypt the snapshot using your own KMS key.