El ALB con instancias sanas y sin tráfico | Labs | DevOps in Practice

Un release terminó correctamente, pero la API pública devuelve 503 porque todos los targets del ALB aparecen unhealthy.

Inspecciona la salud de los targets antes de cambiar la aplicación o las instancias.

Prueba: aws elbv2 describe-target-health --target-group-arn tg/payments-api

Comando de terminal

El ALB vuelve a enrutar.

Los dos targets pasan el check exacto de readiness y pueden recibir tráfico.

Lección

Cuando un ALB reporta response-code mismatch, inspecciona el probe y pruébalo directamente. Mantén los health checks específicos: corregir la ruta es más seguro que aceptar cualquier respuesta como healthy.

Editar payments-api-target-group.tf

Cambia solo la ruta del health check; conserva el matcher estricto.

El health check necesita path = "/health/ready" y matcher = "200".

Conceptos clave

La salud del target controla el ruteo

Un ALB solo enruta a targets que pasan sus checks.

Qué es

Un target group consulta periódicamente cada backend registrado y guarda su estado.

En este incidente

Las instancias corren, pero HTTP 404 hace que el ALB las rechace.

Por qué importa

La salud de una instancia y el readiness de una aplicación son señales distintas.

Los endpoints de readiness son contratos

La infraestructura depende de una ruta y un status code estables.

Qué es

Un endpoint de readiness indica si un proceso puede recibir tráfico de forma segura.

En este incidente

La aplicación movió el readiness de /health a /health/ready.

Por qué importa

Cambiar el contrato requiere coordinar aplicación e infraestructura.

Corrige el contrato, no los síntomas

Un cambio acotado es más seguro que reemplazar instancias sanas.

Qué es

El cambio seguro más pequeño corrige el mismatch sin ampliar las respuestas aceptadas.

En este incidente

El matcher sigue en 200 y solo cambia la ruta.

Por qué importa

Matchers amplios pueden ocultar redirects, pantallas de autenticación y fallos reales.