Un Network Load Balancer (NLB) opera en la Capa 4 del modelo OSI (la capa de transporte), distribuyendo el tráfico de red entrante, como TCP, UDP y TLS, a través de un grupo de destinos saludables. A diferencia de los balanceadores de carga de Capa 7 (Application Load Balancers), los NLB no inspeccionan el contenido de las solicitudes HTTP/HTTPS. En su lugar, toman decisiones de enrutamiento basándose en la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el tipo de protocolo. Esto permite a los NLB manejar volúmenes de tráfico extremadamente altos con una latencia ultrabaja, preservando la dirección IP de origen del cliente, lo cual es crucial para ciertas aplicaciones y sistemas de seguridad.
En el mundo real, los Network Load Balancers son componentes clave en arquitecturas de nube y entornos de alta disponibilidad. Ejemplos concretos incluyen AWS Network Load Balancer, Google Cloud Network Load Balancer y Azure Load Balancer (en su modo de balanceo de carga de Capa 4). Estos servicios se utilizan para balancear el tráfico a bases de datos, clústeres de Kubernetes (exponiendo servicios de tipo LoadBalancer), servidores de juegos, sistemas de streaming en tiempo real y cualquier aplicación que requiera un rendimiento extremo y una baja latencia a nivel de red. También son fundamentales para exponer servicios internos a través de IPs públicas con alta resiliencia y escalabilidad.
Para un arquitecto, el Network Load Balancer es una herramienta estratégica para diseñar sistemas de alto rendimiento y disponibilidad. La elección de un NLB frente a un Application Load Balancer (ALB) implica un trade-off: se gana en rendimiento, latencia y capacidad de manejar tráfico no-HTTP/HTTPS, pero se pierde la inteligencia de enrutamiento basada en el contenido de la aplicación (ej. rutas URL, headers HTTP) y funcionalidades avanzadas como terminación SSL/TLS a nivel de balanceador (aunque algunos NLB modernos ofrecen TLS passthrough). La preservación de la IP de origen es vital para la auditoría, la geolocalización y la implementación de firewalls a nivel de aplicación. Un arquitecto debe considerar el NLB cuando la aplicación requiere la máxima velocidad, el tráfico no es HTTP/HTTPS, o cuando la lógica de enrutamiento de Capa 7 se maneja mejor dentro de los propios servicios backend (ej. con un Ingress Controller en Kubernetes).