Versteckte Kosten von CloudWatch-Metriken aufdecken

Cloud-Monitoring ist unverzichtbar, um AWS-Infrastrukturen zuverlässig zu betreiben und zu optimieren. Amazon CloudWatch zählt dabei zu den zentralen Werkzeugen für Metriken, Logs und Alarme. Mit wachsender AWS-Nutzung steigen jedoch auch die CloudWatch-Kosten – und die lassen sich oft nur schwer nachvollziehen.

Eine typische Hürde für AWS-Anwender: Im Cost & Usage Report (CUR) die tatsächlichen Kostentreiber von CloudWatch zu identifizieren. Der Report liefert zwar eine grobe Aufschlüsselung, ihm fehlt aber die Detailtiefe, um konkrete Quellen hoher Kosten zu erkennen.

Dieser Artikel zeigt anhand eines konkreten Beispiels, wie sich unerwartete CloudWatch-Kosten mit DoiT Cloud Intelligence diagnostizieren lassen. Nachdem wir die kostenintensiven Operationen identifiziert haben, zeigen wir, wie sich mit CloudTrail Data Events und Amazon Athena die Ursachen aufspüren und in handlungsrelevante Erkenntnisse überführen lassen. Am Ende haben Sie eine klare Strategie an der Hand, um versteckte CloudWatch-Kosten zu verstehen und zu steuern.

Amazon CloudWatch ist ein unverzichtbares Monitoring-Tool für AWS-Umgebungen und liefert detaillierte Einblicke in Metriken und Logs. Die Kostenstruktur wirkt allerdings oft undurchsichtig, sodass sich die Ursachen unerwarteter Kostenspitzen nur schwer erkennen lassen.

Der Cost & Usage Report (CUR) bietet zwar eine granulare Aufschlüsselung der AWS-Kosten, stößt jedoch an seine Grenzen, sobald es um Sichtbarkeit auf Ressourcenebene bei einzelnen Posten geht. Ein anschauliches Beispiel ist GetMetricData – eine API-Operation zum Abrufen von CloudWatch-Metrikdaten. Trotz ihres erheblichen Einflusses auf die Kosten liefert der CUR nicht genug Details, um zu bestimmen, welche Services, Anwendungen oder Nutzer für diese Aufrufe verantwortlich sind.

Diese fehlende Transparenz erschwert es AWS-Anwendern, Kosten zu optimieren, Budgetüberschreitungen vorzubeugen und fundierte Entscheidungen zur Monitoring-Konfiguration zu treffen.

Um diese Herausforderung zu veranschaulichen, haben wir DoiT Cloud Analytics Reports genutzt, mit denen sich Cloud-Kostendaten visualisieren und interpretieren lassen. Die Daten lassen sich in unterschiedlichen Diagrammen darstellen, filtern und gruppieren – für klarere Erkenntnisse.

Die folgende Auswertung zeigt zum Beispiel eine detaillierte Kostenaufschlüsselung der CloudWatch-Nutzung über 28 Tage und macht die durchgängig hohen Kosten der GMD-Metrics-(GetMetricData)-Operationen sichtbar.

Die nachstehende Kostentabelle gliedert die CloudWatch-Ausgaben zusätzlich nach SKU (Stock Keeping Unit), Operationstyp und Ressourceninformationen auf. Auffällig ist:

• GMD-Metrics (GetMetricData) gehört zu den größten Kostentreibern.
• Ressourceninformationen fehlen, sodass sich die Quelle der Anfragen nur schwer bestimmen lässt.
• MetricMonitorUsage trägt ebenfalls zu den Kosten bei, allerdings in deutlich geringerem Umfang.

Da GetMetricData erhebliche und ungeklärte Kosten verursacht, brauchen wir eine genauere Analyse mit CloudTrail Data Events und Amazon Athena, um den Ursprung zu ermitteln.

AWS CloudTrail protokolliert standardmäßig Management Events – etwa IAM-Änderungen, Sicherheitskonfigurationen oder das Bereitstellen von Ressourcen. Data Events hingegen, die service-spezifische API-Aufrufe wie S3-Object-Level-Operationen oder Lambda-Ausführungen erfassen, sind standardmäßig deaktiviert.

Um CloudWatch-Metrics-Events nachzuverfolgen, müssen wir CloudTrail Data Events daher explizit aktivieren – entweder in einem bestehenden Trail oder durch Anlegen eines neuen.

CloudTrail einrichten

1. CloudTrail-Trail auswählen

• Bestehenden Trail anpassen oder neuen erstellen.
• S3-Bucket für die Speicherung der CloudTrail-Logs festlegen.

2. Optionale Funktionen konfigurieren

• KMS-Verschlüsselung (optional) für zusätzliche Sicherheit.
• Log-Validierung & SNS-Benachrichtigungen (optional, für Integrität und Alarme).
• CloudWatch-Logs-Speicherung (hier nicht relevant, da wir Athena für die Analyse nutzen).

Data Event für CloudWatch-Metriken definieren

1. CloudWatch metric als Data Event Type auswählen.

2. Log Selector festlegen:

• All events (unsere Wahl, der Einfachheit halber).
• Read-only events oder Write-only events.
• Custom Selectors für mehr Kontrolle.

Sobald aktiviert, erfassen die CloudTrail-Logs die CloudWatch-GetMetricData-Anfragen. Bevor wir mit der Analyse beginnen können, muss sich allerdings erst eine ausreichende Menge an Logs ansammeln.

Athena-Tabelle für CloudTrail-Logs erstellen

Da CloudTrail nun CloudWatch-GetMetricData-Anfragen in einen S3-Bucket schreibt, können wir sie mit Amazon Athena auswerten.

Um CloudTrail-Logs in Amazon Athena zu analysieren, müssen Sie eine Tabelle erstellen, die auf die im S3-Bucket gespeicherten Log-Daten verweist:

• Öffnen Sie die CloudTrail-Konsole und navigieren Sie im linken Menü zu Event history.
• Klicken Sie auf Create Athena table und wählen Sie im Dropdown "Storage location" den S3-Bucket aus, in dem Ihre CloudTrail-Logs liegen.

GetMetricData-Events abfragen

Jetzt können wir in Amazon Athena ermitteln, wer oder was GetMetricData-Anfragen auslöst. Die folgende SQL-Abfrage dient nur als Beispiel auf Basis eines kleinen Datensatzes. Bei einem realen Datenbestand kann eine andere Abfrage präzisere Ergebnisse liefern.

SELECT
    COUNT(*) as count,
    eventname,
    useridentity.principalId,
    useridentity.arn
FROM cloudtrail_logs_aws_cloudtrail_logs_cw_metrics
WHERE eventname = 'GetMetricData'
GROUP BY eventname, useridentity.principalId, useridentity.arn
ORDER BY count DESC
LIMIT 100;

Ergebnisse interpretieren

Die Abfrageergebnisse (siehe Beispiel unten) zeigen, von welchen Quellen die GetMetricData-Anfragen stammen.

• Die oberste Zeile weist 18 Anfragen aus und ist damit der Hauptkostentreiber.
• Die Spalten principalId und arn helfen zu erkennen, ob die Anfragen von einem bestimmten AWS-Service, IAM-User/-Role oder einer Anwendung stammen.
• Sind die Anfragen in dieser Häufigkeit nicht nötig, lohnt es sich, die Polling-Frequenz zu reduzieren, Monitoring-Einstellungen zu optimieren oder Zugriffsrechte einzuschränken – das senkt die Kosten.