CloudWatch: Alarme direkt aus Log-Abfragen statt Metrikfilter

Weniger Umwege.

Eine Abfrage genügt.

Foto: Pexels / Pixabay

Fehlerraten aus Logs brauchen bei Amazon CloudWatch keinen Umweg über Metriken mehr. Seit dem 1. Juli 2026 genügt eine Abfrage mit Schwellwert.

Das Wichtigste in Kürze

• Log-Alarme werten Abfrageergebnisse direkt aus. Metrikfilter und eigene Metriken entfallen.
• Aktionen laufen wie gewohnt über SNS und EventBridge. Bestehende Benachrichtigungswege bleiben nutzbar.
• Die Funktion gibt es in allen kommerziellen Regionen ausser UAE und Bahrain. Dort ist sie noch nicht verfügbar.
• Du richtest sie in Konsole, AWS CLI, CloudFormation oder per SDK ein. Ein Zugriff über Code ist also von Anfang an möglich.

Was sich ändert

Bisher brauchte ein Alarm auf Log-Inhalten zwei Schritte. Zuerst erzeugte ein Metrikfilter aus den Logzeilen eine Metrik, danach legtest du darauf einen Alarm. Das war für einfache Fragen wie „Wie viele Fehler pro Dienst?“ umständlich.

Nun schreibst du eine Abfrage in CloudWatch Logs Insights, legst einen Schwellwert fest und bekommst bei Überschreitung eine Benachrichtigung. AWS beschreibt das in der Ankündigung vom 1. Juli 2026.

Monitoring: So arbeitet ein Log-Alarm

Die Abfrage läuft als geplante Abfrage in einem festen Rhythmus, etwa alle fünf oder zehn Minuten. Ein Aggregationsausdruck wie count(*) macht daraus eine Zahl, die der Alarm gegen den Schwellwert prüft. Wie bei Metrikalarmen legst du fest, wie viele Auswertungen aus den letzten N den Alarm auslösen und wie fehlende Daten zählen.

Dabei braucht CloudWatch Logs eine IAM-Rolle, die die Abfrage ausführen darf. Sie vertraut dem Dienst logs.amazonaws.com und erlaubt unter anderem logs:StartQuery und logs:GetQueryResults. Die Konsole legt diese Rolle auf Wunsch selbst an. Zudem kannst du bis zu 50 Logzeilen in SNS-Mails aufnehmen lassen, was eine zweite Rolle verlangt.

Ein Beispiel aus der Dokumentation für die CLI:

aws cloudwatch put-log-alarm \
    --alarm-name "HighErrorCount" \
    --comparison-operator GreaterThanThreshold \
    --threshold 100 \
    --query-results-to-evaluate 5 \
    --query-results-to-alarm 3 \
    --scheduled-query-configuration '{
        "QueryString": "fields @timestamp, @message | filter @message like /ERROR/",
        "LogGroupIdentifiers": ["/aws/lambda/my-function"],
        "ScheduledQueryRoleARN": "arn:aws:iam::111122223333:role/ScheduledQueryRole",
        "AggregationExpression": "count(*)",
        "ScheduleConfiguration": {"ScheduleExpression": "rate(10 minutes)", "StartTimeOffset": 600}
    }'

Gekürztes Beispiel aus der AWS-Dokumentation: Der Alarm schlägt an, wenn die Fehlerzahl in drei von fünf Abfragen über 100 liegt.

Was Admins jetzt tun

Prüfe zuerst, welche Metrikfilter nur für einen Alarm existieren. Solche Filter lassen sich oft durch einen Log-Alarm ersetzen. Das spart Konfiguration und macht die Regel lesbar, weil Abfrage und Schwellwert an einer Stelle stehen.

Beachte jedoch die Details. Für die Anzeige der Abfrageergebnisse in der Konsole braucht die Rolle die Berechtigung logs:GetScheduledQueryData. Zudem verursachen geplante Abfragen Kosten, die du auf der Preisseite nachschlägst. Wer Logs von Lambda-Funktionen auswertet, liest dazu auch den Artikel zu AWS Lambda mit 90 Minuten und Managed Instances.

Zeitplan der Quelle

AWS hat die Meldung am 1. Juli 2026 veröffentlicht. Die Quelle nennt kein späteres Update. Der Stand dieses Beitrags ist damit der 1. Juli 2026.

Fazit

Log-Alarme machen Fehlerraten-Alarme aus Logs einfacher: eine Abfrage, ein Schwellwert, eine Aktion. Sie ersetzen nicht jeden Metrikfilter, aber viele reine Alarm-Filter. Probiere sie an einer Fehlerrate aus und vergleiche Aufwand und Kosten mit deinem bisherigen Weg.

Quellen: AWS What's New, CloudWatch-Dokumentation: Alarming on logs. Foto: Pexels / Pixabay. Stand: 1. Juli 2026.

Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion