The OSI Model Foundation: A Traveling Packet
Before diving into load balancers, understanding the OSI model layers clarifies what each load balancer type can “see” and manipulate. Imagine sending a message from your laptop to a website:
| Layer | Name | What It Contains | Example |
|---|---|---|---|
| Layer 7 | Application | Actual HTTP/HTTPS request | GET /api/users |
| Layer 4 | Transport | TCP/UDP packets with ports | Source: 54321, Dest: 443 |
| Layer 3 | Network | IP addresses for routing | 192.168.1.100 → 10.0.0.5 |
| Layer 1 | Physical | Electrical signals | Voltage traveling through cables |
Load balancers operate at different layers depending on how much of this packet they can read and understand. The higher the layer, the more application context they have—but also more processing overhead.
Network Load Balancer: Layer 4 Speed
The Network Load Balancer (NLB) operates at Layer 4, meaning it works with raw TCP and UDP traffic. It doesn’t understand HTTP/HTTPS—it simply forwards packets based on IP addresses and ports.
What Layer 4 Can See
- Source IP: 192.168.1.100
- Destination IP: 10.0.0.5
- Source Port: 54321
- Destination Port: 443
- Protocol: TCP or UDP
What it CANNOT see: URL paths, HTTP headers, cookies, request methods, query parameters—anything inside the application payload.
Network Load Balancer Strengths
- Ultra-Low Latency: Handles millions of requests per second with microsecond response times
- Static IP Support: Provides fixed IPs for whitelisting and DNS
- Protocol Flexibility: Works with any TCP/UDP traffic, not just HTTP
- Preserve Source IP: Backend servers see actual client IP addresses
- TLS Offloading: Can terminate SSL/TLS connections while maintaining Layer 4 performance
Best Use Cases
- Gaming Servers: Require ultra-low latency and handle millions of concurrent connections
- Real-Time Applications: Video streaming, VoIP, financial trading platforms
- IoT Workloads: Massive numbers of device connections with simple protocols
- Non-HTTP Protocols: MQTT, SMTP, custom TCP applications
- Extreme Scale: When you need to handle 10M+ requests per second
Application Load Balancer: Layer 7 Intelligence
The Application Load Balancer (ALB) operates at Layer 7, meaning it understands HTTP and HTTPS protocols. It can inspect the content of requests and route traffic based on application-level data.
What Layer 7 Can See
- HTTP Method: GET, POST, PUT, DELETE
- URL Path:
/api/usersvs/api/orders - Host Headers:
api.example.comvswww.example.com - Query Parameters:
?user_id=123®ion=us-east - HTTP Headers: Authorization, Content-Type, User-Agent
- Cookies: Session IDs, authentication tokens
Plus everything Layer 4 sees: IPs, ports, protocols
Application Load Balancer Strengths
- Content-Based Routing: Route
/api/*to microservices,/static/*to CDN - Host-Based Routing: Direct
api.example.comandwww.example.comto different targets - HTTP/2 and WebSocket Support: Modern protocol compatibility
- Built-in Authentication: Integrate with Cognito, OIDC providers
- WAF Integration: Web Application Firewall for security rules
- Advanced Health Checks: Verify specific HTTP responses, not just connection
Best Use Cases
- Microservices Architectures: Route different API endpoints to different services
- Multi-Tenant Applications: Direct traffic based on host headers or subdomains
- A/B Testing: Route percentage of traffic to different versions
- API Gateways: Need content inspection, authentication, rate limiting
- Container Workloads: ECS and EKS benefit from dynamic target registration
The Critical Difference: Routing Intelligence
The fundamental distinction between Layer 4 and Layer 7 load balancing is what information they use for routing decisions:
Network Load Balancer (Layer 4) Routing
Scenario: Three requests arrive at your load balancer:
Request 1: GET /api/users
Request 2: GET /api/orders
Request 3: POST /api/checkoutWhat NLB sees: Three TCP connections to port 443
Routing decision: Distributes all three randomly or round-robin to backend servers. It cannot route based on the URL path because it doesn’t inspect the HTTP payload.
Application Load Balancer (Layer 7) Routing
Same scenario: Three requests arrive
Request 1: GET /api/users
Request 2: GET /api/orders
Request 3: POST /api/checkoutWhat ALB sees: Three distinct HTTP requests with different paths and methods
Routing decision:
/api/users→ User Service (Target Group 1)/api/orders→ Order Service (Target Group 2)/api/checkout→ Payment Service (Target Group 3)
This routing intelligence is why ALB is essential for modern microservices—it eliminates the need for application-level routing logic.
Performance Trade-offs
| Metric | Network Load Balancer | Application Load Balancer |
|---|---|---|
| Latency | ~100 microseconds | ~10-50 milliseconds |
| Throughput | Millions RPS | Tens of thousands RPS |
| Connection Handling | Pass-through (preserves connection) | Terminates and re-establishes |
| Processing Overhead | Minimal (packet forwarding) | Higher (HTTP parsing) |
| Cost | Lower (simpler processing) | Higher (more compute intensive) |
Real-World Architecture Examples
Example 1: E-Commerce Platform (Use ALB)
Requirements:
- Route
/api/products→ Product Service - Route
/api/cart→ Shopping Cart Service - Route
/api/checkout→ Payment Service - Route
/static/*→ S3/CloudFront - A/B test checkout flow (10% of users to new version)
Why ALB: Requires content-based routing, path inspection, and weighted target groups for A/B testing.
Example 2: Multiplayer Gaming (Use NLB)
Requirements:
- Handle 50,000+ concurrent UDP connections
- Maintain sub-50ms latency for player actions
- Preserve client IP addresses for anti-cheat systems
- Support custom binary protocol (not HTTP)
Why NLB: Requires ultra-low latency, UDP support, source IP preservation, and doesn’t need HTTP routing.
Example 3: Hybrid Architecture (Use Both)
Setup:
- NLB at the internet edge (TLS termination, static IPs)
- NLB forwards to ALB in private subnet
- ALB performs content-based routing to microservices
Why Both: NLB provides static IPs for DNS and low-latency TLS termination, while ALB handles intelligent routing. Best of both worlds at the cost of additional complexity.
Decision Framework
Choose your load balancer based on these questions:
Use Network Load Balancer When:
- You need ultra-low latency (gaming, financial trading)
- You’re handling non-HTTP protocols (TCP, UDP, custom protocols)
- You need static IP addresses for whitelisting
- You must preserve source IP addresses
- You’re scaling to millions of requests per second
- All traffic goes to the same backend (no routing logic needed)
Use Application Load Balancer When:
- You’re running microservices that need path-based routing
- You need host-based routing (multiple domains)
- You want built-in authentication (Cognito, OIDC)
- You need WAF integration for security
- You’re using containerized workloads (ECS, EKS)
- You need A/B testing or canary deployments
- You require HTTP/2 or WebSocket support
What’s Next: Load Balancing Algorithms
Understanding layers is just the foundation. Both NLB and ALB support multiple algorithms for distributing traffic across targets:
- Round Robin: Sequential distribution
- Least Outstanding Requests: Route to server with fewest active connections
- Flow Hash (NLB): Consistent hashing for session affinity
- Weighted Targets: Send more traffic to higher-capacity servers
The next article will cover these algorithms in detail, explaining when to use each strategy and how they affect performance, session persistence, and failover behavior.
Key Takeaway: Layer 4 (NLB) sees IPs and ports. Layer 7 (ALB) sees URLs, headers, and application content. Choose based on what routing decisions your architecture requires, not which sounds more sophisticated. Most modern web applications benefit from ALB’s routing intelligence, but high-performance, low-latency workloads demand NLB’s speed.
