06 — Auto Scaling: AMIs, Templates, Groups, and the Load Balancer in Front

"More servers when it gets busy" described Auto Scaling's effect but not its machinery, so the console was a vocabulary list I couldn't act on. The layering that clicked: an Auto Scaling system is a golden image (AMI) that feeds a launch recipe (template) that defines a managed fleet (the Auto Scaling Group) with scaling rules — and a load balancer in front spreads traffic across whatever size the fleet happens to be [1]. Each layer has one job. Once I separated them, the constellation of ASG-related terms stopped being a vocabulary list and became a pipeline.

AMIs: the golden image

An AMI — Amazon Machine Image — is a pre-configured template an EC2 instance boots from [2]. It bundles the OS, any installed software, configuration, and a snapshot of the root volume. Launch an instance from an AMI and you get, identically, whatever was baked in.

The pattern this enables is immutable infrastructure: I bake a new AMI for every release (via a build pipeline), and "deploying" means swapping which AMI the Auto Scaling Group launches from, then rolling instances. No in-place patching, no SSH-and-edit — each instance is a fresh, known-good boot. Public AMIs (Amazon Linux, Ubuntu) cover starting points; the custom ones I bake are private to my account.

Launch Templates: the recipe

A Launch Template is the full recipe the group uses to make an instance [3]: which AMI, which instance type, which keypair, which security groups, what user data, what IAM instance profile, what storage. Templates are versioned, so I can roll forward and back through configurations.

The reason this is separate from the AMI: the AMI is the contents of the disk; the template is how the instance is shaped and launched. The same AMI can be launched as a t3.micro for dev and an m6i.large for prod, via two templates pointing at the same image. That separation keeps the build pipeline (which produces AMIs) cleanly decoupled from the run configuration (which lives in templates).

Auto Scaling Groups: the managed fleet

The Auto Scaling Group (ASG) is the heart of the system [4]. It manages a logical group of EC2 instances spread across multiple Availability Zones, and it owns three numbers:

• Minimum — never fewer than this many instances.
• Desired — the target the group tries to hold.
• Maximum — never more than this many instances.

The ASG launches instances from the launch template, distributes them across AZs, and continuously health-checks each one. If an instance fails its health check (or the AZ it's in fails), the ASG terminates it and launches a replacement — that is self-healing, and it's the single biggest availability win EC2 offers. Spreading across AZs is the other half: lose a zone, the group keeps serving from the survivors and re-balances.

Scaling policies: how the numbers move

The min/desired/max bound the group; scaling policies decide when the desired count changes [5]:

• Target tracking — "keep average CPU at 50%." CloudWatch does the math; the ASG adds or removes capacity to hold the target. The simplest and usually right choice.
• Step scaling — "if CPU is above 70% for 5 minutes, add 2; if above 90%, add 4." A ladder of thresholds and adjustments.
• Simple scaling — a single alarm triggers a single adjustment. Older, coarser; mostly replaced by the other two.

The non-obvious failure mode: cooldowns. After a scaling action, the group waits before acting again, so newly-launched instances have time to take load before the policy re-evaluates. Too-short cooldowns cause thrashing (add, remove, add); too-long ones cause slow response. Target tracking hides most of this.

Elastic Load Balancers: the front door

Traffic has to reach the fleet, and that's the Elastic Load Balancer (ELB) [6]. It sits in front, accepts incoming requests, health-checks each instance, and routes traffic only to healthy ones — so the ASG terminating a sick instance and the ELB draining it are coordinated, not two independent events. Three flavors:

• Application Load Balancer (ALB) — layer 7, HTTP/HTTPS. Path-based routing, host-based routing, the right default for web apps.
• Network Load Balancer (NLB) — layer 4, TCP/UDP. Extreme throughput, static IPs, low latency. Right for non-HTTP or very high-volume workloads.
• Gateway Load Balancer — for inserting third-party security appliances in the traffic path.

(Classic Load Balancer still exists, but it's legacy — ALB and NLB cover its use cases better.)

The whole picture: traffic hits the ALB, which fans out to healthy instances in the ASG; CloudWatch's CPU metric drives a target-tracking policy that nudges desired capacity; the launch template (built from the AMI) defines every new instance the group spins up. Four services, one feedback loop.

How I use this

Auto Scaling is the reason EC2 feels elastic rather than just "rented VMs." The discipline I keep: bake AMIs in CI, never edit running instances; version launch templates and treat them as the deploy unit; size ASGs across at least two AZs with min ≥ 2 so a single AZ outage doesn't take the service down; default to target-tracking scaling on a meaningful metric (CPU for compute-bound, request-count-per-target for web frontends) instead of hand-tuned step ladders; and always pair an ASG with a load balancer — without the LB, the group can scale but traffic won't follow. The min/desired/max triple is the cheapest availability insurance in AWS: I set min to what I need to survive a spike, max to what I'm willing to pay for, and let the policy ride in between.

References

[1] Amazon Web Services, "What is Amazon EC2 Auto Scaling," EC2 Auto Scaling User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

[2] Amazon Web Services, "Amazon Machine Images (AMIs)," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

[3] Amazon Web Services, "Launch templates," EC2 User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html

[4] Amazon Web Services, "Auto Scaling groups," EC2 Auto Scaling User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html

[5] Amazon Web Services, "Scaling policies for Amazon EC2 Auto Scaling," EC2 Auto Scaling User Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scaling-and-policies.html

[6] Amazon Web Services, "Elastic Load Balancing," 2024. [Online]. Available: https://aws.amazon.com/elasticloadbalancing/