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.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.