Klanten uploaden bestanden naar S3 en er wordt een SQS-bericht met de object-ARN verzonden. Een EC2-gebaseerde worker peilt SQS en verwerkt bestanden; de verwerkingstijd varieert met de bestandsgrootte. Om door de klant waargenomen vertragingen te verminderen, maakt een beheerder een AMI van de bestaande instantie en een launch template. Hoe moet Auto Scaling worden geconfigureerd om de responsiviteit te verbeteren?

De correcte optie schaalt op basis van een custom metric die de zichtbare berichten in de SQS-wachtrij deelt door het aantal actieve worker-instanties. Dit geeft een indicatie van de werklast per instantie, waardoor Auto Scaling proactief kan reageren op een toenemende of afnemende vraag. Door deze metric naar CloudWatch te pushen en een Auto Scaling-beleid hierop te baseren, wordt de responsiviteit verbeterd. De eerste optie is onjuist omdat het wijzigen van instantiegrootte op basis van ApproximateNumberOfMessagesVisible niet optimaal is; het is beter om het aantal instanties te schalen. De tweede optie is onjuist omdat ApproximateNumberOfMessagesDelayed verwijst naar berichten die opzettelijk zijn uitgesteld, niet naar berichten die wachten op verwerking. De derde optie is onjuist omdat ASGAverageCPUUtilization en GroupPendingInstances niet direct de werklast van de SQS-wachtrij weerspiegelen.