Load Balancer Selection & Configuration
Key concepts
ALB for HTTP/HTTPS
NLB for TCP/UDP performance
GWLB for appliances
Target group types
Cross-zone load balancing
Overview
Elastic Load Balancing (ELB) is the AWS service that distributes incoming traffic across multiple targets such as EC2 instances, containers, and IP addresses. ELB offers three production load balancer types for the SAA-C03 exam: the Application Load Balancer (ALB) for HTTP and HTTPS traffic at Layer 7, the Network Load Balancer (NLB) for TCP and UDP traffic at Layer 4 with extreme performance, and the Gateway Load Balancer (GWLB) for inserting third-party virtual appliances such as firewalls into the traffic path. Targets are grouped into target groups, and each load balancer routes to one or more of these groups.
This topic is high-yield on SAA-C03 through "which load balancer" scenarios. You should know how to match each load balancer to the protocol and use case, the three target group types (instance, IP, Lambda), how listeners and routing rules work, the role of health checks, and how cross-zone load balancing differs between ALB and NLB (including its billing impact). Picking the wrong type, or misconfiguring cross-zone balancing, is a common source of both exam mistakes and uneven real-world traffic.
Match the Load Balancer to the Protocol
Use ALB for HTTP and HTTPS with content-based routing, NLB for TCP and UDP when you need millions of requests per second, static IPs, or the lowest latency, and GWLB to transparently route traffic through inline security appliances. The traffic protocol and the routing intelligence you need determine the choice.
Anchor on the OSI layer: ALB is Layer 7 (HTTP/HTTPS, path and host routing), NLB is Layer 4 (TCP/UDP, static IP and Elastic IP support, preserves source IP), GWLB is Layer 3 plus the GENEVE protocol on port 6081 for appliances. Remember cross-zone is on by default and free on ALB, off by default on NLB and GWLB where enabling it adds inter-AZ data charges.
Key Concepts
Application Load Balancer (ALB) for HTTP/HTTPS
Layer 7 Content-Based Routing
The Application Load Balancer (ALB) operates at Layer 7 (the application layer) and understands HTTP and HTTPS. It can route requests based on the URL path (for example, /api to one target group and /images to another), the host header, HTTP headers, query strings, and the source IP. ALB supports redirects, fixed responses, authentication through Amazon Cognito or OpenID Connect, HTTP/2, gRPC, and WebSockets. It is the default choice for web applications and microservices that need intelligent routing.
Listeners and Rules
A listener checks for connections on a configured protocol and port (for example HTTPS on 443). On an ALB the listener has rules evaluated in priority order, each with conditions (path, host, header) and actions (forward to a target group, redirect, return a fixed response). TLS certificates for HTTPS listeners are managed through AWS Certificate Manager (ACM), and Server Name Indication (SNI) lets one listener serve multiple certificates for different domains.
Network Load Balancer (NLB) for TCP/UDP Performance
Layer 4 Ultra-Low Latency
The Network Load Balancer (NLB) operates at Layer 4 (the transport layer) and handles TCP, UDP, and TLS. It is built for extreme performance, scaling to millions of requests per second with very low latency. Each NLB exposes one static IP address per Availability Zone and can be assigned an Elastic IP, which is valuable when clients must allowlist fixed addresses. The NLB preserves the client source IP, so the application sees the real caller. It also supports TLS termination to offload certificate work.
ALB vs NLB
| Dimension | Application Load Balancer | Network Load Balancer |
|---|---|---|
| OSI layer | Layer 7 (HTTP/HTTPS) | Layer 4 (TCP/UDP/TLS) |
| Routing | Path, host, header, query | Connection (protocol and port) |
| Performance | High | Millions of requests per second, ultra-low latency |
| Static IP support | No (DNS name only) | Yes (one per AZ, Elastic IP option) |
| Source IP | Preserved via X-Forwarded-For header | Preserved natively |
| Best for | Web apps, microservices, content routing | Extreme performance, static IP, non-HTTP protocols |
Gateway Load Balancer (GWLB) for Appliances
Inline Virtual Appliances
The Gateway Load Balancer (GWLB) lets you deploy, scale, and manage third-party virtual appliances such as firewalls, intrusion detection and prevention systems, and deep packet inspection tools. It operates at Layer 3 (the network layer) and uses the GENEVE protocol on port 6081 to encapsulate traffic and send it to the appliance fleet, then return it to the original flow transparently. A GWLB pairs with a Gateway Load Balancer Endpoint so you can route VPC traffic through a centralized inspection appliance without changing application routing logic.
Load Balancer Type Selection
| Need | Load Balancer |
|---|---|
| HTTP or HTTPS with path or host routing | ALB |
| TCP, UDP, or TLS at extreme scale | NLB |
| Static IP or Elastic IP for clients to allowlist | NLB |
| Inline firewall or security appliance inspection | GWLB |
| WebSockets, gRPC, or Cognito authentication | ALB |
Target Group Types
Where Traffic Lands
A target group routes requests to one or more registered targets and runs health checks against them. The instance type registers EC2 instances by instance ID. The IP type registers private IPv4 or IPv6 addresses, which is useful for on-premises servers reached over Direct Connect or VPN, or for containers. The Lambda type lets an ALB invoke a Lambda function as a target (ALB only). An NLB can also register an ALB as a target (the alb target type) to combine Layer 4 entry with Layer 7 routing. GWLB target groups use the GENEVE protocol for appliances. A health check (path and response code for ALB, or TCP/HTTP probe for NLB) marks each target healthy or unhealthy, and only healthy targets receive traffic.
Target Group Types
| Target type | What it registers | Supported by |
|---|---|---|
| instance | EC2 instances by ID | ALB and NLB |
| ip | Private IPv4 or IPv6 addresses | ALB and NLB |
| lambda | A Lambda function | ALB only |
| alb | An Application Load Balancer | NLB only |
| GENEVE | Appliances on port 6081 | GWLB |
Cross-Zone Load Balancing
Spreading Traffic Across AZs
With cross-zone load balancing enabled, each load balancer node can distribute traffic evenly to all registered targets in every Availability Zone. With it disabled, a node sends traffic only to targets in its own Availability Zone, which can create imbalance when AZs hold different numbers of targets. On ALB cross-zone is always on and free. On NLB and GWLB it is off by default, can be turned on per load balancer or per target group, and enabling it incurs inter-AZ data transfer charges. Choosing the setting trades perfect balance against data transfer cost.
Cross-Zone Defaults and Cost
| Load balancer | Default state | Inter-AZ charge when enabled |
|---|---|---|
| Application Load Balancer | Always enabled | No charge |
| Network Load Balancer | Disabled | Yes |
| Gateway Load Balancer | Disabled | Yes |
Best Practices
1. Match the load balancer to the protocol first
├── HTTP or HTTPS with smart routing → ALB
├── TCP, UDP, TLS, or static IP needs → NLB
└── Inline security appliances → GWLB
2. Terminate TLS at the load balancer with ACM
└── Use SNI to serve multiple certificates from one HTTPS listener
3. Deploy across at least two Availability Zones
└── Register healthy targets in each AZ for resilience
4. Tune health checks to match the app
├── Use a lightweight, dependency-free health path
└── Set thresholds so brief blips do not flap targets
5. Decide cross-zone with cost in mind
├── ALB: always on and free
└── NLB and GWLB: enable for even balance, accept inter-AZ data cost
6. Preserve the client source IP correctly
├── ALB: read the X-Forwarded-For header
└── NLB: source IP is preserved natively to instance targetsCommon Pitfalls
Pitfall 1: Using an NLB for Path-Based Routing
Mistake: Choosing an NLB and then trying to route /api and /static to different target groups.
Why it fails: NLB works at Layer 4 and has no visibility into HTTP paths, hosts, or headers, so it cannot do content-based routing.
Correct Approach: Use an ALB for any HTTP or HTTPS path, host, or header routing. Reserve NLB for connection-level distribution and extreme performance.
Pitfall 2: Expecting a Static IP From an ALB
Mistake: Promising a client a fixed IP address to allowlist while using an ALB.
Why it fails: ALB provides only a DNS name and its underlying IPs can change, so there is no stable IP to allowlist.
Correct Approach: Use an NLB, which gives one static IP per Availability Zone and supports Elastic IP assignment for clients that require fixed addresses.
Pitfall 3: Forgetting NLB Cross-Zone Is Off by Default
Mistake: Assuming an NLB spreads traffic evenly across all AZs out of the box.
Why it fails: NLB cross-zone load balancing is disabled by default, so an AZ with fewer targets receives a disproportionate share of traffic per target.
Correct Approach: Register a balanced number of targets per AZ, or enable cross-zone load balancing on the NLB while accounting for the added inter-AZ data transfer cost.
Pitfall 4: Skipping Health Checks or Setting Them Too Aggressively
Mistake: Pointing the health check at a heavy endpoint or setting thresholds so tight that healthy targets flap in and out.
Why it fails: Targets get marked unhealthy under load and are pulled from rotation, reducing capacity exactly when it is needed.
Correct Approach: Use a lightweight health path with no external dependencies, and set healthy and unhealthy thresholds plus intervals to tolerate brief transient failures.
Test Your Knowledge
A microservices web application needs to route requests for /checkout to one service and /catalog to another, terminate TLS, and authenticate users with Amazon Cognito. Which load balancer fits best?
A financial trading platform requires millions of TCP connections per second with the lowest possible latency, and external partners must allowlist a fixed set of IP addresses. Which load balancer should the architect choose?
A security team wants all VPC egress traffic inspected by a third-party firewall fleet that scales independently, without changing each application route table by hand. Which AWS load balancer supports this pattern?
Related Services
Quick Reference
Limits and Defaults
Load Balancer Facts
| Property | Value |
|---|---|
| GWLB GENEVE port | 6081 |
| NLB static IP | One per Availability Zone (Elastic IP optional) |
| ALB cross-zone | Always enabled, no extra charge |
| NLB and GWLB cross-zone | Disabled by default, inter-AZ charge when enabled |
| ALB Lambda target | Supported (ALB only) |
| Minimum AZs for resilience | Two or more recommended |
Common CLI Commands
# Create an internet-facing Application Load Balancer
aws elbv2 create-load-balancer \
--name web-alb --type application \
--subnets subnet-aaa subnet-bbb \
--security-groups sg-123 --scheme internet-facing
# Create a Network Load Balancer
aws elbv2 create-load-balancer \
--name api-nlb --type network \
--subnets subnet-aaa subnet-bbb
# Create a target group with the IP target type
aws elbv2 create-target-group \
--name api-tg --protocol HTTP --port 80 \
--vpc-id vpc-123 --target-type ip \
--health-check-path /healthz
# Create an HTTPS listener with a path-based rule
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/web-alb/abc \
--protocol HTTPS --port 443 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/abc \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/api-tg/def
# Enable cross-zone load balancing on an NLB
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/api-nlb/abc \
--attributes Key=load_balancing.cross_zone.enabled,Value=true