CloudWatch-Rechnung wird immer teurer? Praxisleitfaden zur Kostensenkung bei Logs & Metrics

CloudWatch kann sich leicht vom „Standard-Observability-Tool“ in ein Abrechnungs-Blackhole verwandeln. Insbesondere wenn Container, Microservices, Lambda, API Gateway und VPC Flow Logs alle angebunden sind, steigen Logs ingest, Log-Retention, Custom Metrics, Alarms und Dashboards gemeinsam an. Um die Kosten zu senken, besteht der erste Schritt nicht darin, das Monitoring zu löschen, sondern genau aufzuschlüsseln, wofür das Geld ausgegeben wird.

Die folgenden Preise basieren beispielhaft auf den üblichen öffentlichen Preisen in us-east-1, die tatsächlichen Kosten hängen von der jeweiligen AWS-Region ab: CloudWatch Logs Standard-Log-Ingestion kostet üblicherweise ca. $0.50/GB, die Log-Archivierung ca. $0.03/GB-month; Logs Insights Abfragen kosten ca. $0.005/GB scanned; Custom Metrics für die ersten 10.000 liegen bei ca. $0.30/metric-month; ein Standard-Resolution alarm kostet ca. $0.10/alarm metric-month und ein benutzerdefiniertes dashboard ca. $3/dashboard-month.

Erst analysieren: Sind Logs oder Metrics teurer?

Wählen Sie im Cost Explorer unter Service CloudWatch und schlüsseln Sie die Kosten nach Usage type auf. Zu den häufigsten Kostentreibern gehören:

• DataProcessing-Bytes: Log-Ingestion.
• TimedStorage-ByteHrs: Log-Speicherung.
• MetricMonitorUsage: Custom Metrics.
• AlarmMonitorUsage: Alarms.
• GMD-Metrics oder API-Anfragen: GetMetricData-Abfragen.

Viele Teams glauben, dass die Dashboards teuer sind, aber in der Realität sind es meistens die Log-Ingestion oder High-Cardinality Custom Metrics.

Logs-Kostensenkung 1: Retention-Perioden festlegen

CloudWatch Log Groups werden standardmäßig oft dauerhaft aufbewahrt. Für Anwendungslogs benötigen viele Teams jedoch nur 7, 14, 30 oder 90 Tage für die Online-Abfrage.

Massenabfrage:

aws logs describe-log-groups \
  --query 'logGroups[*].[logGroupName,retentionInDays,storedBytes]' \
  --output table

Retention festlegen:

aws logs put-retention-policy \
  --log-group-name /aws/ecs/prod-api \
  --retention-in-days 30

Es wird empfohlen, Log-Typen nach Bedarf zu staffeln: Fehler-Logs aus der Produktion für 90 Tage, normale Anwendungs-Logs für 14 bis 30 Tage, Debug-Logs für 3 bis 7 Tage, während Audit- und Compliance-Logs zur langfristigen Speicherung nach S3 exportiert werden.

Logs-Kostensenkung 2: Vor der Ingestion filtern, nicht erst bei der Abfrage

Der teuerste Teil von CloudWatch Logs ist meistens die Ingestion. Wenn die Logs erst einmal in CloudWatch gelandet sind, spart das Filtern mit Subscription Filters oder Logs Insights keine Ingestion-Gebühren mehr ein.

Es sollte bereits auf Ebene der Anwendung, des Sidecars, in Fluent Bit oder im OpenTelemetry Collector gefiltert werden:

[FILTER]
    Name   grep
    Match  app.*
    Exclude log ^.*healthcheck.*$

Verwerfen Sie bevorzugt hochfrequente Logs mit geringem Nutzwert, wie z. B. Health-Checks, HTTP-Status 200 bei statischen Ressourcen, redundante Debug-Meldungen oder zu große Payloads. Die Standardeinstellung in der Produktion sollte INFO sein; das temporäre Erhöhen auf DEBUG zur Fehlerbehebung ist weitaus günstiger als dauerhaftes, vollständiges Debugging.

Logs-Kostensenkung 3: Ungenutzte Log Groups bereinigen

