How does AWS Auto Scaling work and what are the different scaling policies?

AWS Auto Scaling automatically adjusts compute capacity to maintain performance and minimize costs. It monitors your applications and automatically adjusts capacity to maintain steady, predictable performance.

Core Components

Auto Scaling Group (ASG)

• Defines the group of EC2 instances to scale
• Specifies minimum, maximum, and desired capacity
• Distributes instances across multiple Availability Zones

Launch Template / Launch Configuration

• Defines the instance configuration (AMI, instance type, key pair, security groups)

Health Checks

• EC2 health checks (default)
• ELB health checks (recommended for web apps)

Scaling Policies

1. Target Tracking Scaling

Maintains a specific metric at a target value automatically.

Example: Keep average CPU utilization at 60%
- AWS automatically adds/removes instances to maintain this target

Best for most use cases – simple to configure and responsive.

2. Step Scaling

Scales based on CloudWatch alarm breaches with step adjustments.

Example:
- CPU 60-70%: Add 2 instances
- CPU 70-90%: Add 4 instances  
- CPU > 90%: Add 8 instances

3. Simple Scaling

Legacy policy – adds/removes a fixed number of instances based on a single alarm.
Recommend using Target Tracking or Step Scaling instead.

4. Scheduled Scaling

Scales based on predictable load patterns.

Example: Increase to 20 instances every Monday 8 AM,
reduce to 5 instances every Friday 8 PM

5. Predictive Scaling

Uses ML to predict future traffic and proactively scales in advance.

• Analyzes historical patterns
• Creates scaling schedules automatically
• Ideal for cyclical traffic patterns

Lifecycle Hooks

Hooks allow you to run custom actions when instances launch or terminate:

• Launch hook: Install software, run tests before instance joins the group
• Terminate hook: Drain connections, backup data before termination

Best Practices

• Use Target Tracking as the primary policy
• Enable multiple AZs for fault tolerance
• Use launch templates over launch configurations
• Set appropriate cooldown periods to prevent rapid scaling oscillation
• Use warm pools for applications with long startup times