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.

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.

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 for 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:

Aurora Serverless ignores the DB cluster parameter group status of pending-reboot. Aurora applies parameter changes 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. It resumes the DB cluster if it's paused.

With an Aurora Serverless DB cluster, you can modify only the following parameters. For all other configuration parameters, Aurora 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.

To view the supported engine mode for cluster-level parameters, run the describe-engine-default-cluster-parameters command or the RDS API action DescribeEngineDefaultClusterParameters. For example, the following Linux command extracts the names of parameters that you can set for Serverless clusters, from the 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

For example, 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.

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. To copy or share a snapshot of an Aurora Serverless cluster, you encrypt the snapshot using your own KMS key.