Scaling policies (target tracking, step, simple) in AWS - Commands & Configuration

Introduction

Scaling policies help your cloud servers adjust automatically to changes in demand. They make sure your app has enough power when many people use it and save money when fewer people use it.

When your website traffic changes a lot during the day and you want to add or remove servers automatically.

When you want to keep your app fast by adding servers if CPU usage goes above a certain level.

When you want to reduce costs by removing servers when they are not needed.

When you want to keep a specific performance level, like a target CPU usage, without manual checks.

When you want to react in steps, adding or removing a fixed number of servers based on load changes.

Config File - scaling-policy.json

scaling-policy.json

{
  "AutoScalingGroupName": "example-asg",
  "PolicyName": "cpu-target-tracking-policy",
  "PolicyType": "TargetTrackingScaling",
  "TargetTrackingConfiguration": {
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0,
    "DisableScaleIn": false
  }
}

This JSON file defines a target tracking scaling policy for an Auto Scaling group named example-asg. It keeps the average CPU usage at 50%. The policy automatically adds or removes servers to maintain this target.

Commands

This command creates or updates the target tracking scaling policy using the JSON file. It tells AWS how to adjust the number of servers based on CPU usage.

Terminal

aws autoscaling put-scaling-policy --cli-input-json file://scaling-policy.json

Expected Output

{"PolicyARN": "arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:abcdef12-3456-7890-abcd-ef1234567890:autoScalingGroupName/example-asg:policyName/cpu-target-tracking-policy"}

→

--cli-input-json - Specifies the JSON file with the scaling policy details

This command shows the scaling policies attached to the Auto Scaling group to verify the policy was created.

Terminal

aws autoscaling describe-policies --auto-scaling-group-name example-asg

Expected Output

{

    "ScalingPolicies": [

        {

            "AutoScalingGroupName": "example-asg",

            "PolicyName": "cpu-target-tracking-policy",

            "PolicyType": "TargetTrackingScaling",

            "TargetTrackingConfiguration": {

                "PredefinedMetricSpecification": {

                    "PredefinedMetricType": "ASGAverageCPUUtilization"

                },

                "TargetValue": 50.0,

                "DisableScaleIn": false

            }

        }

    ]

}

This command creates a step scaling policy that adds 2 servers when the metric goes above the lower bound (0). It reacts in steps to changes in load.

Terminal

aws autoscaling put-scaling-policy --auto-scaling-group-name example-asg --policy-name step-scale-out --policy-type StepScaling --adjustment-type ChangeInCapacity --step-adjustments MetricIntervalLowerBound=0,ScalingAdjustment=2

Expected Output

{"PolicyARN": "arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:1234abcd-5678-ef90-ab12-34567890cdef:autoScalingGroupName/example-asg:policyName/step-scale-out"}

→

--policy-type - Specifies the policy is step scaling

→

--adjustment-type - Defines how the scaling adjustment is interpreted

→

--step-adjustments - Defines the step change in capacity based on metric intervals

This command creates a simple scaling policy that removes 1 server when triggered. The cooldown period prevents rapid repeated scaling.

Terminal

aws autoscaling put-scaling-policy --auto-scaling-group-name example-asg --policy-name simple-scale-in --policy-type SimpleScaling --adjustment-type ChangeInCapacity --scaling-adjustment -1 --cooldown 300

Expected Output

{"PolicyARN": "arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:abcd1234-5678-90ef-ab12-34567890cdef:autoScalingGroupName/example-asg:policyName/simple-scale-in"}

→

--cooldown - Sets wait time before another scaling action can happen

Key Concept

If you remember nothing else from this pattern, remember: scaling policies automatically adjust your servers to keep your app fast and cost-effective without manual work.

Common Mistakes

Using incorrect JSON syntax in the scaling policy file

AWS CLI will fail to create the policy and show an error

Validate JSON syntax before running the command and use proper quotes and commas

Not specifying the Auto Scaling group name correctly

The policy will not attach to the right group and won't work

Double-check the Auto Scaling group name matches exactly the existing group

Setting scaling adjustments too high or too low without testing

Can cause too many or too few servers, leading to cost waste or poor performance

Start with small adjustments and monitor behavior before increasing

Summary

Create scaling policies using JSON files or CLI flags to automate server adjustments.

Use target tracking to keep a metric like CPU usage at a set value automatically.

Use step scaling to add or remove servers in fixed steps based on metric thresholds.

Use simple scaling for basic add or remove actions with cooldown periods to avoid rapid changes.

Verify policies with describe commands to ensure they are attached and configured correctly.

Practice

1. What is the main purpose of a target tracking scaling policy in AWS Auto Scaling?

easy

A. To automatically adjust resources to keep a metric close to a target value

B. To manually increase or decrease resources based on user input

C. To schedule scaling actions at fixed times regardless of load

D. To disable scaling during peak hours

Solution

1. Step 1: Understand target tracking policy function

   Target tracking automatically adjusts resources to keep a metric (like CPU usage) near a set target value.

2. Step 2: Compare with other options

   Manual scaling and scheduled scaling do not automatically adjust based on metrics, and disabling scaling is unrelated.

3. Final Answer:

   To automatically adjust resources to keep a metric close to a target value -> Option A

