AWS Load Balancers - ALB, NLB, GWLB and When to Use Each

What you will learn

• Why load balancers exist — the four problems they solve that a single EC2 cannot
• ALB — Layer 7 smart routing by path, hostname, query string, and headers
• How ALB dynamic port mapping solves the container port conflict problem
• NLB — Layer 4 extreme performance, static IP, and when it beats ALB
• GWLB — Layer 3 for transparent security appliance inspection
• Health checks — how to design a /health endpoint that actually means healthy
• The correct Security Group setup so EC2 is never directly reachable from the internet
• Sticky sessions — the three cookie types and why ElastiCache is the better solution
• Cross-zone load balancing — defaults and costs per LB type
• SSL termination and SNI for multiple domains on one ALB
• Connection Draining — preventing dropped requests during deployments
• Auto Scaling Group integration — how instances register and deregister automatically

Why this matters

During a Swiggy Big Billion Day sale, traffic spikes 10x in under a minute. A single EC2 instance cannot handle this — it buckles and crashes. A load balancer distributes traffic across many EC2 instances, health-checks each one, stops routing to any that fail, and integrates with Auto Scaling Groups to add instances automatically as load grows. The load balancer is the entry point to every production application. Understanding which type to use, how to configure health checks correctly, and how SSL termination works is fundamental to building any AWS architecture.

Why Load Balancers Exist

Your application runs on a single EC2 instance. Traffic spikes. The instance is maxed out. Response times climb. It crashes. Every user sees a 502 error.

Even on a normal day — what happens when that EC2 needs a restart for a security patch? Every user gets an outage.

A load balancer sits in front of your application servers and forwards incoming requests to them. Users never talk to EC2 directly. They talk to the load balancer, and the load balancer decides which backend handles each request.

What a load balancer gives you:

Why use AWS ELB instead of running your own nginx or HAProxy:

You could self-manage a load balancer on EC2. The problem: you now own that server — patches, scaling, certificates, availability. AWS ELB is fully managed. AWS guarantees availability, handles upgrades, and integrates natively with EC2, ASG, ECS, ACM, CloudWatch, Route 53, WAF, and Global Accelerator.

AWS has 4 load balancer types:

Health Checks and Security Groups

How the LB knows who is alive:

The LB checks every backend instance on a schedule using a protocol, port, and path you configure.

Design a meaningful /health endpoint:

The correct Security Group setup:

Security

EC2 SG allowing only from LB SG is the most secure setup. Never allow direct internet access to EC2 when a load balancer is in front. If you allow 0.0.0.0/0 on EC2, the load balancer provides no security benefit — anyone can bypass it and hit EC2 directly.

Application Load Balancer — Layer 7

ALB operates at Layer 7. It reads and understands your HTTP request — the URL path, hostname, query string, and headers — and makes intelligent routing decisions.

ALB supports HTTP/2, WebSocket, and HTTP-to-HTTPS redirects natively.

4 routing rules:

Path-based routing:

Hostname-based routing:

Query string routing:

HTTP header routing:

ALB Target Types:

Dynamic port mapping for containers:

When multiple containers run on the same EC2 host, each gets a random port at launch. ALB handles this automatically — when an ECS task starts, it registers with the ALB Target Group along with whatever port it was assigned. ALB updates routing. When the container stops, ALB removes it. You never touch port configuration manually.

Client IP — the X-Forwarded-For header:

When ALB forwards a request to EC2, the instance sees the ALB's IP, not the real user IP. The actual client IP is in the X-Forwarded-For header.

Remember

If your application logs IP addresses for analytics or rate limiting, it must read X-Forwarded-For, not the connection source IP. The source IP is always the ALB's private IP. NLB does not have this problem — it passes the real client IP through directly.

NLB and GWLB — Layer 4 and Layer 3

Network Load Balancer — Layer 4:

A gaming company runs servers communicating over TCP. They need 5 million concurrent connections with sub-millisecond latency. Their enterprise clients must whitelist specific IP addresses in their firewalls. ALB cannot solve either of these problems.

NLB operates at Layer 4. It forwards TCP and UDP packets directly to targets without reading HTTP content.

Key NLB facts:

NLB Target Groups:

Gateway Load Balancer — Layer 3:

Your company processes financial transactions. Compliance requires all traffic to pass through a third-party network firewall before reaching your application.

