Klienci przesyłają pliki do S3, a wiadomość SQS zawierająca ARN obiektu jest wysyłana. Proces roboczy oparty na EC2 odpytuje SQS i przetwarza pliki; czas przetwarzania różni się w zależności od rozmiaru pliku. Aby zmniejszyć opóźnienia postrzegane przez klientów, administrator tworzy AMI z istniejącej instancji i szablon uruchamiania. Jak należy skonfigurować Auto Scaling, aby poprawić responsywność?

Poprawna odpowiedź to utworzenie niestandardowej metryki opartej na ApproximateNumberOfMessagesVisible (liczbie widocznych wiadomości w kolejce SQS) i liczbie instancji w stanie InService w grupie Auto Scaling. Aplikacja powinna obliczać tę metrykę (np. wiadomości na instancję) i publikować ją w CloudWatch. Polityka Auto Scaling oparta na tej metryce pozwoli na dynamiczne skalowanie liczby instancji EC2 w zależności od obciążenia kolejki, zapewniając optymalną responsywność. Pozostałe opcje są mniej efektywne: Dodawanie różnych rozmiarów instancji do szablonu uruchamiania nie jest standardowym sposobem skalowania w oparciu o obciążenie SQS i nie rozwiązuje problemu opóźnień. Skalowanie na podstawie ApproximateNumberOfMessagesDelayed jest nieodpowiednie, ponieważ ta metryka wskazuje wiadomości, które celowo zostały opóźnione, a nie te, które czekają na przetworzenie. Użycie ASGAverageCPUUtilization i GroupPendingInstances jest zbyt ogólne i nie odzwierciedla bezpośrednio obciążenia kolejki SQS, co jest kluczowe dla tego scenariusza.