Ya sabes qué es un balanceador y cuándo usar ALB o NLB. Ahora vamos a abrir la caja y ver sus tres componentes internos: los listeners (qué tráfico escucha), las reglas (cómo decide) y los Target Groups (a qué servidores envía). Entender estas tres piezas es entender cómo funciona realmente un balanceador.

Cuando un usuario visita tu web a través del balanceador, su petición pasa por tres etapas:

Veamos cada pieza.

Un listener (oyente) es una «puerta abierta» del balanceador que escucha en un puerto concreto. Por ejemplo:

• Un listener en el puerto 80 escucha el tráfico HTTP.
• Un listener en el puerto 443 escucha el tráfico HTTPS (seguro).

Analogía: los listeners son como las distintas líneas de teléfono de una empresa. Una línea para ventas (puerto 80), otra para soporte (puerto 443). Cada una escucha y, según quién llame, lo deriva al departamento correcto.

Un patrón muy habitual: el listener del puerto 80 (HTTP) redirige automáticamente al 443 (HTTPS) para forzar conexiones seguras.

Un Target Group (grupo de destino) es una lista de servidores (instancias EC2, contenedores, funciones Lambda...) que reciben el tráfico. El balanceador no envía las peticiones a servidores sueltos, sino a un Target Group, que es quien agrupa los destinos.

Aquí está una de las claves más importantes: cada Target Group hace health checks (comprobaciones de salud). Periódicamente, el balanceador «pregunta» a cada servidor si está bien (por ejemplo, haciendo una petición a una URL como /health).

• Si el servidor responde correctamente → está «sano», recibe tráfico.
• Si no responde (se ha caído, está saturado...) → se marca «no sano» y el balanceador deja de enviarle peticiones automáticamente, hasta que se recupere.

Esto es lo que da la alta disponibilidad del subcapítulo 13.1. Gracias a los health checks, si un servidor falla, los usuarios nunca llegan a él: el balanceador los redirige a los servidores sanos sin que nadie note el problema. Sin health checks, el balanceador seguiría enviando gente a un servidor caído.

Las reglas (rules) conectan listeners con Target Groups. En un ALB (que es inteligente, capa 7), las reglas pueden mirar el contenido de la petición para decidir a qué Target Group enviarla:

Esto es el enrutamiento inteligente que mencionamos en el subcapítulo 13.1: un mismo balanceador puede repartir el tráfico a distintos grupos de servidores según la URL, el dominio, las cabeceras, etc.

Imagina una tienda online. El recorrido de una petición a https://tienda.com/api/productos:

1. Listener del puerto 443 (HTTPS) recibe la petición.
2. Una regla ve que la ruta empieza por /api/ → la envía al Target Group servidores-api.
3. El Target Group servidores-api tiene 3 servidores; 2 están sanos. Envía la petición a uno de los sanos.
4. Ese servidor responde, y la respuesta vuelve al usuario por el mismo camino.

• Una petición recorre tres etapas: Listener (escucha un puerto) → Reglas (deciden el destino) → Target Group (servidores que responden).
• El listener escucha en un puerto (80 para HTTP, 443 para HTTPS); es habitual redirigir 80 → 443.
• El Target Group agrupa los servidores destino y hace health checks: si un servidor no responde, deja de recibir tráfico automáticamente. Esto es lo que da la alta disponibilidad.
• Las reglas (en el ALB) permiten enrutamiento inteligente por ruta, host o cabeceras hacia distintos Target Groups.

En el siguiente subcapítulo veremos la otra mitad de la magia: cómo crear y eliminar servidores automáticamente según la demanda, con los Auto Scaling Groups.