AWS
Intermediate 16 min read AWS

Load Balancing & Auto Scaling

Elastic Load Balancing distributes traffic across EC2 instances, containers and IP targets, while Auto Scaling Groups keep the right number of instances running. Learn ALB versus NLB, health checks, target groups, scaling policies and how the two services work together to survive traffic spikes and instance failures.

ALBNLBtarget grouphealth checkAuto Scalinglaunch templatedesired capacityscaling policyconnection draining
Prerequisites: EC2, SSH & IAM VPC, Subnets & Security Groups
Introduction

What is this?

Elastic Load Balancing distributes incoming traffic across EC2 instances, containers and IP targets. The Application Load Balancer (ALB) works at layer 7 with host and path routing; the Network Load Balancer (NLB) works at layer 4. Auto Scaling Groups maintain a desired number of instances, launch or terminate to match demand, replace unhealthy ones, and integrate with the load balancer so only healthy targets receive traffic.

Motivation

Why do you need it?

  • A single server is a single point of failure — load balancers spread risk across many targets.
  • Auto scaling is how AWS handles traffic spikes without manual intervention.
  • Health checks decide when traffic is diverted away from failing instances.
  • Scaling policies (target tracking, scheduled, predictive) drive both cost and reliability.
  • ALB path and host routing lets you run many microservices behind one entry point.
Think about it

Mental model

Imagine

A restaurant host at the door

Think of

A load balancer and its waiters

The host (load balancer) greets every party, checks the seating chart (health checks), and sends them to an available table (a target). If a waiter is slow or leaves, the host stops seating people there and redirects to others. During the dinner rush, the manager (auto scaling) adds tables and waiters; after hours, the extra tables are cleared. Every party gets served without overwhelming any single waiter.

Mechanics

How it works

  • You register targets (instances in an Auto Scaling group, or IPs) with a target group and define a health check — path, port and interval.
  • The load balancer owns a DNS name and listeners; ALB rules route by host header or path prefix to different target groups.
  • The load balancer health-checks targets and stops sending traffic to any that fail; the ASG does its own checks and replaces bad instances.
  • Auto scaling policies read CloudWatch metrics (CPU, request count, custom metrics) and adjust desired capacity between a minimum and maximum.
  • The load balancer performs connection draining — letting in-flight requests finish — before it removes a target from rotation.

Traffic flow through an ALB into an Auto Scaling group.

Clients
ALB listener
Health checks
Target group
Auto Scaling group
Scaling policy
Reference

Key commands

aws autoscaling describe-auto-scaling-groups

Show ASG state, desired, min and max capacity and attached load balancers.

aws elbv2 describe-target-health --target-group-arn <arn>

Check the health state of every target in a group.

aws autoscaling update-auto-scaling-group --desired-capacity 4

Manually scale the group to four instances.

curl -s http://<alb-dns>/health

Hit the health endpoint through the load balancer.

free -m

Watch instance memory when load tests drive CPU up.

Hands-on

Examples

Scale out and confirm the load is balanced

Scale out and confirm the load is balanced
$ aws autoscaling update-auto-scaling-group \
    --auto-scaling-group-name web-asg \
    --desired-capacity 4
 
$ aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/1234
TargetGroups: [
  {
    "Target": {"Id": "i-0abc123..."},
    "TargetHealth": {"State": "healthy"}
  },
  ...
]

Raising desired capacity tells the ASG to launch instances until it reaches four. describe-target-health then confirms each instance reports healthy to the target group — the load balancer spreads traffic across exactly these targets. Scaling works in reverse too: when the metric drops, the ASG terminates instances and the load balancer drains them.

Real world

In production

  • Run stateless web tiers in an ASG behind an ALB with target-tracking scaling on request count.
  • Use ALB path rules to route /api and /admin to separate target groups within one distribution.
  • Attach scheduled scaling policies for known peak hours instead of reacting late.
  • Enable sticky sessions (ALB cookie) only for stateful workloads that cannot be made stateless.
  • Use connection draining and instance de-registration delays for graceful shutdowns during deploys.
Guidelines

Best practices

  • Make instances stateless so any instance can serve any request — scaling and replacement depend on it.
  • Keep the minimum capacity above zero for production and spread instances across availability zones.
  • Define a real health check path (like /healthz) that verifies dependencies, not just a TCP port.
  • Set reasonable cooldown and warm-up so scaling does not thrash under variable load.
  • Test scaling policies with load tests before they are needed during an incident.
Watch out

Common mistakes

  • Scaling on CPU only, while the real bottleneck is request latency or memory.
  • Setting min and max to the same number, which disables scaling entirely.
  • A health check that always succeeds, so the load balancer keeps sending traffic to broken instances.
  • Running stateful sessions on instances and losing user sessions on every scale-in.
  • Ignoring connection draining settings and dropping in-flight requests during rollouts.
Root cause analysis

Common issues

Error
Target marked unhealthy in a loop
Root cause

The health check fails intermittently — timeout, error path, or a dependency the check does not cover.

Fix

Look at the health check status reason, test the path manually with curl on the instance, and lengthen the timeout or fix the endpoint.

Error
ASG will not launch instances
Root cause

The launch template has a bad AMI, the subnet is out of IPs, or an instance quota is exhausted.

Fix

Check the ASG activity history for the exact error, correct the launch template, and verify subnets have free addresses.

Error
5xx errors from the load balancer
Root cause

No healthy targets, or the targets are saturated and returning 500s.

Fix

Check target health and instance CPU and memory; scale out or fix the application before traffic routing is restored.

When things break

Debugging tips

  • Check the health check status and reason — describe-target-health tells you why a target is unhealthy.
  • Look at the ALB access logs for 5xx and latency patterns before blaming the instances.
  • Verify the instance security group allows health-check traffic from the load balancer.
  • Compare the ASG desired count versus running count — a stuck launch (bad AMI, subnet, quota) shows there.
  • Compare instance metrics across AZs to spot a zone-level problem early.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Load and Analyze Requests Like a Balancer
25 min · intermediate
In progress
Objectives
  • Generate a realistic access log with request records
  • Count requests and inspect the busiest entries
  • Aggregate and rank entries the way dashboards do
  • Spot anomalies with head, tail and grep

Simulate Load and Analyze Requests Like a Balancer

25 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component decides which instances receive traffic based on a /healthz path?

2

An Auto Scaling group can be scaled manually by changing its desired capacity.

3

Traffic to your site spikes every weekday at 9am but scaling reacts slowly, causing errors. What is the best approach?

Quick reference

Cheat sheet

Load balancing
ALBLayer 7 — host/path routing, TLS termination
NLBLayer 4 — raw TCP/UDP, low latency
Target groupSet of targets plus a health check
ListenerPort + protocol + routing rules
Connection drainingLet in-flight requests finish
Auto scaling
Desired capacityInstances the ASG targets now
Min / maxBounds the group may scale within
Launch templateAMI, instance type, user data
Target trackingKeep a metric near a value
Scheduled scalingChange capacity at fixed times
Go deeper

Official documentation

What Is Elastic Load Balancing?
docs
Application Load Balancer
docs
Target Groups
docs
What Is Amazon EC2 Auto Scaling?
docs
Auto Scaling Groups
docs