Elastic Load Balancing: ALB, NLB, and Gateway Load Balancer

You've built a microservice that handles 10,000 requests per second. Then a single bad deploy causes a 5-second latency spike, and your entire system collapses because every request queues behind the slow one. That's what happens when you don't use a load balancer—or use the wrong one. Elastic Load Balancing isn't just about distributing traffic; it's about isolating failures, scaling without downtime, and enforcing security policies at the edge. Most teams pick ALB by default, but that choice can cost you 50ms of latency or force you to re-architect for gRPC. The real question isn't whether to use a load balancer—it's which type and how to configure it for your specific failure modes. In this post, we'll break down ALB, NLB, and Gateway Load Balancer with production patterns, common pitfalls, and code examples that actually run.

Why Elastic Load Balancing?

In production, you don't serve traffic from a single server. You scale horizontally, and that means you need a single entry point that distributes requests across multiple targets. Elastic Load Balancing (ELB) is that entry point. It handles traffic distribution, health checks, and automatic scaling integration. But not all load balancers are equal. AWS offers three types: Application Load Balancer (ALB) for HTTP/HTTPS, Network Load Balancer (NLB) for TCP/UDP/TLS, and Gateway Load Balancer (GWLB) for third-party appliances. Choosing the wrong one causes latency, dropped connections, or cost overruns. This article breaks down each type, when to use them, and how to avoid common pitfalls.

aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-abc123 subnet-def456 \
  --security-groups sg-12345678 \
  --scheme internet-facing \
  --type application \
  --ip-address-type ipv4

Application Load Balancer: Layer 7 Routing

ALB operates at Layer 7 (application layer). It understands HTTP/HTTPS, WebSocket, and gRPC. This means it can route based on URL path, host header, query string, or HTTP method. For microservices, ALB is the standard ingress point. You can define listener rules that forward traffic to different target groups. For example, /api/ goes to backend services, /static/ goes to S3. ALB also supports sticky sessions (cookies), SSL termination, and AWS WAF integration. However, ALB adds latency (typically 1-2ms) and cannot handle raw TCP or UDP. Use it when you need content-based routing or when your clients speak HTTP.

aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
  --protocol HTTPS \
  --port 443 \
  --ssl-policy ELBSecurityPolicy-2016-08 \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/1234567890123456

Network Load Balancer: Layer 4 Performance

NLB operates at Layer 4 (transport layer). It handles TCP, UDP, and TLS traffic with ultra-low latency (sub-millisecond). NLB doesn't inspect packets beyond the transport header, so it's fast and can handle millions of requests per second. It preserves the client IP address (no proxy protocol needed) and supports static IPs (Elastic IPs). NLB is ideal for non-HTTP protocols, real-time streaming, or when you need to offload TLS at the load balancer. However, NLB lacks content-based routing and WAF integration. Use it when performance is critical or your application uses custom protocols.

aws elbv2 create-load-balancer \
  --name my-nlb \
  --subnets subnet-abc123 subnet-def456 \
  --scheme internet-facing \
  --type network \
  --ip-address-type ipv4

Gateway Load Balancer: Transparent Appliance Insertion

GWLB is the newest type, designed for third-party virtual appliances like firewalls, IDS/IPS, and deep packet inspection. It operates at Layer 3 (network layer) and uses the GENEVE protocol to encapsulate traffic. GWLB acts as a transparent bump in the wire: it receives traffic, forwards it to a target group of appliances, and then routes the processed traffic back to the original destination. This allows you to insert security appliances without changing routing. GWLB supports automatic scaling of appliances and health checks. However, it adds latency (encapsulation overhead) and requires appliances that support GENEVE. Use it when you need to scale security appliances horizontally.

aws elbv2 create-load-balancer \
  --name my-gwlb \
  --subnets subnet-abc123 subnet-def456 \
  --scheme internet-facing \
  --type gateway \
  --ip-address-type ipv4

Target Groups: Where Traffic Goes

Each load balancer routes traffic to target groups. A target group contains one or more targets (EC2 instances, IP addresses, Lambda functions, or ALBs). You define health checks per target group. ALB target groups can be of type instance, ip, or lambda. NLB target groups can be instance or ip. GWLB target groups are always ip (appliance IPs). Target groups are independent of the load balancer; you can reuse them across multiple listeners. For ALB, you can also register targets by instance ID or private IP. For NLB, using IP targets allows you to route to on-premises servers via AWS Direct Connect. Always configure health checks with realistic intervals and thresholds to avoid routing traffic to unhealthy targets.

aws elbv2 create-target-group \
  --name my-tg \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-12345678 \
  --health-check-protocol HTTP \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --health-check-timeout-seconds 5 \
  --healthy-threshold-count 3 \
  --unhealthy-threshold-count 3

Sticky Sessions: Keeping Users on the Same Target

Sticky sessions (session affinity) ensure a client's requests are always sent to the same target. ALB supports sticky sessions using cookies (AWSALB or custom). NLB supports sticky sessions using source IP (hash of client IP) or a cookie (AWSELB). GWLB does not support sticky sessions. Sticky sessions are useful for stateful applications like shopping carts or login sessions. However, they can cause uneven load distribution if a few clients generate most traffic. Use them sparingly. For ALB, you can set the cookie duration. For NLB, source IP stickiness works best when clients have stable IPs. Avoid sticky sessions if your application is stateless; instead, use a distributed cache like ElastiCache.

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/1234567890123456 \
  --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=lb_cookie Key=stickiness.lb_cookie.duration_seconds,Value=86400

