Клиенты загружают файлы в S3, и отправляется сообщение SQS, содержащее ARN объекта. Рабочий процесс на базе EC2 опрашивает SQS и обрабатывает файлы; время обработки варьируется в зависимости от размера файла. Чтобы уменьшить задержки, воспринимаемые клиентами, администратор создает AMI из существующего экземпляра и шаблон запуска. Как следует настроить Auto Scaling для повышения отзывчивости?

Правильный ответ — создание пользовательской метрики, которая учитывает количество видимых сообщений в очереди SQS и количество запущенных экземпляров EC2. Это позволяет Auto Scaling принимать решения о масштабировании на основе фактической рабочей нагрузки (сообщений в очереди) и текущей мощности обработки (количества экземпляров). Приложение должно публиковать эту метрику в CloudWatch, а политика Auto Scaling будет использовать ее для динамического изменения количества экземпляров. Остальные варианты менее эффективны: Добавление разных размеров экземпляров и масштабирование по ApproximateNumberOfMessagesVisible не учитывает текущую производительность и может привести к неоптимальному выбору размера экземпляра. Масштабирование по ApproximateNumberOfMessagesDelayed не является оптимальным, так как задержки могут быть вызваны другими причинами, а не только недостатком ресурсов. Создание пользовательской метрики на основе ASGAverageCPUUtilization и GroupPendingInstances не отражает напрямую нагрузку из SQS и может не обеспечить своевременное масштабирование.