This chapter covers the three types of Elastic Load Balancers (ELBs) on AWS: Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB). Understanding their differences, use cases, and how they operate at the protocol level is critical for the SAA-C03 exam, particularly for designing resilient architectures. Approximately 10-15% of the exam questions touch on load balancing, often in the context of high availability, auto scaling, and integration with other services like EC2, Lambda, and ECS.
Jump to a section
Imagine a luxury hotel with a single main entrance and a concierge desk. The hotel has 50 guest rooms (EC2 instances) across multiple floors (Availability Zones). Guests arrive at the entrance, and the concierge (Application Load Balancer) decides which room to send them to based on the guest's request type—dining, housekeeping, or maintenance (path-based routing). The concierge checks a clipboard to see which rooms are available and not overloaded (health checks), and if a room is under renovation (unhealthy), it is skipped. For sticky sessions, the concierge gives the guest a loyalty card (cookie) so future requests go to the same room. If the hotel expands to 100 rooms, the concierge can handle it without changing the entrance. A Network Load Balancer is like a fast elevator that just directs guests to the correct floor based on the floor number (TCP/UDP) without any concierge logic, but it can also preserve the guest's identity (source IP) if needed. A Classic Load Balancer is an older, less efficient system where the concierge does everything but with limited rules and slower performance.
Overview of Elastic Load Balancing
Elastic Load Balancing (ELB) is a managed service that automatically distributes incoming application traffic across multiple targets, such as EC2 instances, containers, IP addresses, and Lambda functions. It ensures fault tolerance by routing traffic only to healthy targets and scales automatically to handle varying traffic loads. The SAA-C03 exam expects you to know the three types: Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB). Each operates at a different layer of the OSI model and is suited for different scenarios.
Application Load Balancer (ALB)
ALB operates at Layer 7 (Application layer) of the OSI model. It understands HTTP/HTTPS protocols and can make routing decisions based on content, such as URL path, host header, query string, and HTTP method. ALB supports WebSocket and HTTP/2 protocols. It is ideal for microservices architectures where traffic needs to be routed to different target groups based on the request content.
Key Features:
- Path-based routing: Route requests to different target groups based on the URL path (e.g., /api/* to API servers, /images/* to image servers).
- Host-based routing: Route based on the Host header (e.g., api.example.com vs www.example.com).
- Query string routing: Route based on query parameters (e.g., ?version=2).
- HTTP method routing: Route based on HTTP methods (GET, POST, etc.).
- Support for redirects and fixed responses.
- Support for AWS WAF (Web Application Firewall) integration.
- Support for authentication via Cognito or OIDC.
- Sticky sessions (session affinity) using cookies.
- Connection idle timeout: Default 60 seconds, configurable.
- Request tracing: Supports X-Amzn-Trace-Id header.
How ALB Works Internally:
When a client sends an HTTP request to the ALB, the load balancer terminates the client's connection and establishes a new connection to the target. This is called connection termination or proxy mode. The ALB parses the HTTP request, applies listener rules, and forwards the request to the appropriate target group. It then sends the response back to the client. The ALB can add headers like X-Forwarded-For to preserve the client's IP address.
Target Groups: - Targets can be EC2 instances, IP addresses, Lambda functions, or private IP addresses. - Health checks are performed at the target group level using HTTP/HTTPS or TCP. - ALB supports slow start mode: Gradually increase traffic to a newly registered target.
Listener Configuration: Listeners are processes that check for connection requests. Each listener is configured with a protocol and port (e.g., HTTP:80, HTTPS:443). For HTTPS listeners, you must install an SSL/TLS certificate on the load balancer. ALB supports SNI (Server Name Indication) to host multiple certificates.
Default Values: - Idle timeout: 60 seconds (configurable from 1 to 4000 seconds). - Request timeout: 60 seconds (configurable, but not recommended to change). - Deregistration delay: 300 seconds (configurable from 0 to 3600 seconds).
Network Load Balancer (NLB)
NLB operates at Layer 4 (Transport layer). It can handle TCP, UDP, and TLS traffic. It is designed for extreme performance, handling millions of requests per second with ultra-low latency. NLB does not understand HTTP; it forwards packets as-is without inspecting the payload. It preserves the source IP address of the client, which is a key difference from ALB.
Key Features: - Ultra-low latency: Typically ~100ms vs ALB's ~400ms. - TCP, UDP, and TLS listeners. - Static IP addresses: Each NLB can have a static IP per Availability Zone, which can be used for whitelisting. - Elastic IP support: You can assign Elastic IP addresses to each AZ. - Source IP preservation: The target sees the client's IP address directly. - Proxy Protocol support: If source IP preservation is not needed, you can enable Proxy Protocol to pass client IP. - Sticky sessions: Supported using source IP (hash of source IP and port). - Health checks: TCP or HTTP/HTTPS health checks. - Cross-zone load balancing: Disabled by default (unlike ALB which is enabled by default).
How NLB Works Internally: NLB uses a flow hash algorithm to route packets. For each TCP/UDP flow, the load balancer selects a target based on the 5-tuple (source IP, source port, destination IP, destination port, protocol). All packets of the same flow go to the same target. NLB does not terminate the connection; it forwards packets at Layer 4, so the target sees the client's source IP. NLB supports TLS termination by offloading SSL/TLS decryption, but it can also pass through encrypted traffic.
Target Groups: - Targets can be EC2 instances, IP addresses, or Application Load Balancers (for NLB to ALB chaining). - Health checks: TCP, HTTP, or HTTPS. - NLB supports registering targets by instance ID or IP address.
Static IP and Elastic IP: Each NLB node in an AZ gets a static IP. You can optionally assign Elastic IPs. This is useful for whitelisting or when you need a fixed IP for DNS A records.
Default Values: - Idle timeout: 350 seconds (not configurable). - Deregistration delay: 300 seconds (configurable).
Classic Load Balancer (CLB)
CLB is the legacy load balancer that operates at both Layer 4 and Layer 7. It supports HTTP, HTTPS, TCP, and SSL protocols. However, it lacks many features of ALB and NLB. AWS recommends using ALB or NLB for new deployments. CLB is still on the exam, but you should know its limitations.
Key Features: - Supports HTTP/HTTPS and TCP/SSL. - Sticky sessions using cookies. - Basic health checks. - No path-based routing. - No host-based routing. - No support for Lambda targets. - No native IPv6 support (only dual-stack via DNS). - No WebSocket support. - No HTTP/2 support. - No AWS WAF integration.
How CLB Works: CLB can act as a Layer 4 load balancer (TCP) or a Layer 7 load balancer (HTTP/HTTPS). In Layer 4 mode, it forwards TCP connections without inspection. In Layer 7 mode, it terminates the connection and proxies HTTP requests. However, it does not have the advanced routing capabilities of ALB.
Default Values: - Idle timeout: 60 seconds (configurable). - Connection draining: 300 seconds (configurable).
Comparison and Exam Tips
ALB vs NLB: Use ALB for HTTP/HTTPS traffic with content-based routing. Use NLB for TCP/UDP traffic requiring ultra-low latency or static IP.
CLB: Avoid unless you have legacy applications that cannot migrate. The exam may ask you to identify when to use CLB, but the correct answer is usually ALB or NLB.
Cross-zone load balancing: ALB enabled by default (no extra cost). NLB disabled by default (extra cost when enabled). CLB enabled by default (no extra cost).
Source IP preservation: NLB preserves source IP by default. ALB does not (unless using X-Forwarded-For). CLB preserves source IP in TCP mode, not in HTTP mode.
Security groups: ALB and CLB can have security groups. NLB does not support security groups (you use network ACLs instead).
TLS termination: ALB and NLB support TLS termination. CLB supports SSL termination.
Integration with Other Services
Auto Scaling: ALB and NLB integrate with Auto Scaling groups to automatically register and deregister instances.
ECS: ALB is the recommended load balancer for ECS, supporting dynamic port mapping.
Lambda: ALB can directly invoke Lambda functions as targets.
Global Accelerator: Use with NLB for global traffic management.
Route 53: Use weighted routing, latency routing, or failover routing with ELB DNS names.
AWS WAF: Only ALB supports WAF integration.
Pricing
ALB: Per hour + per LCU (Load Balancer Capacity Units).
NLB: Per hour + per NLCU (Network Load Balancer Capacity Units).
CLB: Per hour + per GB of data processed.
High Availability Best Practices
Deploy load balancer nodes in multiple Availability Zones.
Ensure targets are in multiple AZs.
Use health checks to mark unhealthy targets.
Configure cross-zone load balancing for even distribution.
Use connection draining (deregistration delay) for graceful shutdown.
Client Sends HTTP Request to ALB
The client (e.g., a browser) sends an HTTP GET request to the ALB's DNS name. The ALB's DNS resolves to the IP addresses of its nodes in each AZ. The client's request is directed to one of these nodes based on DNS round-robin. The ALB node terminates the TCP connection and parses the HTTP request. It inspects the request headers, URL path, and method. It then evaluates the listener rules in order of priority. The first matching rule determines which target group to forward the request to. If no rule matches, the default action (e.g., return 404) is applied.
ALB Selects Target in Target Group
Once the target group is identified, the ALB selects a healthy target using the routing algorithm. For ALB, the default is round-robin. If sticky sessions are enabled, the ALB checks for a session cookie. If the cookie exists and maps to a healthy target, that target is used. Otherwise, a new target is selected. The ALB then establishes a new TCP connection to the target (if not using connection reuse). It forwards the HTTP request, adding headers like X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port. The target processes the request and sends a response back to the ALB. The ALB then sends the response to the client over the original TCP connection.
Health Check Determines Target Health
Every 30 seconds (by default), the ALB sends a health check request to each target in the target group. The health check is an HTTP GET to a specified path (e.g., /health). If the target returns a 200 OK status within the timeout (5 seconds default), the target is considered healthy. If it fails, the target is marked unhealthy and is removed from rotation. The health check interval, timeout, healthy threshold, and unhealthy threshold are configurable. For NLB, health checks are TCP or HTTP/HTTPS. If TCP, the NLB attempts to open a TCP connection to the target on the specified port. If successful, the target is healthy.
NLB Forwards TCP Packet to Target
When an NLB receives a TCP SYN packet, it uses a flow hash based on the 5-tuple to select a target. The NLB does not terminate the TCP connection; it rewrites the destination IP and MAC address to the target's IP and forwards the packet. The target sees the client's source IP (since NLB preserves it). The target sends the response directly to the client? No, actually the target sends the response back to the NLB, which then forwards it to the client, rewriting the source IP to the NLB's IP. This is because the target's default route points to the NLB. The NLB maintains the flow state for the duration of the connection. If the target becomes unhealthy, new flows are sent to other targets, but existing flows continue until the connection is closed or the idle timeout (350 seconds) expires.
Connection Draining and Deregistration
When an EC2 instance is deregistering (e.g., during Auto Scaling scale-in), the load balancer stops sending new requests to it but allows in-flight requests to complete. This is called connection draining (CLB) or deregistration delay (ALB/NLB). Default is 300 seconds. For ALB, if the target is unhealthy, the deregistration delay still applies to existing connections. For NLB, if the target is unhealthy, new flows are not sent, but existing flows continue until idle timeout. After the delay, all connections to the target are closed. This ensures a graceful shutdown without dropping active requests.
Scenario 1: Microservices E-Commerce Platform
A large e-commerce company runs a microservices architecture on ECS with multiple services: user authentication, product catalog, shopping cart, and payment processing. They use an Application Load Balancer to route traffic based on the URL path. For example, /api/auth/* goes to the auth service, /api/products/* to the product service, and /api/cart/* to the cart service. Each service runs in its own ECS service with dynamic port mapping. The ALB's target groups use the IP address of the ECS tasks. The ALB is configured with HTTPS listeners using a wildcard certificate for *.example.com. Sticky sessions are enabled for the cart service to maintain session state. The ALB is integrated with AWS WAF to block SQL injection and XSS attacks. The company deploys the ALB across three Availability Zones for high availability. During Black Friday, the ALB handles over 100,000 requests per second without issues. The main challenge is tuning the health check intervals and thresholds to avoid false positives during transient errors. They set the unhealthy threshold to 3 and health check interval to 10 seconds to quickly detect and replace failing tasks.
Scenario 2: Real-Time Gaming Backend
A gaming company needs ultra-low latency for their real-time multiplayer game. They use a Network Load Balancer to distribute UDP traffic from game clients to game servers running on EC2 instances. The NLB is assigned Elastic IPs in each AZ for whitelisting by ISPs. The game servers need to see the client's source IP for anti-cheat and region detection, so source IP preservation is critical. The NLB is configured with TCP health checks on the game server port. The game servers are in an Auto Scaling group that scales based on CPU utilization. The NLB's cross-zone load balancing is enabled to distribute traffic evenly across instances in different AZs. The idle timeout is set to 350 seconds (default) because game sessions can last several minutes. The company also uses Route 53 latency-based routing to direct players to the closest regional NLB endpoint. The main performance consideration is that NLB can handle millions of packets per second, but the game servers must be optimized to handle the load. Misconfiguration often occurs when health checks are too strict, causing healthy servers to be removed from rotation during brief network hiccups.
Scenario 3: Legacy Application Migration
A financial services company has a legacy application that uses TCP for communication between clients and servers. They are migrating from on-premises to AWS and want to use a Classic Load Balancer initially because the application does not support HTTP. However, they soon realize that CLB lacks features like cross-zone load balancing (though it is enabled by default) and advanced health checks. They decide to migrate to a Network Load Balancer for better performance and reliability. The NLB is configured with TCP listeners on port 8080. The application servers are EC2 instances in two AZs. The NLB is assigned a static IP for the firewall whitelist. The migration is seamless because NLB preserves the source IP, which the application requires for logging. The company also uses connection draining to ensure no sessions are dropped during instance replacements. The main lesson is that while CLB works, NLB provides better performance and more features at a similar cost.
The SAA-C03 exam tests your ability to choose the correct load balancer type for a given scenario. The objective code is 2.2 (Resilient Architectures). You will see questions that describe an application's requirements (e.g., HTTP/HTTPS, need for path-based routing, need for static IP, latency sensitivity) and ask which load balancer to use. The most common wrong answers are:
Choosing CLB when ALB is better – Many candidates pick CLB because they are familiar with it, but ALB is almost always the better choice for HTTP applications. CLB is legacy and lacks features. The exam will rarely have a correct answer that is CLB unless the question specifically mentions legacy compatibility or no need for advanced features.
Choosing NLB for HTTP content-based routing – NLB operates at Layer 4 and cannot inspect HTTP headers. Candidates sometimes think NLB can do path-based routing because it is newer, but it cannot. If the requirement is to route based on URL path, ALB is the only option.
Thinking ALB preserves source IP – ALB does not preserve the client's source IP by default; it uses X-Forwarded-For header. NLB preserves source IP. The exam may ask about logging or security requirements where the target needs the client's real IP. The correct answer is NLB.
Confusing cross-zone load balancing defaults – ALB has cross-zone enabled by default (no extra cost). NLB has it disabled by default (extra cost when enabled). CLB has it enabled by default (no extra cost). The exam may ask about cost optimization, and enabling cross-zone on NLB incurs additional charges.
Specific numbers and terms to memorize: - ALB idle timeout: 60 seconds (configurable 1-4000) - NLB idle timeout: 350 seconds (not configurable) - CLB idle timeout: 60 seconds (configurable) - Deregistration delay/connection draining: 300 seconds default (configurable 0-3600) - Health check defaults: Interval 30 seconds, Timeout 5 seconds, Healthy threshold 5, Unhealthy threshold 2 (for ALB/CLB) - NLB supports TCP, UDP, TLS; ALB supports HTTP, HTTPS, HTTP/2, WebSocket; CLB supports HTTP, HTTPS, TCP, SSL. - ALB supports Lambda targets; NLB and CLB do not. - ALB supports WAF; NLB and CLB do not. - NLB supports static IP and Elastic IP; ALB and CLB do not (ALB uses DNS name).
Edge cases: - If the application uses WebSocket, you need ALB (or NLB if you don't need Layer 7 features). - If you need to whitelist IPs, NLB with Elastic IP is the best choice. - If you need mutual TLS (mTLS), ALB supports it (via target group attributes). - If the application uses UDP, only NLB supports UDP. - If you need to route to multiple ports on the same instance, ALB with dynamic port mapping (ECS) is ideal.
How to eliminate wrong answers: - If the question mentions HTTP/HTTPS and content-based routing, eliminate NLB and CLB. - If the question mentions static IP or source IP preservation, eliminate ALB and CLB. - If the question mentions WebSocket or HTTP/2, eliminate CLB. - If the question mentions Lambda target, only ALB works. - If the question mentions UDP, only NLB works. - If the question mentions TLS termination, all three can do it, but ALB and NLB are preferred.
ALB is Layer 7; NLB is Layer 4; CLB is legacy.
Use ALB for HTTP/HTTPS with content-based routing.
Use NLB for TCP/UDP with ultra-low latency or static IP.
NLB preserves source IP; ALB does not (uses X-Forwarded-For).
ALB supports Lambda targets; NLB and CLB do not.
ALB supports AWS WAF; NLB and CLB do not.
Cross-zone load balancing: ALB/CLB enabled by default, NLB disabled.
ALB idle timeout: 60 seconds (configurable); NLB idle timeout: 350 seconds (fixed).
Deregistration delay: 300 seconds default for all.
NLB supports UDP; ALB and CLB do not.
ALB supports WebSocket and HTTP/2; CLB does not.
Only NLB can have Elastic IP addresses.
CLB is not recommended for new deployments.
These come up on the exam all the time. Here's how to tell them apart.
Application Load Balancer (ALB)
Layer 7 (HTTP/HTTPS/WebSocket).
Content-based routing (path, host, query).
Does not preserve source IP; uses X-Forwarded-For.
Cross-zone enabled by default (no extra cost).
Supports Lambda targets and WAF.
Network Load Balancer (NLB)
Layer 4 (TCP/UDP/TLS).
No content-based routing.
Preserves source IP by default.
Cross-zone disabled by default (extra cost).
Supports static IP and Elastic IP.
Mistake
ALB can be used for TCP traffic without HTTP.
Correct
ALB only supports HTTP, HTTPS, HTTP/2, and WebSocket. For TCP or UDP traffic, you must use NLB or CLB.
Mistake
NLB can do path-based routing.
Correct
NLB operates at Layer 4 and cannot inspect HTTP request paths. Path-based routing is a Layer 7 feature only available on ALB.
Mistake
CLB is the best choice for new applications.
Correct
AWS recommends using ALB or NLB for new deployments. CLB is legacy and lacks many features. The exam will rarely have CLB as the correct answer.
Mistake
All load balancers preserve the client's source IP address.
Correct
Only NLB preserves the source IP by default. ALB uses the X-Forwarded-For header to pass the client IP. CLB preserves source IP only in TCP mode.
Mistake
Cross-zone load balancing is enabled by default on all ELB types.
Correct
ALB and CLB have cross-zone enabled by default. NLB has it disabled by default. Enabling cross-zone on NLB incurs additional charges.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
ALB operates at Layer 7 and can route based on HTTP content like URL path and host header. It supports WebSocket, HTTP/2, and Lambda targets. NLB operates at Layer 4, handling TCP/UDP traffic with ultra-low latency. NLB preserves the client's source IP and can have static IP addresses. For HTTP traffic requiring advanced routing, use ALB. For high-performance TCP/UDP or static IP requirements, use NLB.
You should avoid using CLB for new deployments. AWS recommends ALB or NLB. CLB is only appropriate if you have a legacy application that cannot be migrated to ALB or NLB, or if you need both Layer 4 and Layer 7 features in a single load balancer (though this is rare). The exam will rarely have CLB as the correct answer.
Yes, ALB supports sticky sessions (session affinity) using cookies. You can enable it on the target group level. The load balancer generates a cookie (AWSALB) that binds the client to a specific target. This is useful for stateful applications. NLB also supports sticky sessions using source IP hashing.
Yes, you can chain an NLB to an ALB. For example, you can use an NLB with a static IP as the entry point, then forward traffic to an ALB for content-based routing. This gives you both static IP and Layer 7 routing. However, this adds complexity and cost. Typically, you would use Global Accelerator with an ALB instead.
NLB supports TCP, HTTP, and HTTPS health checks. For TCP health checks, the NLB attempts to open a TCP connection to the target on the specified port. If the connection succeeds, the target is healthy. For HTTP/HTTPS, it sends a GET request to a specified path and expects a 200 OK response. Health check settings include interval, timeout, healthy threshold, and unhealthy threshold.
ALB default idle timeout is 60 seconds, configurable from 1 to 4000 seconds. NLB default idle timeout is 350 seconds and is not configurable. CLB default is 60 seconds, configurable.
No, ALB does not support Elastic IP. ALB uses a DNS name that resolves to the IP addresses of its nodes. If you need a static IP, use NLB with Elastic IP or use Global Accelerator with an ALB.
You've just covered Elastic Load Balancing Types — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?