5.1.2. Load Balancing for Scalability & Performance (ALB, NLB, GLB)

Load balancers (ALB, NLB, GLB) efficiently distribute incoming application traffic, ensuring scalability, high availability, and optimal performance for diverse workloads by operating at different network layers.

Scenario: You need to load balance HTTP/S traffic for a web application, routing requests based on URL paths. Separately, you have a gaming application that requires extremely low-latency TCP connections and static IP addresses for its backend servers.

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets (e.g., EC2 instances, containers, Lambda functions). For network specialists, selecting the right load balancer type is crucial for meeting specific application needs.

Key ELB Types for Scalability & Performance:

• Application Load Balancer (ALB):
  • Layer: Layer 7 (Application layer - HTTP/HTTPS).
  • Features: Content-based routing (path, host headers), sticky sessions, WebSockets support, request tracing.
  • Use Cases: Modern web applications, microservices that need intelligent routing.
• Network Load Balancer (NLB):
  • Layer: Layer 4 (Transport layer - TCP/UDP/TLS).
  • Features: Designed for extreme performance and ultra-low latency, handles millions of requests per second. Provides static IP addresses.
  • Use Cases: High-throughput, low-latency workloads (e.g., gaming, IoT, financial trading), applications that require static IP addresses.
• Gateway Load Balancer (GLB):
  • Layer: Layer 3 (Network layer) and Layer 4 (Transport layer).
  • Features: Transparently deploys and manages virtual appliances (e.g., firewalls, intrusion detection/prevention systems) in your network path. Uses GENEVE protocol.
  • Use Cases: Centralizing inspection of traffic, managing fleets of third-party network virtual appliances.
• ELB details the exam probes:
  • Scheme: An internal load balancer has only private IPs and is reachable only from inside the VPC (and connected networks) — the choice for tier-to-tier traffic. An internet-facing one has public IPs.
  • Listener rules vs. target groups: Routing logic lives in the ALB's listener rules (conditions on path, host header, HTTP header or method, query string or source IP → forward, redirect or fixed response). A target group only holds targets and their health check. AWS WAF attaches to an ALB, not an NLB.
  • Target types: instance, ip (any private IP, including on-premises servers reachable over Direct Connect or VPN), lambda (ALB only) and alb (an ALB behind an NLB). Buckets and security groups are never targets.
  • Routing algorithm and stickiness: An ALB target group uses round robin by default (least outstanding requests and weighted random are opt-in); an NLB hashes each flow. Sticky sessions (a load-balancer or application cookie) are enabled on the target group.
  • Cross-zone load balancing: On by default for ALB (it can be turned off per target group), off by default for NLB and GWLB. With it off, each AZ's load balancer node receives an equal share of traffic and sends it only to targets in its own AZ — so the AZ with fewer targets loads each of them harder.
  • Health checks: A target becomes unhealthy after UnhealthyThresholdCount consecutive failed checks and healthy again after HealthyThresholdCount consecutive successes. An ALB's default success code is 200, and the targets' security group must allow the load balancer's security group on the health check port.
  • TLS: HTTPS (ALB) and TLS (NLB) listeners take certificates from AWS Certificate Manager (ACM) — public, imported, or issued by ACM Private CA. The listener's security policy fixes the TLS protocols and ciphers; a certificate list plus SNI serves several hostnames from one listener; an NLB TLS listener can also carry an ALPN policy. An NLB TCP listener passes TLS through untouched, so only the targets decrypt.
  • Private PKI: ACM Private CA issues certificates for internal names (e.g. payment.internal.corp) that a public CA cannot validate — the basis for internal TLS and mutual TLS. Clients trust them only once the private CA's root certificate is in their trust stores, and revoked certificates are published in a signed Certificate Revocation List (CRL) or through OCSP.
  • Deletion protection: A load balancer attribute, off by default, that refuses any delete until it is turned off.
  • EKS: The AWS Load Balancer Controller watches Kubernetes Ingress objects (→ ALB) and LoadBalancer Services (→ NLB) and provisions the load balancers. The Amazon VPC CNI gives each pod a private IP from the VPC subnet, held as a secondary IP on one of the node's ENIs.

Practical Implementation: Creating an ALB and NLB (Conceptual)

# 1. Create an Application Load Balancer (ALB)
aws elbv2 create-load-balancer \
  --name MyWebAppALB \
  --subnets subnet-0a1b2c3d subnet-0e4f5g6h \
  --security-groups sg-0abcdef1234567890 \
  --scheme internet-facing

# 2. Create a Network Load Balancer (NLB)
aws elbv2 create-load-balancer \
  --name MyGamingNLB \
  --type network \
  --subnets subnet-0a1b2c3d subnet-0e4f5g6h \
  --scheme internet-facing \
  --tags Key=Name,Value=GamingNLB

⚠️ Common Pitfall: Choosing an ALB for a non-HTTP/S workload or when static IP addresses are required. ALBs are Layer 7 and do not provide static IPs. NLBs are the correct choice for these scenarios.

Key Trade-Offs:

• Layer 7 Features (ALB) vs. Raw Performance/Static IPs (NLB): ALBs offer advanced routing and application-level features but introduce more latency. NLBs offer extreme performance and static IPs but lack Layer 7 intelligence.

Reflection Question: How do load balancers (ALB for Layer 7, NLB for Layer 4, GLB for virtual appliances) efficiently distribute incoming application traffic, ensuring scalability, high availability, and optimal performance for diverse workloads by operating at different network layers?