Elastic Load Balancer (ELB) , tipos y caracteristicas

Elastic Load Balancer (ELB): Tipos y Características

Durante su campaña anual de préstamos personales en 2024, Nexia Bank experimentó uno de los mayores volúmenes transaccionales en su historia: más de 3 millones de solicitudes procesadas en menos de 48 horas, con picos de tráfico que superaron las 60,000 operaciones por minuto entre aprobaciones, consultas y simulaciones de crédito.

Detrás de este rendimiento impecable se encontraba una infraestructura de balanceo de carga con Elastic Load Balancer (ELB), que distribuyó automáticamente millones de solicitudes entre instancias y servicios backend, manteniendo tiempos de respuesta bajos y evitando cuellos de botella.

Este caso demuestra cómo ELB permite a Nexia Bank escalar de forma automática y resiliente, garantizando una experiencia fluida incluso en los momentos de mayor presión operativa.

Tipos de Elastic Load Balancer

AWS ofrece tres tipos principales de balanceadores de carga, cada uno diseñado para casos de uso específicos:

Application Load Balancer (ALB)

El ALB opera en la capa 7 (aplicación) del modelo OSI, lo que le permite tomar decisiones de enrutamiento basadas en el contenido HTTP/HTTPS:

• Características principales:
  • Enrutamiento basado en contenido (URL, host, encabezados HTTP)
  • Soporte nativo para WebSockets
  • Soporte para HTTP/2
  • Redirecciones HTTP a HTTPS
  • Autenticación de usuarios mediante OIDC o integración con Cognito
  • Desencriptación SSL/TLS centralizada

# Ejemplo de regla de enrutamiento en ALB
IF host = "api.ejemplo.com" AND path = "/usuarios/*" THEN forward to target-group-usuarios

• Casos de uso ideales:
  • Aplicaciones web modernas
  • Microservicios
  • Aplicaciones containerizadas
  • APIs REST

Network Load Balancer (NLB)

El NLB funciona en la capa 4 (transporte), manejando millones de solicitudes por segundo con latencia ultra baja:

• Características principales:
  • Latencia extremadamente baja (~100 microsegundos)
  • Direcciones IP estáticas por zona de disponibilidad
  • Preservación de la dirección IP de origen
  • Soporte para protocolos TCP, UDP y TLS
  • Capacidad de manejar millones de solicitudes por segundo

# Ejemplo de configuración de listener NLB
TCP:443 -> TCP:443 (TLS Passthrough)
UDP:53 -> UDP:53 (DNS)

• Casos de uso ideales:
  • Juegos en línea (UDP)
  • Servicios de streaming de media
  • Aplicaciones que requieren IP estática
  • Protocolos no HTTP (MQTT, SMTP, etc.)
  • Casos donde la preservación de IP de origen es crítica

Classic Load Balancer (CLB)

El CLB es la generación anterior de balanceadores de carga en AWS, que opera tanto en capa 4 como en capa 7:

• Características principales:
  • Funcionalidad básica de balanceo HTTP/HTTPS y TCP
  • Comprobaciones de salud simples
  • Sticky sessions basadas en cookies
  • Soporte limitado para enrutamiento avanzado
• Estado actual:
  • Considerado legacy (no recomendado para nuevas implementaciones)
  • Mantenido para compatibilidad con arquitecturas existentes

Comparativa de rendimiento y características

Listeners y Targets

Los listeners son los puntos de entrada que definen cómo se recibe el tráfico, mientras que los targets son los destinos donde se envía ese tráfico.

Configuración de Listeners

ALB Listeners:

• Soporta HTTP (80) y HTTPS (443)
• Puede redirigir automáticamente HTTP a HTTPS
• Permite terminación SSL/TLS con certificados gestionados en ACM

# Ejemplo de listener ALB
HTTPS:443 (certificado ACM) -> Reglas de enrutamiento -> Target Groups

NLB Listeners:

• Soporta TCP, UDP y TLS
• Permite TLS passthrough (el cifrado se maneja en el backend)
• Puede terminar TLS en el balanceador

# Ejemplo de listener NLB
TCP:443 -> Target Group (instancias en puerto 443)
UDP:10000 -> Target Group (instancias en puerto 10000)

Tipos de Targets

Los balanceadores pueden enviar tráfico a diferentes tipos de targets:

• Instancias EC2: identificadas por ID de instancia
• Direcciones IP: cualquier IP privada en el VPC
• Lambda Functions: para aplicaciones serverless (solo ALB)
• Application Load Balancers: para arquitecturas de balanceo en cascada (solo NLB)

# Ejemplo de registro de targets
aws elbv2 register-targets \\
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 \\
  --targets Id=i-1234567890abcdef0,Port=80 Id=i-0abcdef1234567890,Port=80

Target Groups y Routing Avanzado

Los target groups son agrupaciones lógicas de targets que comparten configuraciones comunes como protocolos, puertos y comprobaciones de salud.

Configuración de Target Groups

# Ejemplo de creación de target group
aws elbv2 create-target-group \\
  --name my-targets \\
  --protocol HTTP \\
  --port 80 \\
  --vpc-id vpc-0123456789abcdef0 \\
  --health-check-protocol HTTP \\
  --health-check-path /health \\
  --health-check-interval-seconds 30 \\
  --health-check-timeout-seconds 5 \\
  --healthy-threshold-count 2 \\
  --unhealthy-threshold-count 2

Routing Avanzado con ALB

El ALB permite implementar estrategias de enrutamiento sofisticadas:

Host-based Routing:

