Load Balancing
Beginner 12 min read Load Balancing

Load Balancing Basics

The front door to your fleet

A load balancer is the front door that spreads incoming traffic across a fleet of instances, runs health checks, handles failures, and gives you one stable DNS name to point clients at.

load balancerALBELBNLBtrafficfront door
Prerequisites: Virtual Machines and Instances
Before we start

What you will learn

  • Explain the role of a load balancer in a tiered architecture
  • Name the AWS/Azure/GCP balancer products
  • Describe health checks and target selection
In 60 seconds

Clients hit one stable endpoint; the balancer picks a healthy target per request, runs health checks to skip dead instances, and scales the distribution as the fleet grows or shrinks.

Introduction

What is this?

AWS: Application Load Balancer (HTTP/HTTPS, path-based routing), Network Load Balancer (TCP/UDP), Gateway LB. Azure: Azure Load Balancer (L4), Application Gateway (L7, WAF). GCP: External Application Load Balancer, TCP/UDP proxy, internal L4/L7. Core mechanics: listener, rules, target group/backend pool, health checks, sticky sessions, TLS termination, and integration with autoscaling groups/instance groups.

Motivation

Why do you need it?

  • No single point of failure at request time — one DNS name maps to many instances.
  • Health checks replace dead instances with live ones automatically.
  • TLS offload concentrates certificate management at one trusted edge.
  • Routing rules (path/host) enable clean microservice fan-out.
Think about it

Mental model

Imagine

A concierge desk assigning guests to receptionists

Think of

Load balancer

Each guest (request) arrives at the desk (LB endpoint); the concierge picks from the receptionists (targets) who are signed in and available (healthy), spread the queue fairly, and knows who's on break (draining).

Mechanics

How it works

  • A listener accepts traffic on a port (e.g. :443), terminates TLS, applies rules.
  • Rules route by path/host/header to a target group or backend pool.
  • Each target group has a health check that pollutes the instance's /health.
  • The balancer routes to healthy targets, skipping failures within seconds.
  • Connection draining lets in-flight requests finish before a target is replaced.

LB request path.

Client
Listener
Health checks
Targets
Response
Hands-on

Examples

Provision an application load balancer

Provision an application load balancer
# AWS ALB
aws elbv2 create-load-balancer --name web-alb --type application \
  --subnets subnet-aaaa subnet-bbbb --security-groups sg-1111
aws elbv2 create-target-group --name web-tg --protocol HTTP \
  --port 8080 --vpc-id vpc-12345 --health-check-path /healthz
aws elbv2 register-targets --target-group-arn <tg> --targets Id=i-1111 Id=i-2222

Subnets, a target group with health-check path, and registered instances — the balancer now fronts the fleet.

Real world

In production

  • An ALB fronts an autoscaling web tier, routing /api to services and /static to origin.
  • Azure App Gateway applies WAF rules and routes host headers to different backend pools.
  • A GCP external LB fronts a global MIG with session affinity and CDN offload.
Guidelines

Best practices

  • Always set a real health-check path that exercises app dependencies minimally.
  • Terminate TLS at the LB; use it to centralize cert rotation.
  • Put the LB behind protection (WAF) and max idle/connection timeouts deliberately.
  • Register targets via autoscaling/instance groups so scale events keep the pool correct.
Watch out

Common mistakes

  • Health check on '/' when the app lives on a different endpoint → flapping targets.
  • Single-AZ subnets on the LB → the balancer becomes the single point of failure.
  • Pointing clients straight at instances 'for simplicity' — losing scale and health for nothing.
  • Forgetting draining: deployments terminate instances mid-request on busy services.
Root cause analysis

Common issues

Error
All targets unhealthy after deploy
Root cause

Health check / new port mismatch

Fix

Re-check health path + port; deploy the pro→ change in lock-step and re-run health status.

Error
Balancer 'connection refused'
Root cause

LB SGs allow clients but not instance SG inbound for the LB

Fix

Reference the LB security group in the target SG inbound rule.

When things break

Debugging tips

  • Balancer unhealthy: hit the health path from a target directly to find the app's failure.
  • Check target-group health status per instance (aws elbv2 describe-target-health).
  • Port/security mismatch: the LB SG must allow traffic to the target SG's port.
  • Sticky resurrects: if sessions stick, review sticky flags before blaming routing.
Interviews

Interview checkpoint

Practice

Hands-on lab

Stand Up a Balancer, Register Targets, Watch Health Checks
30 min · beginner
In progress
Objectives
  • Create a load balancer with listener + target group
  • Register two instances and verify health
  • Drain and re-test failover behavior

Stand Up a Balancer, Register Targets, Watch Health Checks

30 min · beginner

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

Quick quiz

0/1
1

What is the primary input to deciding whether a target is 'healthy'?

Go deeper

Official documentation

AWS — Elastic Load Balancing
docs
Azure — Load Balancer
docs
GCP — Load balancing
docs