Balanceo de carga y health checks

Un load balancer hace 2 cosas, y la segunda es la que rinde examen. Reparte pedidos, sí, pero además le pregunta a cada target si está en condiciones de recibirlos y esquiva a los que no lo están. Cuando esa pregunta se hace mal, o cuando la respuesta miente, aparecen los síntomas raros: instancias que sirven errores sin que nadie reciba una alerta, tráfico repartido 4 a 1 entre zonas, o una zona muerta que devuelve 503 mientras la otra está perfecta.

Tres lecciones, ordenadas de cómo funciona a qué hacer cuando no funciona. La primera arma el modelo de distribución: nodos por zona, las 3 profundidades de inspección que separan ALB, NLB y Gateway Load Balancer, y la aritmética de cross-zone. La segunda convierte un estado de salud en una lista corta de causas y sus pruebas. La tercera sube una capa, hacia el DNS, que es la única que puede alejar a un cliente de una Región entera.

Qué cubre este tema

• Nodos de load balancer por zona de disponibilidad, el TTL de 60 segundos del DNS, y los esquemas internal e internet-facing
• ALB, NLB y Gateway Load Balancer comparados por capa OSI y por la decisión de enrutamiento que esa capa permite
• Listeners, reglas de listener por prioridad, target groups y los target types instance, ip y lambda
• Cross-zone load balancing con números concretos, sus valores predeterminados por tipo y su costo de transferencia de datos
• Atributos de target group que cambian producción: deregistration delay, algoritmo de enrutamiento, slow start y stickiness
• Ajustes de health check, estados de salud y reason codes, y las 5 causas ordenadas detrás de un target no saludable
• El comportamiento fail open, los umbrales de salud de target group, y la diferencia entre códigos HTTP del ELB y del target
• Health checks de Route 53 de endpoint, calculados y de alarma de CloudWatch, con la regla de agregación del 18%
• Failover activo-pasivo y activo-activo, Evaluate Target Health en registros alias, y zonal shift con ARC

Por qué importa

La habilidad 2.2.1 del SOA-C03 pide configurar y diagnosticar health checks de ELB y de Route 53, y las preguntas casi nunca piden una definición. Te dan un síntoma y te piden la causa: los chequeos funcionan desde un bastion host pero fallan desde el load balancer, el tráfico está desparejo entre zonas, todos los targets están no saludables y el sitio igual responde. Cada uno de esos tiene una causa documentada y una prueba que la confirma.

En una guardia real el orden importa igual. Preguntar qué sabe el load balancer antes de preguntar qué hace la aplicación te ahorra la mitad del incidente, y saber a qué capa pertenece la falla decide si el arreglo es un ajuste de target group, un zonal shift o un failover de DNS.