AWS Load Balancer Types: ALB, NLB, GWLB, and CLB

Elastic Load Balancing distributes incoming traffic across registered targets such as EC2 instances, containers, IP addresses, and—in supported configurations—Lambda functions. The right load balancer depends mainly on the traffic protocol, the routing information it needs to understand, and whether it is balancing applications or network appliances.

This is Part 34 of the AWS Cloud Practitioner Study Notes. Part 33 explained how Auto Scaling groups add and remove EC2 capacity; a load balancer provides the stable entry point and routes traffic to the healthy instances behind that group.

The four Elastic Load Balancer types

Load balancer	OSI focus	Common protocols	Best fit
Application Load Balancer (ALB)	Layer 7, application	HTTP, HTTPS, HTTP/2, gRPC	Web applications and microservices
Network Load Balancer (NLB)	Layer 4, transport	TCP, UDP, TLS	High-throughput or low-latency network traffic
Gateway Load Balancer (GWLB)	Layer 3, network	IP traffic using GENEVE to appliances	Firewalls, IDS/IPS, and inspection appliances
Classic Load Balancer (CLB)	Legacy Layer 4/7 model	HTTP, HTTPS, TCP, SSL	Existing legacy applications

The first decision is usually:

HTTP/HTTPS routing?       → ALB
TCP/UDP/TLS connections?  → NLB
Virtual security appliance? → GWLB
Existing legacy CLB?      → Classic Load Balancer

1. Application Load Balancer

An Application Load Balancer operates at Layer 7 and understands HTTP or HTTPS requests. It can inspect information such as the hostname, URL path, HTTP headers, and cookies, then apply listener rules to choose a target group.

                    Application Load Balancer
                         /       |       \
                   Frontend     API     Admin

Path-based routing

The ALB can route different URL paths to different target groups:

example.com/       → frontend target group
example.com/api    → backend API target group
example.com/admin  → administration target group

Host-based routing

It can also route based on the hostname:

shop.example.com → shopping target group
api.example.com  → API target group

ALB features include HTTP and HTTPS listeners, TLS termination, WebSocket support, gRPC support, target-group health checks, and cookie-based stickiness. These make ALB a natural fit for websites, REST APIs, and microservice platforms.

Exam shortcut: website, HTTP, HTTPS, URL routing, hostname routing, or microservices → Application Load Balancer.

2. Network Load Balancer

An NLB operates at Layer 4. It forwards connections based on network information such as IP addresses and ports rather than evaluating URL paths or HTTP headers.

NLB supports TCP, UDP, and TLS traffic. It is designed for high throughput, low latency, and long-lived or non-HTTP connections such as gaming, messaging, custom TCP services, and some real-time systems.

Client connections
        │
        ▼
Network Load Balancer
        │
        ▼
TCP / UDP service targets

NLB provides static IP addresses per enabled Availability Zone and can preserve client IP information in supported configurations. It does not provide ALB-style path-based or host-based HTTP routing.

Network Load Balancers can be created with security groups in supported configurations. If no security group is associated at creation, AWS documents different management constraints, so treat “NLB has no security groups” as an outdated absolute rather than a universal rule.

Exam shortcut: TCP, UDP, static IP, very high throughput, or very low latency → Network Load Balancer.

3. Gateway Load Balancer

A GWLB is designed for deploying, scaling, and managing fleets of virtual network appliances. These may include firewalls, intrusion detection and prevention systems, deep-packet inspection systems, and other security appliances.

Unlike ALB and NLB, the GWLB is not mainly balancing ordinary web or application servers. It provides a transparent network gateway and distributes traffic across appliance targets.

Traffic
   │
   ▼
Gateway Load Balancer
   │
   ├── Firewall appliance 1
   ├── Firewall appliance 2
   └── IDS / IPS appliance

GWLB operates at Layer 3 and exchanges traffic with registered appliances using the GENEVE protocol on port 6081. Gateway Load Balancer endpoints allow traffic to be exchanged across VPC boundaries while keeping the appliance fleet centralised.

Exam shortcut: firewall, IDS, IPS, deep packet inspection, or virtual network appliance → Gateway Load Balancer.

4. Classic Load Balancer

Classic Load Balancer is the older Elastic Load Balancing model. It supports earlier HTTP, HTTPS, TCP, and SSL use cases, but it does not provide the modern routing and target-group capabilities of ALB or the network features of NLB.

Use CLB when maintaining an existing legacy deployment that already depends on it. For a new application, choose ALB, NLB, or GWLB based on the traffic and architecture instead of starting with CLB.

AWS provides migration paths from existing Classic Load Balancers to ALB or NLB. Migration creates a new load balancer, so traffic must be redirected and the old resource removed only after the new path is verified.

Exam shortcut: existing legacy load balancer → Classic Load Balancer; new design → usually ALB or NLB.

ALB versus NLB

Feature	ALB	NLB
Layer	7	4
Understands URL paths	Yes	No
Understands hostnames	Yes	No
HTTP/HTTPS application routing	Yes	Passes supported transport connections rather than applying ALB rules
TCP	Not a raw TCP load balancer	Yes
UDP	No	Yes
Static IP per AZ	Not the usual selection criterion	Yes
Typical choice	Web and API traffic	Network protocols and low latency

