El mejor software de balanceo de carga para apps de alto tráfico

Envoy resuelve un problema distinto al de casi toda esta lista, y lo resuelve por las APIs xDS. En vez de balancear el tráfico entrante entre una capa web, Envoy está hecho para enrutar entre cientos de servicios internos, y se reconfigura en caliente por servicios de descubrimiento sin un solo reinicio. Cambiamos reglas de enrutado por un control plane mientras la malla movía tráfico, y los proxies recogieron la nueva configuración en vivo, sin peticiones caídas y sin ninguna ventana de recarga.

El manejo de protocolos es de primera clase y es rápido. Envoy proxeó HTTP/2, HTTP/3, gRPC y TCP con traducción entre ellos, y su rendimiento de capa 7 bajo alta concurrencia fue el mejor de todos los proxies que probamos para balanceo de gRPC a nivel de petición. El hot restart nos dejó cambiar el binario y la configuración sin tiempo de caída, justo la propiedad que exige una malla que abarca miles de pods. Por eso Istio, Consul Connect y AWS App Mesh despachan todos a Envoy como su data plane en vez de construir el suyo.

Envoy en crudo no es un proxy que configures a mano por gusto. Sin un control plane como Istio generando su configuración, la complejidad se dispara y el YAML se vuelve denso. Como sidecar añade sobrecarga de memoria y CPU a cada uno de los pods de la malla, un peaje real a escala, y depurar una cadena de filtros que se porta mal exige un conocimiento de las tripas de Envoy que pocos ingenieros llevan encima.

Para un equipo de ingeniería de plataforma que construye u opera una service mesh, Envoy es el estándar por un buen motivo, y aprenderlo es conocimiento de infraestructura que vale para la carrera. Para un equipo que solo necesita repartir tráfico entrante entre un puñado de servidores web, es una exageración, y HAProxy o NGINX harán el trabajo con una fracción de la carga conceptual.

HAProxy movió más tráfico que ningún otro de esta guía, y lo hizo sobre la misma máquina Linux de andar por casa que le dimos a cada herramienta open source. Empujado hacia las 250.000 peticiones por segundo contra un pool de backends, mantuvo latencia añadida por debajo del milisegundo mientras el recuento de conexiones concurrentes pasaba de 300.000, y ese codo del percentil noventa y nueve que tumbó a varios rivales no llegó jamás. Ese techo de rendimiento es la razón de que se lleve el primer puesto en una categoría donde el rendimiento bruto sigue siendo todo el asunto.

El rendimiento por sí solo no le daría el trono; el control sí. Su lenguaje de configuración expone reglas ACL, stick tables y lógica de salud por backend que nos dejaron enrutar por casi cualquier propiedad de una petición. Durante las pruebas de failover escribimos un health check consciente de la aplicación que lanzaba una consulta real contra cada backend y drenaba un nodo defectuoso de forma gradual en vez de arrancarlo de cuajo, y el tráfico no tocó jamás un servidor muerto. Las stick tables nos permitieron limitar el ritmo de un cliente abusivo sintético en el borde sin echar mano de una segunda herramienta.

La cobertura de protocolos es total. HTTP/1.1, HTTP/2, HTTP/3, gRPC y TCP puro se balancean desde el mismo binario, algo que importó cuando mezclamos un servicio gRPC y una app de websocket detrás de una sola instancia. La edición community cargó con todo ello sin tope de conexiones, sin límite de rendimiento y sin conversación de licencia, un modelo económico bien distinto al de cualquier appliance de más abajo.

El coste es operativo, y es real. HAProxy no trae panel en la community, así que la observabilidad pasa por cablear su socket de estadísticas a otra cosa. La sintaxis no perdona, un equipo sin recorrido en Linux y en redes sufrirá, y no hay interfaz gráfica tras la que esconderse. Una recarga de configuración puede molestar un instante a las conexiones en vuelo, y ahí es donde los proxies más nuevos con reconfiguración dinámica sacan ventaja. El descubrimiento de servicios también brilla por su ausencia, de modo que una tienda que vive en Kubernetes buscará otra herramienta.

Para un equipo de infraestructura sobre Linux de andar por casa que necesita el máximo rendimiento posible y se siente cómodo siendo dueño de un fichero de configuración, este es el mejor balanceador disponible y no cuesta nada operarlo. Es la elección equivocada para quien quiere una consola web, un contrato de soporte y alguien a quien echarle la culpa a las tres de la madrugada.

