Los clientes suben archivos a S3 y se envía un mensaje de SQS que contiene el ARN del objeto. Un worker basado en EC2 consulta SQS y procesa los archivos; el tiempo de procesamiento varía con el tamaño del archivo. Para reducir los retrasos percibidos por el cliente, un administrador crea una AMI a partir de la instancia existente y una plantilla de lanzamiento. ¿Cómo se debe configurar Auto Scaling para mejorar la capacidad de respuesta?

La opción correcta es crear una métrica personalizada que combine ApproximateNumberOfMessagesVisible (mensajes pendientes en SQS) con la cantidad de instancias InService. Esto permite que Auto Scaling reaccione directamente a la carga de trabajo real (mensajes en cola) en relación con la capacidad de procesamiento actual. La aplicación puede calcular y publicar esta métrica en CloudWatch, lo que permite una política de escalado dinámico. Las otras opciones son menos efectivas: Usar diferentes tamaños de instancia en la plantilla de lanzamiento no escala la cantidad de instancias de manera óptima para la carga de SQS. ApproximateNumberOfMessagesDelayed no es la métrica principal para escalar en función de la carga de trabajo pendiente. ASGAverageCPUUtilization y GroupPendingInstances no reflejan directamente la carga de trabajo de SQS, lo que podría llevar a un escalado ineficiente.