Por qué ELB tiene 3 tipos - La lógica de diseño detrás de la separación de ALB, NLB y CLB
Explicamos por qué los 3 tipos de balanceadores de carga ALB, NLB y CLB (Classic) coexisten sin unificarse, desde la perspectiva de las capas del modelo OSI, las características de rendimiento y la evolución histórica.
Classic Load Balancer - El origen de ELB
CLB fue lanzado en 2009 como el primer servicio de balanceo de carga de AWS. Soporta tanto L4 (TCP) como L7 (HTTP/HTTPS) en un solo producto, pero esta generalidad se convirtió en una limitación. Al intentar cubrir ambas capas, no podía optimizarse completamente para ninguna. Las funciones de L7 como el enrutamiento basado en rutas o la afinidad de sesión basada en cookies eran limitadas, y el rendimiento de L4 no alcanzaba el nivel de un balanceador dedicado. CLB se mantiene por compatibilidad retroactiva, pero AWS recomienda migrar a ALB o NLB para nuevas implementaciones.
El nacimiento de ALB - Diseño especializado en L7
ALB fue lanzado en 2016 como un balanceador de carga especializado en la capa de aplicación (L7). Analiza el contenido HTTP/HTTPS y proporciona enrutamiento basado en rutas, enrutamiento basado en hosts, enrutamiento basado en encabezados y soporte nativo para WebSocket. Los grupos de destino permiten dirigir el tráfico a diferentes microservicios según la URL, lo que lo hace ideal para arquitecturas de microservicios. También soporta autenticación integrada con Cognito y OIDC, terminación gRPC y respuestas fijas. Al especializarse en L7, puede ofrecer funciones ricas que CLB no podía proporcionar.
El nacimiento de NLB - Búsqueda del rendimiento extremo en L4
NLB fue lanzado en 2017 como un balanceador de carga especializado en la capa de transporte (L4). Procesa millones de solicitudes por segundo con latencia de microsegundos. Al no analizar el contenido HTTP, logra un rendimiento extremo con paso directo de paquetes TCP/UDP. Soporta IPs estáticas (Elastic IP), lo que permite registrar IPs fijas en listas de permitidos de firewalls. También soporta terminación TLS, preservación de IP de origen y destinos en múltiples zonas de disponibilidad. Es la opción para protocolos no HTTP, requisitos de ultra baja latencia o necesidad de IP estática.
Por qué no se unifican en uno solo
La razón por la que AWS no unifica los 3 tipos en un solo producto es que los requisitos de L4 y L7 son fundamentalmente incompatibles. L7 necesita analizar el contenido HTTP (inspección profunda de paquetes), lo que inevitablemente agrega latencia. L4 necesita pasar paquetes sin inspección para lograr rendimiento extremo. Intentar satisfacer ambos en un solo producto resultaría en compromisos que no satisfacen completamente a ninguno. La filosofía de AWS de servicios de propósito específico (purpose-built) se refleja aquí: cada servicio se optimiza para un caso de uso específico en lugar de ser un producto genérico que intenta hacer todo.
Criterios de selección
Se elige ALB para aplicaciones HTTP/HTTPS que necesitan enrutamiento basado en contenido, microservicios o WebSocket. Se elige NLB para protocolos TCP/UDP no HTTP, requisitos de ultra baja latencia, necesidad de IP estática o volúmenes extremadamente altos de conexiones. CLB no se recomienda para nuevas implementaciones. Para la mayoría de las aplicaciones web, ALB es la opción predeterminada. NLB se selecciona solo cuando hay requisitos específicos que ALB no puede satisfacer. La combinación de ALB detrás de NLB (NLB → ALB) permite obtener IP estática con funciones de L7, aunque agrega complejidad y costo.