Connection Draining and Deregistration Delay

When a target is deregistered (e.g., during scaling in or replacement), the load balancer stops sending new requests to it but allows in-flight requests to complete. This is called connection draining for ALB and deregistration delay for NLB and GWLB. The default delay is 300 seconds. You can adjust it based on your application's request duration. For long-lived WebSocket connections, set it higher. For short-lived HTTP requests, set it lower to speed up deployments. If you set it too low, in-flight requests may be interrupted. If too high, deployments take longer. Monitor the Deregistering state in CloudWatch to ensure connections drain properly.

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-tg/1234567890123456 \
  --attributes Key=deregistration_delay.timeout_seconds,Value=120

Cross-Zone Load Balancing and Availability

Cross-zone load balancing distributes traffic evenly across all targets in all enabled Availability Zones (AZs). Without it, traffic is distributed only within each AZ, which can cause uneven load if targets are not balanced across AZs. ALB has cross-zone enabled by default (no extra cost). NLB has it disabled by default (no extra cost). GWLB has it enabled by default (no extra cost). For NLB, enabling cross-zone can increase cross-AZ data transfer costs. For fault tolerance, always deploy targets in at least two AZs. Use cross-zone to ensure even distribution, but be aware of cost implications for NLB.

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/1234567890123456 \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

Security: SSL/TLS and WAF Integration

ALB supports SSL/TLS termination, allowing you to offload encryption from your targets. You can upload certificates via ACM or IAM. ALB also integrates with AWS WAF to block malicious requests. NLB supports TLS termination but not WAF. GWLB does not terminate TLS. For ALB, you can configure security policies to control cipher suites. For NLB, TLS termination is done at the listener level, and you can use mutual TLS (mTLS) for client certificate authentication. Always use ACM for certificate management (auto-renewal). For compliance, enforce TLS 1.2 or higher. Use WAF to filter common attacks like SQL injection and XSS.

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:regional/webacl/my-web-acl/12345678-1234-1234-1234-123456789012 \
  --resource-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188

Monitoring and Troubleshooting

ELB provides CloudWatch metrics like RequestCount, TargetResponseTime, HTTPCode_ELB_5XX, and HealthyHostCount. For ALB, you can also enable access logs (S3) and request tracing (X-Ray). For NLB, enable flow logs (VPC Flow Logs) for connection-level data. For GWLB, monitor GENEVE encapsulation errors. Common issues: unhealthy targets (check health check path), TLS handshake failures (check certificate), and cross-zone misconfiguration. Use CloudWatch alarms to alert on high 5xx rates or low healthy host counts. For deep troubleshooting, enable access logs and analyze with Athena.

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 \
  --attributes Key=access_logs.s3.enabled,Value=true Key=access_logs.s3.bucket,Value=my-logs-bucket Key=access_logs.s3.prefix,Value=alb-logs

Cost Optimization and Scaling

ELB costs include hourly charges and LCU/GLCU usage. ALB LCU dimensions: new connections, active connections, processed bytes, and rule evaluations. NLB LCU dimensions: new flows, active flows, and processed bytes. GWLB GLCU dimensions: new flows, active flows, and processed bytes. To optimize, right-size your load balancer type. For low traffic, use ALB with a single target. For high throughput, use NLB. Use target group stickiness to reduce connection churn. Enable connection draining to avoid failed requests. Use Auto Scaling to match capacity. Consider using a single NLB for multiple services with different ports to reduce costs.

# Example: Estimate LCU for ALB
# New connections: 1000/sec
# Active connections: 10000
# Processed bytes: 1 GB/hour
# Rule evaluations: 10 per request
# LCU = max(NewConn/1000, ActiveConn/3000, Bytes/1GB, RuleEval/1000)
# = max(1, 3.33, 1, 10) = 10 LCU
# Cost = 10 LCU * $0.008 per LCU-hour = $0.08/hour

Real-World Architecture: Combining ALB, NLB, and GWLB

In complex architectures, you might use multiple load balancers. For example, an NLB fronting an ALB for TLS termination and static IPs. Or a GWLB inserted between an internet-facing NLB and internal ALB for security inspection. Common pattern: NLB (static IP) -> GWLB (firewall) -> ALB (routing) -> targets. This gives you static IPs, security inspection, and content-based routing. However, each hop adds latency. For latency-sensitive apps, minimize hops. Another pattern: use ALB for public-facing microservices, NLB for internal RPC traffic, and GWLB for network security. Always document the traffic flow and test under load.

Resources:
  PublicNLB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Type: network
      Scheme: internet-facing
      Subnets: [!Ref PublicSubnetA, !Ref PublicSubnetB]
  GWLB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Type: gateway
      Scheme: internal
      Subnets: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
  InternalALB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Type: application
      Scheme: internal
      Subnets: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
      SecurityGroups: [!Ref ALBSecurityGroup]