ALB frente a NLB y GLB: cuándo utilizar cada uno

Elastic Load Balancing (ELB) distribuye automáticamente el tráfico entrante de las aplicaciones entre varios destinos: instancias de EC2, contenedores, funciones de Lambda o direcciones IP. ELB es un servicio administrado, lo que significa que AWS se encarga del aprovisionamiento, el escalado y la disponibilidad del propio balanceador de carga en varias AZ.

AWS ofrece tres tipos de balanceadores de carga bajo la familia ELB: Application Load Balancer (ALB), Network Load Balancer (NLB) y Gateway Load Balancer (GWLB). Cada uno opera en una capa diferente del modelo OSI y está optimizado para distintos casos de uso.

El ALB opera en la capa 7 (HTTP/HTTPS) del modelo OSI. Puede inspeccionar encabezados HTTP, rutas, cadenas de consulta, nombres de host y cookies para tomar decisiones de enrutamiento inteligentes. ALB es la opción habitual para aplicaciones web, microservicios y endpoints de API que necesitan enrutamiento basado en contenido.

Funciones principales de ALB: enrutamiento basado en rutas (/api/* a un grupo de destinos y /static/* a otro), enrutamiento basado en host (distintos hosts virtuales a diferentes backends), enrutamiento basado en encabezados HTTP y cadenas de consulta, compatibilidad con WebSocket y compatibilidad con HTTP/2. ALB puede enrutar hacia instancias de EC2, contenedores (ECS/EKS), funciones de Lambda y direcciones IP.

El NLB opera en la capa 4 (TCP/UDP/TLS). Enruta paquetes basándose en los datos del protocolo IP sin inspeccionar el contenido de la aplicación. NLB está diseñado para un rendimiento extremo: gestiona millones de solicitudes por segundo con una latencia ultrabaja (normalmente inferior a 100 microsegundos).

Funciones principales de NLB: direcciones IP estáticas por AZ (una Elastic IP por subred), transferencia directa de TLS (reenvío de tráfico cifrado sin descifrarlo), conservación de la dirección IP del cliente y compatibilidad con protocolos UDP (por ejemplo, DNS, RADIUS y servidores de juegos). NLB no puede realizar enrutamiento basado en contenido ni inspeccionar encabezados HTTP.

El GWLB opera en la capa 3 (capa de red) y está diseñado exclusivamente para implementar, escalar y administrar dispositivos de red virtuales de terceros: firewalls, sistemas de detección y prevención de intrusiones (IDS/IPS) y sistemas de inspección profunda de paquetes.

GWLB utiliza el protocolo GENEVE (puerto 6081) para encapsular el tráfico y enviarlo a su flota de dispositivos. El dispositivo inspecciona el paquete y lo devuelve a través del mismo endpoint de GWLB. El tráfico fluye de forma transparente sin necesidad de modificar el enrutamiento en la VPC de origen. Este es el patrón estándar para insertar inspección de seguridad centralizada en los flujos de tráfico de las VPC de AWS.

Elija ALB cuando:

• Necesite enrutamiento basado en contenido HTTP/HTTPS (ruta, host, encabezado o cadena de consulta)
• Su backend incluya funciones de Lambda o contenedores de ECS
• Necesite conexiones WebSocket o HTTP/2
• Desee integrarlo con AWS WAF para proteger aplicaciones web en la capa del balanceador de carga
• Esté creando una arquitectura de microservicios con muchos servicios en diferentes rutas URL
• Necesite la terminación de SSL/TLS en el balanceador de carga

ALB es la respuesta correcta para la mayoría de las preguntas del examen SAA-C03 sobre balanceo de carga de aplicaciones web y API REST.

Elija NLB cuando:

• Necesite un rendimiento extremo (millones de solicitudes por segundo y latencia inferior a un milisegundo)
• Requiera direcciones IP estáticas que los socios o firewalls puedan incluir en listas de permitidos
• Necesite gestionar tráfico UDP (videojuegos, DNS, RADIUS o IoT)
• Desee una transferencia directa de TLS sin descifrado en el balanceador de carga (cifrado de extremo a extremo hasta el destino)
• Necesite conservar de forma nativa la IP de origen del cliente en la capa TCP
• Utilice AWS PrivateLink para exponer servicios a otras VPC o cuentas (PrivateLink requiere NLB)

Elija GWLB cuando necesite:

• Insertar dispositivos firewall de terceros (Palo Alto, Fortinet o Check Point) en el flujo de tráfico de su red
• Realizar una inspección profunda de paquetes a nivel de VPC para todo el tráfico entrante o saliente
• Escalar horizontalmente una flota de dispositivos IDS/IPS con balanceo de carga automático

Arquitectura: el tráfico fluye desde la VPC de origen → endpoint de GWLB → VPC de dispositivos (donde GWLB distribuye el tráfico entre las instancias de los dispositivos) → el dispositivo devuelve el tráfico a GWLB → GWLB lo reenvía al destino original. El origen y el destino desconocen la inspección intermedia.

El balanceo de carga entre zonas distribuye el tráfico de forma uniforme entre todos los destinos registrados en todas las AZ habilitadas, independientemente de la AZ en la que el nodo del balanceador de carga haya recibido la solicitud. Sin el balanceo entre zonas, el nodo de cada AZ solo distribuye tráfico a los destinos de su propia AZ.

ALB tiene el balanceo entre zonas habilitado de forma predeterminada y sin costo adicional. NLB tiene el balanceo entre zonas deshabilitado de forma predeterminada; habilitarlo genera cargos por transferencia de datos entre AZ. GWLB también tiene el balanceo entre zonas deshabilitado de forma predeterminada. Habilite el balanceo entre zonas cuando el número de destinos no sea uniforme entre las AZ para evitar puntos de saturación.

Tabla de comparación rápida para el examen:

• Capa OSI: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protocolos: ALB = HTTP, HTTPS y WebSocket; NLB = TCP, UDP y TLS; GWLB = todos los protocolos IP mediante GENEVE
• IP estática: ALB = No (use el patrón NLB + ALB); NLB = Sí (1 por AZ); GWLB = N/A
• Integración con WAF: ALB = Sí; NLB = No; GWLB = No
• Destino Lambda: ALB = Sí; NLB = No; GWLB = No
• Desconexión progresiva: los tres admiten un retraso de anulación del registro

ALB se integra de forma nativa con AWS WAF para ofrecer protección regional (a diferencia de WAF en CloudFront, que proporciona protección global en el edge). Al asociar una ACL web de WAF a un ALB, puede filtrar las solicitudes HTTP antes de que lleguen a su aplicación: bloquear inyecciones de SQL, XSS, IP maliciosas conocidas y clientes que abusen de la tasa de solicitudes.

Use ALB + WAF cuando desee realizar la inspección de seguridad en la capa del balanceador de carga (por ejemplo, para proteger API que no se sirven a través de CloudFront). Las ACL web de WAF asociadas a ALB deben estar en la misma región que el ALB y deben tener el alcance REGIONAL (a diferencia de WAF de CloudFront, que requiere el alcance CLOUDFRONT en us-east-1).

AWS PrivateLink utiliza NLB para exponer servicios de una VPC a consumidores de otras VPC o cuentas de AWS sin necesidad de interconexión de VPC, una puerta de enlace de Internet ni NAT. El proveedor del servicio crea un NLB delante de su servicio y crea un servicio de endpoint de VPC. Los consumidores crean un endpoint de VPC de interfaz en su VPC que apunta al servicio.

El tráfico fluye por la red privada de AWS y nunca atraviesa Internet. PrivateLink es el patrón estándar para proveedores de SaaS en AWS y para exponer servicios compartidos (por ejemplo, un servicio de seguridad centralizado) a varias cuentas internas de AWS.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección aprendió que: ALB enruta en la capa 7 (HTTP) mediante reglas basadas en contenido, integración con WAF y destinos Lambda; NLB enruta en la capa 4 (TCP/UDP) con IP estáticas y un rendimiento extremo; y GWLB implementa dispositivos de red virtuales en la capa 3 mediante GENEVE. Relacione cada balanceador de carga con los requisitos de protocolos y funciones. A continuación, exploraremos los grupos de destinos y las comprobaciones de estado.