Elastic Load Balancing
Servicio de balanceador de carga que distribuye automáticamente el tráfico entrante entre múltiples destinos, ofreciendo 4 tipos: ALB, NLB, GLB y CLB
Descripción general
Elastic Load Balancing (ELB) es un servicio que distribuye automáticamente el tráfico de aplicaciones entrante entre instancias EC2, contenedores, funciones Lambda y direcciones IP en múltiples zonas de disponibilidad. Ofrece cuatro tipos de balanceador: Application Load Balancer (ALB) para tráfico HTTP/HTTPS de capa 7, Network Load Balancer (NLB) para tráfico TCP/UDP de capa 4 con ultra baja latencia, Gateway Load Balancer (GLB) para appliances virtuales de red, y Classic Load Balancer (CLB) como opción legacy.
ALB y NLB - Diferenciación por capa
ALB opera en la capa 7 (aplicación) y toma decisiones de enrutamiento basadas en el contenido HTTP: host headers, paths URL, query strings, headers personalizados y métodos HTTP. Es ideal para arquitecturas de microservicios donde diferentes paths se enrutan a diferentes servicios backend. Soporta WebSocket, HTTP/2, gRPC y autenticación integrada con Cognito u OIDC. NLB opera en la capa 4 (transporte) y enruta basándose en protocolo y puerto, proporcionando latencia ultra baja (microsegundos) y capacidad de manejar millones de solicitudes por segundo. Es adecuado para: aplicaciones que requieren IP estática (NLB asigna una IP elástica por zona), protocolos no-HTTP (bases de datos, IoT, gaming), o cuando se necesita preservar la IP de origen del cliente sin X-Forwarded-For. La elección es clara: si la aplicación es HTTP/HTTPS y necesita enrutamiento basado en contenido, ALB. Si es TCP/UDP puro o necesita latencia mínima e IP estática, NLB.
Health checks y diseño de target groups
Los target groups definen los destinos que reciben tráfico del balanceador y las reglas de health check para verificar su disponibilidad. Los health checks envían solicitudes periódicas a los targets y los marcan como healthy o unhealthy según la respuesta. Para ALB, los health checks son HTTP/HTTPS con path configurable (por ejemplo, /health), código de respuesta esperado y timeouts. Para NLB, pueden ser TCP (solo verifica conexión) o HTTP/HTTPS. Los parámetros críticos son: intervalo (cada cuánto se verifica), umbral healthy (cuántas verificaciones exitosas para marcar como healthy), umbral unhealthy (cuántas fallidas para marcar como unhealthy) y timeout. Un diseño robusto incluye un endpoint de health check dedicado que verifica las dependencias críticas de la aplicación (conexión a base de datos, acceso a caché) y retorna un código de error si alguna falla. Los target groups soportan múltiples tipos de target: instancias EC2, direcciones IP, funciones Lambda (solo ALB) y otros ALBs.
Logs de acceso y troubleshooting
Los access logs de ELB registran información detallada de cada solicitud procesada: timestamp, IP del cliente, latencia de procesamiento, código de respuesta del backend, bytes transferidos y más. Los logs se almacenan en S3 y pueden analizarse con Athena para identificar patrones de tráfico, errores frecuentes y problemas de rendimiento. Para troubleshooting, los códigos de error HTTP del ELB son informativos: 502 (Bad Gateway) indica que el backend no respondió correctamente, 503 (Service Unavailable) indica que no hay targets healthy, y 504 (Gateway Timeout) indica que el backend no respondió dentro del timeout. Las métricas de CloudWatch proporcionan visibilidad en tiempo real: RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count y HealthyHostCount son las más importantes para monitoreo operativo. Connection logs (para NLB) registran los intentos de conexión TLS, útiles para diagnosticar problemas de certificados o compatibilidad de protocolos.