GWLB sits at Layer 3. Every packet entering your network routes through GWLB, which sends it to a fleet of security appliances. If the packet passes inspection, GWLB forwards it. If malicious, the appliance drops it.

GWLB uses the GENEVE protocol on port 6081 to encapsulate traffic between itself and the appliance fleet. Target groups contain EC2 instances running security software.

LB type comparison:

Advanced Features

Sticky Sessions (Session Affinity):

A user adds items to their cart. Cart is stored in EC2 memory, not a database. The next request goes to a different instance — the cart is gone. Stickiness ensures the same user always routes to the same EC2 instance.

Three cookie types for ALB:

Common Mistake

Stickiness causes uneven load distribution. If most sticky users end up on one instance, you lose the benefit of load balancing. The better architecture is storing session data externally in ElastiCache Redis — so any instance can serve any user and stickiness is not needed at all.

Cross-Zone Load Balancing:

Without cross-zone, each LB node distributes traffic only to instances in its own AZ. With cross-zone, each LB node distributes evenly across all instances in all AZs.

Remember

ALB cross-zone is always on and free. NLB and GWLB charge for inter-AZ data transfer when cross-zone is enabled.

SSL Termination and SNI:

The LB uses an X.509 certificate from ACM. EC2 instances receive plain HTTP — no SSL cert management on servers.

SNI (Server Name Indication) lets one ALB serve multiple HTTPS domains. The client tells the server which domain it is connecting to at the start of the TLS handshake. ALB reads the SNI hostname and picks the correct certificate.

Connection Draining (Deregistration Delay):

During a deployment you deregister an EC2 instance. That instance is currently handling 200 in-flight requests — users mid-checkout, uploads in progress. Terminating immediately drops all 200.

Connection Draining tells the LB to stop sending new requests to the instance being removed while allowing existing requests to complete.

Configurable from 1 to 3600 seconds. Default is 300 seconds.

Remember

The feature is called "Connection Draining" for CLB and "Deregistration Delay" for ALB and NLB. Same behaviour, different name — a very common confusion point.

Hands-on Lab — ALB with Two Target Instances

Step 1 — Launch two EC2 instances

Step 2 — Create Security Groups

Step 3 — Create Target Group

Step 4 — Create the ALB

Step 5 — Test distribution

Step 6 — Test health check failover

Step 7 — Cleanup

Production Best Practices and Common Pitfalls

• Always restrict EC2 Security Groups to allow only from the LB Security Group — never 0.0.0.0/0 on EC2
• Design /health endpoints to check actual dependencies — a 200 response from an app that cannot reach the database is worse than useless
• Use ALB for all HTTP/HTTPS workloads — do not use NLB unless you specifically need static IPs or extreme throughput
• Use HTTPS listeners with ACM certificates on all internet-facing ALBs — never serve plain HTTP in production
• Add a redirect rule on port 80 to forward all HTTP to HTTPS instead of having a plain HTTP listener
• Use ElastiCache for session storage instead of sticky sessions — sticky sessions cause uneven load distribution and are a scaling bottleneck
• Set Deregistration Delay based on your actual request duration — too high leaves instances draining unnecessarily, too low drops in-flight requests

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Leaving port 22 or port 80 open to 0.0.0.0/0 on EC2 Security Groups when a load balancer is in front. This defeats the entire purpose of the load balancer from a security perspective — attackers can bypass it and hit EC2 directly. EC2 Security Groups should only allow traffic from the LB Security Group ID.

Tip

When debugging why a target is unhealthy, always start with the target health endpoint in the ALB console — it shows the exact reason for the last failed health check including the HTTP status code and response body. This is far faster than SSH-ing into the instance and checking logs manually.

Common Mistakes to Avoid

Common Mistake

Leaving port 80 or 443 open to 0.0.0.0/0 on EC2 Security Groups when an ALB is in front. This defeats the load balancer from a security perspective — attackers bypass the ALB and hit EC2 directly. EC2 SG should allow traffic only from the ALB Security Group ID.

Common Mistake

Designing a /health endpoint that always returns 200 regardless of actual state. If your DB is down but /health says 200, the LB keeps routing traffic to a broken instance. Design /health to check real dependencies.

Tip

Use ElastiCache for session storage instead of sticky sessions. Sticky sessions cause uneven load distribution — the majority of users end up routed to the same instance while others sit idle. Store sessions in Redis and any instance can serve any user.