You already know what a load balancer is and when to use ALB or NLB. Now let's open the box and look at its three internal components: the listeners (what traffic it listens to), the rules (how it decides), and the Target Groups (which servers it sends to). Understanding these three pieces is understanding how a load balancer really works.

When a user visits your website through the load balancer, their request goes through three stages:

Let's look at each piece.

A listener is an "open door" of the load balancer that listens on a specific port. For example:

• A listener on port 80 listens to HTTP traffic.
• A listener on port 443 listens to HTTPS (secure) traffic.

Analogy: listeners are like the different phone lines of a company. One line for sales (port 80), another for support (port 443). Each one listens and, depending on who calls, forwards to the correct department.

A very common pattern: the listener on port 80 (HTTP) automatically redirects to 443 (HTTPS) to enforce secure connections.

A Target Group is a list of servers (EC2 instances, containers, Lambda functions...) that receive the traffic. The load balancer does not send requests to individual servers, but to a Target Group, which groups the destinations.

Here is one of the most important keys: each Target Group performs health checks. Periodically, the load balancer "asks" each server if it is okay (for example, by making a request to a URL like /health).

• If the server responds correctly → it is "healthy", it receives traffic.
• If it does not respond (it has crashed, is overloaded...) → it is marked "unhealthy" and the load balancer stops sending requests to it automatically, until it recovers.

This is what provides the high availability from subchapter 13.1. Thanks to health checks, if a server fails, users never reach it: the load balancer redirects them to healthy servers without anyone noticing the problem. Without health checks, the load balancer would keep sending people to a downed server.

Rules connect listeners with Target Groups. In an ALB (which is smart, layer 7), rules can look at the content of the request to decide which Target Group to send it to:

This is the smart routing we mentioned in subchapter 13.1: a single load balancer can distribute traffic to different groups of servers depending on the URL, domain, headers, etc.

Imagine an online store. The journey of a request to https://store.com/api/products:

1. Listener on port 443 (HTTPS) receives the request.
2. A rule sees that the path starts with /api/ → sends it to the Target Group api-servers.
3. The Target Group api-servers has 3 servers; 2 are healthy. It sends the request to one of the healthy ones.
4. That server responds, and the response returns to the user the same way.

• A request goes through three stages: Listener (listens on a port) → Rules (decide the destination) → Target Group (servers that respond).
• The listener listens on a port (80 for HTTP, 443 for HTTPS); it's common to redirect 80 → 443.
• The Target Group groups the destination servers and performs health checks: if a server does not respond, it automatically stops receiving traffic. This is what provides high availability.
• Rules (in the ALB) allow smart routing by path, host, or headers to different Target Groups.

In the next subchapter we will see the other half of the magic: how to create and delete servers automatically according to demand, with Auto Scaling Groups.