Auto Scaling Policies

A Complete Guide to Dynamic Scaling for AWS Auto Scaling Groups

What are Auto Scaling Policies?

Auto Scaling policies are rules that define how an Auto Scaling group should automatically adjust its capacity based on changing conditions. These policies enable your applications to scale in and out dynamically, ensuring optimal performance and cost efficiency by maintaining just the right number of EC2 instances needed to handle the current workload.

Key Characteristics

Automatically adjust capacity based on metrics
Respond to changing application demands
Optimize for performance and cost
Support multiple policy types for different scenarios
Integrate with CloudWatch for monitoring
Provide predictable scaling behavior

Types of Auto Scaling Policies

Policy Types Overview

Policy Type	Description	Best For
Target Tracking	Maintains a specific metric value	Predictable workloads
Step Scaling	Scales based on alarm thresholds	Variable workloads
Simple Scaling	Basic alarm-based scaling	Legacy applications
Scheduled Scaling	Scales at specific times	Predictable time patterns
Predictive Scaling	Scales based on forecasts	Recurring traffic patterns

Auto Scaling Policy Components

Metrics

CPU Utilization
Network In/Out
Request Count Per Target
Average Latency
Custom CloudWatch Metrics
SQS Queue Length
Memory Utilization (custom)

Thresholds & Targets

Target values (e.g., 70% CPU)
Alarm thresholds
Breach duration
Evaluation periods
Statistic types (Average, Sum, etc.)
Comparison operators
Metric math expressions

Scaling Actions

Capacity adjustments
Cooldown periods
Minimum/Maximum capacity
Desired capacity
Scaling adjustment types
Warm-up periods
Instance protection

Scaling Process Flow

How Auto Scaling policies work:

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ │ │ CloudWatch │────▶│ Policy │────▶│ Decision │ │ Monitoring │ │ Evaluation │ │ Making │ │ │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ │ │Verification │◀────│ Scaling │◀────│ Action │ │ │ │Stabilization│ │ Execution │ │ │ │ (Cooldown) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘

Monitoring: CloudWatch collects and analyzes metrics from your Auto Scaling group
Evaluation: The policy evaluates metrics against defined thresholds or targets
Decision: When conditions are met, the policy determines the scaling action needed
Action: The Auto Scaling group adds or removes instances according to the policy
Stabilization: Cooldown or warm-up periods prevent rapid scaling oscillations
Verification: The system confirms the scaling action was successful

Understanding Cooldown Periods

Cooldown periods help ensure that your Auto Scaling group doesn't launch or terminate additional instances before the previous scaling activity takes effect.

Default Cooldown

Applies to all simple scaling policies
Default value: 300 seconds (5 minutes)
Can be modified at the Auto Scaling group level
Starts when a scaling activity ends

# Set default cooldown
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --default-cooldown 180

Scaling-Specific Cooldown

Override default cooldown for specific policies
Useful for different scale-out and scale-in behaviors
Can be shorter for scale-out actions
Can be longer for scale-in actions

# Set policy-specific cooldown
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name scale-out-policy \
  --scaling-adjustment 1 \
  --adjustment-type ChangeInCapacity \
  --cooldown 60

Best Practices for Cooldown Periods

Scale-Out: Use shorter cooldowns (60-120 seconds) to respond quickly to increased demand
Scale-In: Use longer cooldowns (300-600 seconds) to avoid premature instance termination
Instance Warmup: Consider application startup time when setting cooldown periods
Monitoring: Track scaling activities to adjust cooldown periods based on actual needs
Target Tracking: Uses built-in cooldown logic, no manual configuration needed
Step Scaling: Consider using warm-up time instead of cooldown periods

Target Tracking Scaling

How It Works

Target tracking scaling policies automatically adjust capacity to maintain a specific metric value. This is the simplest and most recommended approach for most applications.

For example, you can set a target of 70% average CPU utilization. The policy will automatically add or remove instances to maintain this target.

Implementation

Creating a target tracking policy via AWS CLI:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-target-tracking-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 70.0,
    "DisableScaleIn": false
  }'

Common predefined metrics:

ASGAverageCPUUtilization
ASGAverageNetworkIn
ASGAverageNetworkOut
ALBRequestCountPerTarget

Custom Metrics

