Eine Kostenanomalie ist eine Bewegung, die die eigene Historie des betrachteten Bereichs unwahrscheinlich macht: ein Sprung nach oben, ein Einbruch oder eine Position, die es gestern noch nicht gab. Für die Rechnung zählt sie, weil die Cloud nach Nutzung abrechnet und niemand einen Betrag freigibt, bevor er entsteht. Ein vergessener Lasttest oder ein Deployment mit falscher Instanzgröße läuft bis zum Monatsende weiter, wenn ihn nichts meldet. Die Anomalie ist das früheste Signal, das die Abrechnungsdaten hergeben, und ein Kosteneinblick, der eine Frage stellt, bevor der Bericht sie beantwortet.

So funktioniert es

Jede Erkennung braucht einen Bereich, eine Erwartung und eine Schwelle. Der Bereich ist die Einheit, deren Verlauf beobachtet wird: ein Dienst, ein Konto, ein Tag-Wert, ein Nutzungstyp. Die Erwartung ist der Wert, den die Historie dieses Bereichs für den Tag nahelegt; sie berücksichtigt Saisonalität nach Wochentag und Monat und ein natürliches Wachstum, damit der Montag nach einem ruhigen Wochenende nicht alarmiert. Die Schwelle legt fest, ab welcher Abweichung ein Hinweis zur Benachrichtigung wird: absolut in Währung, relativ in Prozent oder beides, meist mit einem Mindestbetrag, damit ein Dienst mit vernachlässigbaren Tageskosten keinen Alarm für eine Verdopplung auslöst.

Der Bereich entscheidet mehr als das Modell. Eine Gesamtsumme glättet, was ein einzelner Dienst zeigt: Vervielfacht sich ein kleiner Dienst, bewegt sich die Kontosumme nur um einen Bruchteil davon und bleibt innerhalb ihrer üblichen Schwankung. Deshalb beobachten die Provider pro Dienst, Konto oder Tag-Wert und nicht nur die Summe.

AWS

AWS Cost Anomaly Detection arbeitet mit Monitoren und Alert-Abonnements. Ein Monitor beobachtet eine Dimension: AWS-Services, verknüpfte Konten, einen Kostenzuordnungs-Tag oder eine Kostenkategorie. Von AWS verwaltete Monitore bewerten jeden Wert der Dimension einzeln und nehmen neue Konten oder Tag-Werte automatisch auf; vom Kunden verwaltete Monitore fassen bis zu zehn ausgewählte Werte zusammen. Ein Abonnement legt Empfänger, Frequenz (einzelne Alarme über Amazon SNS, tägliche oder wöchentliche Zusammenfassung per E-Mail) und die Schwelle fest: absolut als Betrag, prozentual als Abweichung von der erwarteten Ausgabe oder beides. Zu jeder Anomalie nennt AWS die wahrscheinlichsten Ursachen nach Service, Konto, Region und Nutzungstyp. Bewertet werden die Net-Unblended-Kosten, also die Kosten nach Rabatten. Die Erkennung läuft etwa dreimal täglich auf Daten aus Cost Explorer, die bis zu 24 Stunden verzögert sind; ein neuer Monitor braucht 24 Stunden, ein neu genutzter Service zehn Tage Historie.

Azure

Azure Cost Management bewertet Anomalien auf Subscription-Ebene, einmal täglich. Die Tagessumme wird mit einer Prognose aus den letzten 60 Tagen verglichen, die wiederkehrende Muster wie einen Montag mit Lastspitzen berücksichtigt; die Auswertung läuft 36 Stunden nach Tagesende (UTC), damit der Datensatz vollständig ist. Das Ergebnis erscheint als Insight in den Smart Views der Kostenanalyse. Eine Anomalie-Warnung ist eine Alert-Regel vom Typ Anomaly, nur auf Subscription-Scope und höchstens fünf pro Subscription; die E-Mail geht einmal zum Zeitpunkt der Erkennung und fasst die Veränderung nach Ressourcengruppen gegenüber den vorherigen 60 Tagen zusammen. Azure unterscheidet neue, weggefallene und veränderte Kosten, bei denen etwa eine Größenänderung als neuer Meter unter derselben Ressource auftaucht.

Google Cloud

