Un informe diario sin servidores para cazar Auto Scaling Groups suspendidos
Un desarrollador monta con EventBridge, Lambda y SES un aviso diario que detecta procesos de escalado suspendidos y olvidados en las cuentas de AWS, sin coste apreciable.
Los Auto Scaling Groups de EC2 dejan suspender procesos sueltos: Launch, Terminate, HealthCheck, AZRebalance. Es cómodo durante un incidente —congelas capacidad mientras despliegas o paras el baile de instancias mientras depuras— y es una trampa después, porque nadie avisa de que siguen así. Un grupo con Launch suspendido no añade capacidad cuando sube el tráfico, y uno con HealthCheck suspendido no sustituye instancias enfermas. CloudWatch no alarma por defecto sobre eso. Te enteras en el peor momento posible.
Se ha publicado un montaje serverless que convierte esa comprobación en un correo diario.
Cómo está montado
El flujo son tres piezas: una regla cron de EventBridge dispara una función Lambda escrita en Python con boto3, y el resultado sale por SES como una tabla HTML legible en lugar de un volcado de JSON. No hay agentes ni máquina con cron que mantener, y el coste de ejecución es prácticamente nulo.
La lógica recorre todas las regiones configuradas y se queda solo con los grupos que tienen procesos suspendidos. El detalle que importa: usa el paginador de describe_auto_scaling_groups. En cuentas con muchos ASGs, una llamada suelta devuelve resultados paginados y se deja grupos por el camino sin dar error. El informe final incluye, por cada grupo afectado, la región, el nombre, qué procesos están suspendidos y las capacidades mínima, deseada y máxima, que es lo que permite calibrar el daño de un vistazo. Hay además un interruptor para elegir entre recibir correo solo cuando algo va mal o un parte diario de que todo está en orden.
El despliegue no usa frameworks: un script de bash sobre la CLI de AWS que empaqueta el fichero en un zip y crea la función con runtime python3.12 y timeout de 120 segundos. La regla de EventBridge y el rol de IAM se crean igual o una vez a mano.
Los dos errores del camino
El primero fue un ImportModuleError: el handler de Lambda seguía apuntando a lambda_function.lambda_handler, el valor por defecto de consola, mientras el código vivía en handler.py con una función llamada handler. La cadena de handler es una ruta de archivo y función, y se desincroniza con facilidad si la función se creó desde la consola.
El segundo fue un AccessDenied al llamar a autoscaling:DescribeAutoScalingGroups. El rol de ejecución tenía la política de confianza pero le faltaban los permisos reales. La corrección es una política inline mínima con esa acción y los dos métodos de envío de SES. Ojo con un matiz: DescribeAutoScalingGroups no admite restricciones a nivel de recurso, así que exige Resource: "*". SES sí se puede acotar a un ARN de identidad verificada si se quiere apretar más.
Por qué importa
Una suspensión olvidada no rompe nada el día que se hace: rompe el día que hace falta escalar. En entornos con muchas cuentas y muchos grupos, revisarlo a mano no se hace. Un cron serverless que lista los sospechosos es de esas cosas que se montan en una tarde y ahorran una guardia entera. Queda por ver si el autor añade cobertura para otras señales del mismo tipo —políticas de escalado deshabilitadas, por ejemplo— o si se queda como está.