Using custom CloudWatch metrics:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name custom-metric-tracking-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "MyCustomMetric",
      "Namespace": "MyNamespace",
      "Dimensions": [
        {
          "Name": "MyDimension",
          "Value": "MyValue"
        }
      ],
      "Statistic": "Average",
      "Unit": "Count"
    },
    "TargetValue": 100.0
  }'

Step Scaling

How It Works

Step scaling policies allow you to define different scaling adjustments based on the size of the alarm breach. This provides more granular control over scaling actions.

For example, you might add 1 instance when CPU is between 70-85%, but add 3 instances when CPU exceeds 85%.

Implementation

Creating a step scaling policy requires two steps:

1. Create a CloudWatch alarm:

aws cloudwatch put-metric-alarm \
  --alarm-name cpu-high-alarm \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 70 \
  --comparison-operator GreaterThanThreshold \
  --dimensions "Name=AutoScalingGroupName,Value=my-asg"

2. Create the step scaling policy:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-step-scaling-policy \
  --policy-type StepScaling \
  --adjustment-type PercentChangeInCapacity \
  --metric-aggregation-type Average \
  --step-adjustments '[
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 15,
      "ScalingAdjustment": 10
    },
    {
      "MetricIntervalLowerBound": 15,
      "ScalingAdjustment": 30
    }
  ]' \
  --min-adjustment-magnitude 1

Adjustment Types

Type	Description
ChangeInCapacity	Add or remove a specific number of instances
PercentChangeInCapacity	Add or remove a percentage of current capacity
ExactCapacity	Set the group to an exact number of instances

Simple and Scheduled Scaling

Simple Scaling

Simple scaling policies adjust capacity based on a single CloudWatch alarm. Unlike step scaling, simple scaling doesn't provide granular adjustments based on the size of the alarm breach.

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name simple-scaling-policy \
  --scaling-adjustment 1 \
  --adjustment-type ChangeInCapacity \
  --cooldown 300

aws cloudwatch put-metric-alarm \
  --alarm-name cpu-high-simple-alarm \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 70 \
  --comparison-operator GreaterThanThreshold \
  --dimensions "Name=AutoScalingGroupName,Value=my-asg" \
  --alarm-actions "arn:aws:autoscaling:region:account-id:scalingPolicy:policy-id:autoScalingGroupName/my-asg:policyName/simple-scaling-policy"

Scheduled Scaling

Scheduled scaling allows you to set up scaling actions that occur at specific times, such as increasing capacity before a known traffic spike.

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name increase-capacity-weekday-mornings \
  --recurrence "0 8 * * 1-5" \
  --min-size 5 \
  --max-size 10 \
  --desired-capacity 5

Common scheduling scenarios:

Business hours scaling (weekdays 9-5)
Weekend capacity reduction
Monthly batch processing
Seasonal traffic patterns
Marketing campaign launches

Predictive Scaling

How It Works

Predictive scaling uses machine learning to analyze historical workload patterns and forecast future capacity needs. It proactively scales your Auto Scaling group before anticipated load increases.

This is particularly useful for applications with regular traffic patterns, such as daily or weekly cycles.

Implementation

Creating a predictive scaling policy:

aws autoscaling put-scaling-policy \
  --policy-name predictive-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications": [
      {
        "TargetValue": 70,
        "PredefinedMetricPairSpecification": {
          "PredefinedMetricType": "ASGCPUUtilization"
        }
      }
    ],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 300
  }'

Predictive scaling modes:

ForecastOnly: Generate forecasts but don't scale automatically
ForecastAndScale: Generate forecasts and scale automatically

Best Practices

Requires at least 24 hours of historical data
Works best with regular, predictable patterns
Combine with dynamic scaling for unexpected changes
Start in ForecastOnly mode to validate predictions
Review forecasts regularly to ensure accuracy
Adjust buffer time based on instance launch time

Multiple Scaling Policies

Combining Policy Types

You can apply multiple scaling policies to a single Auto Scaling group to handle different aspects of your application's scaling needs.

When multiple policies suggest different scaling actions, Auto Scaling chooses the one that provides the largest capacity.

Common Combinations

CPU + Request Count: Balance compute and traffic load
Dynamic + Scheduled: Handle both predictable and unpredictable patterns
Predictive + Target Tracking: Proactive and reactive scaling
Memory + CPU: Cover different resource constraints
Queue Length + Latency: Balance throughput and performance

