cooldown property
The amount of time, in seconds, to wait for a previous scaling activity to take effect.
With scale-out policies, the intention is to continuously (but not excessively) scale out. After Application Auto Scaling successfully scales out using a step scaling policy, it starts to calculate the cooldown time. The scaling policy won't increase the desired capacity again unless either a larger scale out is triggered or the cooldown period ends. While the cooldown period is in effect, capacity added by the initiating scale-out activity is calculated as part of the desired capacity for the next scale-out activity. For example, when an alarm triggers a step scaling policy to increase the capacity by 2, the scaling activity completes successfully, and a cooldown period starts. If the alarm triggers again during the cooldown period but at a more aggressive step adjustment of 3, the previous increase of 2 is considered part of the current capacity. Therefore, only 1 is added to the capacity.
With scale-in policies, the intention is to scale in conservatively to protect your application’s availability, so scale-in activities are blocked until the cooldown period has expired. However, if another alarm triggers a scale-out activity during the cooldown period after a scale-in activity, Application Auto Scaling scales out the target immediately. In this case, the cooldown period for the scale-in activity stops and doesn't complete.
Application Auto Scaling provides a default value of 300 for the following scalable targets:
- ECS services
- Spot Fleet requests
- EMR clusters
- AppStream 2.0 fleets
- Aurora DB clusters
- Amazon SageMaker endpoint variants
- Custom resources
- DynamoDB tables
- DynamoDB global secondary indexes
- Amazon Comprehend document classification and entity recognizer endpoints
- Lambda provisioned concurrency
- Amazon Keyspaces tables
- Amazon MSK cluster storage
Implementation
final int? cooldown;