Una empresa procesa mensajes con una aplicación worker que se ejecuta en tres instancias EC2 en un grupo de Auto Scaling que utiliza una política de escalado simple. Los workers sondean mensajes de una cola de Amazon SQS. Los aumentos esporádicos de mensajes están degradando el rendimiento del procesamiento, y el administrador de SysOps debe escalar el grupo de Auto Scaling para manejar un mayor volumen de cola. ¿Qué enfoque satisface mejor este requisito?

La opción correcta utiliza CloudWatch metric math para calcular los mensajes visibles por instancia (aproximadamente VisibleMessages / GroupDesiredCapacity). Esta métrica personalizada es un indicador directo de la carga de trabajo por instancia. Una política de escalado de seguimiento de destino (target tracking) puede mantener este valor en un objetivo deseado, escalando el grupo de Auto Scaling de forma proactiva cuando la carga por instancia aumenta, lo que es ideal para manejar picos de mensajes en SQS. Las otras opciones son menos efectivas: Estimar la antigüedad del mensaje más antiguo (OldestMessageAge) no es una métrica directa para escalar por carga de trabajo por instancia. Un Application Load Balancer (ALB) no es útil aquí porque los workers extraen mensajes de SQS, no reciben tráfico HTTP/S de un ALB. La política de escalado programado no se adapta a aumentos esporádicos e impredecibles de mensajes.