Load Balancer
A load balancer distributes incoming traffic across multiple EC2 instances, containers, or IPs, continuously health-checking every backend and automatically removing unhealthy targets from rotation. AWS offers three types: ALB for Layer 7 HTTP/HTTPS routing decisions, NLB for ultra-low-latency Layer 4 TCP/UDP traffic with static IPs, and GWLB for routing packets through third-party security appliances.
At Swiggy, an ALB in front of the order-service fleet uses path-based routing so /api/orders and /api/restaurants hit separate target groups, each scaled independently during dinner-hour spikes.
Why It Matters
Users never connect directly to EC2 — they connect to the load balancer. This decouples client connections from backend capacity, so instances can be added, removed, or replaced without any client-visible disruption. Health checks run every 30 seconds by default; after 3 consecutive failures a target is pulled from rotation automatically.
ALB vs NLB vs GWLB
- ALB — reads HTTP content, routes by path/host/header, best for web apps and microservices
- NLB — passes raw packets, sub-millisecond latency, static per-AZ IP, best for gaming/IoT/finance
- GWLB — routes through a fleet of firewalls or IDS appliances using GENEVE
RememberALB does not have a static IP. Clients needing a fixed IP to whitelist should use NLB or put Global Accelerator in front of the ALB.
Frequently Asked Questions
When should you choose ALB over NLB on AWS, given both distribute traffic?
ALB operates at Layer 7, so it can route based on the actual HTTP request — path (`/api/*` to one target group, `/static/*` to another), hostname, or headers — and terminates TLS with native support for things like WebSockets and Lambda targets. NLB operates at Layer 4, passing TCP/UDP through with minimal processing and much lower latency, and it exposes static IPs per Availability Zone (which ALB does not), making it the choice when clients need to allowlist a fixed IP or when raw throughput matters more than routing intelligence.
What's a common misconfiguration that causes healthy-looking backends to get marked unhealthy behind an AWS load balancer?
Pointing the health check at a path that requires authentication or hits a database dependency, so a transient downstream blip fails the health check and the load balancer pulls a perfectly capable instance out of rotation. Health check endpoints should be lightweight and check only what's needed to confirm the process can serve traffic — a dedicated `/healthz` route, not the same endpoint real users hit, and not one that fails for reasons unrelated to the instance's own ability to respond.