Ein Kostentreiber in der Cloud ist eine Größe, deren Veränderung die Kosten bewegt: Instanzstunden, Anfragen, gespeicherte Gigabyte oder ein Geschäftsvolumen wie Kunden und Bestellungen. Wer den Treiber einer Kostenlinie kennt, kann eine Veränderung erklären und dem zuordnen, der sie steuern kann; wer nur die Summe sieht, weiß nur, dass sie gestiegen ist. Jede Veränderung zerlegt sich in drei Teile: mehr oder weniger Menge, ein anderer Preis je Einheit und ein anderer Mix, also eine Verschiebung zu teureren oder günstigeren Positionen. Vorher ist zu klären, ob die Linie überhaupt einen Trend zeigt oder nur Rauschen.
So funktioniert es
Trend oder Rauschen
Tagesdaten schwanken aus Gründen, die nichts mit dem Verbrauch zu tun haben. Lasten, die an Werktagen laufen, erzeugen ein Wochenmuster; Monate haben 28 bis 31 Tage; die jüngsten Tage sind unvollständig, weil die Provider Nutzung verzögert melden (Datenstand in Kostenberichten); und Käufe erscheinen in berechneten Kosten als Spitze. AWS bucht etwa die laufende Gebühr eines Savings Plans jeweils am ersten Tag der Abrechnungsperiode, und die Azure-Kostenanalyse zeigt einen Reservierungskauf in den tatsächlichen Kosten am Kauftag, in den amortisierten über die Laufzeit verteilt.
Ein Trend ist deshalb eine Richtung, die über mehrere vergleichbare Fenster hält: Tagesdurchschnitte je Monat, Summen über sieben Tage, in denen jeder Wochentag genau einmal vorkommt, oder derselbe Wochentag gegen denselben, jeweils in effektiven Kosten. Ein einzelner Tag, der aus der Reihe fällt, ist eine Frage für die Anomalieerkennung. Die Konsolen geben dafür unterschiedlich viel Historie her: Cost Explorer standardmäßig bis zu 13 Monate, stündlich nach Aktivierung für die letzten 14 Tage; die Azure-Kostenanalyse täglich für bis zu 92 Tage, darüber monatlich; Google Cloud nach Nutzungsdatum zurück bis Januar 2017.
Menge, Preis und Mix
FOCUS trennt die Bausteine. PricingQuantity ist die abgerechnete Menge in der PricingUnit, ConsumedQuantity die verbrauchte Menge in der ConsumedUnit, oft feiner und nur in Nutzungszeilen gefüllt. ListUnitPrice und ContractedUnitPrice sind Listen- und Vertragspreis je Einheit, und die Spezifikation verlangt, dass ein Kostenwert gleich Stückpreis mal PricingQuantity ist. Stückpreise gelten nur in ihrer Zeile und sollen laut FOCUS nicht zu einer Summe addiert werden. Einen effektiven Stückpreis kennt FOCUS nicht; er ergibt sich je SkuPriceId als EffectiveCost geteilt durch PricingQuantity, und Azure liefert ihn als Erweiterung x_EffectiveUnitPrice. Wie die Provider Menge, Einheit und Preis in ihren Exporten benennen, beschreibt Nutzung, Preise und Rechnungsposten.
| Effekt | Was er misst | FOCUS | AWS CUR 2.0 | Azure | Google Cloud |
|---|---|---|---|---|---|
| Menge | mehr oder weniger Einheiten zum selben Preis | PricingQuantity | line_item_usage_amount | Quantity | usage.amount_in_pricing_units |
| Preis | anderer Betrag je Einheit | EffectiveCost ÷ PricingQuantity, ContractedUnitPrice | line_item_net_unblended_rate, line_item_unblended_rate | EffectivePrice, UnitPrice | price.effective_price, dazu credits.amount |
| Mix | Verschiebung zwischen Positionen mit verschiedenen Preisen | SkuId, SkuPriceId, RegionId | line_item_usage_type | MeterId, MeterRegion | sku.id, location.region |
Gerechnet wird je Preisposition: Mit q für die Menge und p für den effektiven Preis je Einheit ist der Mengeneffekt (q₁ − q₀) × p₀ und der Preiseffekt q₁ × (p₁ − p₀). Die Summe beider Effekte über alle Positionen ergibt die Veränderung genau. Für eine Gruppe von Positionen mit derselben Einheit, etwa Instanzstunden verschiedener Größen, lässt sich dieselbe Zerlegung auch mit dem Durchschnittspreis der Gruppe rechnen. Der Preiseffekt fällt dann anders aus als die Summe der Preiseffekte je Position; der Unterschied ist der Mixeffekt. Neue und weggefallene Positionen stehen getrennt, weil sie keinen Vorher-Preis haben. Wie das monatliche Review diese Zerlegung samt Kurs- und Gutschrifteffekten aufbaut, zeigt Monatliches Cloud-Kostenreview.
Geschäftstreiber
Technische Treiber erklären die Rechnung, Geschäftstreiber erklären, ob sie in Ordnung ist. Anfragen, aktive Kunden oder Bestellungen sind der Nenner der Stückkosten: Wachsen die Kosten im selben Maß wie der Treiber, bleiben die Kosten je Einheit gleich, und der Anstieg ist Wachstum. Wachsen sie schneller, steigt der Preis je Geschäftseinheit, und der Anstieg ist eine Frage an die Technik. Die Zahl kommt nicht aus der Rechnung, sondern aus dem Produkt, und braucht denselben Zeitraum und denselben Umfang wie die Kosten.
Was es für Ihre Kosten bedeutet
Warum hat sich die Linie bewegt? Diese Reihenfolge schließt die billigen Erklärungen zuerst aus:
- Datenstand. Ist der letzte Tag vollständig, ist der Monat noch geschätzt?
- Kalender und Kostenart. Gleich viele Tage oder Tagesdurchschnitte, und auf beiden Seiten dieselbe Kostenart; ein Kauf in berechneten Kosten ist kein Verbrauch (Zeitraumvergleich).
- Währung. Ist es ein Kurseffekt (Multi-Cloud-Reporting in einer Währung)?
- Umfang. Ist ein Konto, eine Subscription oder ein Projekt hinzugekommen, hat sich eine Zuordnungsregel geändert?
- Ort. Gruppieren nach Dienst, dann nach Konto, dann nach Nutzungsart oder SKU. Die Azure-Kostenanalyse gruppiert nach einem Merkmal zur Zeit; Microsoft nennt als Ausweg, erst zu filtern und dann feiner zu gruppieren.
- Menge oder Preis. Je Position zerlegen: Hat sich die Menge bewegt, ist es Verbrauch; hat sich der Preis bewegt, ist ein Commitment ausgelaufen, eine Gutschrift weggefallen oder eine Staffel gewechselt; bleiben beide gleich, ist es Mix oder eine neue Position.
- Geschäftstreiber. Hat sich das Geschäftsvolumen im selben Maß bewegt?
- Owner und Beleg. Die Ursache geht mit Abfrage, Deployment oder Vertragsänderung als Beleg an den Verantwortlichen.
Wer so vorgeht, erklärt eine Veränderung mit Zahlen, die jeder nachrechnen kann, und trennt, was ein Team steuern kann (Menge und Mix), von dem, was Einkauf und Verträge bestimmen (Preis).
Wo es schiefgeht
- Mengen über Einheiten addiert. Symptom: Die Nutzung eines Dienstes steigt um eine Zahl, die nichts bedeutet. Ursache: Stunden und Gigabyte wurden addiert; die Cost-Explorer-API summiert
UsageQuantityohne Rücksicht auf Einheiten, AWS rät, nach Nutzungsart zu filtern. - Abdeckung als Preis gelesen. Symptom: Der Stückpreis von EC2-Stunden fällt im Cost and Usage Report, die Rechnung nicht. Ursache: Durch Reserved Instances abgedeckte EC2- und RDS-Nutzung hat
line_item_unblended_rate0, die Gebühr steht in anderen Zeilen; der Preiseffekt gehört in effektive Kosten. - Stückpreise summiert. Symptom: Ein Durchschnittspreis, der zu keiner Rechnung passt. Ursache: Preise wurden über Zeilen addiert oder gemittelt statt Kosten durch Menge zu teilen.
- Rabatt neben dem Preis. Symptom: Google-Kosten fallen bei gleicher Menge und gleichem
price.effective_price. Ursache: Ressourcenbasierte und ältere ausgabenbasierte Committed Use Discounts stehen als Gutschrift incredits, nicht im Preis. - Wochentag als Trend. Symptom: Jeden Montag wird ein Anstieg gemeldet. Ursache: Lasten laufen an Werktagen; verglichen wurde Montag mit Sonntag statt Woche mit Woche.
- Mix übersehen. Symptom: Menge und Preis je Dienst sind stabil, die Kosten steigen. Ursache: Innerhalb des Dienstes hat sich die Nutzung zu teureren Positionen oder Regionen verschoben, gerechnet wurde nur auf Dienstebene.
Quellen
Gelesen am 2026-10-16. FOCUS 1.4 Pricing Quantity, Consumed Quantity, List Unit Price, Contracted Unit Price, Effective Cost, Resource Usage und Prüfung, Vergleich und Verlauf von Stückpreisen; AWS Was ist Cost Explorer, Cost-Explorer-Diagramm anpassen, GetCostAndUsage und CUR 2.0: Line-Item-Spalten; Microsoft Ansichten in der Kostenanalyse anpassen, Felder der Kostendetails und Schema der FOCUS-Kostendetails; Google Cloud Struktur des Standard-Exports und Cloud-Billing-Berichte.