Eine Anwendung, die auf EC2-Instances in einer Auto Scaling-Gruppe läuft, verarbeitet eine große Menge von Nachrichten aus einer Amazon SQS-Warteschlange. Die Verarbeitung eines Nachrichtenstapels dauerte mehrere Stunden, und die durchschnittliche CPU-Auslastung der Auto Scaling-Gruppe überschritt nicht den Schwellenwert ihrer Target-Tracking-Skalierungsrichtlinie. Anwendungs-Logs werden an Amazon CloudWatch Logs gesendet. Sie müssen die Warteschlange schneller und mit dem geringsten Betriebsaufwand verarbeiten. Welche Option erfüllt diese Anforderung?

Die korrekte Option nutzt CloudWatch Metrik-Mathematik, um die Anzahl der Nachrichten pro Instanz direkt zu berechnen (ApproximateNumberOfMessagesVisible / GroupInServiceInstances). Dies ist die effizienteste Lösung, da sie keine benutzerdefinierten Metriken, Lambda-Funktionen oder EventBridge-Regeln erfordert, was den Betriebsaufwand minimiert. Target-Tracking-Skalierungsrichtlinien sind ideal für die Aufrechterhaltung einer Zielauslastung und passen die Skalierung automatisch an die Warteschlangenlast an. Die anderen Optionen sind umständlicher: Die Erstellung einer Lambda-Funktion zur Veröffentlichung benutzerdefinierter Metriken erhöht den Betriebsaufwand und die Komplexität. Die Verwendung von CloudWatch Logs-Abonnementfiltern für Anwendungs-Logs ist nicht direkt auf die SQS-Warteschlangenlänge anwendbar und würde eine zusätzliche Verarbeitung erfordern. Das Schreiben von SQS-Werten in CloudWatch Logs und das Zählen mit Metrikfiltern ist ein ineffizienter Umweg, um eine Metrik zu erhalten, die bereits direkt verfügbar ist.