CloudWatch-PromQL-Alarme können jetzt Auto Scaling auslösen: EC2-Gruppen unterstützen einfache und gestufte Richtlinien, aber kein Target Tracking, die Tabelle im Handbuch zeigt für Application Auto Scaling nur gestuft, was vom Einstieg der Meldung „gestuft und einfach“ abweicht, und die Abfrage muss eine einzelne Reihe liefern

Am 10. November 2026 hat AWS mitgeteilt, dass Amazon-CloudWatch-Alarme, die in der Prometheus Query Language (PromQL) geschrieben sind, jetzt Skalierungsrichtlinien von Amazon EC2 Auto Scaling und Application Auto Scaling auslösen können. Die Meldung sagt, man könne EC2-Auto-Scaling-Gruppen anhand von OpenTelemetry-Metriken in CloudWatch skalieren, mit derselben Art von PromQL-Abfragen wie für Dashboards und Alarmierung. Für Teams, die zu OpenTelemetry wechseln, ist der genannte Nutzen, dass die Kapazität denselben Metriken folgen kann wie das übrige Monitoring, statt einen zweiten Satz klassischer Metrikalarme nur für die Skalierung zu behalten. Dieser Bericht stützt sich auf die AWS-Meldung und zwei Seiten des CloudWatch-Benutzerhandbuchs, eine zu PromQL-Alarmen und eine zu Alarmaktionen. Er hat weder einen Alarm angelegt noch einen Skalierungstest ausgeführt.

Der wichtigste Punkt ist, was unterstützt wird und was nicht. Die Meldung sagt, PromQL-Alarme unterstützten jetzt einfache (simple) und gestufte (step) Skalierungsrichtlinien von EC2 Auto Scaling, und Target Tracking sei derzeit kein unterstützter Richtlinientyp für PromQL-Alarme. Die Seite zu Alarmaktionen hat eine Tabelle, die das neben andere Alarmtypen stellt. Bei Aktionen für Auto-Scaling-Gruppen unterstützt ein Standard-Metrikalarm einfach, gestuft und Target Tracking, ein PromQL-Alarm einfach und gestuft, und der Metrics-Insights-Alarm mit mehreren Zeitreihen sowie der Logalarm sind als nicht unterstützt aufgeführt. Bei Aktionen für Application Auto Scaling unterstützt ein Standard-Metrikalarm gestuft und Target Tracking, ein PromQL-Alarm nur gestuft. Das passt nicht zum ersten Satz der Meldung, der sagt, PromQL-Alarme könnten „gestufte und einfache Skalierungsrichtlinien von Amazon EC2 und Application Auto Scaling“ auslösen. Die Tabelle im Handbuch ist genauer. Der vorsichtige Rat dieses Berichts, keine Aussage von AWS, lautet: Wer mit einem PromQL-Alarm ECS-Services, DynamoDB-Tabellen, Aurora-Replikate oder Spot Fleets skalieren will, sollte bis zu einer Klarstellung durch AWS nur mit gestuften Richtlinien planen.

Wie der Alarm die Richtlinie steuert, braucht eine Regel. Bei gestufter Skalierung entscheidet laut Meldung der Abstand des Werts in Ihrer PromQL-Abfrage zum Schwellenwert, welche Stufe gilt. Die Abfrage muss eine einzelne Reihe liefern und sie mit einem Schwellenwert vergleichen. Das PromQL-Handbuch sagt dasselbe in den gewöhnlichen Schritten zum Erstellen eines PromQL-Alarms: Die Abfrage muss eine einzelne Zeitreihe liefern, damit der Alarm sie auswerten kann. Dasselbe Handbuch hat außerdem einen eigenen Abschnitt zur Anomalieerkennung, in dem jede verletzende Zeitreihe über eine ganze Flotte als eigener Beitragender verfolgt wird, und die Tabelle der Alarmaktionen führt einige Aktionen für PromQL-Alarme auf Beitragenden-Ebene. Keine der beiden Quellen sagt, dass dieser Beitragenden-Modus eine Skalierungsrichtlinie steuern kann; dieser Bericht nimmt das daher nicht an. Die Anforderung betrifft das Ergebnis: Die Abfrage muss am Ende eine einzige Reihe ergeben. Wer aus mehreren Instanzen oder Labels ein einziges Skalierungssignal gewinnen will, kann zum Beispiel zu einer Zahl für die ganze Flotte aggregieren; das ist ein möglicher Weg, und welche Aggregation passt, hängt davon ab, was die Metrik bedeutet. Die Meldung gibt keine Beispielabfrage, und dieser Bericht nennt keine.

