Cloud-Kosten gestiegen: die Ursache in AWS und Azure belegen

Ein Kostenanstieg in AWS oder Azure ist erst erklärt, wenn Sie ihn auf eine Ressource oder einen Tarif eingegrenzt, Menge und Preis getrennt und die Änderung mit einem Ereignis belegt haben. Wer beim Gesamtbetrag beginnt und nach dem passenden Deployment sucht, findet fast immer eines, und oft das falsche. Dieser Leitfaden zeigt eine Reihenfolge, die Sie heute in AWS Cost Explorer, CUR 2.0, Azure Cost Management und den Azure-Exporten durchgehen können: erst Datenartefakte ausschließen, dann eingrenzen, dann klassifizieren, dann belegen und entscheiden.

Was Sie vor der ersten Abfrage festlegen

Halten Sie drei Dinge schriftlich fest, bevor Sie Zahlen vergleichen. Ohne sie diskutieren zwei Personen über zwei verschiedene Anstiege.

Was amortisierte Kosten genau sind, erklärt das Glossar unter amortisierte Kosten.

Schritt 1: Ist der Anstieg echt?

Ein Teil der Anstiege existiert nur in der Darstellung. Prüfen Sie diese Punkte, bevor Sie jemanden aus dem Engineering fragen:

1. Offener Monat. Cost Explorer zeigt Nutzung bis zum Vortag; im laufenden Abrechnungszeitraum können Daten später als nach 24 Stunden nachkommen. Azure aktualisiert die geschätzten Kosten des offenen Zeitraums sechsmal täglich, bei EA und MCA meist mit 8 bis 24 Stunden Verzögerung, und schließt den Zeitraum typischerweise bis zu 72 Stunden nach dessen Ende. Bis zur Rechnung können Kosten neu bewertet werden.
2. Gestaffelte Preise in Azure. Solange keine Rechnung erstellt ist, rechnet Azure Cost Management gestaffelte Preise nach der höchsten Stufe. Ein Anstieg im offenen Monat kann nach der Rechnung kleiner ausfallen.
3. Gebühren am Monatsersten. Die wiederkehrende Gebühr eines Savings Plans ohne oder mit teilweiser Vorauszahlung bucht AWS am ersten Tag jedes Abrechnungszeitraums. In der Tagesansicht zeigt Cost Explorer den ungenutzten Teil von Commitment-Gebühren am Monatsersten oder am Kaufdatum. Eine Tagesspitze am 1. ist deshalb zuerst ein Metrikthema.
4. Credits und Steuern. In CUR 2.0 haben Gutschriften, Erstattungen und Steuern eigene Zeilentypen (Credit, Refund, Tax). Azure Cost Management enthält weder Credits noch Steuern. Steigt die Rechnung, die Kostenanalyse aber nicht, kann zum Beispiel ein Guthaben ausgelaufen sein.
5. Währung. Cost Explorer zeigt Kosten nur in US-Dollar. Kommt Ihre Rechnung in Euro, kann sich der Betrag ohne jede Verbrauchsänderung verschieben. Weisen Sie den Wechselkurseffekt als eigene Position aus, statt ihn in einem Service aufgehen zu lassen.

Bleibt nach diesen Prüfungen ein Anstieg im gleichen Scope, mit derselben Metrik und gleich langen Fenstern, ist er echt.

Schritt 2: Eingrenzen, eine Dimension nach der anderen

Gehen Sie von grob nach fein und wechseln Sie erst zur nächsten Ebene, wenn eine Zeile den Großteil der Differenz erklärt: Konto oder Abonnement, dann Service, dann Usage Type oder Meter, dann Region, dann Ressource, dann Tag.

In AWS. Cost Explorer bietet unter Report parameters die Funktion Compare: Sie analysiert die Veränderung zwischen zwei ausgewählten Monaten und zeigt die größten Treiber über Services, Konten und Regionen, einschließlich Nutzungs- und Rabattänderungen. Das Widget Top trends auf der Startseite der Billing and Cost Management Console zeigt die zehn größten Veränderungen zwischen den beiden Vormonaten. Für einen Anstieg mitten im Monat stellen Sie Cost Explorer auf tägliche Granularität und gruppieren nacheinander nach Service und Usage Type.

In Azure. Öffnen Sie die Kostenanalyse für Ihren Scope, stellen Sie die Granularität auf Daily, filtern Sie auf den auffälligen Service und gruppieren Sie nach Resource. Microsoft beschreibt genau diesen Weg für unerwartete Kosten bei virtuellen Maschinen. Die Ansicht nach Ressourcen ist nur auf Abonnement- und Ressourcengruppenebene verfügbar.

Abfrage für CUR 2.0 in Athena

Die Konsole zeigt den Anstieg, aber nicht immer, ob sich Menge oder Preis bewegt hat. Diese Abfrage vergleicht zwei gleich lange Fenster je Konto, Service, Usage Type und Zeilentyp. Ersetzen Sie Tabellenname, Partitionen und Zeitstempel durch Ihre Werte.

