AWS ELB

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.