# Elastic Load Balancing — ALB vs NLB

> Chapter 83 of the Courseiva CLF-C02 curriculum — https://courseiva.com/learn/clf-c02/aws-elb-alb-nlb

**Official objective:** 3.1 — Cloud Technology Services

## Introduction

How do you decide between an Application Load Balancer and a Network Load Balancer in AWS Elastic Load Balancing? 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.

## The Airport Terminal vs Express Lane

How does a busy airport terminal manage passengers arriving 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.

## Core explanation

### 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

```bash
aws elbv2 create-load-balancer --name my-alb --subnets subnet-12345678 subnet-87654321 --security-groups sg-12345678
```

Creating an NLB:

```bash
aws elbv2 create-load-balancer --name my-nlb --type network --subnets subnet-12345678 subnet-87654321
```

Note: 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.

## Real-world context

### 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.

## Exam focus

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:

1. **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.

5. **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.

## Step by step

1. **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.
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.
3. **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.
4. **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.
5. **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.

## Comparisons

### Application Load Balancer (ALB) vs Network Load Balancer (NLB)

**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)

## Common misconceptions

- **Misconception:** ALB and NLB both support HTTP and TCP traffic. **Reality:** 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.
- **Misconception:** NLB can route traffic based on URL paths. **Reality:** 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.
- **Misconception:** Both ALB and NLB require security groups. **Reality:** ALB requires security groups to control inbound traffic. NLB does not have security groups; you control traffic using security groups on the target instances.
- **Misconception:** Classic Load Balancer is the best choice for new applications. **Reality:** 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.
- **Misconception:** Cross-zone load balancing is enabled by default for both ALB and NLB. **Reality:** 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.

## Key takeaways

- 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.

## FAQ

**What is the difference between ALB and NLB for CLF-C02?**

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.

**Can I use an NLB for HTTP traffic?**

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.

**Does NLB support static IP addresses?**

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.

**Which load balancer should I use for microservices?**

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.

**What is cross-zone load balancing and which load balancer has it enabled by default?**

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.

**Can ALB and NLB be used together?**

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.

**Do ALB and NLB support health checks?**

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.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/clf-c02/aws-elb-alb-nlb