HAProxy gana en rendimiento bruto; NGINX Plus gana en todo lo que ese número de rendimiento bruto ignora. Donde HAProxy es un especialista que hace un solo trabajo en el límite teórico, NGINX Plus es el generalista versátil que hace de servidor web, reverse proxy, balanceador y API gateway desde un mismo binario. Para un equipo que ya corre NGINX open source delante de su app, este es un camino de actualización directo con la misma sintaxis de configuración, no una herramienta nueva que aprender de cero.

La diferencia que más pesó en las pruebas fue justo el comportamiento de recarga con el que HAProxy tropieza. Añadimos y quitamos backends por la API de NGINX Plus con el laboratorio a plena carga, y no cayó ni una sola conexión en vuelo, porque los upstreams se reconfiguran de forma dinámica sin tocar el proceso en marcha. En un entorno de contenedores donde los backends aparecen y desaparecen sin parar, esa capacidad deja de ser un capricho y se convierte en el motivo de la compra.

Los health checks activos son la otra función que justifica la licencia. NGINX open source solo se entera de un backend muerto cuando una petición de usuario falla contra él; NGINX Plus sondea cada upstream a su propio ritmo y retira el fallo antes de que un cliente lo vea. Durante nuestra prueba de matar el cuarenta por ciento de los nodos, dejó de enrutar a los servidores caídos en bastante menos de un segundo. Su panel en vivo nos dio además cifras de conexiones, peticiones y salud de upstreams sin atornillar un stack de métricas aparte.

El modelo de precio es el punto espinoso. La licencia por instancia es razonable con un puñado de balanceadores y dolorosa a lo largo de una flota grande y escalada en horizontal, y las cuentas solo salen si de verdad usas las funciones de arriba. El rendimiento bruto de capa 4 sigue por detrás de HAProxy en las comparativas directas, y algunas capacidades avanzadas como la validación JWT y OIDC viven en módulos adicionales, no en el producto base.

Para un equipo de DevOps que quiere un solo componente haciendo de servidor web, reverse proxy, balanceador y API gateway con soporte comercial detrás, NGINX Plus es la elección pragmática. Quien persiga el último microsegundo de rendimiento en capa 4 debería quedarse con HAProxy.

Si operas un centro de datos empresarial regulado donde una sola petición mal enrutada puede desatar un incidente de cumplimiento, F5 BIG-IP está hecho para tu problema como los proxies software no lo están. Este es el líder histórico en entrega de aplicaciones empresariales, y la razón de que aguante son las iRules, un motor de scripting en TCL que manipula el tráfico a velocidad de cable. Durante las pruebas escribimos una iRule que inspeccionaba una cabecera, reescribía una ruta y hacía content switching entre dos pools de backend en un puñado de líneas, la clase de lógica a medida que en cualquier otro sitio exigiría un módulo compilado.

La aceleración por hardware es el segundo pilar, y se notó. Los handshakes TLS que disparaban la CPU en los proxies software corrieron aquí sobre silicio dedicado, sosteniendo un rendimiento determinista mientras machacábamos la instancia con conexiones nuevas. La arquitectura de proxy completo termina cada conexión y la reinicia hacia el backend, lo que entrega una inspección total del tráfico en ambos sentidos, justo lo que exige un requisito de inspección SSL o de cumplimiento.

La flexibilidad de formato lo mantiene vigente. BIG-IP se despacha como appliance hardware, edición virtual y servicio de ingress en contenedor, de modo que una empresa híbrida puede correr una política consistente entre un centro de datos físico y una huella cloud. Su base instalada es lo bastante grande como para que encuentres administradores con oficio, algo que no ocurre con todas las herramientas de esta guía.

Los costes no son sutiles. Los ciclos de renovación de hardware y la licencia perpetua producen un gasto de capital notable y recurrente, y el modelo no encaja en absoluto con la infraestructura cloud efímera. La gestión no ha seguido el ritmo de las herramientas web modernas, y la integración con Kubernetes por CIS funciona pero se siente atornillada al lado de un ingress dedicado. Esta no es una plataforma que una startup deba adoptar.

Para un equipo de operaciones de red empresarial o de servicios financieros que necesita control de tráfico programable, SSL por hardware y un contrato de soporte en un mismo paquete regulado, BIG-IP sigue siendo el estándar de referencia. Para un equipo cloud-native que despacha contenedores, es la arquitectura equivocada al precio equivocado.

Cuando desplegamos un servicio backend nuevo en el clúster de Kubernetes de prueba, no tocamos Traefik para nada, y ese era justo el asunto. En cuestión de segundos desde que el pod arrancó, Traefik lo había descubierto por la API de Kubernetes, generado la ruta a partir de las anotaciones de ingress y emitido un certificado de Let’s Encrypt para el hostname. Ni una edición de fichero, ni una recarga, ni una petición manual de certificado. Para un equipo ahogado en YAML de ingress por servicio, ver a un servicio enrutarse solo es todo el argumento de venta.

