ECS/Fargate escala a cero con SQS usando métricas de backlog por tarea
AWS permite que un servicio ECS/Fargate escale a 0 tareas cuando la cola de SQS está vacía, pero el punto de datos de RunningTaskCount desaparece al alcanzar 0, lo que complica la lógica de escalado.
El problema surge cuando un worker de ECS/Fargate, que consume una cola SQS, llega a cero tareas en ejecución. El objetivo de AWS es usar target‑tracking con la métrica ApproximateNumberOfMessagesVisible / RunningTaskCount, pero al llegar a 0 no existe datapoint para RunningTaskCount y la expresión se vuelve indefinida.
Para evitar mantener min_capacity = 1, la comunidad propone tres alternativas:
- Escalado de salida exclusivo: un policy de Step Scaling que solo escale de 0 a 1 tareas, luego dejar que el target‑tracking maneje el resto.
- Expresión de metric‑math que sustituya el valor de RunningTaskCount por 1 cuando sea 0, evitando la división por cero.
- Alarmas separadas: usar la métrica cruda de backlog de SQS para disparar la inicialización de la primera tarea y después usar backlog‑per‑task para el escalado normal.
El código Terraform que se muestra implementa el tercer enfoque, con un policy llamado backlog‑per‑task. Se define un metric‑math que calcula "Backlog per task" con la expresión IF(running > 0, backlog / running, backlog). Así, cuando no hay tareas, la métrica devuelve simplemente el backlog, lo que provoca que la escala vuelva a 1.
Los comentarios en Reddit señalan que ninguna de las opciones es oficial, pero la comunidad recomienda la solución de metric‑math por su simplicidad y por no requerir un paso de escalado manual.
En la práctica, el patrón que se está adoptando es:
- Mantener
min_capacity = 0ymax_capacity = 10. - Usar la política de target‑tracking con la expresión anterior.
- Asegurarse de que las alarmas de CloudWatch tengan un cool‑down adecuado para evitar escaladas rápidas.
Esto permite que el worker se mantenga inactivo cuando la cola está vacía y que se reactive de forma automática cuando aparezcan mensajes, sin sobre‑provisionar recursos.
El caso demuestra cómo la combinación de métricas de SQS y ECS/ContainerInsights, junto con metric‑math, permite superar la limitación de AWS de no registrar RunningTaskCount cuando el servicio está a cero.
