Ja saps què és un balancejador i quan utilitzar ALB o NLB. Ara obrirem la caixa i veurem els seus tres components interns: els listeners (quin tràfic escolta), les regles (com decideix) i els Target Groups (a quins servidors envia). Entendre aquestes tres peces és entendre com funciona realment un balancejador.

Quan un usuari visita el teu web a través del balancejador, la seva petició passa per tres etapes:

Vegem cada peça.

Un listener (oient) és una «porta oberta» del balancejador que escolta en un port concret. Per exemple:

• Un listener al port 80 escolta el tràfic HTTP.
• Un listener al port 443 escolta el tràfic HTTPS (segur).

Analogia: els listeners són com les diferents línies de telèfon d’una empresa. Una línia per a vendes (port 80), una altra per a suport (port 443). Cada una escolta i, segons qui truqui, ho deriva al departament correcte.

Un patró molt habitual: el listener del port 80 (HTTP) redirigeix automàticament al 443 (HTTPS) per forçar connexions segures.

Un Target Group (grup de destinació) és una llista de servidors (instàncies EC2, contenidors, funcions Lambda...) que reben el tràfic. El balancejador no envia les peticions a servidors solts, sinó a un Target Group, que és qui agrupa els destinataris.

Aquí hi ha una de les claus més importants: cada Target Group fa health checks (comprovacions de salut). Periòdicament, el balancejador «pregunta» a cada servidor si està bé (per exemple, fent una petició a una URL com /health).

• Si el servidor respon correctament → està «sa», rep tràfic.
• Si no respon (ha caigut, està saturat...) → es marca «no sa» i el balancejador deixa d’enviar-li peticions automàticament, fins que es recuperi.

Això és el que dona l’alta disponibilitat del subcapítol 13.1. Gràcies als health checks, si un servidor falla, els usuaris mai hi arriben: el balancejador els redirigeix als servidors sans sense que ningú noti el problema. Sense health checks, el balancejador seguiria enviant gent a un servidor caigut.

Les regles (rules) connecten listeners amb Target Groups. En un ALB (que és intel·ligent, capa 7), les regles poden mirar el contingut de la petició per decidir a quin Target Group enviar-la:

Això és l’enrutament intel·ligent que vam esmentar al subcapítol 13.1: un mateix balancejador pot repartir el tràfic a diferents grups de servidors segons la URL, el domini, les capçaleres, etc.

Imagina una botiga online. El recorregut d’una petició a https://botiga.com/api/productes:

1. Listener del port 443 (HTTPS) rep la petició.
2. Una regla veu que la ruta comença per /api/ → l’envia al Target Group servidors-api.
3. El Target Group servidors-api té 3 servidors; 2 estan sans. Envia la petició a un dels sans.
4. Aquest servidor respon, i la resposta torna a l’usuari pel mateix camí.

• Una petició recorre tres etapes: Listener (escolta un port) → Regles (decideixen el destí) → Target Group (servidors que responen).
• El listener escolta en un port (80 per HTTP, 443 per HTTPS); és habitual redirigir 80 → 443.
• El Target Group agrupa els servidors destinació i fa health checks: si un servidor no respon, deixa de rebre tràfic automàticament. Això és el que dona l’alta disponibilitat.
• Les regles (a l’ALB) permeten enrutament intel·ligent per ruta, host o capçaleres cap a diferents Target Groups.

Al següent subcapítol veurem l’altra meitat de la màgia: com crear i eliminar servidors automàticament segons la demanda, amb els Auto Scaling Groups.