Ein Cloud-Kosten-Anomalie-Runbook füllt der Cloud-Verantwortliche einmal aus, bevor der erste Alarm der Provider-Werkzeuge scharf geschaltet wird, und arbeitet es bei jedem Alarm ab; es hält fest, welche Quellen einen Vorfall auslösen, wer in welcher Frist reagiert, wie der Vorfall eingegrenzt und eingedämmt wird, wer wann informiert wird und welche Felder die Nachbereitung füllt. Die Entscheidung, die es je Vorfall festhält: stoppen, drosseln, beobachten oder akzeptieren, mit Person und Datum. Wie die Erkennung der Provider arbeitet und wo sie blind ist, erklärt Anomalieerkennung; die Methode der Eingrenzung mit Beispielen der Artikel Kostenanstieg untersuchen. Diese Seite ist das Runbook.
Die Vorlage
Kostenanomalie-Runbook <Organisation>, Version <1.0>, gültig ab <Datum>, Eigentümer <Cloud-Verantwortlicher>
Auslöser und Schwellen
| Quelle | Schwelle | Empfänger | Reaktionszeit |
|---|---|---|---|
AWS Cost Anomaly Detection, Monitor <Dienste oder Konten> | Auswirkung ab <Betrag> | <Kanal, Bereitschaft> | <4> Stunden |
| Azure Cost Management, Anomaliewarnung je Subscription | jede Warnung | <Kanal> | <4> Stunden |
| Google Cloud, Kostenanomalien je Abrechnungskonto | Abweichung ab <Betrag> | <Kanal> | <4> Stunden |
| Budget-Alarm je Konto, Subscription, Projekt | <80> Prozent Ist, <100> Prozent Prognose | <Team-Lead> | <1> Arbeitstag |
| Eigene Prüfung: Tagesvergleich je Konto und Dienst aus dem Export | plus <Prozent> gegen das Mittel der letzten <7> Tage | <Cloud-Verantwortlicher> | <1> Arbeitstag |
| Hinweis aus Team oder Finance | jeder | <Kanal> | <1> Arbeitstag |
Schweregrad
| Stufe | Mehrkosten je Tag | Reaktion | Information |
|---|---|---|---|
| S1 | ab <Betrag> | sofort eindämmen, auch nachts | <Management, Finance> sofort |
| S2 | <Betrag> bis <Betrag> | am selben Arbeitstag | <Team-Lead> am selben Tag |
| S3 | unter <Betrag> | im nächsten Review | Protokoll des Reviews |
Rollen
| Rolle | Person | Vertretung | Erreichbar über |
|---|---|---|---|
| Erstreaktion | <Bereitschaft oder Cloud-Verantwortlicher> | <Name> | <Kanal> |
| Verursachendes Team | <aus Tag owner oder Konto> | <Team-Lead> | <Kanal> |
| Finance | <Name> | <Name> | <Kanal> |
| Management ab S1 | <Name> | <Name> | <Kanal> |
Schritt 1, aufnehmen, innerhalb der Reaktionszeit
- Vorfallsdatensatz angelegt: Zeitstempel, Quelle, Scope, Mehrkosten je Tag, Beginn
- Datenstand geprüft: ist der Tag vollständig, oder ist es ein Nachtrag des Providers?
- Erste Einordnung: Nutzung, Preis, Einmaliges oder Datenartefakt
- Schweregrad nach Tabelle gesetzt, Information ausgelöst
Schritt 2, eingrenzen, innerhalb <1> Arbeitstag
- Aufgeteilt in dieser Reihenfolge: Konto oder Subscription oder Projekt, Dienst, Usage Type oder Meter oder SKU, Region, Ressource
- Ressource und Zeitpunkt der Änderung ermittelt: Deployment, Konfiguration, Skalierung, neuer Job, neuer Nutzer
- Auf Kompromittierung geprüft: unbekannte Regionen, Dienste oder Instanztypen, GPU- oder Mining-Muster; bei Verdacht
<Security-Runbook>zuerst - Verursachendes Team mit Ressourcen-IDs informiert, Hypothese im Datensatz
Schritt 3, eindämmen
- Entscheidung durch
<Rolle>: stoppen, drosseln, beobachten bis<Datum>, akzeptieren mit Begründung - Reversible Maßnahme zuerst: stoppen vor löschen, Skalierung begrenzen, Quota senken, Schlüssel sperren
- Bei Preis oder Einmaligem: keine technische Maßnahme; Finance informiert, Budgetzeile geprüft
- Bei Provider-Fehler: Support-Fall
<ID>eröffnet, Gutschrift beantragt
Kommunikation
| Wann | Wen | Was | Kanal |
|---|---|---|---|
| bei Aufnahme | Erstreaktion, Team | Scope, Betrag je Tag, Schweregrad | <Kanal> |
| bei S1 | Management, Finance | Betrag, Hypothese, nächste Entscheidung | <Kanal> |
| nach Eindämmung | alle Beteiligten | Maßnahme, erwartete Wirkung ab <Datum> | <Kanal> |
| nach Abschluss | Review | Vorfallsdatensatz | Protokoll des Reviews |
Schritt 4, abschließen
- Kosten wieder auf Basis bestätigt: zwei volle Tage im Export unter
<Schwelle> - Mehrkosten gesamt berechnet: Betrag je Tag mal Tage, Quelle genannt
- Gutschrift oder Korrektur mit Rechnungsnummer eingetragen
- Alarm im Werkzeug geschlossen, Datensatz vollständig
Vorfallsdatensatz und Nachbereitung
| Feld | Wert |
|---|---|
| ID, erkannt am, erkannt durch | <ID>, <Datum>, <Quelle> |
| Beginn und Ende | <Datum> bis <Datum> |
| Scope, Dienst, Ressourcen | <Konto>, <Dienst>, <IDs> |
| Art und Auslöser | <Nutzung, Preis, Einmaliges, Artefakt>, <Deployment, Konfiguration, Kompromittierung> |
| Mehrkosten gesamt und Gutschrift | <Betrag>, <Betrag, Rechnungsnummer> |
| Zeit bis Erkennung, bis Eindämmung | <Stunden>, <Stunden> |
| Was hätte es früher gefunden | <Alarm, Budget, Quota, Review> |
| Maßnahme zur Vermeidung | <Maßnahme>, <Person>, fällig <Datum> |
So füllen Sie sie aus
Auslöser: Schwellen in Beträgen, nicht in Prozent, weil ein kleines Konto sonst jeden Tag alarmiert; wo die Werkzeuge der drei Provider ihre Schwellen setzen, steht in Budget-Alarme und Schwellen. Die eigene Prüfung aus dem Export fängt, was die Werkzeuge erst nach Tagen melden.
Aufnehmen: Der zweite Punkt verhindert den häufigsten Fehlalarm, einen Nachtrag, der einen alten Tag aufstockt (Aktualität, Nachträge und Finalisierung). Eingrenzen: Die Reihenfolge ist die der Abrechnungsdaten, von grob nach fein; welche Spalte je Provider was trägt, steht in Trends und Treiber. Eindämmen: Eine Gutschrift gibt es nur mit Support-Fall und nur für Fehler des Providers (Gutschriften, Erstattungen und Korrekturen); die Quota als Bremse beschreibt Leitplanken und Freigabeschwellen.
Nachbereitung: Die Zeile "was hätte es früher gefunden" ist der Grund für das Feld; die Maßnahme daraus bekommt eine Person aus dem RACI und steht im nächsten monatlichen Review.
So passen Sie sie an
Ein Team: Erstreaktion und verursachendes Team sind dieselben Personen; die Kommunikationstabelle schrumpft auf die Zeile für S1. Mehrere Teams: Das Tag owner entscheidet, wer Schritt 2 übernimmt; ohne Tag geht der Vorfall an den Konto-Eigentümer.
Ein Provider: Die Auslöser-Tabelle hat drei Zeilen, Werkzeug, Budget und eigene Prüfung. Drei Provider: Je Provider ein Werkzeug und eine Reaktionszeit, weil Azure und Google Cloud ihre Daten zu anderen Zeiten liefern, und der Tagesvergleich läuft in einer Währung.
Startup: Zwei Schweregrade, sofort und Review, und die Prüfung auf Kompromittierung als erster Punkt, weil ein geleakter Schlüssel der teuerste Vorfall ist. Finance-geführt: Finance ist Empfänger ab S2, und die Mehrkosten jedes Vorfalls erscheinen als Zeile im Showback-Bericht des Teams.
Quellen
Gelesen am 2026-10-21. FinOps Framework (CC BY 4.0), AWS Cost Anomaly Detection, Monitore und Alarmabonnements, Was tun bei unberechtigter Aktivität im AWS-Konto, unerwartete Kosten in Azure analysieren, Kostenanomalien in Google Cloud, Budgets und Budgetbenachrichtigungen in Google Cloud.