How Aurora Serverless Works - Amazon Aurora
AWS services or capabilities described in AWS documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with AWS services in China.

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

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.

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

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

Note that for clusters with many concurrent connections, specifying Force the capacity change can result in dropping any connection—not only those with long-running transactions.

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

Aurora Serverless and Parameter Groups

Parameter groups work differently for Aurora Serverless DB clusters than for provisioned DB clusters. Aurora manages the capacity settings for you. Some of the configuration procedures, default parameter values, and so on that you use with other kinds of Aurora clusters don't apply for Aurora Serverless clusters.

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 scales the associated DB instance automatically as needed. The scaling operation involves modifying parameter values to be suitable for the larger or smaller capacity.

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 an 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, modifications to parameter values only take effect for the following parameters. You can modify other parameters, but Aurora doesn't use the changed values. For all other configuration parameters, Aurora MySQL Serverless clusters use default values. These default values might be different than for other kinds of Aurora clusters. These values might also change as Aurora scales the Aurora Serverless cluster up or down.

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

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 seven days. After each day that no scaling point can be found, Aurora Serverless creates a cluster event to notify you that it must scale to apply maintenance. The notification includes the date at which scaling will be applied with the ForceApplyCapacityChange timeout action to apply the maintenance, regardless of the ScalingConfiguration settings. If your DB cluster has RollbackCapacityChange set as the TimeoutAction for its ScalingConfiguration, Aurora Serverless tries to apply maintenance using the RollbackCapacityChange timeout action prior to the time included in the event. If your DB cluster has ForceApplyCapacityChange set as the TimeoutAction for its ScalingConfiguration, then scaling to apply maintenance uses it for all attempts. When ForceApplyCapacityChange is used, it might interrupt your workload. For more information, see Timeout Action for Capacity Changes.

Note

Maintenance windows don't apply to Aurora Serverless.

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 not turn off 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).