Step 1: Register your scalable target
Begin by registering your resource as a scalable target with Application Auto Scaling. A scalable target is a resource that Application Auto Scaling can scale out or scale in.
You can use any resource that works with Application Auto Scaling and supports scheduled scaling, but for these examples, let's assume that you want to scale a DynamoDB table called my-table. If you don't already have a DynamoDB table, you can create one now (Step 1: Create a DynamoDB table in the Amazon DynamoDB Developer Guide).
To use a DynamoDB global secondary index or a resource for a different service, update the examples accordingly. Specify its namespace in --service-namespace, its scalable dimension in --scalable-dimension, and its resource ID in --resource-id. For a list of valid values for each option, see register-scalable-target.
To register your scalable target with Application Auto Scaling
1. (Optional) Use the describe-scalable-targets command to check whether any DynamoDB resources are already registered. This helps you verify whether to register the my-table table. For example, if you previously configured automatic scaling for this table from the DynamoDB console, it may already be registered with Application Auto Scaling.
Linux, macOS, or Unix
aws application-autoscaling describe-scalable-targets \
Step 2: Create two scheduled actions
--service-namespace dynamodb \ --profile adminuser
Windows
aws application-autoscaling describe-scalable-targets service-namespace dynamodb --profile adminuser
If there are no existing scalable targets, this is the response.
{
"ScalableTargets": []
}
2. Use the following register-scalable-target command to register or update the write capacity of a DynamoDB table called my-table. Set a minimum desired capacity of 5 write capacity units and a maximum desired capacity of 10 write capacity units.
Linux, macOS, or Unix
aws application-autoscaling register-scalable-target \ --service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/my-table \
--min-capacity 5 --max-capacity 10 \ --profile adminuser
Windows
aws application-autoscaling register-scalable-target service-namespace dynamodb scalable-dimension dynamodb:table:WriteCapacityUnits resource-id table/my-table --min-capacity 5 --max-capacity 10 --profile adminuser
This command does not return any output if it is successful.
Step 2: Create two scheduled actions
Application Auto Scaling allows you to schedule the time when a scaling action should occur. You specify the scalable target, the schedule, and the minimum and maximum capacity. At the specified time, Application Auto Scaling updates the minimum and maximum value for the scalable target. If its current capacity is outside of this range, this results in a scaling activity.
Scheduling updates to the minimum and maximum capacity is also helpful if you decide to create a scaling policy. A scaling policy allows your resources to scale dynamically based on current resource utilization. A common guardrail for a scaling policy is having appropriate values for minimum and maximum capacity.
For this exercise, we create two one-time actions for scale out and scale in.
To create and view the scheduled actions
1. To create the first scheduled action, use the following put-scheduled-action command.
The at command in --schedule schedules the action to be run once at a specified date and time in the future. Hours are in 24-hour format in UTC. Schedule the action to occur about 5 minutes from now.
Step 2: Create two scheduled actions
At the date and time specified, Application Auto Scaling updates the MinCapacity and MaxCapacity values. Assuming the table currently has 5 write capacity units, Application Auto Scaling scales out to MinCapacity to put the table within the new desired range of 15-20 write capacity units.
Linux, macOS, or Unix
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/my-table \
--scheduled-action-name my-first-scheduled-action \ --schedule "at(2019-05-20T17:05:00)" \
--scalable-target-action MinCapacity=15,MaxCapacity=20 \ --profile adminuser
Windows
aws application-autoscaling put-scheduled-action service-namespace dynamodb scalable-dimension dynamodb:table:WriteCapacityUnits resource-id table/my-table scheduled-action-name my-first-scheduled-action schedule "at(2019-05-20T17:05:00)" --scalable-target-action MinCapacity=15,MaxCapacity=20 --profile adminuser
This command does not return any output if it is successful.
2. To create the second scheduled action that Application Auto Scaling uses to scale in, use the following put-scheduled-action command.
Schedule the action to occur about 10 minutes from now.
At the date and time specified, Application Auto Scaling updates the table's MinCapacity and MaxCapacity, and scales in to MaxCapacity to return the table to the original desired range of 5-10 write capacity units.
Linux, macOS, or Unix
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/my-table \
--scheduled-action-name my-second-scheduled-action \ --schedule "at(2019-05-20T17:10:00)" \
--scalable-target-action MinCapacity=5,MaxCapacity=10 \ --profile adminuser
Windows
aws application-autoscaling put-scheduled-action service-namespace dynamodb scalable-dimension dynamodb:table:WriteCapacityUnits resource-id table/my-table --scheduled-action-name my-second-scheduled-action --schedule "at(2019-05-20T17:10:00)"
--scalable-target-action MinCapacity=5,MaxCapacity=10 --profile adminuser
3. (Optional) Get a list of scheduled actions for the specified service namespace using the following describe-scheduled-actions command.
Linux, macOS, or Unix
aws application-autoscaling describe-scheduled-actions \
Step 3: View the scaling activities
--service-namespace dynamodb \ --profile adminuser
Windows
aws application-autoscaling describe-scheduled-actions service-namespace dynamodb --profile adminuser
The following is example output.
{ "ScheduledActions": [ {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Schedule": "at(2019-05-20T18:35:00)",
"ResourceId": "table/my-table", "CreationTime": 1561571888.361,
"ScheduledActionARN":
"arn:aws:autoscaling:us-east-1:123456789012:scheduledAction:2d36aa3b-cdf9-4565-b290-81db519b227d:resource/
"ScheduledActionName": "my-first-scheduled-action", "ServiceNamespace": "dynamodb"
}, {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Schedule": "at(2019-05-20T18:40:00)",
"ResourceId": "table/my-table", "CreationTime": 1561571946.021,
"ScheduledActionARN":
"arn:aws:autoscaling:us-east-1:123456789012:scheduledAction:2d36aa3b-cdf9-4565-b290-81db519b227d:resource/
"ScheduledActionName": "my-second-scheduled-action", "ServiceNamespace": "dynamodb"
} ] }
Step 3: View the scaling activities
In this step, you view the scaling activities triggered by the scheduled actions, and then verify that DynamoDB changed the table's write capacity.
To view the scaling activities
1. Wait for the time you chose, and verify that your scheduled actions are working by using the following describe-scaling-activities command.
Linux, macOS, or Unix
aws application-autoscaling describe-scaling-activities \ --service-namespace dynamodb \
Step 3: View the scaling activities
--profile adminuser
Windows
aws application-autoscaling describe-scaling-activities service-namespace dynamodb --profile adminuser
The following is example output for the first scheduled action while the scheduled action is in progress.
Scaling activities are ordered by creation date, with the newest scaling activities returned first.
{ "ScalingActivities": [ {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Description": "Setting write capacity units to 15.", "ResourceId": "table/my-table",
"ActivityId": "d8ea4de6-9eaa-499f-b466-2cc5e681ba8b", "StartTime": 1561574108.904,
"ServiceNamespace": "dynamodb",
"Cause": "minimum capacity was set to 15",
"StatusMessage": "Successfully set write capacity units to 15. Waiting for change to be fulfilled by dynamodb.",
"StatusCode": "InProgress"
}, {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting min capacity to 15 and max capacity to 20", "ResourceId": "table/my-table",
"ActivityId": "3250fd06-6940-4e8e-bb1f-d494db7554d2", "StartTime": 1561574108.512,
"ServiceNamespace": "dynamodb",
"Cause": "scheduled action name my-first-scheduled-action was triggered", "StatusMessage": "Successfully set min capacity to 15 and max capacity to
The following is example output after both scheduled actions have run.
{
"ScalingActivities": [ {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Description": "Setting write capacity units to 10.", "ResourceId": "table/my-table",
"ActivityId": "4d1308c0-bbcf-4514-a673-b0220ae38547", "StartTime": 1561574415.086,
"ServiceNamespace": "dynamodb", "EndTime": 1561574449.51,
"Cause": "maximum capacity was set to 10",
"StatusMessage": "Successfully set write capacity units to 10. Change successfully fulfilled by dynamodb.",
"StatusCode": "Successful"
}, {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting min capacity to 5 and max capacity to 10",
Step 3: View the scaling activities
"ResourceId": "table/my-table",
"ActivityId": "f2b7847b-721d-4e01-8ef0-0c8d3bacc1c7", "StartTime": 1561574414.644,
"ServiceNamespace": "dynamodb",
"Cause": "scheduled action name my-second-scheduled-action was triggered", "StatusMessage": "Successfully set min capacity to 5 and max capacity to 10",
"StatusCode": "Successful"
}, {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits", "Description": "Setting write capacity units to 15.", "ResourceId": "table/my-table",
"ActivityId": "d8ea4de6-9eaa-499f-b466-2cc5e681ba8b", "StartTime": 1561574108.904,
"ServiceNamespace": "dynamodb", "EndTime": 1561574140.255,
"Cause": "minimum capacity was set to 15",
"StatusMessage": "Successfully set write capacity units to 15. Change successfully fulfilled by dynamodb.",
"StatusCode": "Successful"
}, {
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting min capacity to 15 and max capacity to 20", "ResourceId": "table/my-table",
"ActivityId": "3250fd06-6940-4e8e-bb1f-d494db7554d2", "StartTime": 1561574108.512,
"ServiceNamespace": "dynamodb",
"Cause": "scheduled action name my-first-scheduled-action was triggered", "StatusMessage": "Successfully set min capacity to 15 and max capacity to
2. After running the scheduled actions successfully, go to the DynamoDB console and choose the table that you want to work with. View the Write capacity units under the Capacity tab. After the second scaling action ran, the write capacity units should have been scaled from 15 to 10.
You can also view this information through the AWS CLI.
Verify the table's current write capacity by using the DynamoDB describe-table command. Include the --query option to filter the output. For more information about the output filtering capabilities of the AWS CLI, see Controlling command output from the AWS CLI in the AWS Command Line Interface User Guide.
Linux, macOS, or Unix
aws dynamodb describe-table --table-name my-table \
--query 'Table.[TableName,TableStatus,ProvisionedThroughput]' \ --profile adminuser
Windows
aws dynamodb describe-table --table-name my-table --query "Table.
[TableName,TableStatus,ProvisionedThroughput]" --profile adminuser
The following is example output.
Step 4: Next steps
[ "my-table", "ACTIVE", {
"NumberOfDecreasesToday": 1, "WriteCapacityUnits": 10,
"LastIncreaseDateTime": 1561574133.264, "ReadCapacityUnits": 5,
"LastDecreaseDateTime": 1561574435.607 }
]
Step 4: Next steps
Now that you have familiarized yourself with Application Auto Scaling and some of its features, consider doing the following:
• If you want to try scaling on a recurring schedule, see the tutorial in Tutorial: Configuring auto scaling to handle a heavy workload (p. 60).
• If you want to try scaling dynamically in response to changes in resource utilization (for example, by using the DynamoDBWriteCapacityUtilization metric), follow the steps in Target tracking scaling policies for Application Auto Scaling (p. 33).
Step 5: Clean up
When you are done working with the getting started exercises, you can clean up the associated resources as follows.
To delete the scheduled actions
The following delete-scheduled-action command deletes a specified scheduled action. You can skip this step if you want to keep the scheduled action for future use.
Linux, macOS, or Unix
aws application-autoscaling delete-scheduled-action \ --service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/my-table \
--scheduled-action-name my-second-scheduled-action \ --profile adminuser
Windows
aws application-autoscaling delete-scheduled-action service-namespace dynamodb scalable-dimension dynamodb:table:WriteCapacityUnits resource-id table/my-table --scheduled-action-name my-second-scheduled-action --profile adminuser
To deregister the scalable target
Use the following deregister-scalable-target command to deregister the scalable target. If you have any scaling policies that you created or any scheduled actions that have not yet been deleted, they are deleted by this command. You can skip this step if you want to keep the scalable target registered for future use.
Step 5: Clean up
Linux, macOS, or Unix
aws application-autoscaling deregister-scalable-target \ --service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/my-table \
--profile adminuser
Windows
aws application-autoscaling deregister-scalable-target service-namespace dynamodb --scalable-dimension dynamodb:table:WriteCapacityUnits --resource-id table/my-table --profile adminuser
To delete the DynamoDB table
Use the following delete-table command to delete the table that you used in this tutorial. You can skip this step if you want to keep the table for future use.
Linux, macOS, or Unix
aws dynamodb delete-table --table-name my-table \ --profile adminuser
Windows
aws dynamodb delete-table --table-name my-table --profile adminuser
Getting started with Application Auto Scaling
This topic explains key concepts to help you learn about Application Auto Scaling and start using it.
Scalable target
An entity that you create to specify the resource that you want to scale. Each scalable target is uniquely identified by a service namespace, resource ID, and scalable dimension, which represents some capacity dimension of the underlying service. For example, an Amazon ECS service supports auto scaling of its task count, a DynamoDB table supports auto scaling of the read and write capacity of the table and its global secondary indexes, and an Aurora cluster supports scaling of its replica count.
TipEach scalable target also has a minimum and maximum capacity. Scaling policies will never go higher or lower than the minimum-maximum range. You can make out-of-band changes directly to the underlying resource that are outside of this range, which Application Auto Scaling doesn't know about. However, anytime a scaling policy is invoked or the RegisterScalableTarget API is called, Application Auto Scaling retrieves the current capacity and compares it to the minimum and maximum capacity. If it falls outside of the minimum-maximum range, then the capacity is updated to comply with the set minimum and maximum.
Scale in
When Application Auto Scaling automatically decreases capacity for a scalable target, the scalable target scales in. The minimum capacity of the scalable target is the lowest capacity a scaling policy can scale in to.
Scale out
When Application Auto Scaling automatically increases capacity for a scalable target, the scalable target scales out. The maximum capacity of the scalable target is the highest capacity a scaling policy can scale out to.
Scaling policy
A scaling policy instructs Application Auto Scaling to track a specific CloudWatch metric. Then, it determines what scaling action to take when the metric is higher or lower than a certain threshold value. For example, you might want to scale out if the CPU usage across your cluster starts to rise, and scale in when it drops again.
The metrics that are used for auto scaling are published by the target service, but you can also publish your own metric to CloudWatch and then use it with a scaling policy.
A cooldown period between scaling activities lets the resource stabilize before another scaling activity starts. Application Auto Scaling continues to evaluate metrics during the cooldown period.
When the cooldown period ends, the scaling policy initiates another scaling activity if needed. While a cooldown period is in effect, if a larger scale out is necessary based on the current metric value, the scaling policy scales out immediately.
Scheduled action
Scheduled actions automatically scale resources at a specific date and time. They work by modifying the minimum and maximum capacity for a scalable target, and therefore can be used to scale in and
Learn more
out on a schedule by setting the minimum capacity high or the maximum capacity low. For example, you can use scheduled actions to scale an application that doesn't consume resources on weekends by decreasing capacity on Friday and increasing capacity on the following Monday.
You can also use scheduled actions to optimize the minimum and maximum values over time to adapt to situations where higher than normal traffic is expected, for example, marketing campaigns or seasonal fluctuations. Doing this can help you improve performance for times when you need to scale out higher for the increasing usage, and reduce costs at times when you use fewer resources.
Learn more
AWS services that you can use with Application Auto Scaling (p. 15) — This section introduces you to the services that you can scale and helps you set up auto scaling by registering a scalable target. It also describes each of the IAM service-linked roles that Application Auto Scaling creates to access resources in the target service.
Target tracking scaling policies for Application Auto Scaling (p. 33) — One of the primary features of Application Auto Scaling is target tracking scaling policies. Learn how target tracking policies automatically adjust desired capacity to keep utilization at a constant level based on your configured metric and target values. For example, you can configure target tracking to keep the average CPU utilization for your Spot Fleet at 50 percent. Application Auto Scaling then launches or terminates EC2 instances as required to keep the aggregated CPU utilization across all servers at 50 percent.
AWS services that you can use with Application Auto Scaling
Application Auto Scaling integrates with other AWS services so that you can add scaling capabilities to meet your application's demand. Auto scaling is an optional feature of the service that is disabled by default in almost all cases.
The following table lists the AWS services that you can use with Application Auto Scaling, including information about supported methods for configuring auto scaling. You can also use Application Auto Scaling with custom resources.
Console access – You can configure a compatible AWS service to start auto scaling by configuring a scaling policy in the console of the target service. Currently, only ElastiCache and Spot Fleet provide console support for scheduled scaling. If a service supports console access, see the Learn more link to learn how to configure auto scaling from that service's console.
CLI access – You can configure a compatible AWS service to start auto scaling using the AWS CLI.
SDK access – You can configure a compatible AWS service to start auto scaling using the AWS SDKs.
CloudFormation access – You can configure a compatible AWS service to start auto scaling using an AWS CloudFormation stack template. For more information, see Creating Application Auto Scaling resources with AWS CloudFormation (p. 108).
AWS service Console access CLI access SDK access CloudFormation access AppStream
2.0 (p. 16) Yes
Learn more
Yes Yes Yes
Aurora (p. 17) Yes Learn more
Yes Yes Yes
Amazon
Comprehend (p. 18) No Yes Yes Yes
Amazon
DynamoDB (p. 20) Yes Learn more
Yes Yes Yes
Amazon
ECS (p. 21) Yes
Learn more
Yes Yes Yes
Amazon
ElastiCache (p. 22) Yes Learn more
Yes Yes Yes
Amazon EMR Yes
Learn more
Yes Yes Yes
Amazon AppStream 2.0
AWS service Console access CLI access SDK access CloudFormation access Amazon
Keyspaces (p. 24) Yes Learn more
Yes Yes Yes
Lambda (p. 25) No Yes Yes Yes
Amazon
MSK (p. 26) Yes
Learn more
Yes Yes Yes
Amazon
Neptune (p. 27) No Yes Yes Yes
SageMaker (p. 28) Yes Learn more
Yes Yes Yes
Spot
Fleet (p. 30) Yes
Learn more
Yes Yes Yes
Custom
resources (p. 31) No Yes Yes Yes
Amazon AppStream 2.0 and Application Auto Scaling
You can scale AppStream 2.0 fleets using target tracking scaling policies, step scaling policies, and scheduled scaling.
Use the following information to help you integrate AppStream 2.0 with Application Auto Scaling.
If you are just getting started with scaling AppStream 2.0 fleets, you can view sample configurations and details about using AppStream 2.0 with Application Auto Scaling in the following documentation:
• Fleet Auto Scaling for AppStream 2.0 in the Amazon AppStream 2.0 Administration Guide
Service-linked role created for AppStream 2.0
The following service-linked role is automatically created in your AWS account when registering AppStream 2.0 resources as scalable targets with Application Auto Scaling. This role allows Application Auto Scaling to perform supported operations within your account. For more information, see Service-linked roles for Application Auto Scaling (p. 90).
• AWSServiceRoleForApplicationAutoScaling_AppStreamFleet
Service principal used by the service-linked role
The service-linked role in the previous section can be assumed only by the service principal authorized by the trust relationships defined for the role. The service-linked role used by Application Auto Scaling grants access to the following service principal:
Registering AppStream 2.0 fleets as scalable targets with Application Auto Scaling
• appstream.application-autoscaling.amazonaws.com
Registering AppStream 2.0 fleets as scalable targets with Application Auto Scaling
Application Auto Scaling requires a scalable target before you can create scaling policies or scheduled
Application Auto Scaling requires a scalable target before you can create scaling policies or scheduled