WITH base AS (
  SELECT line_item_usage_account_id AS account_id,
         line_item_product_code     AS product,
         line_item_usage_type       AS usage_type,
         line_item_line_item_type   AS line_type,
         line_item_usage_amount     AS menge,
         line_item_unblended_cost   AS kosten,
         CASE
           WHEN line_item_usage_start_date >= TIMESTAMP '{vor_start}'
            AND line_item_usage_start_date <  TIMESTAMP '{vor_ende}'  THEN 'vor'
           WHEN line_item_usage_start_date >= TIMESTAMP '{nach_start}'
            AND line_item_usage_start_date <  TIMESTAMP '{nach_ende}' THEN 'nach'
         END AS fenster
  FROM cur2
  WHERE billing_period IN ('{periode_1}', '{periode_2}')
)
SELECT account_id, product, usage_type, line_type,
       SUM(IF(fenster = 'vor',  menge,  0)) AS menge_vor,
       SUM(IF(fenster = 'nach', menge,  0)) AS menge_nach,
       SUM(IF(fenster = 'vor',  kosten, 0)) AS kosten_vor,
       SUM(IF(fenster = 'nach', kosten, 0)) AS kosten_nach,
       SUM(IF(fenster = 'nach', kosten, 0))
         - SUM(IF(fenster = 'vor', kosten, 0)) AS delta
FROM base
WHERE fenster IS NOT NULL
GROUP BY 1, 2, 3, 4
ORDER BY delta DESC
LIMIT 25;

Die Gruppierung nach line_item_line_item_type ist der wichtigste Teil: Sie trennt Nutzung zum On-Demand-Preis (Usage), durch einen Savings Plan gedeckte Nutzung (SavingsPlanCoveredUsage) und Reservierungsnutzung (DiscountedUsage). Haben Sie den Usage Type gefunden, wiederholen Sie die Abfrage mit line_item_resource_id statt des Zeilentyps. Diese Spalte gibt es nur, wenn der Export mit der Tabellenoption INCLUDE_RESOURCES angelegt wurde, und sie bleibt für Datentransfer, API-Anfragen, Rabatte, Credits und Steuern leer.

Abfrage für einen Azure-Kostenexport

Für Azure legen Sie einen Export Cost and usage details (amortized) als CSV oder Parquet in einem Storage-Konto an und fragen ihn mit einem Werkzeug Ihrer Wahl ab, etwa einer SQL-Engine, die Parquet liest. Die Spaltennamen gelten für EA und MCA; Groß- und Kleinschreibung kann je Vertragstyp abweichen. Liegt Date als Text vor, wandeln Sie es vorher in ein Datum um.

SELECT SubscriptionName, ResourceGroup, MeterCategory, MeterName,
       PricingModel, ChargeType,
       SUM(CASE WHEN Date BETWEEN '{vor_start}'  AND '{vor_ende}'  THEN Quantity ELSE 0 END) AS menge_vor,
       SUM(CASE WHEN Date BETWEEN '{nach_start}' AND '{nach_ende}' THEN Quantity ELSE 0 END) AS menge_nach,
       SUM(CASE WHEN Date BETWEEN '{vor_start}'  AND '{vor_ende}'  THEN CostInBillingCurrency ELSE 0 END) AS kosten_vor,
       SUM(CASE WHEN Date BETWEEN '{nach_start}' AND '{nach_ende}' THEN CostInBillingCurrency ELSE 0 END) AS kosten_nach
FROM azure_amortized
GROUP BY SubscriptionName, ResourceGroup, MeterCategory, MeterName, PricingModel, ChargeType
ORDER BY kosten_nach - kosten_vor DESC;

Weil MeterName in der Gruppierung steht, haben die Mengen je Zeile dieselbe Einheit. PricingModel unterscheidet OnDemand, Reservation, Spot und SavingsPlan. In der tatsächlichen statt der amortisierten Sicht hätte eine VM mit Reservierungsvorteil keine Kosten, und der Kauf stünde als Purchase in einem einzigen Monat.

Schritt 3: Das Muster klassifizieren

Jetzt steht eine Zeile mit Menge und Kosten vor und nach dem Anstieg. Ordnen Sie sie einem Muster zu. Die Tabelle ist eine Arbeitshypothese, keine Diagnose: Sie sagt, welcher Beleg die Vermutung bestätigt.

Mischformen sind häufig. Rechnen Sie dann je Zeile Mengen- und Preiseffekt getrennt, wie es der Variance Walk im monatlichen Cloud-Kostenreview beschreibt.

Schritt 4: Die Ursache mit einem Ereignis belegen

Ein zeitlicher Zusammenfall ist kein Beleg. Suchen Sie das Ereignis, das genau die gefundene Ressource oder den gefundenen Tarif verändert hat.

