Kunden laden Dateien in S3 hoch, und eine SQS-Nachricht mit dem Objekt-ARN wird gesendet. Ein EC2-basierter Worker fragt SQS ab und verarbeitet Dateien; die Verarbeitungszeit variiert mit der Dateigröße. Um kundenbedingte Verzögerungen zu reduzieren, erstellt ein Administrator ein AMI aus der vorhandenen Instanz und eine Startvorlage. Wie sollte Auto Scaling konfiguriert werden, um die Reaktionsfähigkeit zu verbessern?

Die korrekte Antwort ist, eine benutzerdefinierte Metrik zu erstellen, die die Anzahl der sichtbaren Nachrichten in SQS durch die Anzahl der aktiven Worker-Instanzen teilt. Diese Metrik, die die Arbeitslast pro Worker darstellt, sollte von der Anwendung berechnet und an CloudWatch gesendet werden, um eine dynamische Skalierung der Auto Scaling-Gruppe zu ermöglichen. Dies gewährleistet, dass die Anzahl der Worker immer proportional zur aktuellen Arbeitslast ist, was die Reaktionsfähigkeit optimiert. Die Option, mehrere Instance-Größen hinzuzufügen und basierend auf ApproximateNumberOfMessagesVisible zu skalieren, ist unzureichend, da sie die aktuelle Verarbeitungskapazität der Worker nicht berücksichtigt. ApproximateNumberOfMessagesDelayed ist irrelevant, da es sich auf verzögerte Nachrichten bezieht, nicht auf die aktuelle Arbeitslast. Eine benutzerdefinierte Metrik basierend auf ASGAverageCPUUtilization und GroupPendingInstances ist ebenfalls nicht optimal, da die CPU-Auslastung nicht immer ein direkter Indikator für die SQS-Warteschlangenlast ist und GroupPendingInstances die aktuelle Verarbeitungskapazität nicht widerspiegelt.