AWS Database Blog
Schedule scaling for Amazon Aurora replicas using AWS Application Auto Scaling
In this post, we demonstrate how to modify the Amazon Aurora reader auto scaling configuration on a schedule using AWS Application Auto Scaling, on top of the existing auto scaling policies. When your application grows, the load on your database will most likely grow as your application saves larger amounts of data. Whether it’s the number of connections needed, the amount of data to be stored, or the increased processing power, your database should be able to scale up to meet the demand. A possible solution to this scenario is the ability to scale your database up or down in a scheduled scaling fashion.
Solution overview
Aurora allows auto scaling to dynamically adjust the number of reader instances provisioned for an Aurora DB cluster. Aurora supports up to 15 low-latency read replicas in a single Aurora cluster that share the same underlying cluster volume. Auto scaling manages the sudden increase in workload when required and helps in deprovisioning extra resources when the workload decreases so that you don’t pay for unused provisioned DB instances.
Application Auto Scaling allows you to automatically scale your scalable resources according to the conditions that you define for Aurora DB clusters using the following features:
However, it’s not possible to set up and perform scheduled scaling from the AWS Management Console. In this post, we discuss how to schedule scaling for Aurora readers using the Application Auto scaling CLI. We also provide an AWS CloudFormation template that you can use to schedule the scaling. You can edit the CloudFormation template according to your business needs.
Application Auto Scaling
It’s important to understand how Application Auto Scaling treats the maximum and minimum capacities when using scheduled scaling. With Application Auto Scaling, you can create a scheduled action that instructs the service to perform scaling activities at specific times.
When setting up a scheduled action, you define the scalable target, the timing for the scaling activity, as well as the minimum and maximum capacity. These scheduled actions can either scale just one time or on a recurring basis. At the specified time, Application Auto Scaling scales based on the new capacity values by comparing the current capacity to the specified minimum and maximum capacity. For more details refer to Application Auto Scaling.
Note: you can use scheduled scaling and scaling policies together on the same resource to get the benefits of both.
Prerequisites
Requirements that you should have to follow along with this post:
- You must have the AWS Command Line Interface (AWS CLI) version 2 installed. For instructions refer to AWS CLI install and update instructions.
- You must have an Aurora cluster on which to add replicas that will use Application AutoScaling. Application Auto Scaling supports both Amazon Aurora MySQL- Compatible Edition and Amazon Aurora PostgreSQL- Compatible Edition provisioned clusters.
Additionally, there are a few things that we must identify before scheduling the scaling:
- Aurora cluster name
- Scale-up time
- Minimum readers at time of scale-up
- Scale-down time
- Maximum readers at time of scale-down
- Timezone (defaults to UTC)
Deploy the solution using the AWS CLI
In this section, we demonstrate scaling the reader instances up and down as per scheduled scaling action using the AWS CLI. The high level steps are as follows :
- Register the target, in this case your Aurora cluster, with Application Auto Scaling.
- Create a scheduled action to scale up the number of reader instances in the cluster.
- Create another scheduled action to scale down the number of reader instances when necessary.
Register your Aurora cluster, with Application Auto Scaling
The following code registers the target Aurora cluster for which we want to dynamically scale the reader instances, with Application Auto Scaling.
The following example registers an Aurora cluster named database-1 with a minimum capacity of 0 and maximum of 5 in the us-east-2 Region.
aws application-autoscaling register-scalable-target --service-namespace rds --resource-id cluster:database-1 --scalable-dimension rds:cluster:ReadReplicaCount --min-capacity 0 -max-capacity 5 --region us-east-2
You can verify that the target is registered using the following AWS CLI commands:
For example: aws application-autoscaling describe-scalable-targets --service-namespace rds --resource-ids cluster:database-1 --region us-east-2
Create the scheduled action for scaling up
In the following code, we create a scheduled scale-up action for the Aurora readers at the required time.
In the following example, we create a scheduled action named ScaleUpAurora on our cluster database-1 to set the minimum capacity of 6 and maximum capacity of 10, every day at 06:10 AM UTC:
aws application-autoscaling put-scheduled-action --service-namespace rds --schedule "cron(10 6 ? * * * )" --scheduled-action-name ScaleUpAurora --resource-id cluster:database-1 --scalable-dimension rds:cluster:ReadReplicaCount --scalable-target-action MinCapacity=6,MaxCapacity=10 --region us-east-2
You can use the --timezone parameter if you want to provide a time zone; Application Auto Scaling uses UTC by default. The time zone is provided in Joda-Time format. For example:
You can verify the scheduled action using the following command:
When the scheduled time arrives, you’ll observe an increase in the number of reader instances, as shown in the following screenshot.
Additionally, you can view these events in the Amazon Aurora console by navigating to the Clusters page and looking under the Logs and Events section.
Create a scheduled action to scale down
We use the following code to create a scheduled scale-down action for the Aurora readers at the required time:
In the following example, we create a scheduled action named ScaleDownAurora on our cluster database-1 to set the minimum capacity of 0 and maximum capacity of 0, every day at 6:50 AM UTC
aws application-autoscaling put-scheduled-action —service-namespace rds —schedule "cron(50 6 ? * * * )" —scheduled-action-name ScaleDownAurora —resource-id cluster:database-1 —scalable-dimension rds:cluster:ReadReplicaCount —scalable-target-action MinCapacity=0,MaxCapacity=0 —region us-east-2
You can observe the scale-down event on the Aurora console. The following screenshot displays the operation status as In Progress, signifying that Application Auto Scaling is in the process of scaling down the Aurora cluster. When it’s complete, the status will change to Successful.
You can also view all the scaling events using the AWS CLI:
There are other parameters available for this command that you can use. For more details, refer to describe-scaling-activities .
Deploy the solution using AWS CloudFormation
You can implement the same solution using AWS CloudFormation. Complete the following steps :
- Download the CloudFormation template.
- Open the AWS CloudFormation console and launch the stack.
- For
AuroraCluster, enter the name of the Aurora cluster you intend to scale. - For
MaximumReaderAtScaleDown, specify the desired number of instances in the cluster during scale-down. - For
MaximumReaderAtScaleUp, specify the intended number of instances in the cluster for scale-up.
- For
MinimumReaderAtScaleDown, specify the minimum number of instances in the cluster during scale-down. - For
MinimumReaderAtScaleUp, specify the minimum number of instances in the cluster during scale-up. - For
ScaleDownActionName, enter a unique identifier for the scale-down action. - For
ScaleDownTime, enter a cron expression to determine the scale-down time. - In
ScaleUpActionName, enter a unique identifier for the scale-up action. - For
ScaleUpTime, enter a cron expression to determine the scale-up time. - For
TimeZone, specify the desired time zone for scaling, using the Joda-Time format.
- Choose Next after you have provided all the relevant details.
- On the Review page, double-check all the parameter values that you provided for the Aurora cluster, then choose Submit.
After 2-3 minutes, you will see that the CloudFormation template is deployed, and the scaling operation will take place as per the given schedule.
Additional considerations
When you use the AWS CLI to set register-scalable-target and set a minimum and maximum number, Application AutoScaling won’t do the scaling right away. However, when using AWS CloudFormation for the same configuration, as soon as you specify ScalableTarget and provide MaxCapacity and MinCapacity, AWS CloudFormation will scale the cluster readers accordingly. Therefore, we have explicitly set them to 0, but you can change them as desired.
The following code is part of the CloudFormation template for reference :
Application Auto Scaling can only remove the reader instances that it has created and won’t have any effect on manually created readers in a scale down operation. However, all manually created readers are counted towards the MinCapacity at the time of scaling up.
Let’s explore an example. Assume we have an Aurora cluster with a writer and two manually created reader instances. If we enable Auto Scaling and set the MinCapacity for the scale-up action to 3, Application Auto Scaling will account for the two manually created readers. As a result, it will only add one additional reader to the cluster.
Conversely, if we set the MaxCapacity for the scale down action to 0 for the same cluster, Application Auto Scaling will only remove the one reader instance it added. Therefore, the cluster will still contain the two original, manually created readers. In this scenario, the scale down action won’t fail. Instead, its status will display as “Unfulfilled.”
If you want to add three more readers you must set the MinCapacity as 5.
Keep in mind that if you use AWS CloudFormation to schedule reader scaling and later delete the template, you will also delete the scaling policy, which will result in the deletion of the auto-scaled added readers.
Tips and troubleshooting
It’s best to avoid deleting and re-creating individual AWS components that have interdependencies. The following tips should help you make any changes you need:
- When Aurora Auto Scaling adds a new Aurora Replica, the new Aurora Replica uses the same DB instance class as the one used by the primary instance.
- Aurora Auto Scaling only scales a DB cluster if the DB cluster is in the available state.
- Aurora Auto Scaling only removes Aurora Replicas that it created.
- During a scale down operation Aurora terminates the extra reader instance, any running queries are terminated.
- To change CloudFormation stack parameters, update the stack. See the example script update-stack.cli in the GitHub Repo.
- You can also delete the entire CloudFormation stack and start over
Clean up
When you are done with the solution, you can clean up your resources using either AWS CLI or AWS CloudFormation.
Clean up using AWS CLI
Deregister the target using the following code:
For example: aws application-autoscaling deregister-scalable-target --service-namespace rds --resource-id cluster:database-1 --scalable-dimension rds:cluster:ReadReplicaCount
Delete the scheduled action with the following code:
For example: aws application-autoscaling delete-scheduled-action --service-namespace --scheduled-action-name ScaleUpAurora --resource-id cluster:database-1 --scalable-dimension rds:cluster:ReadReplicaCount
Clean up using CloudFormation
Deleting the Cloudformation template will delete the scaling actions and deregister the target.
Summary
Aurora offers advantages such as high availability, flexibility, and streamlined management. In this post, we delved into how you can harness the scheduled scaling feature of Application Auto Scaling to adjust the number of reader instances in your Aurora cluster based on a set schedule. We covered the steps for implementation, testing, and troubleshooting, complemented by best practices.
Try it out today and leave a comment if you have any questions or suggestions.
About the Authors
Asad Aazam is a Solutions Architect at AWS with expertise in AWS Database technologies such as Aurora, RDS and DynamoDB, With good knowledge on relational databases he is helping homogeneous and heterogeneous database migrations and optimization in AWS cloud. When not working he likes to go on bike rides, travel and enjoy the beauty of nature.
Aparna Bansal is a Solutions Architect at AWS. She extensively works on tools, artifacts and process automations to ensure Security is not looked at as an extended burden but as Job Zero, just as it is done at Amazon. Outside of work, she enjoys reading novels and exploring new places.