Google Cloud Billing erkennt Anomalien auf dem Abrechnungskonto über alle verknüpften Projekte. Die Dokumentation beschreibt sie als Spitzen oder Abweichungen gegenüber dem historischen Ausgabemuster; Schwellen für Kostenwirkung und prozentuale Abweichung werden automatisch aus dem Nutzungsmuster gesetzt, ein Billing Account Administrator kann sie anpassen. Bewertet werden Bruttokosten zu On-Demand-Preisen einschließlich ausgabenbasierter Committed Use Discounts, aber ohne Gutschriften und ohne Sustained Use Discounts. Benachrichtigungen gehen per E-Mail, einzeln oder als tägliche Zusammenfassung, oder über Pub/Sub; die Einstellungen gelten für alle Projekte des Kontos. Zu jeder Anomalie nennt Google die größten Beiträge nach Service, Region und SKU. Standard-Anomalien kommen über die Kanäle des Folgetags; nur für die Gemini API und Vertex AI, das Google inzwischen Gemini Enterprise Agent Platform nennt, gibt es in der Vorschau frühe Anomalien aus Schätzungen, die nicht in den Kostenberichten erscheinen.

Was es für Ihre Kosten bedeutet

Eine Anomalie ist eine Frage, kein Befund. Sie sagt, dass sich ein Bereich anders verhält als seine Historie, nicht, dass etwas falsch ist: Ein neues Produkt oder eine Migration erzeugt dieselbe Kurve wie ein vergessener Cluster. Die Antwort kennt nur, wer den Bereich verantwortet; darum endet eine Anomalie erst, wenn ihr Owner eine Ursache festgehalten und entschieden hat, ob die Kosten bleiben. Darum sollte eine Erkennung auf einem Bereich laufen, der einen Owner hat, also auf Konto, Tag oder Kostenkategorie, nicht nur auf dem Service.

Auf der Rechnung steht die Anomalie nie als eigene Position. Sie ist der Teil einer Nutzungsposition, der über der Erwartung lag, und die Erkennung nennt ihn als Kostenwirkung: tatsächliche minus erwartete Ausgabe über die Dauer der Anomalie. Dazwischen liegt die Verzögerung: Nutzung entsteht, wird Stunden später abgerechnet, erreicht nach bis zu einem Tag die Kostendaten und wird im nächsten Lauf bewertet. Ein Tag Verzögerung ist der Regelfall, manchmal mehr. Was die Erkennung meldet, läuft also seit mindestens einem Tag, und was sie als beendet meldet, ist seit einem Tag vorbei.

Im Kostenbericht zeigt sich die Anomalie als Ausreißer im Tagesverlauf des Bereichs, nicht in der Monatssumme. Welche Kostenart bewertet wird, entscheidet, was auffällt: AWS prüft Kosten nach Rabatten, Google Bruttokosten ohne Gutschriften; eine auslaufende Gutschrift erscheint bei AWS als Anstieg, bei Google gar nicht. FinOps führt die Erkennung als eigene Capability, Anomaly Management, in der Domain Understand Usage & Cost des FinOps Framework der FinOps Foundation.

Wo es schiefgeht

  • Erkennung nur auf der Summe. Der Monitor beobachtet das Gesamtkonto, und ein Dienst verfünffacht sich, ohne dass die Summe ihre übliche Schwankung verlässt. Im beobachteten Bereich ist nichts Ungewöhnliches passiert, also wird nichts gemeldet.
  • Schwellen, bei denen jedes Deployment alarmiert. Prozentschwellen ohne Mindestbetrag melden die Verdopplung eines Dienstes, der fast nichts kostet; die Empfänger lernen, die E-Mails zu ignorieren, und übersehen die eine, die zählt.
  • Niemand abonniert. Der Monitor existiert, aber das Abonnement hat keinen gültigen Empfänger oder dessen Berechtigung ist weg; Azure sendet nur, solange die erstellende Person noch Leserechte hat. Die Anomalien stehen in einer Liste, die niemand öffnet.
  • Geschlossen ohne Ursache. Die Anomalie wird als bekannt markiert, weil der Anstieg wieder vorbei ist. Ohne festgehaltene Ursache wiederholt sich derselbe Fehler im nächsten Monat.
  • Ein Commitment oder eine Gutschrift als Anomalie gelesen. Ein Reservierungskauf erscheint als Sprung an einem Tag, eine auslaufende Gutschrift als Anstieg der Nettokosten bei gleicher Nutzung. Beides ist eine Preiswirkung, keine Nutzungsänderung, und gehört in den Zeitraumvergleich.
  • Erkennung statt Budget. Eine Anomalie meldet Abweichungen von der Historie. Ein stetiges Wachstum von wenigen Prozent im Monat ist nie anomal und übersteigt trotzdem das Budget; dafür gibt es die Budgetwarnung, die gegen einen Betrag prüft statt gegen die Vergangenheit.

Quellen

Gelesen am 2026-10-15. AWS Cost Anomaly Detection und Monitore und Alert-Abonnements; Microsoft Anomalien und unerwartete Kostenänderungen erkennen; Google Cloud Kostenanomalien; FinOps Foundation FinOps Framework.