Auto Scaling Groups

The plain-language idea

An Auto Scaling Group (ASG) manages a fleet of EC2 instances so it always has roughly the right number running — not too few to handle load, not too many wasting money. Three numbers define its bounds:

• Minimum — the fleet never shrinks below this, even with zero traffic.
• Maximum — the fleet never grows past this, even under a huge spike, capping runaway cost.
• Desired capacity — the number the ASG actively maintains right now, somewhere between min and max.

"Desired capacity" isn't a suggestion — it's a target the ASG continuously enforces. Terminate an instance manually, or one fails an EC2 health check, and the ASG launches a replacement to get back to the desired count, independent of whether traffic changed at all. That's self-healing, and it happens even with scaling never coming into play.

Scaling policies decide how desired capacity itself changes in response to demand:

• Target-tracking scaling — pick a metric and a target value (e.g. "keep average CPU near 50%"), and the ASG manages the underlying CloudWatch alarms and adjustments itself, like a thermostat holding a temperature.
• Step scaling — define specific capacity adjustments at specific alarm thresholds yourself (e.g. "+2 instances if CPU > 70%, +5 if CPU > 90%") — more manual control over the exact reaction at each severity level.

See it in a real thing: an alarm firing into a scaling action

A CloudWatch alarm — the same mechanism from the monitoring lesson — watches an ASG's average CPU utilization. It crosses 70% and stays there for the evaluation window. That alarm state change triggers a scaling policy, which raises desired capacity by a defined amount. The ASG launches new instances from its launch template (which defines the AMI, instance type, and configuration every new instance gets), and registers them with the load balancer once they pass their health checks.

What people usually miss

Watch out

• ASGs replace unhealthy instances even when demand hasn't changed. Self-healing (maintaining desired capacity) and scaling (changing desired capacity in response to load) are two separate behaviors — a flat-traffic fleet with a crashed instance still gets a replacement launched.
• Target-tracking doesn't mean "no alarms involved." Under the hood, target tracking still creates and manages CloudWatch alarms — the difference from step scaling is that the ASG manages those alarms for you instead of you configuring each threshold by hand.
• Scaling actions have cooldown periods, for the same reason alarms need a sustained evaluation window. Without a cooldown, a scale-out action could trigger repeatedly before the new instances even finish booting and affecting the metric, causing overshoot — cooldowns prevent that flapping.
• Manually terminating an instance in an ASG doesn't shrink the fleet. Desired capacity doesn't change just because an instance disappeared — the ASG treats that as a health failure and launches a replacement to get back to the number it's maintaining, not a signal to scale down.

Why this matters in interviews

"Would you use an Auto Scaling Group or just let Lambda handle it?" tests whether a candidate reasons about who owns the scaling logic — Lambda scaling being free and automatic in exchange for its execution constraints, versus an ASG requiring explicit policies and launch templates in exchange for long-running, fully controllable compute — rather than treating "auto-scaling" as one interchangeable feature everywhere.