Day-26 | AWS Load Balancers | ALB vs NLB vs GWLB | Detailed Comparison

This chapter explores the core architecture, mechanics, and use cases of AWS Load Balancers. We will dissect how traffic flows through the seven layers of the OSI model, analyze the operational differences between Application Load Balancers (ALB), Network Load Balancers (NLB), and Gateway Load Balancers (GWLB), and establish a clear decision framework for selecting the right load-balancing tier for production workloads.

1. The Core Problem: Why Do We Need Load Balancers?

To understand the necessity of a load balancer, we must look at how applications scale from initial deployment to high-traffic production environments.

Real-Life Analogy: The Game Application Bottleneck

Imagine you are an application developer who has built a multiplayer game. You deploy this game on a single AWS EC2 instance.

• The Initial State: When you launch the game, you have only five concurrent users. The single EC2 instance easily handles the traffic. The CPU and memory utilization remain low, and the user experience is seamless.
• The Scaling Problem: Your game suddenly goes viral. Instead of 5 users, you now have hundreds or thousands of concurrent users attempting to connect.
• The Failure Mode: A single virtual machine has finite hardware resources (CPU, RAM, Network Bandwidth). Under heavy concurrent load, the instance becomes overwhelmed. Users experience extreme latency (slowness) or complete downtime (502/504 errors), leading to a poor user experience.

The Solution: Horizontal Scaling with a Load Balancer

To prevent downtime and ensure high availability, you must scale horizontally by deploying multiple identical copies of your application across several EC2 instances. However, clients need a single point of entry. This is where a Load Balancer is introduced.

By placing a load balancer in front of your compute resources, you abstract the backend infrastructure. The load balancer acts as a reverse proxy, receiving all incoming client requests and distributing them across healthy backend instances.

2. What is a Load Balancer? Core Concepts & Techniques

A load balancer is a physical or virtual appliance designed to distribute network or application traffic across a cluster of servers. This distribution ensures optimal resource utilization, maximizes throughput, minimizes response time, and avoids overloading any single resource.

Load Balancing Algorithms

The method by which a load balancer decides where to route a packet depends on its configuration and the specific algorithm used:

• Round Robin: The most basic load-balancing technique. If you have three backend servers with equal specifications and receive 100 requests, the load balancer distributes them sequentially:

• Weighted/Ratio-Based Routing: If one of your EC2 instances is significantly more powerful (e.g., a c6g.xlarge vs. two t3.medium instances), you can assign weights to the targets. The load balancer might route $50\%$ of the traffic to the powerful instance and $25\%$ to each of the smaller instances.
• Least Connections: Routes traffic to the server with the fewest active transactions. This is highly effective for long-running requests.
• IP Hash: Computes a hash of the client's IP address to determine which server receives the request, ensuring the client consistently hits the same backend server.

Industry Landscape

While AWS provides managed load-balancing services, several open-source and commercial self-managed alternatives exist in the industry:

3. The OSI Model: Understanding the 7 Layers of Traffic Flow

To understand why AWS offers different types of load balancers, we must first understand the Open Systems Interconnection (OSI) model. The OSI model standardizes the communication functions of a telecommunication or computing system into seven distinct logical layers.

The Seven Layers Explained

• Layer 7: Application Layer The layer closest to the end-user. It directly interacts with software applications (e.g., Google Chrome, Postman).

  • Protocols: HTTP, HTTPS, FTP, SFTP, SMTP, DNS.
  • Role: Decides how applications talk to the network.

• Layer 6: Presentation Layer Responsible for data translation, encryption, and compression.

  • Protocols/Standards: SSL, TLS, ASCII, JPEG.
  • Role: Ensures that data sent from the application layer of one system is readable by the application layer of another. This is where TLS encryption/decryption typically occurs.

• Layer 5: Session Layer Manages the sessions (connections) between local and remote applications.

  • Role: Establishes, coordinates, and terminates conversations between applications. It tracks session state and metadata.

