Ein Budget, ein Forecast-Alarm und ein Anomaliealarm beantworten drei verschiedene Fragen: Liegen wir innerhalb des vereinbarten Rahmens? Werden wir ihn bis zum Periodenende überschreiten? Ist gerade etwas passiert, das nicht zum bisherigen Muster passt? Wer eine Kontrolle für die Frage einer anderen einsetzt, bekommt Warnungen, die entweder zu spät kommen oder niemand mehr liest. Dieser Leitfaden zeigt, was AWS, Azure und Google Cloud heute dokumentieren, mit welcher Verzögerung jede Kontrolle reagiert, wer welche Meldung erhalten sollte, und endet mit einer Entscheidungstabelle für kleine Teams.
Drei Fragen, drei Kontrollen
| Frage | Kontrolle | Bezugsgröße | Typische Reaktion |
|---|---|---|---|
| Sind wir im Rahmen? | Budget mit Ist-Schwelle | aufgelaufene Kosten der Periode gegen den Budgetbetrag | Abweichung im Monatsreview erklären oder Budget bewusst anpassen |
| Werden wir den Rahmen reißen? | Budget mit Forecast-Schwelle | Hochrechnung bis Periodenende gegen den Budgetbetrag | Ursache suchen, solange die Periode noch läuft; Freigabe einholen |
| Ist etwas Ungewöhnliches passiert? | Anomalieerkennung | tatsächliche gegen erwartete Kosten aus der Historie | am selben oder nächsten Arbeitstag untersuchen |
Der wichtigste Unterschied: Budgets und Forecasts messen gegen eine Zahl, die Sie festgelegt haben. Anomalieerkennung misst gegen ein Muster, das der Provider aus Ihrer Historie lernt. Ein Dienst kann sich verdoppeln, ohne dass ein Budget reagiert, weil andere Kosten gesunken sind. Umgekehrt kann ein Budget überschritten werden, ohne dass eine Anomalie vorliegt, weil das Wachstum gleichmäßig und erwartbar war. Ein festgestellter Ausreißer ist zudem noch keine Erklärung, sondern ein Kosteneinblick, der eine Untersuchung auslöst.
Keine der Kontrollen stoppt von sich aus Ausgaben. Azure sagt das ausdrücklich: Ressourcen sind nicht betroffen, der Verbrauch läuft weiter. Bei Google Cloud deckelt ein reines Alarmbudget weder Nutzung noch Ausgaben.
Was die Provider heute dokumentieren
AWS Budgets
AWS Budgets kennt Kosten-, Nutzungs-, Reservierungs- und Savings-Plans-Budgets. Benachrichtigungen lösen auf Ist- oder Forecast-Werte aus. Die Budgetdaten werden bis zu dreimal täglich aktualisiert, typischerweise 8 bis 12 Stunden nach der vorherigen Aktualisierung. Ein Ist-Alarm geht je Budget und Periode nur einmal hinaus, beim ersten Erreichen der Schwelle. Ein Forecast-Alarm kann mehrfach auslösen, wenn die Hochrechnung über die Schwelle steigt, wieder fällt und erneut steigt. Für Forecasts braucht AWS etwa fünf Wochen Nutzungsdaten; vorher löst ein Forecast-Alarm nicht aus.
Je Alarm sind bis zu zehn E-Mail-Adressen und ein SNS-Topic möglich. Die Kostenbasis wählen Sie selbst: unblended, amortisiert oder netto, mit oder ohne Gutschriften, Steuern und Support. Budgets mit eigenem Zeitraum verlängern sich nicht und laufen am Enddatum aus. Budget-Aktionen können bei einer Schwelle zum Beispiel eine IAM-Richtlinie anwenden, die neue Ressourcen verbietet. AWS weist darauf hin, dass zwischen Nutzung und Benachrichtigung eine Lücke liegt, in der weitere Kosten entstehen.
AWS Cost Anomaly Detection
Cost Anomaly Detection prüft die Net-Unblended-Kosten nach der Verarbeitung der Abrechnungsdaten etwa dreimal täglich. Weil die Daten aus Cost Explorer bis zu 24 Stunden verzögert sind, kann es bis zu 24 Stunden dauern, bis eine Anomalie nach der Nutzung erkannt wird. Ein neuer Monitor braucht 24 Stunden, ein neu genutzter Dienst zehn Tage Historie.
Von AWS verwaltete Monitore beobachten alle Dienste, alle Mitgliedskonten, alle Werte eines Kostenzuordnungs-Tags oder einer Kostenkategorie, jeweils bis zu 5.000 Werte. Selbst verwaltete Monitore fassen bis zu zehn ausgewählte Werte zusammen. Ein Abonnement liefert Einzelalarme über SNS, eine tägliche Zusammenfassung der zehn größten Alarme per E-Mail (erzeugt um 00:00 UTC für den Vortag) oder eine wöchentliche Zusammenfassung. Schwellen sind absolut (Kostenwirkung) oder prozentual, kombinierbar mit UND oder ODER. Hält eine Anomalie über mehrere Tage an, kommen weitere Meldungen. Marketplace-Käufe überwacht der Dienst nicht, mit Ausnahme von Drittanbieter-Modellen in Amazon Bedrock; dafür verweist AWS auf ein Kostenbudget mit Filter auf die Billing Entity.
Azure-Budgets
Azure-Budgets gibt es auf Management-Gruppe, Abonnement und Ressourcengruppe sowie auf den Abrechnungsscopes von EA und Microsoft Customer Agreement (MCA). Kosten- und Nutzungsdaten liegen typischerweise nach 8 bis 24 Stunden vor, Budgets werden alle 24 Stunden dagegen ausgewertet, und die E-Mail folgt normalerweise innerhalb einer Stunde nach der Auswertung. Ein Budget nimmt bis zu fünf Schwellen und fünf E-Mail-Adressen auf, jeweils als Ist- oder Forecast-Schwelle. Aktionsgruppen, etwa für eine Automatisierung oder Push-Benachrichtigungen, gehen nur auf Abonnement- und Ressourcengruppen-Ebene.
Zwei Details führen zu verpassten Alarmen: Alle Abonnements eines Scopes müssen dieselbe Währung haben, sonst wird das Budget nicht verlässlich ausgewertet. Und auf MCA-Abrechnungskontoebene rechnet die Auswertung in USD, unabhängig von der Rechnungswährung. Ausgewertet werden tatsächliche Kosten ohne Amortisierung.
Azure-Kostenwarnungen und Anomaliealarme
Die Seite Cost alerts sammelt Budgetwarnungen, bei EA außerdem Guthabenwarnungen bei 90 und 100 Prozent der Azure-Vorauszahlung und Warnungen zu Abteilungskontingenten. Anomalieerkennung läuft täglich je Abonnement: Ein Modell, trainiert auf 60 Tagen Historie, sagt den Tagesverbrauch vorher, und die Auswertung startet 36 Stunden nach Ende des UTC-Tages. Ein Anomaliealarm geht einmal zum Zeitpunkt der Erkennung hinaus und nennt die größten Veränderungen nach Ressourcengruppe. Er lässt sich nur auf Abonnementebene anlegen, höchstens fünf je Abonnement, und braucht mindestens die Rolle Cost Management Contributor. Azure prüft vor jedem Versand die Berechtigung der Person, die die Regel angelegt hat. Verliert sie den Zugriff, verstummt der Alarm; als Ausweg nennt Microsoft einen Service Principal, der den Alarm über die Scheduled Actions API anlegt.
Google-Cloud-Budgets
Google-Cloud-Budgets gelten für ein Rechnungskonto, Ordner, Projekte, Dienste oder ein Label. Schwellen sind Prozentwerte des Budgets auf Ist- oder Forecast-Kosten; voreingestellt sind 50, 90 und 100 Prozent auf Ist-Kosten. Budgets mit eigenem Zeitraum können nicht auf Forecasts auslösen. Rabatte und Gutschriften sind standardmäßig abgezogen, bevor die Schwelle geprüft wird; Steuern sind enthalten. Monatsbudgets erfassen in den ersten zwei Tagen des Folgemonats noch spät gemeldete Nutzung. Die erste Benachrichtigung kann nach dem Anlegen mehrere Stunden dauern; Pub/Sub-Meldungen kommen mehrmals täglich mit dem aktuellen Stand. Empfänger sind standardmäßig Billing-Account-Administratoren und -Nutzer, ergänzbar über Cloud-Monitoring-Kanäle.
Zusätzlich gibt es Budgets mit Ausgabendeckel für wenige Dienste, darunter die Gemini API und Cloud Run: Beim Überschreiten pausiert der Dienst im Projekt, laufende Anfragen werden noch berechnet, persistente Ressourcen laufen weiter, und Google nennt die Durchsetzung ausdrücklich nicht sofort. Daneben gibt es eine eigene Anomalieerkennung je Rechnungskonto, die Standard-Anomalien über die üblichen Kanäle am Folgetag meldet.
Mit welcher Verzögerung Sie rechnen müssen
| Kontrolle | Frühestes dokumentiertes Signal |
|---|---|
| AWS Budgets | Aktualisierung bis zu dreimal täglich, 8 bis 12 Stunden Abstand, plus Abrechnungsverzögerung |
| AWS Cost Anomaly Detection | bis zu 24 Stunden nach der Nutzung; Tageszusammenfassung erst am Folgetag |
| Azure-Budgets | Daten nach 8 bis 24 Stunden, Auswertung alle 24 Stunden, Mail innerhalb einer Stunde |
| Azure-Anomaliealarm | Auswertung 36 Stunden nach Ende des UTC-Tages |
| Google-Cloud-Budgets | erste Meldung nach mehreren Stunden; Pub/Sub mehrmals täglich |
Daraus folgt eine harte Grenze: Keine dieser Kontrollen schützt vor einem Fehler, der in wenigen Stunden teuer wird, etwa einer Endlosschleife gegen eine kostenpflichtige API. Dafür brauchen Sie Begrenzungen in der Anwendung, Kontingente beim Dienst oder, wo es sie gibt, einen Ausgabendeckel. Die Cloud-Kontrollen sind das Netz darunter, nicht die erste Linie.
Entscheidungstabelle
| Situation | Kontrolle | Empfänger | Hinweis |
|---|---|---|---|
| Fester Monatsrahmen je Team, Umgebung oder Kunde | Budget mit Ist-Schwellen je Scope | Kostenverantwortliche des Scopes; Finance im Monatsreview | Scope so schneiden, dass ein Owner zuständig ist |
| Rechtzeitig vor dem Überschreiten warnen | Forecast-Schwelle bei 100 Prozent des Budgets | Owner und die Person, die Budgetänderungen freigibt | Erst sinnvoll mit Historie; bei AWS etwa fünf Wochen |
| Unerwarteter Sprung in einem Dienst oder Konto | Anomalieerkennung | Engineering-Kanal oder Bereitschaft | Einzelalarme für Produktion, Zusammenfassung für Teamleads |
| Neues Konto oder neuer Dienst ohne Historie | Budget mit niedrigen Ist-Schwellen | Owner des Projekts | Anomaliemodelle brauchen erst Daten |
| AWS-Marketplace-Kosten | Kostenbudget mit Filter auf die Billing Entity | Einkauf und Owner | Anomalieerkennung deckt Marketplace nicht ab, außer Drittanbieter-Modellen in Bedrock |
| Sandbox oder Experiment mit harter Obergrenze | AWS-Budget-Aktion oder Google-Ausgabendeckel | Owner, mit Absprache vorab | Verzögerung einplanen; Persistentes läuft weiter |
| Auslastung von Reservierungen oder Savings Plans | AWS-Auslastungs- oder Abdeckungsbudget | Wer Commitments kauft | Messgröße ist Prozent, nicht Betrag |
| Azure-Scope mit mehreren Währungen | getrennte Budgets je Währung | Owner je Gesellschaft | sonst drohen verpasste Alarme |
Wer welche Meldung bekommt
Eine Meldung ohne Empfänger, der handeln kann, ist Rauschen. Drei Regeln halten sich auch in kleinen Teams:
- Jeder Alarm hat einen Owner und eine Reaktion. Notieren Sie neben jeder Schwelle, wer sie erhält und was diese Person innerhalb welcher Frist tut. Ohne diesen Eintrag wird der Alarm gelöscht, nicht gelesen.
- Budgetmeldungen gehen an Kostenverantwortliche, Anomaliemeldungen an Engineering. Eine Budgetüberschreitung ist eine Planungsfrage, eine Anomalie meist eine technische. Bei AWS führen Sie Einzelalarme über SNS in einen Chat-Kanal; bei Azure leiten Sie die Mail an ein gemeinsames Postfach, das ein Ticketsystem überwacht, wie Microsoft es beschreibt.
- Persönliche Postfächer meiden. Googles Voreinstellung schickt an Billing-Administratoren, Azure-Anomaliealarme hängen an der Berechtigung der anlegenden Person. Beides bricht beim Personalwechsel.
Typische Fehlkonfigurationen
- Unterschiedliche Kostenbasis. Das Budget wurde aus der Rechnung abgeleitet, ausgewertet wird aber amortisiert oder nach Gutschriften. Azure-Budgets nutzen tatsächliche Kosten ohne Amortisierung, Google zieht Rabatte standardmäßig ab. Legen Sie die Basis so fest wie im monatlichen Cloud-Kostenreview; welche AWS-Spalten dafür in Frage kommen, zeigt CUR 2.0 oder FOCUS.
- Forecast ohne Historie. Ein Forecast-Alarm auf einem neuen Konto schweigt, bis genug Daten vorliegen.
- Schwellen zu niedrig. Anomaliealarme mit kleiner Kostenwirkung erzeugen täglich Meldungen, bei AWS auch Folgemeldungen, solange die Anomalie anhält. Kombinieren Sie absolute und prozentuale Schwelle.
- Alarm als Deckel verstanden. Ohne Aktion oder Ausgabendeckel läuft der Verbrauch weiter.
- Abgelaufene Budgets. AWS-Budgets mit eigenem Zeitraum enden ohne Hinweis; wiederkehrende Budgets sind die sichere Voreinstellung.
- Nicht bestätigte Kanäle. Ein SNS-Abonnement, das nie bestätigt wurde, oder eine Absenderadresse im Spam-Filter verhindern die Zustellung.
Einrichtung in sieben Schritten
- Scopes mit Owner auflisten: Konten, Abonnements, Projekte, bei Bedarf Tag-Werte.
- Kostenbasis je Provider festlegen und dokumentieren.
- Je Scope ein wiederkehrendes Budget mit Ist-Schwellen anlegen.
- Forecast-Schwellen ergänzen, sobald genug Historie vorliegt.
- Anomalieerkennung einschalten: bei AWS einen verwalteten Monitor für Dienste und einen für Mitgliedskonten, bei Azure einen Alarm je Abonnement, bei Google die Schwellen im Anomalie-Dashboard prüfen.
- Zustellung testen: SNS bestätigen, Absender freigeben, Kanal-Empfang prüfen.
- Im Monatsreview durchgehen, welche Alarme kamen, was geschah und welche Schwelle sich ändern muss.
Was Costfluent dabei abdeckt
Costfluent liest Kosten aus AWS, Azure und Google Cloud über lesende Konnektoren. Budgets legen Sie für den gesamten Workspace, einen gespeicherten Kostenbericht oder ein Segment an, im Produkt, über die Public API oder mit dem Terraform-Provider; Costfluent stellt die tatsächlichen Ausgaben dem Budget der Periode gegenüber. Jedes Budget hat eigene Schwellen als Anteil seines Betrags; Costfluent prüft sie stündlich und meldet eine überschrittene Schwelle im Produkt und an die E-Mail-, Slack-, Microsoft-Teams- oder Webhook-Kanäle, die das Budget nennt, soweit Ihr Plan sie enthält. Kosteneinblicke heben wesentliche Veränderungen, wachsende Dienste und Anomalien hervor und führen zu den Kostendaten dahinter; eigene Schwellen für Ausgaben und Veränderungen sind Kostenwarnungen, angelegt über die Public API. Einen gespeicherten Kostenbericht stellen Sie täglich, wöchentlich oder monatlich per E-Mail zu. Ausgabenprognosen für Budgets sind In Planung (siehe Budgets).
Quellen und Methode
Geprüft am 10. Oktober 2026: AWS: Managing your costs with AWS Budgets, AWS: Best practices for AWS Budgets, AWS: Detecting unusual spend with Cost Anomaly Detection, AWS: Getting started with Cost Anomaly Detection, Microsoft: Create and manage budgets, Microsoft: Cost alerts, Microsoft: Identify anomalies and unexpected changes in cost, Google Cloud: Create, edit, or delete budgets and budget alerts, Google Cloud: Spend caps und Google Cloud: View and manage cost anomalies. Entscheidungstabelle, Empfängerregeln und Einrichtungsschritte sind Costfluent-Empfehlungen.
