ELB Types: ALB, NLB, and Gateway Load Balancer

AWS offers three types of load balancers under the Elastic Load Balancing (ELB) service, each designed for different network layers and use cases. The Application Load Balancer (ALB) operates at Layer 7 (the application layer of the OSI model), the Network Load Balancer (NLB) operates at Layer 4 (transport layer), and the Gateway Load Balancer (GWLB) operates at Layer 3 (network layer) with Layer 4 capabilities for transparent inspection. The exam expects you to know the specific features, limitations, and appropriate scenarios for each.

Application Load Balancer (ALB): ALB is a Layer 7 load balancer that makes routing decisions based on content of the HTTP/HTTPS request. When a client sends an HTTP request, the ALB terminates the TLS connection (if HTTPS), reads the request headers, path, query string, and optionally the body, then forwards the request to a target group based on listener rules. ALB supports path-based routing (e.g., /images/* to one target group, /api/* to another), host-based routing (e.g., api.example.com vs. app.example.com), HTTP header-based routing, query string routing, and HTTP method routing. It also supports WebSocket and HTTP/2. ALB can offload TLS termination, reducing backend CPU load. It operates at the connection level: it maintains two separate TCP connections — one with the client and one with the target. This allows it to inspect and modify application-layer data. ALB also provides sticky sessions (session affinity) using cookies, either application-generated or AWS-generated (AWSALB cookie). The default idle timeout is 60 seconds (configurable 1-4000 seconds).

Network Load Balancer (NLB): NLB is a Layer 4 load balancer designed for extreme performance and low latency. It handles millions of requests per second with very low latency (as low as sub-millisecond). NLB does not terminate the TCP connection; instead, it forwards the TCP/UDP traffic directly to the target while preserving the client's source IP address (by default) or using a proxy protocol to pass the client IP. NLB is stateless — it does not maintain connection state; it simply maps connections to targets based on a hash algorithm (5-tuple: source IP, source port, destination IP, destination port, protocol). NLB supports both TCP and UDP, as well as TLS termination (with a listener configured for TLS). It can also handle static IP addresses (one per Availability Zone) and can be assigned an Elastic IP. NLB supports cross-zone load balancing (disabled by default) and health checks using TCP, HTTP, or HTTPS. The idle timeout is 350 seconds for TCP (not configurable). For UDP, there is no timeout because UDP is connectionless.

Gateway Load Balancer (GWLB): GWLB is a Layer 3/4 load balancer that helps you deploy, scale, and manage third-party virtual appliances, such as firewalls, intrusion detection/prevention systems (IDS/IPS), and deep packet inspection (DPI) appliances. GWLB operates in a transparent mode: it does not modify the packet content; it forwards the entire packet (Layer 2-4) to the target appliance. GWLB uses the GENEVE protocol (Generic Network Virtualization Encapsulation) on port 6081 to encapsulate packets between the load balancer and the target appliances. The GWLB is deployed at the edge of a VPC (subnet) and can be used as a next-hop for traffic routing (via route tables). It supports two modes: transparent (the appliance sees the original client IP) and with proxy (the appliance sees the GWLB IP). GWLB health checks are done using the GENEVE protocol. GWLB supports TCP, UDP, and ICMP traffic. It is integrated with AWS Transit Gateway and can be used for east-west traffic inspection.

Load balancers are configured via AWS Management Console, AWS CLI, or CloudFormation. Key CLI commands:

# Create an ALB
alb create-load-balancer --name my-alb --subnets subnet-123 subnet-456 --security-groups sg-789

# Create an NLB
nlb create-load-balancer --name my-nlb --type network --subnets subnet-123 subnet-456

# Create a GWLB
gwlb create-load-balancer --name my-gwlb --type gateway --subnets subnet-123 subnet-456

# Describe load balancers
aws elbv2 describe-load-balancers

# Describe target health
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:...

A large e-commerce platform runs a microservices architecture with services for user authentication, product catalog, shopping cart, and payment processing. Each service is deployed on EC2 instances in Auto Scaling groups. The platform uses an Application Load Balancer to route incoming HTTPS traffic based on URL paths: /auth/* to the authentication service, /products/* to the catalog service, /cart/* to the cart service, and /payments/* to the payment service. The ALB terminates TLS using certificates from ACM, offloading encryption overhead from the backend. The ALB also integrates with AWS WAF to block SQL injection and cross-site scripting attacks. In production, the ALB handles over 50,000 requests per second with sub-10ms latency. The SysOps team monitors CloudWatch alarms for TargetResponseTime and HTTPCode_ELB_5XX_Count. A common misconfiguration is forgetting to update the target group's health check path to the correct endpoint (e.g., /health), causing all targets to be marked unhealthy and the site to go down.

A gaming company deploys a real-time multiplayer game using a custom TCP protocol. The game requires extremely low latency (under 1ms) and can handle up to 1 million concurrent connections. The company chooses a Network Load Balancer to distribute TCP traffic across a fleet of game servers. The NLB is configured with static Elastic IPs so that players can whitelist the IPs for firewall rules. Client IP preservation is enabled so that the game servers see the original player IP for geolocation and anti-cheat measures. Cross-zone load balancing is enabled to distribute traffic evenly across Availability Zones. The NLB is also used as a target for AWS Global Accelerator to further reduce latency and provide a static anycast IP. In production, the NLB processes over 10 Gbps of traffic with minimal packet loss. A common issue is misconfiguring health checks: using TCP health checks on a port that the game server doesn't respond to, causing the server to be marked unhealthy even though it's serving players.

A financial services company needs to inspect all traffic between VPCs and on-premises data centers for compliance. They deploy a Gateway Load Balancer with a fleet of third-party firewall appliances (e.g., Palo Alto Networks VM-Series). The GWLB is placed in a dedicated inspection VPC, and route tables in the spoke VPCs point to the GWLB as the next hop for all inter-VPC traffic. The GWLB distributes traffic across multiple firewall appliances using GENEVE encapsulation. The appliances perform deep packet inspection and forward allowed traffic back to the GWLB, which then forwards it to the destination. This setup allows transparent inspection without modifying the original packet headers. The company scales the number of firewall appliances based on traffic load using Auto Scaling. In production, the GWLB handles up to 40 Gbps of traffic. A common misconfiguration is not properly configuring the GENEVE encapsulation on the firewall appliances, causing traffic to be dropped.