Methoden der Cloud-Kostenprognose

Eine Prognose der Cloud-Kosten ist eine Schätzung der Kosten zum Ende einer Periode, mit einem Bereich, die mit jedem neuen Datenstand neu gerechnet wird; sie ist keine Zusage. Sie entscheidet, ob ein Budget am Monatsende hält, ob ein Commitment gekauft wird und welche Zahl Finance für den Abschluss abgrenzt. Welche Methode die Prognose erzeugt und was sie als Eingabe bekommt, bestimmt, wie weit man ihr trauen darf.

So funktioniert es

Jede Methode beantwortet dieselbe Frage mit anderen Eingaben: Was kostet dieser Zuschnitt am Ende der Periode? Die FinOps Foundation ordnet die Methoden in ihrem FinOps Framework nach Reifegrad: zuerst manuelle Modelle aus der Historie, dann rollierende und trendbasierte Modelle, zuletzt deren Kombination mit treiberbasierten Modellen auf amortisierten Daten.

Hochrechnung des laufenden Monats. Die Kosten bis heute, geteilt durch die vergangenen Tage, mal die Tage des Monats. Sie braucht nur den laufenden Monat und ist bei einem neuen Konto die einzige Methode ohne Historie. Sie versagt, sobald der Monat nicht gleichmäßig ist: eine Vorauszahlung am Ersten, ein Batchlauf zum Monatsende, ein Wochenende am Anfang.

Gleitender Durchschnitt. Der Mittelwert der letzten drei, sechs oder zwölf Monate als Erwartung für den nächsten. Er glättet Ausreißer und braucht mehrere abgeschlossene Monate. Er versagt bei Wachstum und bei Rückbau, weil er jede Veränderung mit Verzögerung nachzieht, und er trägt einen alten Ausreißer so lange mit, wie das Fenster reicht.

Trend mit Saisonalität. Ein Modell über Tageswerte, das die Richtung von wiederkehrenden Mustern trennt: weniger Nutzung am Wochenende, mehr zum Monatsende, mehr im vierten Quartal. Es braucht so viel Historie, dass jedes Muster mehrmals vorkommt, und es ist die Methode, mit der die Anbieterkonsolen rechnen. Es versagt bei einem Strukturbruch: nach einer Migration, einer Preisänderung oder einem Commitment-Kauf ist die Historie nicht mehr die Zukunft.

Treiberbasiert. Geplante Nutzung mal Stückkosten: erwartete Kunden, Anfragen oder Datenvolumen, multipliziert mit den Unit Economics der letzten Monate. Die Methode braucht einen Plan für den Treiber und eine stabile Beziehung zwischen Treiber und Kosten. Sie versagt, wenn die Stückkosten selbst wandern, etwa weil ein Commitment ausläuft oder eine Architektur sich ändert, und sie ist so gut wie der Geschäftsplan, der den Treiber liefert.

Bottom-up je Team. Jedes Team schätzt seine Kosten aus seiner Roadmap, die Summe ist die Prognose. Sie kennt Vorhaben, die in keiner Historie stehen. Sie versagt, wenn Teams ihre geteilten Kosten vergessen, Puffer einbauen oder die Schätzung nie mit dem Ergebnis vergleichen.

Keine Methode weiß, was noch nicht in den Daten ist: ein Commitment, das nächsten Monat gekauft wird; ein Workload, der in den Betrieb geht; eine Preisänderung des Anbieters; eine Kursbewegung, wenn die Rechnung in einer anderen Währung kommt als das Budget. Diese Posten werden der Prognose hinzugefügt, nicht aus ihr gelesen.

Deshalb ist eine Prognose ein Bereich. Eine einzelne Zahl verspricht eine Genauigkeit, die die Eingaben nicht haben; der Bereich sagt, wie breit die Unsicherheit ist. Ein Budget wird gegen das obere Ende gehalten, nicht gegen die Mitte.

AWS

Cost Explorer prognostiziert aus der bisherigen Nutzung mit einem Prognoseintervall von 80 Prozent, das in Linien- und Balkendiagrammen als Band um die Prognose erscheint; je unruhiger die Historie, desto breiter das Band. Reicht die Historie für dieses Intervall nicht, zeigt Cost Explorer keine Prognose, was laut Dokumentation bei Konten mit weniger als einem vollen Abrechnungszyklus üblich ist. Rabatte sind standardmäßig enthalten. Die Prognose reicht laut AWS bis zu 18 Monate bei monatlicher und 3 Monate bei täglicher Granularität. Prognosewarnungen in AWS Budgets brauchen etwa fünf Wochen Nutzungsdaten.