Nach dem Deaktivieren von Lambda, ECS, API Gateway oder Step Functions werden die Log Groups nicht immer automatisch gelöscht. Sie können gezielt nach Gruppen suchen, in die schon länger nichts mehr geschrieben wurde:

aws logs describe-log-groups \
  --query 'logGroups[?storedBytes>`0`].[logGroupName,storedBytes,retentionInDays]' \
  --output table

Prüfen Sie anschließend in Kombination mit lastEventTimestamp, ob sie tatsächlich noch verwendet werden. Vor dem Löschen empfiehlt sich unbedigt ein Export nach S3, um den Verlust von Compliance-Daten zu vermeiden.

Logs-Kostensenkung 4: Logs mit hohem Traffic mit Vorsicht anbinden

VPC Flow Logs, ALB Access Logs, WAF Logs und CloudFront Logs können extrem groß werden. Aktivieren Sie diese nicht standardmäßig für die vollständige Weiterleitung nach CloudWatch.

Ein bewährter Ansatz ist:

• Logs für kurzfristige Fehlerbehebungen in CloudWatch zu speichern.
• Langfristige Zugriffslogs nach S3 zu schreiben.
• Historische Daten mit Athena abzufragen.
• Bei VPC Flow Logs nur die notwendigen Felder zu erfassen (Sampling) oder diese nur für kritische Subnets/ENIs zu aktivieren.

Die interaktive Erfahrung mit S3 + Athena ist zwar nicht so direkt wie mit CloudWatch Logs, aber die langfristigen Speicherkosten sind in der Regel deutlich niedriger, was sich besonders für seltene Audit-Abfragen eignet.

Logs-Kostensenkung 5: Alternativen als ergänzende Option evaluieren

Wenn das Hauptproblem in den Ingestion- und Speicherkosten von CloudWatch Logs liegt, können alternative Lösungen evaluiert werden. Beispielsweise ist S4 Logs ein auf die Kostenoptimierung von CloudWatch Logs ausgerichtetes Alternativprodukt. Es eignet sich besonders für Szenarien mit großem Log-Volumen, langen Retention-Perioden und wenn die nativen CloudWatch-Abfragefunktionen keine absolute Voraussetzung sind.

Es sollte jedoch nicht als blinder Rundum-Ersatz für CloudWatch gesehen werden. Wenn Ihr Team stark von Logs Insights, CloudWatch Alarms und bestehenden Betriebsprozessen abhängt, müssen die Migrationskosten mit eingerechnet werden. Ein pragmatischer Weg ist es, eine unkritische Log-Group mit hohem Traffic für ein Pilotprojekt auszuwählen und das Einsparpotenzial mit dem Kostenrechner zu ermitteln.

Metrics-Kostensenkung 1: Cardinality kontrollieren

Das Hauptrisiko bei Custom Metrics ist eine hohe Cardinality. CloudWatch rechnet basierend auf der Kombination aus Namespace, Metric Name und Dimension ab. Ein Dimension-Design wie das folgende ist riskant:

MetricName=Latency
Dimensions=service, endpoint, customer_id, pod_id, request_id

Wenn es 10.000 verschiedene customer_id-Werte und 50 endpoint-Werte gibt, explodiert die Anzahl der theoretischen Kombinationen sehr schnell. Ein sicherer Ansatz besteht darin, nur die Dimensionen beizubehalten, die tatsächlich für die Fehlerbehebung und Alarmierung benötigt werden:

MetricName=LatencyP95
Dimensions=service, endpoint, environment

Felder mit hoher Cardinality wie pod_id oder request_id gehören eher in die Logs oder Traces und eignen sich nicht als Dimensionen für CloudWatch Custom Metrics.

Metrics-Kostensenkung 2: Erst aggregieren, dann senden

Vermeiden Sie es, für jede Instanz, jeden Mandanten oder jeden API-Endpunkt direkt PutMetricData aufzurufen. Sie können Metriken auf Anwendungs- oder Collector-Ebene aggregieren, z. B. indem Sie alle 60 Sekunden p50/p95/p99, Count und Error-Count senden.

