How Aurora Serverless works - Amazon 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 router fleet that sends the workload to a fleet of resources that are automatically scaled. Because of the router 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 router 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 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 roll back to current 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. The action your Aurora Serverless DB cluster takes when a timeout occurs depends on whether the following option has been enabled, or not:

  • Force scaling the capacity to the specified values when the timeout is reached

If you choose this option and your DB cluster can't find the scaling point before timing out, Aurora Serverless forces the change. To do so, Aurora Serverless might close existing connections that are consuming additional resources.

If you don't enable this option and your DB cluster can't find the scaling point before timing out, the change isn't made. Instead, Aurora Serverless stops looking for a scaling point and rolls back your DB cluster to its current capacity settings.

Important

For clusters with many concurrent connections, specifying Force scaling the capacity... can result in dropping any connections needed to conform to the modified capacity settings, not only those with long-running transactions.

You specify the timeout action for your Aurora Serverless when you create your Aurora Serverless DB cluster and configure its capacity settings. You can use the AWS Management Console and choose the Force scaling the capacity... in Configuration settings.

You can also use the create-db-cluster AWS CLI command to create your Aurora Serverless DB cluster. You include the TimeoutAction option in the --scaling-configuration parameter and set the option to RollbackCapacityChange or ForceApplyCapacityChange, depending on the action you want your Aurora Serverless DB cluster to take if it can't find a scaling point before timing out. For more information about creating and configuring capacity for your Aurora Serverless DB cluster, see Creating an Aurora Serverless DB cluster.

For an Aurora Serverless DB cluster that's already been configured, you can 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. You can change your capacity configuration including the timeout action, at any time. For more information, 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 looks for a scaling point. For more information about scaling points, see Autoscaling for Aurora Serverless.

If maintenance is required for your Aurora Serverless DB cluster, the DB cluster attempts to find a scaling point for up to seven days. After each day that your Aurora Serverless DB cluster can't find a scaling point, it creates a cluster event notify you that it must scale to apply maintenance. The notification includes the date when 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 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.