Elastic Load Balancer es el servicio de balanceo de AWS como servicio, que nos permite definir una única IP para después balancear el tráfico a distintos destinos (instancias EC2, lambda functions, …).
Hay varios tipos, que se detallarán a continuación:
CLB – Classic Load Balancer
Es el más antiguo de los tres, y ya no se recomienda su uso, ya que es preferible utilizar cualquiera de los otros dos que están vigentes desde 2016/2017. Las características son:
- Soporta TCP (capa 4) HTTP y HTTPS (capa 7)
- Health Checks TCP o HTTP
- Nombre fijo: XXXX.region.elb.amazonaws.com
- El destino del balanceo son instancias EC2
Y los inconvenientes son:
- No permite crear health checks bajo HTTPS.
- Solo puede gestionar un único balanceo de tipo HTTPS.
- No analiza el tráfico HTTPS, por tanto no permite crear reglas de balanceo en base a distintos patrones (Host, Path, …)
ALB – Application Load Balancer
Balanceador específico y exclusivo para capa 7 HTTP, que tiene las siguientes características:
- Puede balancear a múltiples aplicaciones HTTP a distintas máquinas (target groups)
- Puede balancear a múltiples aplicaciones en la misma máquina (ej: contenedores)
- Soporte HTTP/2 y WebSocket
- Soporta redirecciones (ej: de HTTP a HTTPS)
- Puede redireccionar a distintos target groups basado en:
- Path de URL (/cats y /dogs)
- Hostname de la URL (one.example.com y other.example.com
- QueryString de cabeceras (example.com/users?id=321&stock=false)
- El Target Group puede ser:
- EC2 instances
- ECS tasks
- Lambda functions
- IP Addresses (deben ser IPs privadas)
- Los health checks se definen a nivel de target group
- La IP del cliente no llega como IP origen a los target group, sino que viene en la cabecera X-Forwarded-For. También para el puerto (X-Forwarded-Port) y el protocolo (X-Forwarded-Proto)
- Nombre fijo: XXXX.region.elb.amazonaws.com
NLB – Network Load Balancer
Es un balanceador de red en capa 4, con las siguientes características:
- Balancear tráfico TCP y UDP
- Muy muy eficiente, puede gestionar millones de peticiones por segundo
- Muy baja latencia, unos 100ms (~400ms en ALB)
- Utiliza una IP estática por AZ, y soporta la asignación de Elastic IP.
- El destino puede ser una instancia EC2 o una IP
Inconvenientes:
- NLB no asocia un SG al NLB, por tanto no es sencillo habilitar tráfico desde el NLB a las instancias destino de las conexiones. En la documentación indican que se habilite el tráfico de la red del VPC completo, y además también hay que habilitar el tráfico desde los clientes, porque el NLB no hace SNAT, al destino llega la IP origen del cliente.
Stickiness
- Permite mantener las sesiones de los clientes contra las mismas instancias para mantener persistencia.
- Se puede habilitar para CLB y ALB, pero no para NLB.
- Consiste en una cookie, para la que se puede configurar la fecha de expiración
- La carga se puede repartir de manera desigual entre los backends.
- En ALB se configura a nivel de Target Group.
Cross-Zone Load Balancing
La distribución de tráfico se realiza entre todas las AZ donde se ha habilitado el balanceo:
- Classic Load Balancer: deshabilitado por defecto, pero se puede habilitar y no tiene coste.
- Application Load Balancer: siempre habilitado y no se puede deshabilitar, no tiene coste.
- Network Load Balancer: deshabilitado por defecto, y se paga una pequeña cantidad al habilitarlo.
Certificados SSL
- El balanceador utiliza certificados X.509
- Los certificados se gestionan desde ACM (AWS Certificate Manager)
- Se pueden subir certificados propios
- Listener HTTPS:
- Se debe especificar un certificado por defecto
- Se pueden añadir certificados adicionales
- Se puede utilizar una Política de Seguridad para soportar versiones antiguas de SSL/TLS.
- Se puede utilizar SNI (Server Name Indication): evita tener múltiples configuraciones (IPs o puertos diferentes) en un servidor web para cada dominio. En la negociación SSL inicial se especifica el nombre del dominio, y así se envía el certificado adecuado. Solo funciona para ALB y NLB, pero no para CLB.
Connection Draining
Es el tiempo que una instancia tarda en completar las peticiones que tiene pendientes mientras la instancia está de-registering o unhealthy. Durante este tiempo, no se envían nuevas peticiones a la instancia. Por defecto son 300 segundos, pero se puede personalizar entre 1 y 3600 segundos. Se puede deshabilitar poniendo un valor de cero.