Let's think about this for a second
If you run a web app on a single EC2 instance, the app becomes unreachable the moment that instance goes down (or gets overwhelmed by traffic). A Load Balancer (ALB - Application Load Balancer) health-checks multiple instances (backend targets) and distributes incoming traffic across them — if one instance becomes unhealthy, it routes traffic only to the remaining healthy ones. An Auto Scaling Group (ASG) lets you set a policy for 'how many instances at minimum, how many at maximum' and then auto-adjusts the instance count based on CPU usage (or a custom metric) — similar in concept to Kubernetes' HPA.
Let's connect this to a real scenario
If you have 3 EC2 instances attached to a target group behind an ALB, traffic gets evenly distributed across all 3 — if one instance crashes, the ALB detects the failed health check and sends traffic only to the remaining 2. Set an ASG to min=2, max=10, and when traffic picks up it auto-scales up to 10 instances, then scales back down to 2 once traffic drops.
Let's look at this together
# Create a target group and an ALB
aws elbv2 create-target-group --name tutorial-tg --protocol HTTP --port 80 --vpc-id vpc-0123456789abcdef0
aws elbv2 create-load-balancer --name tutorial-alb --subnets subnet-abc subnet-def
# Create an Auto Scaling Group: 2-10 instances
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name tutorial-asg \
--min-size 2 --max-size 10 --desired-capacity 2 \
--target-group-arns <target-group-arn>$ aws elbv2 describe-target-health --target-group-arn <arn>
# Shows each instance's health state: healthy / unhealthyTry it in 5 minutes
Try designing an ALB target group + ASG (min=2, max=4) config yourself (a documentation review / cost-free dry-run) — explain how the ALB responds when one instance becomes unhealthy.
A quick word of caution
Both the ALB and the ASG incur hourly costs based on the number of running instances — don't forget to delete the ASG (which auto-terminates all instances) once you're done practicing.