Auto Scaling Groups & Policies

An Auto Scaling Group contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for scaling and management.

Core Settings:

• Minimum capacity: Minimum number of instances (never goes below)
• Maximum capacity: Maximum number of instances (never exceeds)
• Desired capacity: Target number of instances ASG maintains

Example Configuration:

• Min: 2, Max: 10, Desired: 4
• ASG maintains 4 instances
• Can scale out to 10 during peak load
• Never drops below 2 instances

Launch Templates define the instance configuration for ASG:

• AMI ID
• Instance type
• Key pair
• Security groups
• Block device mappings
• IAM instance profile
• User data scripts

Advantages over Launch Configurations:

• Support for multiple instance types (mixed instances)
• Versioning support
• Can specify Spot and On-Demand mix
• Required for new instance types (post-2023)

Target tracking works like a thermostat - you set a target value, and ASG adjusts to maintain it.

Predefined Metrics:

• ASGAverageCPUUtilization - Average CPU across instances
• ASGAverageNetworkIn - Average bytes received
• ASGAverageNetworkOut - Average bytes sent
• ALBRequestCountPerTarget - Requests per target from ALB

Custom Metrics:

• Any CloudWatch metric (e.g., SQS queue depth per instance)

Behavior:

• Scales out quickly when metric exceeds target
• Scales in gradually to avoid flapping
• Creates and manages CloudWatch alarms automatically

Step scaling allows different scaling actions based on the size of the alarm breach.

Example Configuration:

CPU 60-70%: Add 1 instance
CPU 70-80%: Add 2 instances
CPU > 80%:  Add 3 instances

Advantages:

• More control than simple scaling
• Can react proportionally to breach size
• Supports both scale-out and scale-in steps

Step Adjustments:

• ChangeInCapacity: Add/remove specific number
• ExactCapacity: Set to specific count
• PercentChangeInCapacity: Increase/decrease by percentage

Scheduled scaling performs scaling actions at specific times.

Use Cases:

• Scale up before business hours
• Scale down on weekends
• Prepare for known events (sales, releases)

Schedule Options:

• One-time schedule (specific date/time)
• Recurring schedule (cron expression)

Example:

Scale to 10 instances at 8 AM weekdays
Scale to 2 instances at 8 PM weekdays
Scale to 2 instances all day weekends

Predictive scaling uses machine learning to forecast load and proactively scale.

How It Works:

1. Analyzes up to 14 days of historical data
2. Identifies daily and weekly patterns
3. Creates forecast for next 48 hours
4. Proactively launches instances before demand increases

Requirements:

• At least 24 hours of historical data
• Works best with recurring patterns
• Can combine with dynamic scaling policies

Modes:

• Forecast only: View predictions without scaling
• Forecast and scale: Automatically scale based on predictions

ASG monitors instance health and replaces unhealthy instances:

EC2 Health Check (Default):

• Checks EC2 status checks (system and instance)
• Instance marked unhealthy if status check fails
• Replaced automatically

ELB Health Check (Optional):

• Uses load balancer health checks
• Instance unhealthy if ELB reports unhealthy
• Recommended when using ELB

Custom Health Check:

• Application sends health status via API
• Use set-instance-health command
• For application-level health monitoring

The cooldown period prevents rapid-fire scaling actions.

How It Works:

• After a scaling activity, ASG waits before next action
• Allows previous instances to start handling traffic
• Prevents over-scaling or thrashing

Default: 300 seconds

Types:

• Default cooldown: Applies to all scaling activities
• Scale-out cooldown: Specific to scale-out actions
• Scale-in cooldown: Specific to scale-in actions

Note: Target tracking policies have built-in warmup and don't use cooldowns the same way.

Warm pools reduce scale-out latency by maintaining pre-initialized instances.

How It Works:

1. Instances launched and initialized (run user data scripts)
2. Instances stopped or hibernated (not running, no compute cost)
3. On scale-out: Instances started instead of launched fresh
4. Much faster than launching cold instances

States:

• Stopped: No compute cost, storage cost only
• Hibernated: Preserves memory state, faster start
• Running: Full cost (rarely used)

Use Cases:

• Applications with long initialization (5+ minutes)
• Pre-loading large datasets or caches
• Complex bootstrap processes

Lifecycle hooks pause instances during launch or termination to perform custom actions.

Launch Hook (scale-out):

• Instance pauses in Pending:Wait state
• Run custom initialization scripts
• Install software, configure settings
• Complete hook to continue to InService

Termination Hook (scale-in):

• Instance pauses in Terminating:Wait state
• Download logs, deregister from services
• Backup data before termination
• Complete hook to continue termination

Timeout: Default 1 hour (configurable)

Integration Options:

• EventBridge → Lambda
• SNS notifications
• SQS messages

Mixed instances policy allows combining instance types and purchase options.

Instance Types:

• Specify multiple instance types (e.g., m5.large, m5.xlarge, m4.large)
• ASG selects based on availability and priorities
• Improves availability (not dependent on single type)

Purchase Options:

• On-Demand instances (reliable, higher cost)
• Spot instances (up to 90% savings, can be interrupted)
• Configure percentage split (e.g., 70% Spot, 30% On-Demand)

Allocation Strategies:

• lowest-price: Launch cheapest Spot pools
• capacity-optimized: Launch from pools with most capacity
• price-capacity-optimized: Balance price and capacity (recommended)