Example of combining CPU and request count policies:

# CPU-based policy
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 70.0
  }'

# Request count policy
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name request-count-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-targets/943f017f100becff"
    },
    "TargetValue": 1000.0
  }'

Custom Metrics and Scaling

Using Custom Metrics

You can use custom CloudWatch metrics to scale based on application-specific indicators that aren't available as predefined metrics.

# Publish custom metric
aws cloudwatch put-metric-data \
  --namespace "MyApplication" \
  --metric-name "ActiveConnections" \
  --value 42 \
  --dimensions "AutoScalingGroupName=my-asg"

# Create scaling policy with custom metric
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name custom-metric-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "ActiveConnections",
      "Namespace": "MyApplication",
      "Statistic": "Average",
      "Dimensions": [
        {
          "Name": "AutoScalingGroupName",
          "Value": "my-asg"
        }
      ]
    },
    "TargetValue": 100.0
  }'

Common Custom Metrics

Memory utilization
Application queue depth
Database connections
Custom business metrics
Error rates
Cache hit ratios

Best Practices

Choose metrics that correlate with instance load
Use appropriate statistics (Average, Sum, etc.)
Consider metric collection frequency
Set appropriate thresholds
Monitor metric reliability
Document metric significance

Real-World Examples

E-commerce Website

An e-commerce site that experiences varying traffic patterns throughout the day and during special sales events.

# Target tracking for normal traffic
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name ecommerce-asg \
  --policy-name request-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/ecommerce-alb/targetgroup/main/123456"
    },
    "TargetValue": 1000.0
  }'

# Scheduled scaling for sales events
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name ecommerce-asg \
  --scheduled-action-name black-friday-scale-up \
  --start-time "2024-11-29T00:00:00" \
  --min-size 10 \
  --max-size 30 \
  --desired-capacity 20

Data Processing Pipeline

A data processing system that scales based on SQS queue length.

# Custom metric based on queue length
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name data-processing-asg \
  --policy-name queue-based-scaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Dimensions": [{
        "Name": "QueueName",
        "Value": "data-processing-queue"
      }],
      "Statistic": "Average"
    },
    "TargetValue": 100.0
  }'

Microservices Architecture

Multiple services with different scaling requirements.

# API service with step scaling
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-service-asg \
  --policy-name api-step-scaling \
  --policy-type StepScaling \
  --adjustment-type ChangeInCapacity \
  --metric-aggregation-type Average \
  --step-adjustments '[
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 20,
      "ScalingAdjustment": 1
    },
    {
      "MetricIntervalLowerBound": 20,
      "ScalingAdjustment": 2
    }
  ]'

Advantages

Cost Benefits

Pay only for needed resources
Automatic capacity optimization
Reduced over-provisioning
Efficient resource utilization
Predictable cost management

Performance Benefits

Automatic handling of load variations
Improved application responsiveness
Proactive capacity management
Multiple scaling options
Fine-grained control over scaling

Limitations

Technical Challenges

Initial configuration complexity
Metric selection challenges
Potential scaling delays
Complex troubleshooting
Application must be scale-aware

Operational Considerations

Requires careful monitoring
May need frequent adjustments
Testing can be challenging
Policy conflicts possible
Cost prediction complexity

Test Your Knowledge

1. Which scaling policy type is recommended for most applications?

A) Target Tracking Scaling

B) Simple Scaling

C) Scheduled Scaling

D) Step Scaling

2. What is the purpose of cooldown periods in Auto Scaling policies?

A) To save costs

B) To improve performance

C) To prevent rapid scaling oscillations

D) To reduce network traffic

3. Which scaling policy type is best suited for applications with regular, predictable traffic patterns?

A) Simple Scaling

B) Step Scaling

C) Predictive Scaling

D) Target Tracking

4. What happens when multiple scaling policies suggest different scaling actions?

A) The most recently created policy takes precedence

B) Auto Scaling chooses the action that provides the largest capacity

C) The policies are executed in sequence

D) No action is taken until policies agree

5. What is required for predictive scaling to work effectively?

A) Multiple Availability Zones

B) Custom metrics

C) At least 24 hours of historical data

D) Target tracking policy