Eine zweite Bedingung betrifft die Wiederholung. Das Alarmaktionen-Handbuch sagt, außer bei Auto-Scaling-Aktionen fänden Alarmaktionen nur bei Zustandsübergängen statt und würden nicht wiederholt, wenn die Bedingung stunden- oder tagelang anhalte. Auto-Scaling-Aktionen sind die Ausnahme, das heißt, sie können sich wiederholen, solange die Bedingung anhält. Das Handbuch sagt das für Auto-Scaling-Aktionen allgemein, nicht speziell für PromQL-Alarme, und beschreibt kein Verhalten bei Abkühlzeit oder Aufwärmphase. Teams, die Skalierungslogik von klassischen Alarmen auf PromQL-Alarme verlagern, sollten die Einstellungen der EC2-Auto-Scaling-Richtlinie prüfen, die wiederholte Auslösungen steuern, denn die Quellen tun es nicht.

Die Einrichtung läuft über bekannte Werkzeuge. Die Meldung sagt, man könne EC2-Auto-Scaling- und Application-Auto-Scaling-Aktionen in der CloudWatch-Konsole beim Erstellen oder Bearbeiten eines Alarms hinzufügen oder mit der PutMetricAlarm-API, der AWS-CLI, den AWS-SDKs oder AWS CloudFormation. Das PromQL-Handbuch beschreibt den Weg über die Konsole: Auf der Seite Alarme „Alarm erstellen“ wählen, „Metrik auswählen“, dann den Reiter PromQL, die Abfrage eingeben, Schwellenwert, Auswertungszeitraum und Datenpunkte für den Alarm festlegen und Aktionen konfigurieren. Es sagt auch, man könne einen Alarm aus einer in Query Studio ausgeführten Abfrage erstellen, wenn diese eine einzelne Zeitreihe liefert. Für einfache und gestufte Skalierung sagt das Alarmaktionen-Handbuch, man erstelle den CloudWatch-Metrikalarm und hänge ihn an die Richtlinie. Beim Target Tracking erstellt und verwaltet der Auto-Scaling-Dienst die Alarme selbst, und man soll sie weder bearbeiten noch löschen. Das Handbuch beschreibt damit, wie diese Alarme verwaltet werden, nicht den Grund, warum PromQL-Alarme kein Target Tracking unterstützen, und auch die Meldung nennt keinen Grund.

Zwei betriebliche Grenzen sind im Handbuch sichtbar. Zusammengesetzte Alarme können keine Auto-Scaling-Aktionen auslösen. Und PromQL-Alarme enthalten in ihren Benachrichtigungen weder einen Zustandsgrund noch Zustandsgrunddaten, anders als Einzelmetrikalarme, die die konkreten Datenpunkte zeigen, die den Zustandswechsel ausgelöst haben. Wenn ein Skalierungsereignis falsch aussieht, stehen in der Alarmnachricht weniger Details zur Erklärung. Ein Team sollte einplanen, die PromQL-Abfrage und die zugrunde liegenden Metriken direkt zu prüfen. Die Quellen führen außerdem auf, dass PromQL-Alarme keine EC2-Aktionen wie Stoppen oder Neustarten, keine Systems-Manager-OpsItems und -Vorfälle und keine CloudWatch-Untersuchungen unterstützen; ein PromQL-Alarm für die Skalierung kann diese Aktionen also nicht zugleich tragen.

Zu Verfügbarkeit und Kosten sagt die Meldung, die Funktion sei in allen AWS-Regionen verfügbar, in denen CloudWatch-PromQL-Alarme verfügbar sind, und es gelte die übliche Preisgestaltung für CloudWatch-Alarme. Sie nennt weder Regionen noch Preise. Die Quellen enthalten keine Messungen, wie schnell ein PromQL-Alarm im Vergleich zu einem klassischen Metrikalarm reagiert; ein Team, das auf kurze Spitzen hin skaliert, sollte die Verzögerung zwischen einer Metrikänderung und einer Kapazitätsänderung testen. Die Quellen stützen eine enge Aussage: Für EC2-Auto-Scaling-Gruppen können einfache und gestufte Richtlinien jetzt durch einen PromQL-Alarm gesteuert werden, der eine einzelne Reihe liefert, Target Tracking dagegen nicht.