• Enruta tráfico basado en el dominio de la solicitud
• Permite consolidar múltiples dominios en un solo balanceador

# Ejemplo de host-based routing
IF host = "api.ejemplo.com" THEN forward to api-target-group
IF host = "admin.ejemplo.com" THEN forward to admin-target-group

Path-based Routing:

• Enruta tráfico basado en la ruta URL
• Ideal para arquitecturas de microservicios

# Ejemplo de path-based routing
IF path = "/api/v1/*" THEN forward to api-v1-target-group
IF path = "/api/v2/*" THEN forward to api-v2-target-group
IF path = "/images/*" THEN forward to static-content-target-group

Header y Query String Routing:

• Enruta basado en encabezados HTTP o parámetros de consulta
• Útil para testing A/B o despliegues canary

# Ejemplo de header-based routing
IF header["User-Agent"] contains "Mobile" THEN forward to mobile-target-group
IF query_string["version"] = "beta" THEN forward to beta-target-group

Sticky Sessions y Estado

Las sticky sessions (o session affinity) garantizan que las solicitudes de un usuario específico se dirijan consistentemente a la misma instancia backend.

Tipos de Sticky Sessions

Cookie-based Stickiness:

• Cookies generadas por el balanceador:
  • ALB: AWSALB cookie (duración configurable)
  • CLB: AWSELB cookie (duración configurable)
• Cookies de aplicación:
  • La aplicación genera su propia cookie
  • El balanceador la utiliza para mantener la afinidad

# Configuración de sticky sessions basadas en cookie del balanceador
aws elbv2 modify-target-group-attributes \\
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 \\
  --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=lb_cookie Key=stickiness.lb_cookie.duration_seconds,Value=86400

Stateful vs. Stateless Backends

Aplicaciones Stateful:

• Mantienen información de sesión en la instancia
• Requieren sticky sessions o mecanismos de sincronización
• Ejemplos: aplicaciones con carritos de compra en memoria, sesiones de juego

Aplicaciones Stateless:

• No mantienen estado en la instancia
• Almacenan estado externamente (DynamoDB, ElastiCache, etc.)
• Más resilientes y escalables
• Recomendadas para arquitecturas cloud nativas

# Arquitectura stateless recomendada
Cliente -> ALB -> Instancias EC2 (stateless) -> ElastiCache/DynamoDB (estado)

Integración con Servicios Container y Auto Scaling

Los balanceadores de carga se integran perfectamente con servicios de contenedores y auto scaling para crear arquitecturas dinámicas y resilientes.

Integración con ECS (Elastic Container Service)

El ALB es el balanceador recomendado para ECS:

• Service Discovery automática:
  • ECS registra automáticamente contenedores como targets
  • Soporta despliegues rolling y blue/green
• Dynamic Port Mapping:
  • Permite ejecutar múltiples copias del mismo contenedor en una instancia
  • ECS asigna puertos dinámicamente y los registra con el ALB

# Ejemplo de definición de servicio ECS con ALB
{
  "serviceName": "web-service",
  "taskDefinition": "web-task:1",
  "loadBalancers": [
    {
      "targetGroupArn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-targets/73e2d6bc24d8a067",
      "containerName": "web",
      "containerPort": 80
    }
  ],
  "desiredCount": 3,
  "deploymentConfiguration": {
    "minimumHealthyPercent": 75,
    "maximumPercent": 200
  }
}

Integración con EKS (Elastic Kubernetes Service)

AWS Load Balancer Controller facilita la integración entre EKS y los balanceadores:

• Ingress para ALB:
  • Crea automáticamente ALBs basados en recursos Ingress de Kubernetes
  • Soporta todas las características avanzadas del ALB
• Service tipo LoadBalancer para NLB:
  • Crea NLBs para servicios Kubernetes de tipo LoadBalancer
  • Soporta IP preservation y protocolos no-HTTP

# Ejemplo de Ingress para EKS que crea un ALB
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: api.ejemplo.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Integración con Auto Scaling

Los balanceadores de carga trabajan en conjunto con Auto Scaling para ajustar dinámicamente la capacidad:

• Registro automático de instancias:
  • Las nuevas instancias se registran automáticamente como targets
  • Las instancias terminadas se eliminan automáticamente
• Comprobaciones de salud integradas:
  • Auto Scaling puede usar las comprobaciones de salud del balanceador
  • Reemplaza automáticamente instancias no saludables

# Configuración de Auto Scaling Group con ELB health checks
aws autoscaling create-auto-scaling-group \\
  --auto-scaling-group-name my-asg \\
  --launch-template LaunchTemplateId=lt-0123456789abcdef0,Version='$Latest' \\
  --min-size 2 \\
  --max-size 10 \\
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 \\
  --health-check-type ELB \\
  --health-check-grace-period 300

Consideraciones Finales

Los Elastic Load Balancers son componentes críticos en arquitecturas cloud modernas, proporcionando alta disponibilidad, escalabilidad y seguridad. La elección del tipo correcto de balanceador depende de los requisitos específicos de la aplicación: ALB para aplicaciones web y APIs con enrutamiento sofisticado, NLB para rendimiento extremo y protocolos no-HTTP, y CLB solo para compatibilidad con sistemas legacy.

Al diseñar arquitecturas con balanceadores de carga, es importante considerar aspectos como la statelessness de las aplicaciones, la estrategia de despliegue, los requisitos de seguridad y la integración con otros servicios de AWS. Un diseño bien pensado que aproveche las capacidades de ELB puede marcar la diferencia entre una aplicación que colapsa bajo carga y una que escala sin problemas para atender millones de usuarios simultáneos.