Empezamos la Parte IV dando un salto: de servidores sueltos a arquitecturas que escalan. La primera pieza clave es el balanceador de carga, el componente que reparte el tráfico entre varios servidores. En este capítulo aprenderás a usarlo y, en este primer subcapítulo, a elegir entre los dos tipos principales de AWS: el Application Load Balancer (ALB) y el Network Load Balancer (NLB).

En el Capítulo 12 montaste un servidor. Pero ¿qué pasa si...?

• Recibes mucho tráfico y un servidor no da abasto.
• Ese servidor se cae: tu web entera deja de funcionar.

La solución es tener varios servidores y poner algo delante que reparta las peticiones entre ellos. Ese «algo» es el balanceador de carga (load balancer).

Un balanceador de carga es como el maître de un restaurante muy concurrido: en la puerta, va asignando a cada cliente que llega una mesa libre, repartiéndolos entre todos los camareros para que ninguno se sature.

Beneficios inmediatos:

• Reparte la carga: ningún servidor se satura.
• Alta disponibilidad: si un servidor se cae, el balanceador deja de enviarle tráfico y usa los demás. Los usuarios ni se enteran.
• Punto de entrada único: los usuarios acceden a una sola dirección, sin saber cuántos servidores hay detrás.

AWS ofrece varios balanceadores, pero los dos que debes conocer son el ALB y el NLB. La diferencia clave está en a qué nivel trabajan.

Trabaja a nivel de aplicación (capa 7): entiende de HTTP y HTTPS. Esto significa que «sabe leer» las peticiones web y puede tomar decisiones inteligentes según su contenido:

• Enviar /api/* a unos servidores y /imagenes/* a otros (enrutamiento por ruta).
• Enviar tienda.midominio.com y blog.midominio.com a grupos distintos (enrutamiento por host).
• Gestionar certificados HTTPS, cabeceras, cookies de sesión, etc.

Es el balanceador por defecto para aplicaciones web y APIs.

Trabaja a nivel de red (capa 4): solo entiende de TCP/UDP, sin mirar el contenido. A cambio, es extremadamente rápido y soporta muchísimo tráfico con latencia mínima.

• No lee HTTP; solo reparte conexiones de red.
• Ideal para rendimiento extremo, protocolos que no son HTTP (por ejemplo, bases de datos, juegos online, IoT, streaming) o cuando necesitas una IP fija.

• El ALB es como un recepcionista de hotel que lee tu petición («quiero el spa», «busco el restaurante») y te dirige al sitio adecuado. Es inteligente, pero esa lectura lleva un instante.
• El NLB es como un torniquete de metro: no le importa quién eres ni a dónde vas, solo deja pasar a la gente lo más rápido posible. Es tremendamente veloz, pero «no piensa».

La regla práctica para empezar es sencilla:

• ¿Es una aplicación web o una API (HTTP/HTTPS)? → ALB. Es el caso del 90 % de los proyectos. Es lo que usarás casi siempre.
• ¿Necesitas máximo rendimiento, una IP fija, o trabajas con protocolos que no son HTTP? → NLB.

Para principiantes: céntrate en el ALB. Es el que usarás en la inmensa mayoría de aplicaciones web, y es el que veremos en el resto del capítulo (Target Groups, listeners, autoescalado). El NLB lo tendrás ahí para casos especiales de alto rendimiento.

• Un balanceador de carga reparte el tráfico entre varios servidores: da escalado y alta disponibilidad (si uno cae, usa los demás).
• El ALB (capa 7) entiende de HTTP/HTTPS y es inteligente: enruta por ruta, host, cabeceras. Es el estándar para webs y APIs.
• El NLB (capa 4) solo entiende de TCP/UDP, es extremadamente rápido y permite IP fija. Para rendimiento extremo o protocolos no-HTTP.
• Regla práctica: ¿aplicación web? → ALB. Casos especiales de rendimiento o no-HTTP → NLB.

En el siguiente subcapítulo veremos cómo el balanceador sabe a qué servidores enviar el tráfico: los Target Groups, los listeners y las reglas.