# Step scaling policies for Application Auto Scaling
A step scaling policy scales your application's capacity in predefined increments based on CloudWatch alarms. You can define separate scaling policies to handle scaling out (increasing capacity) and scaling in (decreasing capacity) when an alarm threshold is breached.
With step scaling policies, you create and manage the CloudWatch alarms that invoke the scaling process. When an alarm is breached, Application Auto Scaling initiates the scaling policy associated with that alarm.
The step scaling policy scales capacity using a set of adjustments, known as *step adjustments*. The size of the adjustment varies based on the magnitude of the alarm breach.
+ If the breach exceeds the first threshold, Application Auto Scaling will apply the first step adjustment.
+ If the breach exceeds the second threshold, Application Auto Scaling will apply the second step adjustment, and so on.
This allows the scaling policy to respond appropriately to both minor and major changes in the alarm metric.
The policy will continue to respond to additional alarm breaches, even while a scaling activity is in progress. This means Application Auto Scaling will evaluate all alarm breaches as they occur. A cooldown period is used to protect against over-scaling due to multiple alarm breaches occurring in rapid succession.
Like target tracking, step scaling can help automatically scale your application's capacity as traffic changes occur. However, target tracking policies tend to be easier to implement and manage for steady scaling needs.
**Supported scalable targets**
You can use step scaling policies with the following scalable targets:
+ WorkSpaces Applications fleets
+ Aurora DB clusters
+ ECS services
+ EMR clusters
+ SageMaker AI endpoint variants
+ SageMaker AI inference components
+ SageMaker AI Serverless provisioned concurrency
+ Spot Fleets
+ Custom resources
**Topics**
+ [How step scaling works](step-scaling-policy-overview.md)
+ [Create a step scaling policy](create-step-scaling-policy-cli.md)
+ [Describe step scaling policies](describe-step-scaling-policy.md)
+ [Delete a step scaling policy](delete-step-scaling-policy.md)
# How step scaling for Application Auto Scaling works
This topic describes how step scaling works and introduces the key elements of a step scaling policy.
**Topics**
+ [How it works](#step-scaling-how-it-works)
+ [Step adjustments](#as-scaling-steps)
+ [Scaling adjustment types](#as-scaling-adjustment)
+ [Cooldown period](#step-scaling-cooldown)
+ [Commonly used commands](#step-scaling-policy-commonly-used-commands)
+ [Considerations](#step-scaling-considerations)
+ [Related resources](#step-scaling-related-resources)
+ [Console access](#step-scaling-console-access)
## How it works
To use step scaling, you create a CloudWatch alarm that monitors a metric for your scalable target. Define the metric, threshold value, and number of evaluation periods that determine an alarm breach. You also create a step scaling policy that defines how to scale capacity when the alarm threshold is breached and associate it with your scalable target.
Add the step adjustments in the policy. You can define different step adjustments based on the breach size of the alarm. For example:
+ Scale out by 10 capacity units if the alarm metric reaches 60 percent
+ Scale out by 30 capacity units if the alarm metric reaches 75 percent
+ Scale out by 40 capacity units if the alarm metric reaches 85 percent
When the alarm threshold is breached for the specified number of evaluation periods, Application Auto Scaling will apply the step adjustments defined in the policy. The adjustments can continue for additional alarm breaches until the alarm state returns to `OK`.
Scaling activities are performed with cooldown periods between them to prevent rapid fluctuations in capacity. You can optionally configure the cooldown periods for your scaling policy.
## Step adjustments
When you create a step scaling policy, you specify one or more step adjustments that automatically scale the capacity of the target dynamically based on the size of the alarm breach. Each step adjustment specifies the following:
+ A lower bound for the metric value
+ An upper bound for the metric value
+ The amount by which to scale, based on the scaling adjustment type
CloudWatch aggregates metric data points based on the statistic for the metric associated with your CloudWatch alarm. When the alarm is breached, the appropriate scaling policy is invoked. Application Auto Scaling applies your specified aggregation type to the most recent metric data points from CloudWatch (as opposed to the raw metric data). It compares this aggregated metric value against the upper and lower bounds defined by the step adjustments to determine which step adjustment to perform.
You specify the upper and lower bounds relative to the breach threshold. For example, let's say you made a CloudWatch alarm and a scale-out policy for when the metric is above 50 percent. You then made a second alarm and a scale-in policy for when the metric is below 50 percent. You made a set of step adjustments with an adjustment type of `PercentChangeInCapacity` for each policy:
**Example: Step adjustments for scale-out policy**
| **Lower bound** | **Upper bound** | **Adjustment** |
| --- | --- | --- |
| 0 | 10 | 0 |
| 10 | 20 | 10 |
| 20 | null | 30 |
**Example: Step adjustments for scale-in policy**
| **Lower bound** | **Upper bound** | **Adjustment** |
| --- | --- | --- |
| -10 | 0 | 0 |
| -20 | -10 | -10 |
| null | -20 | -30 |
This creates the following scaling configuration.
```
Metric value
-infinity 30% 40% 60% 70% infinity
-----------------------------------------------------------------------
-30% | -10% | Unchanged | +10% | +30%
-----------------------------------------------------------------------
```
Now, let's say that you use this scaling configuration on a scalable target that has a capacity of 10. The following points summarize the behavior of the scaling configuration in relation to the capacity of the scalable target:
+ The original capacity is maintained while the aggregated metric value is greater than 40 and less than 60.
+ If the metric value gets to 60, Application Auto Scaling increases the capacity of the scalable target by 1, to 11. That's based on the second step adjustment of the scale-out policy (add 10 percent of 10). After the new capacity is added, Application Auto Scaling increases the current capacity to 11. If the metric value rises to 70 even after this increase in capacity, Application Auto Scaling increases the target capacity by 3, to 14. That's based on the third step adjustment of the scale-out policy (add 30 percent of 11, 3.3, rounded down to 3).
+ If the metric value gets to 40, Application Auto Scaling decreases the capacity of the scalable target by 1, to 13, based on the second step adjustment of the scale-in policy (remove 10 percent of 14, 1.4, rounded down to 1). If the metric value falls to 30 even after this decrease in capacity, Application Auto Scaling decreases the target capacity by 3, to 10, based on the third step adjustment of the scale-in policy (remove 30 percent of 13, 3.9, rounded down to 3).
When you specify the step adjustments for your scaling policy, note the following:
+ The ranges of your step adjustments can't overlap or have a gap.
+ Only one step adjustment can have a null lower bound (negative infinity). If one step adjustment has a negative lower bound, then there must be a step adjustment with a null lower bound.
+ Only one step adjustment can have a null upper bound (positive infinity). If one step adjustment has a positive upper bound, then there must be a step adjustment with a null upper bound.
+ The upper and lower bound can't be null in the same step adjustment.
+ If the metric value is above the breach threshold, the lower bound is inclusive and the upper bound is exclusive. If the metric value is below the breach threshold, the lower bound is exclusive and the upper bound is inclusive.
## Scaling adjustment types
You can define a scaling policy that performs the optimal scaling action, based on the scaling adjustment type that you choose. You can specify the adjustment type as a percentage of the current capacity of your scalable target or in absolute numbers.
Application Auto Scaling supports the following adjustment types for step scaling policies:
+ **ChangeInCapacity**—Increase or decrease the current capacity of the scalable target by the specified value. A positive value increases the capacity and a negative value decreases the capacity. For example: If the current capacity is 3 and the adjustment is 5, then Application Auto Scaling adds 5 to the capacity for a total of 8.
+ **ExactCapacity**—Change the current capacity of the scalable target to the specified value. Specify a non-negative value with this adjustment type. For example: If the current capacity is 3 and the adjustment is 5, then Application Auto Scaling changes the capacity to 5.
+ **PercentChangeInCapacity**—Increase or decrease the current capacity of the scalable target by the specified percentage. A positive value increases the capacity and a negative value decreases the capacity. For example: If the current capacity is 10 and the adjustment is 10 percent, then Application Auto Scaling adds 1 to the capacity for a total of 11.
If the resulting value is not an integer, Application Auto Scaling rounds it as follows:
+ Values greater than 1 are rounded down. For example, `12.7` is rounded to `12`.
+ Values between 0 and 1 are rounded to 1. For example, `.67` is rounded to `1`.
+ Values between 0 and -1 are rounded to -1. For example, `-.58` is rounded to `-1`.
+ Values less than -1 are rounded up. For example, `-6.67` is rounded to `-6`.
With **PercentChangeInCapacity**, you can also specify the minimum amount to scale using the `MinAdjustmentMagnitude` parameter. For example, suppose that you create a policy that adds 25 percent and you specify a minimum amount of 2. If the scalable target has a capacity of 4 and the scaling policy is performed, 25 percent of 4 is 1. However, because you specified a minimum increment of 2, Application Auto Scaling adds 2.
## Cooldown period
You can optionally define a cooldown period in your step scaling policy.
A cooldown period specifies the amount of time the scaling policy waits for a previous scaling activity to take effect.
There are two ways to plan for the use of cooldown periods for a step scaling configuration:
+ With the cooldown period for scale-out policies, the intention is to continuously (but not excessively) scale out. After Application Auto Scaling successfully scales out using a scaling policy, it starts to calculate the cooldown time. A scaling policy won‘t increase the desired capacity again unless either a larger scale out is triggered or the cooldown period ends. While the scale-out cooldown period is in effect, the capacity added by the initiating scale-out activity is calculated as part of the desired capacity for the next scale-out activity.
+ With the cooldown period for scale-in policies, the intention is to scale in conservatively to protect your application‘s availability, so scale-in activities are blocked until the scale-in cooldown period has expired. However, if another alarm triggers a scale-out activity during the scale-in cooldown period, Application Auto Scaling scales out the target immediately. In this case, the scale-in cooldown period stops and doesn‘t complete.
For example, when a traffic peak occurs, an alarm is triggered and Application Auto Scaling automatically adds capacity to help handle the increased load. If you set a cooldown period for your scale-out policy, when the alarm triggers the policy to increase the capacity by 2, the scaling activity completes successfully, and the scale-out cooldown period starts. If an 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. This allows faster scaling than waiting for the cooldown to expire but without adding more capacity than you need.
The cooldown period is measured in seconds and applies only to scaling policy-related scaling activities. During a cooldown period, when a scheduled action starts at the scheduled time, it can trigger a scaling activity immediately without waiting for the cooldown period to expire.
The default value is 300 if no value is specified.
## Commonly used commands for scaling policy creation, management, and deletion
The commonly used commands for working with scaling policies include:
+ [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) to register AWS or custom resources as scalable targets (a resource that Application Auto Scaling can scale), and to suspend and resume scaling.
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) to add or modify scaling policies for an existing scalable target.
+ [describe-scaling-activities](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scaling-activities.html) to return information about scaling activities in an AWS Region.
+ [describe-scaling-policies](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scaling-policies.html) to return information about scaling policies in an AWS Region.
+ [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) to delete a scaling-policy.
## Considerations
The following considerations apply when working with step scaling policies:
+ Consider whether you can predict the step adjustments on the application accurately enough to use step scaling. If your scaling metric increases or decreases proportionally to the capacity of the scalable target, we recommend that you use a target tracking scaling policy instead. You still have the option to use step scaling as an additional policy for a more advanced configuration. For example, you can configure a more aggressive response when utilization reaches a certain level.
+ Make sure to choose an adequate margin between the scale-out and scale-in thresholds to prevent flapping. Flapping is an infinite loop of scaling in and scaling out. That is, if a scaling action is taken, the metric value would change and start another scaling action in the reverse direction.
## Related resources
For information about creating step scaling policies for Auto Scaling groups, see [Step and simple scaling policies for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) in the *Amazon EC2 Auto Scaling User Guide*.
## Console access
Console access to view, add, update, or remove step scaling policies on scalable resources depends on the resource that you use. For more information, see [AWS services that you can use with Application Auto Scaling](integrated-services-list.md).
# Create a step scaling policy for Application Auto Scaling using the AWS CLI
This example uses AWS CLI commands to create a step scaling policy for an Amazon ECS service. For a different scalable target, specify its namespace in `--service-namespace`, its scalable dimension in `--scalable-dimension`, and its resource ID in `--resource-id`.
When using the AWS CLI, remember that your commands run in the AWS Region configured for your profile. If you want to run the commands in a different Region, either change the default Region for your profile, or use the `--region` parameter with the command.
**Topics**
+ [Step 1: Register a scalable target](#step-scaling-register-scalable-target)
+ [Step 2: Create a step scaling policy](#create-step-scaling-policy)
+ [Step 3: Create an alarm that invokes a scaling policy](#step-scaling-create-alarm)
## Step 1: Register a scalable target
If you haven't already done so, register the scalable target. Use the [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) command to register a specific resource in the target service as a scalable target. The following example registers an Amazon ECS service with Application Auto Scaling. Application Auto Scaling can scale the number of tasks at a minimum of 2 tasks and a maximum of 10. Replace each *user input placeholder* with your own information.
**Linux, macOS, or Unix**
```
aws application-autoscaling register-scalable-target --service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/my-cluster/my-service \
--min-capacity 2 --max-capacity 10
```
**Windows**
```
aws application-autoscaling register-scalable-target --service-namespace ecs ^
--scalable-dimension ecs:service:DesiredCount ^
--resource-id service/my-cluster/my-service ^
--min-capacity 2 --max-capacity 10
```
**Output**
If successful, this command returns the ARN of the scalable target. The following is example output.
```
{
"ScalableTargetARN": "arn:aws:application-autoscaling:region:account-id:scalable-target/1234abcd56ab78cd901ef1234567890ab123"
}
```
## Step 2: Create a step scaling policy
To create a step scaling policy for your scalable target, you can use the following examples to help you get started.
------
#### [ Scale out ]
**To create a step scaling policy for scale out (increase capacity)**
1. Use the following `cat` command to store a step scaling policy configuration in a JSON file named `config.json` in your home directory. The following is an example configuration with an adjustment type of `PercentChangeInCapacity` that increases the capacity of the scalable target based on the following step adjustments (assuming a CloudWatch alarm threshold of 70):
+ Increase capacity by 10 percent when the value of the metric is greater than or equal to 70 but less than 85
+ Increase capacity by 20 percent when the value of the metric is greater than or equal to 85 but less than 95
+ Increase capacity by 30 percent when the value of the metric is greater than or equal to 95
```
$ cat ~/config.json
{
"AdjustmentType": "PercentChangeInCapacity",
"MetricAggregationType": "Average",
"Cooldown": 60,
"MinAdjustmentMagnitude": 1,
"StepAdjustments": [
{
"MetricIntervalLowerBound": 0.0,
"MetricIntervalUpperBound": 15.0,
"ScalingAdjustment": 10
},
{
"MetricIntervalLowerBound": 15.0,
"MetricIntervalUpperBound": 25.0,
"ScalingAdjustment": 20
},
{
"MetricIntervalLowerBound": 25.0,
"ScalingAdjustment": 30
}
]
}
```
For more information, see [StepScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_StepScalingPolicyConfiguration.html) in the *Application Auto Scaling API Reference*.
1. Use the following [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) command, along with the `config.json` file that you created, to create a scaling policy named `my-step-scaling-policy`.
**Linux, macOS, or Unix**
```
aws application-autoscaling put-scaling-policy --service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/my-cluster/my-service \
--policy-name my-step-scaling-policy --policy-type StepScaling \
--step-scaling-policy-configuration file://config.json
```
**Windows**
```
aws application-autoscaling put-scaling-policy --service-namespace ecs ^
--scalable-dimension ecs:service:DesiredCount ^
--resource-id service/my-cluster/my-service ^
--policy-name my-step-scaling-policy --policy-type StepScaling ^
--step-scaling-policy-configuration file://config.json
```
**Output**
The output includes the ARN that serves as a unique name for the policy. You need it to create a CloudWatch alarm for your policy. The following is example output.
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:ac542982-cbeb-4294-891c-a5a941dfa787:resource/ecs/service/my-cluster/my-service:policyName/my-step-scaling-policy"
}
```
------
#### [ Scale in ]
**To create a step scaling policy for scale in (decrease capacity)**
1. Use the following `cat` command to store a step scaling policy configuration in a JSON file named `config.json` in your home directory. The following is an example configuration with an adjustment type of `ChangeInCapacity` that decreases the capacity of the scalable target based on the following step adjustments (assuming a CloudWatch alarm threshold of 50):
+ Decrease capacity by 1 when the value of the metric is less than or equal to 50 but greater than 40
+ Decrease capacity by 2 when the value of the metric is less than or equal to 40 but greater than 30
+ Decrease capacity by 3 when the value of the metric is less than or equal to 30
```
$ cat ~/config.json
{
"AdjustmentType": "ChangeInCapacity",
"MetricAggregationType": "Average",
"Cooldown": 60,
"StepAdjustments": [
{
"MetricIntervalUpperBound": 0.0,
"MetricIntervalLowerBound": -10.0,
"ScalingAdjustment": -1
},
{
"MetricIntervalUpperBound": -10.0,
"MetricIntervalLowerBound": -20.0,
"ScalingAdjustment": -2
},
{
"MetricIntervalUpperBound": -20.0,
"ScalingAdjustment": -3
}
]
}
```
For more information, see [StepScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_StepScalingPolicyConfiguration.html) in the *Application Auto Scaling API Reference*.
1. Use the following [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) command, along with the `config.json` file that you created, to create a scaling policy named `my-step-scaling-policy`.
**Linux, macOS, or Unix**
```
aws application-autoscaling put-scaling-policy --service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/my-cluster/my-service \
--policy-name my-step-scaling-policy --policy-type StepScaling \
--step-scaling-policy-configuration file://config.json
```
**Windows**
```
aws application-autoscaling put-scaling-policy --service-namespace ecs ^
--scalable-dimension ecs:service:DesiredCount ^
--resource-id service/my-cluster/my-service ^
--policy-name my-step-scaling-policy --policy-type StepScaling ^
--step-scaling-policy-configuration file://config.json
```
**Output**
The output includes the ARN that serves as a unique name for the policy. You need this ARN to create a CloudWatch alarm for your policy. The following is example output.
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:ac542982-cbeb-4294-891c-a5a941dfa787:resource/ecs/service/my-cluster/my-service:policyName/my-step-scaling-policy"
}
```
------
## Step 3: Create an alarm that invokes a scaling policy
Finally, use the following CloudWatch [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) command to create an alarm to use with your step scaling policy. In this example, you have an alarm based on average CPU utilization. The alarm is configured to be in an ALARM state if it reaches a threshold of 70 percent for at least two consecutive evaluation periods of 60 seconds. To specify a different CloudWatch metric or use your own custom metric, specify its name in `--metric-name` and its namespace in `--namespace`.
**Linux, macOS, or Unix**
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service \
--metric-name CPUUtilization --namespace AWS/ECS --statistic Average \
--period 60 --evaluation-periods 2 --threshold 70 \
--comparison-operator GreaterThanOrEqualToThreshold \
--dimensions Name=ClusterName,Value=default Name=ServiceName,Value=sample-app-service \
--alarm-actions PolicyARN
```
**Windows**
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service ^
--metric-name CPUUtilization --namespace AWS/ECS --statistic Average ^
--period 60 --evaluation-periods 2 --threshold 70 ^
--comparison-operator GreaterThanOrEqualToThreshold ^
--dimensions Name=ClusterName,Value=default Name=ServiceName,Value=sample-app-service ^
--alarm-actions PolicyARN
```
# Describe step scaling policies for Application Auto Scaling using the AWS CLI
You can describe all scaling policies for a service namespace using the [describe-scaling-policies](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scaling-policies.html) command. The following example describes all scaling policies for all Amazon ECS services. To list them for a specific Amazon ECS service only add the `--resource-id` option.
```
aws application-autoscaling describe-scaling-policies --service-namespace ecs
```
You can filter the results to just the step scaling policies using the `--query` parameter. For more information about the syntax for `query`, see [Controlling command output from the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-output.html) in the *AWS Command Line Interface User Guide*.
**Linux, macOS, or Unix**
```
aws application-autoscaling describe-scaling-policies --service-namespace ecs \
--query 'ScalingPolicies[?PolicyType==`StepScaling`]'
```
**Windows**
```
aws application-autoscaling describe-scaling-policies --service-namespace ecs ^
--query "ScalingPolicies[?PolicyType==`StepScaling`]"
```
**Output**
The following is example output.
```
[
{
"PolicyARN": "PolicyARN",
"StepScalingPolicyConfiguration": {
"MetricAggregationType": "Average",
"Cooldown": 60,
"StepAdjustments": [
{
"MetricIntervalLowerBound": 0.0,
"MetricIntervalUpperBound": 15.0,
"ScalingAdjustment": 1
},
{
"MetricIntervalLowerBound": 15.0,
"MetricIntervalUpperBound": 25.0,
"ScalingAdjustment": 2
},
{
"MetricIntervalLowerBound": 25.0,
"ScalingAdjustment": 3
}
],
"AdjustmentType": "ChangeInCapacity"
},
"PolicyType": "StepScaling",
"ResourceId": "service/my-cluster/my-service",
"ServiceNamespace": "ecs",
"Alarms": [
{
"AlarmName": "Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service",
"AlarmARN": "arn:aws:cloudwatch:region:012345678910:alarm:Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service"
}
],
"PolicyName": "my-step-scaling-policy",
"ScalableDimension": "ecs:service:DesiredCount",
"CreationTime": 1515024099.901
}
]
```
# Delete a step scaling policy for Application Auto Scaling using the AWS CLI
When you no longer need a step scaling policy, you can delete it. To delete both the scaling policy and the associated CloudWatch alarm, complete the following tasks.
**To delete your scaling policy**
Use the [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) command.
**Linux, macOS, or Unix**
```
aws application-autoscaling delete-scaling-policy --service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/my-cluster/my-service \
--policy-name my-step-scaling-policy
```
**Windows**
```
aws application-autoscaling delete-scaling-policy --service-namespace ecs ^
--scalable-dimension ecs:service:DesiredCount ^
--resource-id service/my-cluster/my-service ^
--policy-name my-step-scaling-policy
```
**To delete the CloudWatch alarm**
Use the [delete-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/delete-alarms.html) command. You can delete one or more alarms at a time. For example, use the following command to delete the `Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service` and `Step-Scaling-AlarmLow-ECS:service/my-cluster/my-service` alarms.
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-ECS:service/my-cluster/my-service Step-Scaling-AlarmLow-ECS:service/my-cluster/my-service
```