• Layer 4: Transport Layer Responsible for host-to-host communication, flow control, and error recovery.

  • Protocols: TCP (Transmission Control Protocol), UDP (User Datagram Protocol).
  • Role: Splits large application messages into smaller packets (segments) for transmission and ensures reliable delivery.

• Layer 3: Network Layer Responsible for packet forwarding and routing through intermediate routers.

  • Protocols: IP (IPv4, IPv6), ICMP.
  • Role: Determines the physical path the data should take based on network conditions, priority, and IP addressing.

• Layer 2: Data Link Layer Provides node-to-node data transfer over a physical link.

  • Protocols: Ethernet, MAC addressing, PPP.
  • Role: Packages raw bits from the physical layer into frames and handles local network delivery via switches.

• Layer 1: Physical Layer The physical hardware transmission medium.

  • Components: Fiber optic cables, coaxial cables, copper wires, network interface cards (NICs).
  • Role: Transmits raw, unstructured bitstreams over a physical medium.

4. How a Packet Travels: Step-by-Step Flow from Client to Server

When a user opens a browser and requests a URL (e.g., https://linkedin.com/in/abhishekveeramalla), the request travels down the client's network stack, across the internet, and up the server's network stack.

5. Deep Dive: Application Load Balancer (ALB) - Layer 7

The Application Load Balancer (ALB) operates at the highest layer of the OSI model: Layer 7 (Application Layer). Because it operates at this layer, the ALB is highly application-aware. It does not merely route packets blindly; it inspects the contents of the HTTP/HTTPS header to make intelligent routing decisions.

Advanced Routing Capabilities

An ALB can inspect various components of an incoming HTTP request:

• Path-Based Routing: You can route traffic to different target groups based on the URL path.
  • example.com/payments $\rightarrow$ routed to the Payment Service Target Group.
  • example.com/transactions $\rightarrow$ routed to the Transaction Service Target Group.
  • example.com/login $\rightarrow$ routed to the Identity Service Target Group.
• Host-Based Routing: You can route traffic based on the HTTP Host header.
  • api.example.com $\rightarrow$ routed to the API Target Group.
  • portal.example.com $\rightarrow$ routed to the Web Portal Target Group.
• Header/Query-String/Method-Based Routing: You can route traffic based on specific HTTP headers, query parameters, or HTTP methods (e.g., routing POST requests to a write-optimized database cluster and GET requests to a read-replica cluster).

SSL/TLS Offloading (SSL Termination)

ALB supports SSL offloading. The ALB decrypts the incoming HTTPS traffic (using an SSL certificate managed via AWS Certificate Manager) and forwards the decrypted HTTP traffic to the backend EC2 instances. This relieves the backend instances of the CPU-intensive task of cryptographic decryption.

Architectural Trade-offs of ALB

• Latency (The "Hop" Delay): Because the ALB must intercept, terminate the TCP connection, decrypt the TLS layer, and inspect the Layer 7 HTTP headers before making a routing decision, it introduces a small amount of latency (a few milliseconds).
• Cost: ALB is feature-rich and requires more compute resources under the hood from AWS to parse application layers. Consequently, it is generally more expensive than Layer 4 routing options.

6. Deep Dive: Network Load Balancer (NLB) - Layer 4

The Network Load Balancer (NLB) operates at Layer 4 (Transport Layer). It is designed to handle tens of millions of requests per second with ultra-low latency. Unlike the ALB, the NLB does not look at HTTP headers, cookies, or URL paths. It only inspects Layer 4 TCP/UDP packets.

Key Characteristics of NLB

• Ultra-Low Latency: Because it does not inspect Layer 7 payloads, there is no "stoppage" or deep packet inspection. It routes packets directly to the backend instances, making it significantly faster than an ALB.
• Static IP Support: Unlike an ALB (which has dynamic IP addresses and requires DNS resolution), an NLB can be assigned a static Elastic IP address per Availability Zone. This is critical for clients with strict firewall rules that only allow traffic to specific IP addresses.
• High Throughput: It is capable of handling sudden, volatile traffic spikes (e.g., millions of concurrent connections) without pre-warming.

The Importance of Sticky Sessions in Content Streaming

For applications like video streaming (e.g., YouTube, Netflix) or real-time gaming, maintaining a continuous connection to a single backend server is critical.

If you used a standard round-robin ALB without sticky sessions for a video stream, individual packets of the video file could be distributed across different backend servers. This would break the stream state and cause buffering or playback errors.

The NLB handles this by establishing a Sticky Session (or session affinity) at the transport layer, ensuring that once a connection is established between a client and a backend instance, all subsequent packets from that client are routed to the exact same backend instance for the duration of the session.

7. Deep Dive: Gateway Load Balancer (GWLB) - Virtual Appliances

The Gateway Load Balancer (GWLB) is a specialized load balancer designed for deploying, scaling, and managing third-party virtual appliances. These appliances include firewalls, intrusion detection and prevention systems (IDS/IPS), deep packet inspection systems, and VPN gateways.

Why Can't We Use ALB or NLB for Firewalls?

Virtual security appliances (like Palo Alto, Check Point, or Fortinet firewalls) operate transparently. They must inspect all network traffic (including raw IP packets, routing protocols, and non-HTTP traffic) before it reaches your application servers.

• Traffic Incompatibility: ALBs and NLBs are designed to route traffic directly to application endpoints. They cannot easily route raw, un-inspected traffic to a security appliance, wait for inspection, and then forward the approved traffic to the destination.
• Security & Encapsulation: GWLB acts as a single gateway for all entry and exit traffic. It uses the GENEVE protocol (on port 6081) to encapsulate the original IP packets and send them to the virtual appliance for inspection. Once the appliance approves the packet, it sends it back to the GWLB, which then routes it to its actual destination.

8. Architectural Comparison: ALB vs. NLB vs. GWLB

To synthesize the differences between these three managed load balancers, we can compare them across key operational dimensions:

9. Real-World Use Cases & Decision Matrix

As a DevOps Engineer or Cloud Architect, selecting the correct load balancer is a critical architectural decision. Use the following decision matrix to guide your selection:

Scenario A: Microservices-Based E-Commerce Platform

• Requirement: You have a web application where /cart goes to a Cart microservice, /checkout goes to a Checkout microservice, and you need to terminate SSL certificates.
• Decision: ALB. The requirement demands path-based routing and Layer 7 application awareness.

Scenario B: Real-Time Multiplayer Game Server

• Requirement: Your game client communicates via raw UDP packets. You need ultra-low latency, and any delay in packet transmission will ruin the player experience.
• Decision: NLB. It operates at Layer 4, supports UDP, and routes packets with microsecond latency.

Scenario C: Enterprise Security Compliance

• Requirement: All incoming traffic from the internet must pass through a cluster of third-party Palo Alto firewalls for deep packet inspection before hitting any internal AWS resources.
• Decision: GWLB. It is specifically built to scale and manage virtual security appliances transparently using GENEVE encapsulation.

10. Summary and Key Takeaways

• Load balancers provide high availability by distributing incoming traffic across multiple backend instances, preventing single points of failure and application downtime.
• The OSI Model is the foundation of load balancing. ALBs operate at Layer 7 (Application), NLBs operate at Layer 4 (Transport), and GWLBs operate at Layer 3 (Network).
• ALB is highly intelligent but slower. It inspects HTTP/HTTPS headers, paths, and cookies to perform advanced routing, but introduces minor latency due to deep packet inspection.
• NLB is built for raw speed and scale. It routes TCP/UDP packets without inspecting application data, making it the ideal choice for video streaming, gaming, and high-throughput workloads.
• Sticky sessions are crucial for streaming. NLB ensures that continuous data streams (like video playback) are bound to a single backend instance to maintain session state.
• GWLB is a security-focused gateway. It transparently routes raw network traffic through virtual security appliances (firewalls, VPNs) using the GENEVE protocol.
• Static IPs are exclusive to NLB. If your application architecture or client firewalls require whitelisting static IP addresses, you must use an NLB.