Do not choose NLB merely because it is “faster” if the application requires URL-based routing. Do not choose ALB if the service requires raw UDP or a Layer 4 connection model.

Components required for an ALB or NLB

Creating a load balancer is more than choosing its type.

VPC and subnets

The load balancer is created in a VPC. For high availability, enable subnets in at least two Availability Zones and configure the route tables and network ACLs appropriately.

Security groups

ALBs use security groups. NLBs can also use security groups when configured with that feature. The target instances still need rules that permit traffic and health checks from the load balancer or approved clients, depending on the design.

Target group

A target group is the set of registered backend targets and their health-check configuration.

Users
  │
  ▼
Load balancer
  │
  ▼
Target group
  │
  ├── EC2 instance
  ├── EC2 instance
  └── IP or supported service target

ALB target groups can route requests to EC2 instances, IP addresses, and Lambda functions in supported configurations. NLB and GWLB target types and protocols depend on their respective service model.

Listener

A listener checks for incoming connections on a configured protocol and port. Examples include:

HTTP listener  :80  → frontend target group
HTTPS listener :443 → API target group
TCP listener   :5432 → TCP target group

For an ALB, listener rules can evaluate hostnames, paths, headers, query strings, and other supported conditions before forwarding to a target group.

Health checks

The load balancer continually checks registered targets. For a web target, that might be:

GET /health → HTTP 200 → healthy

Only healthy targets receive normal traffic. A target can be running as an EC2 instance while its application is broken, which is why an application-level health endpoint is more useful than checking only whether the virtual machine is powered on.

End-to-end request flow

For an ALB, the request path is:

1. User requests https://example.com
2. DNS resolves the load balancer name
3. HTTPS listener receives the connection
4. Listener rules are evaluated in priority order
5. A target group is selected
6. A healthy target is selected
7. The request is forwarded to the target
8. The target responds
9. The load balancer returns the response

For an NLB, the listener selects a target using its network-level routing model. For a GWLB, traffic is directed to the selected virtual appliance using GENEVE encapsulation.

Choosing the right load balancer

Need URL or hostname routing?
└── Application Load Balancer

Need raw TCP, UDP, or TLS connections?
└── Network Load Balancer

Need static IPs and very low-latency network traffic?
└── Network Load Balancer

Need to scale firewalls or IDS/IPS appliances?
└── Gateway Load Balancer

Already running a legacy Classic Load Balancer?
└── Classic Load Balancer, or plan a migration

The load balancer normally works with an Auto Scaling group for EC2 applications. The ASG changes the number of instances; the load balancer sends traffic to the healthy instances that are registered in the target group.

Common exam questions

Scenario	Likely answer
URL path-based routing	Application Load Balancer
Hostname-based routing	Application Load Balancer
HTTP/HTTPS microservices	Application Load Balancer
TCP or UDP application	Network Load Balancer
Static IP per Availability Zone	Network Load Balancer
Very low-latency, high-throughput connections	Network Load Balancer
Load balance firewall or IDS/IPS appliances	Gateway Load Balancer
Existing legacy ELB deployment	Classic Load Balancer
Send traffic only to healthy targets	Target-group health checks
Route requests to different backend groups	Listener rules and target groups

Common exam traps

ALB versus NLB

The key question is whether the load balancer needs to understand HTTP application information. If it needs paths or hostnames, choose ALB. If it needs TCP, UDP, static IPs, or raw network performance, choose NLB.

GWLB versus ordinary load balancing

GWLB is for virtual network appliances, not simply for distributing requests across web servers. It also uses GENEVE and Gateway Load Balancer endpoints in appliance architectures.

Load balancer versus Auto Scaling group

The load balancer distributes traffic. The Auto Scaling group launches, terminates, and replaces instances. They often work together, but they solve different problems.

Health checks versus security groups

A security group controls whether traffic is permitted. A health check determines whether a registered target is healthy enough to receive traffic. Both must be configured correctly.

Memory map for CLF-C02

• ALB → Layer 7 web and HTTP routing
• NLB → Layer 4 TCP, UDP, TLS, static IP, low latency
• GWLB → Layer 3 virtual security appliances
• CLB → legacy load balancing

The one-sentence rule is: ALB understands the application, NLB understands the connection, GWLB handles network appliances, and CLB supports older deployments.

Conclusion

Choose a load balancer by asking what traffic it must understand. ALB is the usual choice for websites, APIs, and microservices that need path or hostname routing. NLB is designed for TCP, UDP, TLS, static IPs, and high-performance network connections. GWLB distributes traffic across virtual security appliances. CLB remains for legacy systems rather than new application designs.

Once the type is selected, configure the VPC subnets, security controls, listener, target group, and health checks. The load balancer then becomes the stable traffic entry point while Auto Scaling groups adjust the backend capacity behind it.

Sources

• How Elastic Load Balancing works
• Application Load Balancer listeners
• Application Load Balancer target groups and health checks
• Network Load Balancers
• Network Load Balancer security groups
• Gateway Load Balancers
• Migrating Classic Load Balancers