This chapter covers Elastic Load Balancing (ELB) in AWS, focusing on the two most common load balancer types: Application Load Balancer (ALB) and Network Load Balancer (NLB). Understanding the differences between ALB and NLB is critical for the CLF-C02 exam, as questions frequently test your ability to choose the right load balancer for a given scenario. This objective falls under Cloud Technology Services domain, which comprises approximately 24% of the exam. Mastering this topic will help you answer questions on high availability, scalability, and traffic distribution.
Jump to a section
Imagine a busy airport terminal where passengers arrive at different gates. An Application Load Balancer (ALB) is like a full-service terminal: it checks each passenger's ticket (HTTP header), knows if they're flying first class (path-based routing), can send them to a specific lounge (target group) based on their destination (host header), and even inspects their carry-on bags (SSL termination). It operates at Layer 7, understanding the content of the request. In contrast, a Network Load Balancer (NLB) is like an express lane at the security checkpoint: it just looks at the flight number (IP address and port) and quickly directs passengers to the correct gate without any additional checks. It operates at Layer 4, forwarding traffic based solely on network information. The ALB is slower but smarter, handling complex routing decisions. The NLB is faster but simpler, ideal for handling millions of requests per second with ultra-low latency. Just as an airport might use both terminals for different passenger flows, AWS architectures often combine ALB and NLB for different traffic types.
What is Elastic Load Balancing and What Problem Does It Solve?
Elastic Load Balancing (ELB) is a fully managed AWS service that automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, IP addresses, and Lambda functions. It solves the problem of single points of failure and ensures high availability and fault tolerance. Without a load balancer, if one server fails, users lose access to the application. ELB also scales with traffic, adding or removing targets as needed. It provides a single point of contact (DNS name) for clients, abstracting the underlying infrastructure.
How It Works: The Mechanism
When a client sends a request to an application, the request first hits the load balancer's DNS name. The load balancer then evaluates the request based on its type (ALB or NLB) and forwards it to a healthy target in a target group. The target group defines the destination (EC2 instances, IP addresses, or Lambda functions) and a health check path. The load balancer performs health checks on each target; if a target fails, traffic is redirected to healthy targets. This process ensures continuous availability.
Key Tiers and Configurations
Application Load Balancer (ALB): - Operates at Layer 7 (application layer) of the OSI model. - Supports HTTP, HTTPS, and WebSocket protocols. - Features: path-based routing, host-based routing, query string routing, header routing, and redirects. - Supports AWS WAF integration for web application firewall. - Ideal for microservices, containerized applications, and HTTP/HTTPS traffic. - Pricing: per hour plus per LCU (Load Balancer Capacity Unit).
Network Load Balancer (NLB): - Operates at Layer 4 (transport layer). - Supports TCP, UDP, and TLS protocols. - Features: ultra-low latency (millions of requests per second), static IP addresses, and preservation of source IP. - Can handle sudden volatile traffic patterns. - Ideal for TCP/UDP traffic, latency-sensitive applications, and when you need static IPs. - Pricing: per hour plus per NLCU (Network Load Balancer Capacity Unit).
Gateway Load Balancer (GWLB): - Operates at Layer 3 (network layer) – not covered in CLF-C02 in depth. - Used for third-party virtual appliances like firewalls.
Classic Load Balancer (CLB): - Legacy; operates at Layer 4/7. Not recommended for new applications. Not tested on CLF-C02.
Comparison to On-Premises or Competing Approaches
On-premises load balancers (e.g., F5 BIG-IP, HAProxy) require hardware procurement, maintenance, and capacity planning. AWS ELB is fully managed, scales automatically, and integrates with other AWS services like Auto Scaling, Route 53, and CloudWatch. Unlike on-premises, you pay only for what you use, with no upfront costs. AWS also handles software updates and fault tolerance across Availability Zones.
When to Use ALB vs NLB
Use ALB when: you need content-based routing (e.g., /api vs /web), host-based routing (e.g., example1.com vs example2.com), or SSL termination. It's ideal for web applications, REST APIs, and microservices.
Use NLB when: you need ultra-low latency, static IP addresses, or handle TCP/UDP traffic. It's ideal for gaming, IoT, financial trading, or when clients require direct connection to the load balancer IP.
Use both together: For end-to-end TLS encryption, you can place an NLB in front of an ALB (NLB handles TLS termination at the edge, then forwards to ALB for application routing).
AWS CLI Example: Creating an ALB
aws elbv2 create-load-balancer --name my-alb --subnets subnet-12345678 subnet-87654321 --security-groups sg-12345678Creating an NLB:
aws elbv2 create-load-balancer --name my-nlb --type network --subnets subnet-12345678 subnet-87654321Note: NLB does not require security groups; it uses security groups on targets.
Important Defaults and Limits
ALB idle timeout: 60 seconds (configurable).
NLB idle timeout: 350 seconds (not configurable).
ALB supports up to 100 target groups per load balancer.
NLB supports up to 100 target groups per load balancer.
Both support cross-zone load balancing (disabled by default for NLB, enabled for ALB).
Health checks: ALB uses HTTP/HTTPS health checks; NLB uses TCP, HTTP, or HTTPS health checks.
Pricing
ALB: $0.0225 per hour + $0.008 per LCU-hour (LCU based on connections, active connections, processed bytes, and rule evaluations).
NLB: $0.0225 per hour + $0.006 per NLCU-hour (NLCU based on new connections, active connections, and processed bytes).
Data transfer costs apply for both.
Security
ALB: Supports security groups, AWS WAF, and SSL/TLS termination.
NLB: Does not support security groups; uses security groups on targets. Supports TLS termination but not WAF.
Monitoring
Both integrate with Amazon CloudWatch for metrics (e.g., request count, latency, healthy hosts) and AWS CloudTrail for API logging.
Create a Target Group
A target group is a logical grouping of targets (EC2 instances, IP addresses, Lambda functions) that receive traffic from the load balancer. You specify the protocol (HTTP, HTTPS, TCP, UDP) and port. For ALB, you also set a health check path (e.g., /health). For NLB, you set health check protocol and port. Target groups are independent of the load balancer; you can attach multiple target groups to one load balancer. Default health check interval is 30 seconds, with a healthy threshold of 5 and unhealthy threshold of 2.
Register Targets
Register EC2 instances, IP addresses, or Lambda functions with the target group. For EC2, you can specify instance IDs. For IP addresses, you can specify private IPv4 or IPv6 addresses. For Lambda, you specify the function ARN. You can also use Auto Scaling groups to automatically register and deregister instances. Each target must be in the same VPC as the load balancer. You can register targets across multiple Availability Zones for high availability.
Configure Listener Rules
Listeners check for connection requests from clients using the protocol and port you configure. For ALB, you define rules that forward requests to target groups based on conditions like path, host, query string, or HTTP header. For example, forward requests to /api to one target group and /web to another. Rules are evaluated in priority order. For NLB, listeners forward all traffic on a port to a single target group (no content-based routing). You can have multiple listeners on different ports.
Test Health Checks
After configuring, the load balancer begins health checks. For ALB, health checks are HTTP/HTTPS requests to the specified path. A 200 OK response indicates healthy. For NLB, health checks can be TCP, HTTP, or HTTPS. If a target fails health checks consistently (unhealthy threshold count), the load balancer stops sending traffic to it. You can view health check status in the AWS Management Console under Target Groups. Misconfigured health checks are a common cause of traffic loss.
Verify DNS Resolution
Each load balancer receives a DNS name (e.g., my-alb-1234567890.us-east-1.elb.amazonaws.com). For NLB, you can optionally assign Elastic IP addresses for static IP support. Clients resolve the DNS name to the load balancer's IP addresses. For ALB, the DNS name resolves to multiple IP addresses (one per AZ). For NLB with EIPs, the DNS name resolves to the static IPs. Always use the DNS name in your application, not IP addresses, as IPs can change for ALB.
Scenario 1: Microservices E-Commerce Platform
A company deploys a microservices-based e-commerce platform on ECS with Fargate. They use an ALB to route traffic based on path: /api/orders goes to the orders service, /api/products to the products service, and /api/users to the users service. The ALB also terminates SSL, offloading encryption from the containers. Health checks ensure that if a service becomes unhealthy, traffic is redirected. Cost: ALB hourly plus LCU charges. Misconfiguration: If health checks point to the root path (/) instead of a dedicated health endpoint, the service might appear healthy even when critical components fail, leading to customer-facing errors.
Scenario 2: Real-Time Gaming Platform
A gaming company needs ultra-low latency for TCP-based game traffic. They deploy an NLB with static IP addresses (Elastic IPs) so that players can whitelist the IPs in firewalls. The NLB forwards traffic to a fleet of game servers on EC2. The NLB handles millions of concurrent connections with minimal latency. Cost: NLB hourly plus NLCU charges. Misconfiguration: If cross-zone load balancing is disabled (default for NLB), traffic might not distribute evenly across AZs, causing one AZ to be overloaded while others are underutilized.
Scenario 3: Hybrid Application with TCP and HTTP Traffic
An enterprise runs a legacy application that uses both TCP (for backend sync) and HTTP (for admin dashboard). They place an NLB in front of the TCP backend and an ALB for the HTTP frontend. The NLB preserves the source IP, which the backend needs for logging. The ALB provides path-based routing for the dashboard. Cost: both load balancers incur separate charges. Misconfiguration: Mixing protocols on the same listener can cause failures; each listener must match the protocol.
The CLF-C02 exam tests your ability to differentiate between load balancer types and choose the right one for a scenario. Domain: Cloud Technology Services. Key points:
ALB vs NLB: ALB operates at Layer 7 (application), understands HTTP/HTTPS, and supports content-based routing. NLB operates at Layer 4 (transport), handles TCP/UDP, and provides ultra-low latency and static IPs.
2. Common Wrong Answers: - Choosing ALB for TCP traffic: Candidates think ALB can handle any traffic, but ALB only supports HTTP/HTTPS/WebSocket. NLB is for TCP/UDP. - Choosing NLB for path-based routing: Candidates assume NLB can route based on URL path, but NLB does not inspect application layer data. - Assuming both support security groups: NLB does not have security groups; security is on targets. - Thinking Classic Load Balancer is still recommended: CLB is legacy; not tested.
3. Specific Exam Terms: - "Target group" – the group of resources that receive traffic. - "Listener" – checks for connection requests. - "Health check" – determines target availability. - "Cross-zone load balancing" – distributes traffic across all AZs. - "Sticky sessions" (session affinity) – only for ALB (via cookies). - "Static IP" – NLB only (via Elastic IP).
4. Tricky Distinctions: - ALB can route to Lambda functions; NLB cannot. - NLB can have static IPs; ALB DNS name resolves to dynamic IPs. - ALB integrates with AWS WAF; NLB does not. - Both support TLS termination, but NLB does not support client certificate authentication.
Decision Rule: If the question mentions HTTP/HTTPS, path-based routing, or microservices, choose ALB. If it mentions TCP/UDP, ultra-low latency, or static IP, choose NLB. If it mentions both, consider using both in tandem.
ALB operates at Layer 7 and supports HTTP/HTTPS/WebSocket; NLB operates at Layer 4 and supports TCP/UDP/TLS.
ALB offers content-based routing (path, host, query string); NLB does not inspect application data.
NLB provides ultra-low latency and static IP addresses; ALB does not have static IPs.
ALB integrates with AWS WAF and can route to Lambda functions; NLB cannot.
NLB does not have security groups; ALB does.
Cross-zone load balancing is enabled by default for ALB, disabled for NLB.
Both support health checks, but ALB uses HTTP/HTTPS health checks by default; NLB can use TCP, HTTP, or HTTPS.
For the exam, choose ALB for HTTP traffic with routing needs; choose NLB for TCP/UDP traffic or when static IPs are required.
These come up on the exam all the time. Here's how to tell them apart.
Application Load Balancer (ALB)
Layer 7 (application layer)
Supports HTTP, HTTPS, WebSocket
Path-based, host-based routing
Integrates with AWS WAF
No static IP (DNS only)
Network Load Balancer (NLB)
Layer 4 (transport layer)
Supports TCP, UDP, TLS
No content-based routing
Does not support WAF
Supports static IP (Elastic IP)
Mistake
ALB and NLB both support HTTP and TCP traffic.
Correct
ALB only supports HTTP, HTTPS, and WebSocket. NLB supports TCP, UDP, and TLS. ALB cannot handle raw TCP traffic, and NLB cannot inspect HTTP headers.
Mistake
NLB can route traffic based on URL paths.
Correct
NLB operates at Layer 4 and does not examine application layer data. It forwards traffic based on IP and port only. Path-based routing is exclusive to ALB.
Mistake
Both ALB and NLB require security groups.
Correct
ALB requires security groups to control inbound traffic. NLB does not have security groups; you control traffic using security groups on the target instances.
Mistake
Classic Load Balancer is the best choice for new applications.
Correct
Classic Load Balancer is legacy and not recommended for new applications. AWS recommends using ALB or NLB depending on your needs. CLF-C02 does not test CLB.
Mistake
Cross-zone load balancing is enabled by default for both ALB and NLB.
Correct
Cross-zone load balancing is enabled by default for ALB but disabled by default for NLB. You must enable it manually for NLB to distribute traffic evenly across AZs.
ALB operates at Layer 7 (application) and is ideal for HTTP/HTTPS traffic with content-based routing. NLB operates at Layer 4 (transport) and handles TCP/UDP traffic with ultra-low latency and static IP support. For the exam, remember that ALB understands URLs and can route based on path or host, while NLB only sees IP and port.
Yes, NLB can forward HTTP traffic because HTTP runs over TCP, but it will not inspect HTTP headers. This means you cannot do path-based routing or SSL termination at the NLB (though it can terminate TLS). For most HTTP applications, ALB is preferred because it offers richer features.
Yes, NLB supports static IP addresses by assigning Elastic IPs to the load balancer. This is useful when clients need to whitelist IPs in firewalls. ALB does not support static IPs; its DNS name resolves to dynamic IPs that can change.
ALB is the best choice for microservices because it supports path-based and host-based routing, allowing you to direct traffic to different services. It also integrates with ECS and Kubernetes. NLB is not suitable for content-based routing.
Cross-zone load balancing distributes traffic evenly across all registered instances in all Availability Zones. ALB has it enabled by default. NLB has it disabled by default; you must enable it manually to avoid uneven load distribution.
Yes, a common pattern is to place an NLB in front of an ALB. The NLB handles TLS termination and provides static IPs, while the ALB performs application-level routing. This combines the benefits of both.
Both support health checks. ALB uses HTTP/HTTPS health checks by default, while NLB can use TCP, HTTP, or HTTPS. Health checks are configured on the target group and determine whether traffic is sent to a target.
You've just covered Elastic Load Balancing — ALB vs NLB — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?