• AWS CloudTrail Event history zeigt kostenfrei die Management-Ereignisse der letzten 90 Tage je Region, also Erstellen, Ändern und Löschen von Ressourcen. Eine Suche gilt für ein Konto und eine Region und erlaubt nur einen Attributfilter neben dem Zeitraum. Datenereignisse fehlen dort.
• Das Azure-Aktivitätsprotokoll speichert Steuerungsereignisse wie das Anlegen einer VM 90 Tage lang ohne Kosten. Laut Microsoft ist es der einzige Ort, der festhält, wer eine Ressource erstellt hat. Lesevorgänge erfasst es in der Regel nicht.

Daraus folgt eine harte Grenze: Liegt der Anstieg länger als 90 Tage zurück und haben Sie weder einen CloudTrail-Trail noch eine Diagnoseeinstellung für das Aktivitätsprotokoll, lässt sich die Ursache aus Provider-Daten oft nicht mehr belegen. Untersuchen Sie deshalb zeitnah und legen Sie die dauerhafte Aufzeichnung an, bevor Sie sie brauchen.

Ergänzen Sie den Beleg um Ihre eigenen Quellen: Deployment-Historie, Infrastructure-as-Code-Änderungen, Feature-Flags und Traffic-Metriken. Ein bestätigter Treiber hat eine Abfrage und ein Ereignis; ein wahrscheinlicher hat nur eines davon.

Typische Fehler

• Teilmonat gegen vollen Monat. Der laufende Monat bis gestern ist mit dem vollen Vormonat nicht vergleichbar. Vergleichen Sie gleich lange Fenster oder Tagesdurchschnitte.
• Metrik gewechselt. Ein Teil des Teams schaut auf tatsächliche, ein anderer auf amortisierte Kosten. Der Unterschied ist oft größer als der Anstieg.
• Aggregation verdeckt Bewegung. Ein stabiler Gesamtbetrag kann einen stark steigenden Service enthalten, den Rückgänge anderswo ausgleichen. Sortieren Sie nach Differenz, nicht nach Summe.
• Monatsvergleich für einen Tagesanstieg. Die Compare-Funktion in Cost Explorer vergleicht Monate. Für einen Sprung am 17. brauchen Sie die Tagesgranularität.
• Geteilte Ressourcen. Ein gemeinsamer Cluster oder ein NAT-Gateway zeigt den Anstieg, aber nicht den Verursacher. Dann liegt der Beleg in Anwendungs- oder Netzwerkmetriken, nicht in der Abrechnung.

Die Entscheidung festhalten

Jede Untersuchung endet mit einer von drei Entscheidungen und einem Owner:

1. Akzeptieren. Der Anstieg ist erwartetes Wachstum. Passen Sie Forecast und Budget an.
2. Beheben. Der Anstieg ist vermeidbar. Legen Sie eine Maßnahme mit Termin an und prüfen Sie im nächsten Fenster mit derselben Abfrage, ob die Kosten zurückgehen.
3. Weiter untersuchen. Die Ursache ist wahrscheinlich, aber nicht belegt. Verkleinern Sie den Scope, setzen Sie einen Termin und kennzeichnen Sie den Betrag als ungeklärt.

Tragen Sie Abfrage, Beleg und Entscheidung in das Protokoll Ihres Monatsreviews ein. Ein zweiter Blick nach einem Monat zeigt, ob die Erklärung trägt.

Was Costfluent dabei abdeckt

Costfluent liest die Abrechnungsdaten von AWS, Azure und Google Cloud über lesende Konnektoren und Kubernetes-Kosten über einen Agenten im Cluster. In Kostenberichten gruppieren Sie nach Provider, Konto, Service, Ressource, Region, Tag oder Segment, filtern auf das Vergleichsfenster, speichern die Ansicht für die nächste Untersuchung und laden sie als CSV herunter. Kosteneinblicke heben deutliche Veränderungen und wachsende Services hervor, nennen den Vergleichszeitraum und führen in die Kostenzeilen dahinter. Sie zeigen, wo Sie suchen sollten, und behaupten keine Ursache, die das Produkt nicht festgestellt hat. Die Änderungsuntersuchung, also der Weg von einer Veränderung zu Dimensionen und Belegen samt festgehaltener Erklärung, ist In Planung. Mehr dazu unter Kostenberichte; was ein Kosteneinblick ist, erklärt das Glossar. Welchen AWS-Export Sie für die Abfragen anlegen, klärt der Vergleich CUR 2.0 oder FOCUS.

Quellen und Methode

Geprüft am 10. Oktober 2026: AWS: Comparing your costs between time periods, AWS: Exploring your data using Cost Explorer, AWS CUR 2.0: Line item columns, AWS CUR 2.0: Table configurations, AWS CloudTrail: Working with event history, Microsoft: Understand Cost Management data, Microsoft: Common cost analysis uses, Microsoft: Understand cost details fields, Microsoft: Create and manage Cost Management exports und Microsoft: Activity log in Azure Monitor. Prüfreihenfolge, Abfragen und Mustertabelle sind Costfluent-Empfehlungen.