Auto Scaling Cheat Sheet
Explains horizontal vs vertical scaling, scaling policies, cooldowns, and AWS Auto Scaling Group configuration with practical CLI examples.
Core Concepts
Fundamental auto scaling terminology.
- Horizontal Scaling (Scale Out/In)- Adding or removing instances/nodes to handle load
- Vertical Scaling (Scale Up/Down)- Increasing or decreasing the resources (CPU/RAM) of an existing instance
- Auto Scaling Group (ASG)- AWS construct that manages a fleet of EC2 instances between min/max/desired capacity
- Launch Template- Defines instance configuration (AMI, instance type, security groups) used by an ASG
- Cooldown Period- Time after a scaling activity during which further scaling actions are suppressed
- Warm-up Time- Time a new instance needs before it counts toward aggregated metrics
Scaling Policy Types
Different strategies for triggering scaling actions.
- Target Tracking- Maintains a metric (e.g. CPU 50%) automatically, similar to a thermostat
- Step Scaling- Adds/removes capacity in steps based on the size of the alarm breach
- Simple Scaling- Single scaling adjustment triggered by a CloudWatch alarm, then waits for cooldown
- Scheduled Scaling- Scales at predictable times, e.g. business hours or known traffic spikes
- Predictive Scaling- Uses ML forecasts of historical traffic patterns to scale ahead of demand
Create an Auto Scaling Group (AWS CLI)
Provision an ASG with min/max/desired capacity across subnets.
aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template LaunchTemplateName=my-template,Version='$Latest' \ --min-size 2 \ --max-size 10 \ --desired-capacity 3 \ --vpc-zone-identifier "subnet-abc123,subnet-def456" \ --health-check-type ELB \ --health-check-grace-period 120
Target Tracking Policy
Keep average CPU utilization near 50% automatically.
aws autoscaling put-scaling-policy \ --auto-scaling-group-name my-asg \ --policy-name cpu-target-tracking \ --policy-type TargetTrackingScaling \ --target-tracking-configuration '{ "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" }, "TargetValue": 50.0 }'
Lifecycle Hooks
Pause instances mid-launch or mid-terminate to run custom bootstrap or drain logic before they enter service.
aws autoscaling put-lifecycle-hook \ --lifecycle-hook-name warm-up-hook \ --auto-scaling-group-name my-asg \ --lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \ --heartbeat-timeout 300 \ --default-result CONTINUE# Instance stays in Pending:Wait until it calls:aws autoscaling complete-lifecycle-action \ --lifecycle-hook-name warm-up-hook \ --auto-scaling-group-name my-asg \ --lifecycle-action-result CONTINUE \ --instance-id i-0123456789abcdef0
Predictive Scaling Policy
Use ML forecasts of historical CPU load to pre-provision capacity ahead of recurring demand spikes.
aws autoscaling put-scaling-policy \ --auto-scaling-group-name my-asg \ --policy-name predictive-cpu \ --policy-type PredictiveScaling \ --predictive-scaling-configuration '{ "MetricSpecifications": [{ "TargetValue": 50, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } }], "Mode": "ForecastAndScale", "SchedulingBufferTime": 300 }'
Scale on a Custom Metric (SQS Queue Depth)
Drive step scaling from a non-CPU signal like queue backlog, which better reflects worker demand.
aws cloudwatch put-metric-alarm \ --alarm-name queue-depth-high \ --namespace AWS/SQS \ --metric-name ApproximateNumberOfMessagesVisible \ --dimensions Name=QueueName,Value=work-queue \ --statistic Average \ --period 60 \ --evaluation-periods 2 \ --threshold 100 \ --comparison-operator GreaterThanThreshold \ --alarm-actions arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:...:policyName/queue-step-scale
Rolling Instance Refresh
Replace all ASG instances with a new launch template version while respecting a minimum healthy percentage.
aws autoscaling start-instance-refresh \ --auto-scaling-group-name my-asg \ --preferences '{ "MinHealthyPercentage": 90, "InstanceWarmup": 120, "CheckpointPercentages": [50, 100], "CheckpointDelay": 600 }'aws autoscaling describe-instance-refreshes --auto-scaling-group-name my-asg
Autoscaling Beyond EC2 (Kubernetes)
Analogous scaling primitives once workloads move to a Kubernetes cluster.
- HPA (Horizontal Pod Autoscaler)- Adds/removes pod replicas based on CPU, memory, or custom/external metrics
- VPA (Vertical Pod Autoscaler)- Adjusts container CPU/memory requests over time instead of replica count
- Cluster Autoscaler- Adds/removes worker nodes when pods are unschedulable or nodes are underutilized
- Karpenter- Just-in-time node provisioning that bypasses node group templates for faster, right-sized scaling
- KEDA- Event-driven autoscaling that scales pods (including to zero) off queue depth, Kafka lag, cron, etc.
- PodDisruptionBudget- Caps how many pods can be evicted at once during scale-in or node drain
Combine target tracking with a scheduled minimum capacity for known traffic spikes (e.g. Black Friday) — reactive policies alone often lag behind sudden demand surges.