4. Quick Check:

   Target tracking = automatic metric-based scaling [OK]

Hint: Target tracking = auto adjust to keep metric near target [OK]

Common Mistakes:

• Confusing target tracking with manual scaling
• Thinking scheduled scaling is target tracking
• Assuming target tracking disables scaling

2. Which of the following is the correct JSON snippet to define a simple scaling policy in AWS Auto Scaling?

easy

A. {"PolicyName": "ScaleOut", "PolicyType": "TargetTrackingScaling", "TargetValue": 50}

B. {"PolicyName": "ScaleOut", "PolicyType": "StepScaling", "StepAdjustments": [{"MetricIntervalLowerBound": 0, "ScalingAdjustment": 1}]}

C. {"PolicyName": "ScaleOut", "PolicyType": "SimpleScaling", "AdjustmentType": "ChangeInCapacity", "ScalingAdjustment": 2}

D. {"PolicyName": "ScaleOut", "PolicyType": "ScheduledScaling", "Schedule": "cron(0 12 * * ? *)"}

Solution

1. Step 1: Identify simple scaling policy syntax

   Simple scaling uses PolicyType "SimpleScaling" with AdjustmentType and ScalingAdjustment fields.

2. Step 2: Verify JSON options

   {"PolicyName": "ScaleOut", "PolicyType": "SimpleScaling", "AdjustmentType": "ChangeInCapacity", "ScalingAdjustment": 2} matches simple scaling syntax; others are for target tracking, step scaling, or scheduled scaling.

3. Final Answer:

   {"PolicyName": "ScaleOut", "PolicyType": "SimpleScaling", "AdjustmentType": "ChangeInCapacity", "ScalingAdjustment": 2} -> Option C

4. Quick Check:

   Simple scaling = PolicyType "SimpleScaling" [OK]

Hint: Simple scaling uses PolicyType "SimpleScaling" with adjustment fields [OK]

Common Mistakes:

• Using TargetTrackingScaling type for simple scaling
• Confusing step scaling syntax with simple scaling
• Including schedule fields in simple scaling

3. Given this step scaling policy snippet:

{
  "PolicyType": "StepScaling",
  "StepAdjustments": [
    {"MetricIntervalLowerBound": 0, "ScalingAdjustment": 1},
    {"MetricIntervalLowerBound": 10, "ScalingAdjustment": 2}
  ]
}

If the metric increases by 12 units, how many instances will be added?

medium

A. 0

B. 1

C. 3

D. 2

Solution

1. Step 1: Understand step adjustments

   Each step defines scaling for metric intervals. For metric increase of 12, check which intervals apply.

2. Step 2: Find matching step

   12 is >=10, so the second step applies with ScalingAdjustment 2.

3. Final Answer:

   2 -> Option D

4. Quick Check:

   Metric 12 >= 10 -> add 2 instances [OK]

Hint: Metric value matches highest lower bound step [OK]

Common Mistakes:

• Adding adjustments from both steps
• Choosing the first step only
• Ignoring metric intervals

4. You configured a step scaling policy but it never triggers scaling actions even when the metric crosses thresholds. What is the most likely cause?

medium

A. The scaling adjustment values are negative

B. The metric alarms are not properly linked to the scaling policy

C. The target tracking policy is overriding the step scaling policy

D. The Auto Scaling group has no instances

Solution

1. Step 1: Check alarm linkage

   Step scaling policies rely on CloudWatch alarms to trigger. If alarms are not linked, no scaling occurs.

2. Step 2: Evaluate other options

   Target tracking does not override step scaling; negative adjustments cause scale-in, not no action; no instances means no scaling needed.

3. Final Answer:

   The metric alarms are not properly linked to the scaling policy -> Option B

4. Quick Check:

   Missing alarm linkage = no scaling trigger [OK]

Hint: Step scaling needs alarms linked to trigger [OK]

Common Mistakes:

• Assuming target tracking disables step scaling
• Ignoring alarm configuration
• Confusing negative adjustment with no scaling

5. You want to keep your application's CPU usage at 50% using AWS Auto Scaling. You also want to add 2 instances if CPU usage goes above 70%, and remove 1 instance if it drops below 30%. Which combination of scaling policies should you use?

hard

A. Use a target tracking policy for 50% CPU and step scaling for adding/removing instances at 70% and 30%

B. Use only a simple scaling policy with fixed adjustments

C. Use only a target tracking policy with target 50%

D. Use scheduled scaling to add and remove instances at fixed times

Solution

1. Step 1: Understand target tracking role

   Target tracking keeps CPU near 50% automatically adjusting capacity.

2. Step 2: Understand step scaling role

   Step scaling defines specific actions when CPU crosses 70% (add 2) or 30% (remove 1).

3. Step 3: Combine policies

   Use target tracking for steady state and step scaling for aggressive changes beyond thresholds.

4. Final Answer:

   Use a target tracking policy for 50% CPU and step scaling for adding/removing instances at 70% and 30% -> Option A

5. Quick Check:

   Target tracking + step scaling = precise control [OK]

Hint: Combine target tracking for steady and step scaling for thresholds [OK]

Common Mistakes:

• Using only one policy type for all needs
• Confusing scheduled scaling with metric-based scaling
• Ignoring removal scaling actions