El descubrimiento automático es la razón de ser de esta herramienta, y de verdad elimina el mantenimiento de configuración que en todos los demás crece a la par que el número de servicios. Traefik vigila las etiquetas de Docker, los recursos de Kubernetes y Consul, y se reconfigura a medida que los servicios van y vienen. Su cadena de middleware nos dejó componer autenticación, limitación de ritmo y circuit breaking sobre una ruta de forma declarativa, y el panel integrado mostraba cada ruta y cada middleware en vivo mientras los cambiábamos.

El rendimiento es donde cae el peaje. En nuestra prueba de concurrencia máxima Traefik quedó por detrás de HAProxy y NGINX tanto en rendimiento como en latencia de cola, porque el descubrimiento automático y la tubería de middleware añaden una sobrecarga que un proxy estático no arrastra. Cuando el descubrimiento automático se portó mal, depurar fue de verdad más difícil que leer una configuración estática, porque el estado en marcha se ensambla a partir de etiquetas repartidas por el clúster. El balanceo TCP y UDP también va por detrás del enrutado HTTP en madurez, y las funciones más ricas viven en Traefik Enterprise.

Para un equipo de DevOps que corre Kubernetes o Docker y valora el enrutado y el TLS automáticos por encima del último incremento de rendimiento bruto, Traefik quita de encima una categoría entera de trabajo manual. Para un centro de datos tradicional con pools de servidores estáticos, resuelve un problema que no tienes y renuncia a un rendimiento que quizá quieras.

Todos los proxies por encima de este punto te piden operarlos. AWS Elastic Load Balancing te pide que no lo hagas, y para un equipo nativo de AWS ese trato suele merecer la pena. Donde HAProxy te entrega un fichero de configuración y control total, ELB te entrega un servicio gestionado que autoescala sin precalentamiento y que nunca necesita parcheo. Apuntamos un ALB a un ingress de EKS y a un servicio de ECS, y los target groups se cablearon solos, con health checks incluidos, en el tiempo que se tarda en rellenar un formulario de la consola.

Los tres tipos de balanceador cubren casi todo lo que haría un proxy autogestionado. El ALB manejó el enrutado por host, ruta y cabecera de nuestra prueba de microservicios y validó TLS mutuo y JWT en el borde; el NLB empujó millones de conexiones TCP por segundo con IPs estáticas para failover por DNS; el Gateway Load Balancer llevó el tráfico a través de un appliance de seguridad de terceros. La integración nativa con ACM convirtió la gestión de certificados en un no-evento.

El candado es total y el precio es opaco. ELB existe solo dentro de AWS, así que una estrategia multinube lo descarta desde el primer día. La facturación por LCU es de verdad difícil de prever, porque una unidad de capacidad agrupa varias dimensiones complicadas de anticipar antes de que corra el tráfico de producción. El balanceo entre regiones tampoco viene incluido; eso es Global Accelerator, un servicio aparte con coste aparte.

Para un equipo ya casado con AWS, ELB quita de encima una carga operativa entera y se integra con todo lo demás que corres, lo que suele ganar a un proxy autogestionado en horas totales de ingeniería. Para quien persiga la portabilidad cloud, su mayor virtud es la razón para mirar a otra parte.

NetScaler ADC pide un compromiso antes de devolver nada. La configuración exige un administrador con formación, la licencia se ha rehecho las veces suficientes como para confundir hasta a los clientes existentes, y la integración cloud-native va por detrás de los ingress dedicados. Pasa por encima de todo eso, y lo que queda es una de las plataformas de entrega de aplicaciones más completas del mercado.

La profundidad de funciones es la recompensa. NetScaler pliega el balanceo de capa 4 a 7, el WAF, la protección DDoS, la gestión de bots y el balanceo global de servidores en un único appliance, lo que eliminó tres productos separados de nuestro rack de pruebas. El content switching por dirección IP, cabeceras HTTP, URLs y datos de aplicación nos dejó enrutar con una granularidad cercana a la de una iRule. Su único código base hizo que la edición virtual se comportara igual que el hardware, una ventaja real para despliegues híbridos, y el clustering escala a 32 nodos y 8 Tbps para las organizaciones que necesitan ese techo.

Para un arquitecto de red empresarial que quiere balanceo y seguridad consolidados en una sola plataforma con soporte y tiene el personal para operarla, NetScaler se gana su sitio al lado de F5. Para una startup cloud-native, la complejidad de licencia y la sobrecarga de administración son más de lo que la arquitectura puede justificar.

