We start Part IV with a leap: from single servers to scalable architectures. The first key piece is the load balancer, the component that distributes traffic among several servers. In this chapter, you’ll learn how to use it and, in this first subchapter, how to choose between the two main types in AWS: the Application Load Balancer (ALB) and the Network Load Balancer (NLB).

In Chapter 12 you set up one server. But what if...?

• You get a lot of traffic and one server can’t handle it.
• That server goes down: your entire website stops working.

The solution is to have multiple servers and put something in front that distributes requests among them. That “something” is the load balancer.

A load balancer is like the maître d’ at a busy restaurant: at the door, assigning each arriving customer to a free table, distributing them among all the waiters so none get overwhelmed.

Immediate benefits:

• Distributes the load: no server gets overwhelmed.
• High availability: if a server goes down, the balancer stops sending it traffic and uses the others. Users don’t even notice.
• Single entry point: users access a single address, without knowing how many servers are behind it.

AWS offers several balancers, but the two you need to know are the ALB and the NLB. The key difference is at what level they operate.

Works at the application level (layer 7): understands HTTP and HTTPS. This means it can “read” web requests and make smart decisions based on their content:

• Send /api/* to some servers and /images/* to others (path-based routing).
• Send store.mydomain.com and blog.mydomain.com to different groups (host-based routing).
• Manage HTTPS certificates, headers, session cookies, etc.

It’s the default balancer for web applications and APIs.

Works at the network level (layer 4): only understands TCP/UDP, without looking at the content. In return, it’s extremely fast and supports huge amounts of traffic with minimal latency.

• Doesn’t read HTTP; just distributes network connections.
• Ideal for extreme performance, protocols that aren’t HTTP (for example, databases, online games, IoT, streaming) or when you need a fixed IP.

• The ALB is like a hotel receptionist who reads your request (“I want the spa,” “I’m looking for the restaurant”) and directs you to the right place. Smart, but that reading takes a moment.
• The NLB is like a subway turnstile: it doesn’t care who you are or where you’re going, it just lets people through as fast as possible. It’s incredibly fast, but “doesn’t think.”

The practical rule to start is simple:

• Is it a web application or an API (HTTP/HTTPS)? → ALB. This is the case for 90% of projects. It’s what you’ll use almost always.
• Do you need maximum performance, a fixed IP, or work with protocols that aren’t HTTP? → NLB.

For beginners: focus on the ALB. It’s what you’ll use in the vast majority of web applications, and it’s what we’ll cover in the rest of the chapter (Target Groups, listeners, autoscaling). The NLB will be there for special high-performance cases.

• A load balancer distributes traffic among several servers: it provides scaling and high availability (if one goes down, it uses the others).
• The ALB (layer 7) understands HTTP/HTTPS and is smart: routes by path, host, headers. It’s the standard for websites and APIs.
• The NLB (layer 4) only understands TCP/UDP, is extremely fast and allows fixed IP. For extreme performance or non-HTTP protocols.
• Practical rule: web application? → ALB. Special performance or non-HTTP cases → NLB.

In the next subchapter we’ll see how the balancer knows which servers to send traffic to: the Target Groups, the listeners, and the rules.