Azure

Cost Analysis beschreibt sein Modell als lineare Regression über eine Zeitreihe, die bis zu ein Jahr voraus rechnet. Ein Reservierungskauf hebt die Prognose laut Dokumentation vorübergehend an und stabilisiert sich innerhalb weniger Tage; die Dokumentation empfiehlt, solche Spitzen herauszufiltern. Das Rückblickfenster hängt vom Horizont ab: 28 Tage für Prognosen bis 28 Tage, so lang wie der Horizont darüber, höchstens 90 Tage. Für eine Jahresprognose werden mindestens 90 Tage Historie empfohlen.

Google Cloud

Die Abrechnungsberichte zeigen eine Prognose bis zu zwölf Monate voraus, als Annäherung aus dem historischen Trend, die laut Dokumentation Tages-, Wochen- und Monatszyklen erkennt und dafür die gesamte Historie heranzieht, die zu den Filtern passt, nicht nur den gewählten Zeitraum. Sie erscheint nur für einen Zeitraum nach Nutzungsdatum, der in der Zukunft endet, nicht für einen Zeitraum nach Rechnungsmonat, und nicht bei bestimmten Filtern, etwa nach Produkt oder ausgabenbasierten Committed Use Discounts. Eine Mindesthistorie nennt die Dokumentation nicht.

Was es für Ihre Kosten bedeutet

Die Monatsfrage lautet Prognose gegen Budget: nicht, wo die Kosten heute stehen, sondern wo sie landen und ob das innerhalb des Betrags liegt.

Die Kostenbasis entscheidet, wofür die Prognose taugt. Für Teams gehört sie auf effektive Kosten, weil Commitments dort auf die Nutzung verteilt sind, die sie abdecken, und die Kurve das Verhalten des Teams zeigt. Für die Rechnung gehört sie auf berechnete Kosten, weil Finance den Betrag braucht, der fällig wird, mit der Vorauszahlung in dem Monat, in dem sie bezahlt wird. Dieselbe Nutzung ergibt zwei Prognosen, und beide sind richtig für ihre Frage.

Eine Prognose je Zuschnitt summiert sich schlecht zu einer Gesamtprognose, wenn Zuschnitte sich bewegen: ein Workload wechselt das Konto, ein Tag wird umbenannt, ein Team wird geteilt. Die Historie je Zuschnitt bricht, die Gesamthistorie nicht. Die Differenz zwischen Gesamtprognose und Summe der Teilprognosen zeigt verschobene Zuordnung, nicht Mehrkosten.

Wo es schiefgeht

• Einfache Skalierung eines Teilmonats. Die Kosten der ersten fünf Tage mal sechs. Enthält der Anfang eine Vorauszahlung oder ein Wochenende, liegt die Prognose um genau den Faktor daneben, den der Rest des Monats nicht hat.
• Prognose über einen Commitment-Kauf. Eine Vorauszahlung in der Historie wird als Nutzung fortgeschrieben; Azure beschreibt diesen Effekt ausdrücklich. Die Prognose meldet eine Überschreitung, die nie kommt.
• Vertrauen in drei Tage Daten. Ein neues Konto, ein neues Projekt, drei Datenpunkte. Cost Explorer zeigt in dieser Lage keine Prognose; eine Tabellenkalkulation schon.
• Eine Prognose für alle Zuschnitte. Die Gesamtsumme sieht stabil aus, während ein Team um die Hälfte wächst und ein anderes abbaut. Die Prognose je Verantwortlichem zeigt beides, die Summe keines.
• Eine Prognose, die niemand mit dem Ergebnis vergleicht. Ohne Abgleich von Prognose und Ist am Periodenende bleibt die Methode, wie sie ist, auch wenn sie jeden Monat daneben liegt. Das FinOps Framework führt diesen Abgleich als eigene Kennzahl, die Forecast Accuracy Rate.

Quellen

Gelesen am 2026-10-15. AWS: Forecasting with Cost Explorer, Zeiträume in Cost Explorer, Best practices for AWS Budgets; Microsoft: Start using Cost Analysis; Google Cloud: View forecasted costs; FinOps Foundation: Forecasting, FinOps Framework (CC BY 4.0); FOCUS: Effective Cost.