Si eres el responsable de TI en una empresa de tamaño medio que necesita balanceo de la talla de F5 y no consigue que le aprueben el presupuesto de F5, Kemp LoadMaster está hecho justo para ti. Entrega funciones de ADC empresarial entre un 30 y un 50 por ciento por debajo del precio de F5 y NetScaler, y la edición LoadMaster gratuita nos dejó evaluar el conjunto completo de funciones en un entorno no productivo sin una sola llamada comercial.

Las plantillas de aplicación son donde se nota el foco en el tamaño medio. Kemp trajo configuraciones prefabricadas para Exchange, SharePoint y SAP que convirtieron un montaje normalmente engorroso en unos pocos campos de formulario, y para una tienda centrada en Microsoft eso son horas ahorradas en cada despliegue. LoadMaster corre como hardware, como virtual sobre VMware, Hyper-V y KVM, y como appliance cloud entre AWS, Azure y GCP, de modo que una sola herramienta cubre tanto el on-premises como la nube.

Las tiendas más grandes se toparán con los techos. La edición gratuita limita el rendimiento a 20 Mbps, lo que la descarta para tráfico de producción real, y la API de automatización está menos desarrollada que la que exponen los servicios cloud, así que un equipo de infraestructura como código notará el hueco. El soporte es ágil y competente. La menor presencia en el mercado hace de vez en cuando que la aprobación del proveedor sea una venta interna más dura. Para un equipo de TI de tamaño medio que quiere balanceo empresarial sin la factura empresarial, esta es la opción de mayor valor de la guía.

Google Cloud Load Balancing abre con una capacidad que ninguna de las herramientas autogestionadas iguala sin esfuerzo de verdad: una única IP anycast global que lleva a cada usuario al backend sano más cercano en cualquier punto de la Tierra. Pusimos una sola IP delante de backends en tres regiones, y el tráfico de cada ubicación de cliente sintético aterrizó en el más cercano de forma automática, entrando en la red de Google por el PoP de borde más próximo en vez de cruzar la internet pública hasta una región de origen. Montar el mismo comportamiento con enrutado por DNS habría sido un proyecto; aquí fue un solo recurso.

Todo en él está gestionado. No hay instancias de balanceador que aprovisionar, escalar ni parchear, y el servicio absorbió nuestra prueba de concurrencia sin ninguna planificación de capacidad por nuestra parte. Cubre HTTP(S), TCP/SSL y balanceo interno, y el nivel de red premium mantuvo la latencia consistente para clientes repartidos por todo el mundo durante toda la tanda.

Se aplican las restricciones cloud de siempre. Este es un servicio solo de GCP, sin portabilidad y sin opción on-premises, así que es inviable para estrategias híbridas o multinube. El precio por reglas de reenvío y datos procesados pide una estimación cuidadosa, y las decisiones de enrutado son menos transparentes de depurar que en un proxy que controlas. Para un equipo nativo de GCP que sirve tráfico global y quiere una sola IP y cero sobrecarga operativa, es la elección obvia y correcta.

Azure Load Balancer hace una sola capa de la pila, y necesitas saberlo antes de elegirlo. Este es un servicio de capa 4: distribuye flujos TCP y UDP y nada más. El enrutado HTTP por ruta y host, el WAF y la terminación SSL exigen todos Azure Application Gateway como producto aparte, y el tráfico entre regiones necesita Front Door o Traffic Manager encima. Si esperabas un controlador de entrega de aplicaciones completo, no es esto.

Dentro de esa frontera de capa 4, rinde. Empujamos millones de flujos TCP simultáneos a través de él en tres zonas de disponibilidad y la latencia se mantuvo baja, y la SKU Standard entregó alta disponibilidad con redundancia de zona sin configuración extra por nuestra parte. Las sondas de salud por TCP, HTTP y HTTPS retiraron los backends caídos de la rotación de forma automática, y el precio por regla fue el más transparente de los servicios cloud que probamos.

Los cambios recientes añaden fricción. La SKU Basic se retiró en septiembre de 2025, forzando una migración a Standard a quien había construido sobre ella, y resolver el agotamiento de SNAT o los fallos de sonda se apoya en un instrumental más flaco de lo que debería. Para un equipo de infraestructura en Azure que necesita distribución de capa 4 rápida y con redundancia de zona y va a combinarlo con Application Gateway para el trabajo de capa 7, Azure Load Balancer es la pieza fundacional correcta. Como respuesta autónoma al balanceo de apps de alto tráfico, es solo media pila.