Die PutMetricData-API selbst verursacht ebenfalls Anfragegebühren, in der Regel ca. $0.01/1,000 requests. Eine Erhöhung des Meldeintervalls von 10 Sekunden auf 60 Sekunden beeinträchtigt die meisten betrieblichen Alarme nicht, senkt jedoch die Anzahl der API-Anfragen und Metrics erheblich.

Metrics-Kostensenkung 3: EMF richtig einsetzen

Das Embedded Metric Format (EMF) kann Metriken aus strukturierten Logs extrahieren, was ideal ist, um Logs und Metriken zu verknüpfen. Allerdings ist EMF keine „kostenlose Metrik“. Es fallen weiterhin Kosten für die Log-Ingestion an und es können Kosten für Custom Metrics entstehen.

Achten Sie bei der Verwendung von EMF auf folgende Punkte:

• Fügen Sie user_id, order_id oder container_id nicht in die Dimensions ein.
• Begrenzen Sie die Anzahl der Namespaces.
• Aggregieren Sie hochfrequente Events, bevor Sie EMF-Logs schreiben.
• Überprüfen Sie regelmäßig, wie viele unique metrics tatsächlich erzeugt werden.

Metrics-Kostensenkung 4: Alarms und Dashboards optimieren

Bei Alarms besteht ein typischer Fehler darin, für jede Dimension-Kombination einen eigenen Alarm anzulegen, was schnell zu Tausenden von Alarms führt. Besser:

• Richten Sie für kritische SLOs nur wenige, aggregierte Alarms ein.
• Klären Sie Detailfragen über Dashboards oder Log-Analysen.
• Nutzen Sie Composite Alarms für verwandte Alarme, um Alarm-Rauschen (Noise) zu reduzieren.
• Löschen Sie Dashboards, die nicht mehr aktiv genutzt werden.

Ein einzelnes Dashboard ist zwar nicht unbedingt teuer, aber häufige automatische Aktualisierungen verursachen GetMetricData API-Kosten, besonders bei Monitoring-Monitoren in Büros (Großbildschirmen) und Polling-Systemen.

Wann ist S4 Metrics eine Überlegung wert?

Wenn das Hauptproblem bei CloudWatch Custom Metrics die durch hohe Cardinality getriebenen Kosten sind, Ihr System aber dennoch feingranulare Metriken benötigt, lohnt sich eine Evaluierung von S4 Metrics. Es dient gezielt dazu, die Cardinality-Kosten von benutzerdefinierten CloudWatch-Metriken zu senken – nicht als kompletter Ersatz für das gesamte Observability-System. Ein guter Ansatz ist ein A/B-Pilotprojekt mit weniger kritischen Namespaces oder den teuersten Metrikfamilien.

Ein konkreter 7-Tage-Plan

Tag 1: Identifizieren Sie im Cost Explorer die Top-Usage-Types von CloudWatch. Tag 2: Listen Sie die Speichergröße und Retention aller Log Groups auf. Tag 3: Ändern Sie die unbegrenzte Aufbewahrung in eine Staffelung von 7, 14, 30 oder 90 Tagen. Tag 4: Filtern Sie unkritische Logs vorab in Fluent Bit oder im OTel Collector. Tag 5: Leiten Sie Logs für die Langzeitspeicherung nach S3 + Athena um. Tag 6: Analysieren Sie Ihre Custom Metrics und entfernen Sie Dimensionen mit hoher Cardinality. Tag 7: Prüfen Sie, ob alternative Lösungen wie S4 Logs oder S4 Metrics für ein Pilotprojekt infrage kommen.

Das Prinzip zur CloudWatch-Kostensenkung ist simpel: Behalten Sie Signale mit hohem Nutzwert, vermeiden Sie die Ingestion von nutzlosem Rauschen, und lagern Sie Daten für die langfristige Aufbewahrung in Systeme aus, die dafür optimiert sind.

Offenlegung: Der Autor dieses Artikels arbeitet bei abyo software (dem Entwickler des Kostenoptimierungsprodukts S4 im AWS Marketplace).