Die Cloud-Rechnung ist keine Rechnung im gewohnten Sinn. Sie ist ein Auszug aus einem Zähler — hunderte Positionen mit technischen Bezeichnungen, sortiert nach Dienst statt nach Zweck. Wer wissen will, was ein bestimmtes Projekt gekostet hat, findet die Antwort dort nicht.
Das ist kein Mangel des Anbieters. Die Abrechnung bildet ab, was verbraucht wurde, und der Anbieter weiß nicht, wofür. Diese Zuordnung muss aus dem Unternehmen kommen — und zwar bevor die Kosten entstehen, nicht danach.
Cloud-Ausgaben werden nicht durch bessere Auswertungen sichtbar, sondern durch Zuordnung an der Quelle. Fünf Datenquellen müssen zusammenkommen: die Abrechnung des Anbieters, die Ressourcen-Tags, die Vertrags- und Lizenzdaten, das Kontokorrent und die Zuständigkeiten aus dem eigenen Haus. Tags sind dabei der Hebel mit der größten Wirkung — sie kosten beim Anlegen nichts und lassen sich nachträglich nur mit erheblichem Aufwand rekonstruieren.
„Tags beschreiben nicht nur Ressourcen, sondern aktivieren das Governance-Modell, das Kostentransparenz in Kostenkontrolle umwandelt.”
itsValue zum Zusammenhang von Tagging und Kostensteuerung
Der Satz trifft den Kern: Transparenz und Kontrolle sind zwei verschiedene Dinge. Eine Auswertung, die zeigt, dass 40 Prozent der Kosten auf „Compute” entfallen, ist transparent und trotzdem wertlos — sie beantwortet keine Frage, die jemand stellt.
Die fünf Datenquellen
| Quelle | Was sie liefert | Was ohne sie fehlt |
|---|---|---|
| Abrechnung des Anbieters | Verbrauch je Dienst und Ressource | nichts — sie ist die Basis |
| Ressourcen-Tags | Projekt, Kostenstelle, Besitzer | jede Zuordnung zu Zweck und Verantwortung |
| Verträge und Lizenzen | Laufzeiten, Fristen, Reservierungen | der planbare Teil der Kosten |
| Kontobewegungen | was tatsächlich abgeflossen ist | alles außerhalb der Cloud-Rechnung |
| Zuständigkeiten | wer entscheidet, wer bezahlt | die Möglichkeit, etwas zu ändern |
Die ersten beiden liefert die Cloud-Plattform selbst. Die dritte und vierte liegen außerhalb — in Vertragsordnern und im Onlinebanking. Die fünfte steht nirgends und ist trotzdem die wichtigste.
Tags: der Hebel, den man nur einmal richtig setzt
Ein Tag ist ein Schlüssel-Wert-Paar an einer Ressource: projekt = erp-migration, kostenstelle = 4200, besitzer = m.schmidt. Alle großen Anbieter unterstützen das, und die Abrechnung lässt sich anschließend danach aufschlüsseln.
Der Haken ist die Reihenfolge. Tags wirken ab dem Moment, in dem sie gesetzt werden — rückwirkend lassen sich Kosten nicht neu zuordnen. Wer nach einem Jahr Betrieb anfängt zu taggen, hat ein Jahr ohne Zuordnung, und das bleibt so. Deshalb ist eine Tagging-Regel, die von Anfang an gilt, mehr wert als jedes Auswertungswerkzeug, das man später kauft.
Drei Tags genügen für den Anfang: Projekt oder Anwendung, verantwortliche Person, Ablaufdatum. Mehr wird in der Praxis nicht gepflegt, und ungepflegte Tags sind schlimmer als keine — sie erzeugen den Eindruck von Zuordnung, wo keine ist.
Budgets und Anomalie-Erkennung
Alle großen Plattformen bieten inzwischen Budgets mit Schwellenwert-Meldungen sowie eine automatische Erkennung ungewöhnlicher Kostenverläufe. Beides ist nützlich, aber beides setzt voraus, dass jemand die Meldung bekommt und einordnen kann.
Ein Budgetalarm, der an eine Sammeladresse geht, wird nach der zweiten Auslösung ignoriert. Einer, der an die im Tag hinterlegte verantwortliche Person geht, führt zu einer Reaktion. Der Unterschied liegt wieder nicht in der Technik, sondern in der Zuordnung.
Sinnvoll ist außerdem, den Schwellenwert nicht auf den Monatsbetrag zu setzen, sondern auf die Veränderung. Ein Budget von 2.000 € meldet erst, wenn es fast verbraucht ist — dann ist der Monat gelaufen. Eine Meldung bei plus 20 Prozent gegenüber dem Vormonat kommt früh genug, um noch etwas zu tun.
Warum die Standardauswertung die falsche Frage beantwortet
Jede Cloud-Konsole liefert von Haus aus eine Aufschlüsselung nach Diensten: so viel für virtuelle Maschinen, so viel für Speicher, so viel für Datenbanken. Diese Ansicht ist technisch korrekt und praktisch unbrauchbar, weil niemand in diesen Kategorien denkt.
Die Fragen, die im Unternehmen tatsächlich gestellt werden, lauten anders: Was kostet uns der Webshop? Was hat das ERP-Projekt verbraucht? Warum ist die Rechnung diesen Monat um 400 € höher? Keine davon lässt sich mit einer Dienst-Aufschlüsselung beantworten — sie alle brauchen eine Zuordnung nach Zweck.
Der Unterschied lässt sich an einem Beispiel zeigen. Eine Rechnung über 2.400 € könnte so aussehen:
| Nach Dienst (Standard) | Betrag | Nach Zweck (mit Tags) | Betrag |
|---|---|---|---|
| Virtuelle Maschinen | 1.150 € | Warenwirtschaft | 980 € |
| Speicher | 610 € | Webshop | 740 € |
| Datenbanken | 430 € | Testumgebungen | 390 € |
| Datenverkehr | 210 € | Altsystem Archiv | 290 € |
Die linke Spalte löst keine Handlung aus. Die rechte schon: „390 € für Testumgebungen” führt sofort zur Frage, ob die nachts laufen müssen, und „290 € für ein Archiv” zu der, ob es das noch braucht. Beide Fragen sind in fünf Minuten beantwortet — aber nur, wenn die Zahlen so dastehen.
Multi-Cloud macht es nicht komplizierter, sondern nur mehrfach
Wer mehr als einen Anbieter nutzt, hat dasselbe Problem zweimal — mit unterschiedlichen Bezeichnungen für dieselben Dinge. Microsoft bietet für den plattformübergreifenden Blick eine Kostenanalyse an, die auch Ausgaben anderer Anbieter einbeziehen kann; vergleichbare Ansätze gibt es bei den übrigen Plattformen.
Für mittelständische Umgebungen lohnt der Aufwand einer solchen Zusammenführung selten. Zwei getrennte Auswertungen, die monatlich in dieselbe Übersicht getippt werden, liefern dieselbe Erkenntnis mit einem Bruchteil des Aufwands. Der Punkt ist nicht, alles in einem Werkzeug zu haben — sondern alles in einer Zahl.
Was außerhalb der Cloud-Rechnung liegt
Der blinde Fleck jeder Cloud-Kostenanalyse sind die Posten, die nicht beim Cloud-Anbieter anfallen: die Software, die auf den Servern läuft, das Monitoring-Werkzeug eines Drittanbieters, das Backup in einer anderen Umgebung, der Dienstleister, der die Umgebung betreut.
Diese Posten erscheinen auf Rechnungen und Lastschriften, nicht in der Cloud-Konsole. Wer die Frage beantworten will, was der Betrieb einer Anwendung insgesamt kostet, muss beide Seiten zusammenbringen — und das ist die Stelle, an der die meisten Auswertungen aufhören.
Sichtbar in der Cloud-Konsole
- + Rechenleistung, Speicher, Datenverkehr
- + Plattformdienste und Datenbanken
- + Reservierungen und Sparpläne
- + Betriebssystem-Lizenzen im Stundenpreis
Nur auf Rechnungen sichtbar
- − Anwendungs- und Datenbanklizenzen Dritter
- − Monitoring, Backup, Sicherheitswerkzeuge
- − Betreuung durch einen Dienstleister
- − SaaS-Abos, die dieselbe Aufgabe erfüllen
Für diese zweite Spalte gibt es keine Konsole. Sie steht in Verträgen, Lastschriften und Kreditkartenabrechnungen — verteilt über Systeme, die miteinander nichts zu tun haben. Werkzeuge, die Verträge, Lizenzen und Kontobewegungen in einer Ansicht zusammenführen, setzen genau dort an, wo die Cloud-Auswertung endet.
Ein pragmatischer Aufbau in vier Schritten
- Tagging-Regel festlegen Drei Pflicht-Tags, schriftlich, eine halbe Seite. Ab sofort für jede neue Ressource.
- Bestand nachziehen Vorhandene Ressourcen einmalig taggen — das ist Fleißarbeit und dauert je nach Größe wenige Stunden.
- Budget je Projekt Nicht ein Gesamtbudget, sondern eines je Tag-Wert. Meldung an die im Tag hinterlegte Person.
- Monatliche Zusammenführung Cloud-Auswertung plus die Posten von außerhalb, in einer Übersicht. Fünfzehn Minuten.
Der vierte Schritt ist der, der am häufigsten wegfällt — und der einzige, der die Frage beantwortet, die die Geschäftsführung tatsächlich stellt.
Was der Aufbau nicht leistet
Sichtbarkeit senkt keine Kosten. Sie zeigt nur, wo sie entstehen — die Entscheidung, etwas abzuschalten, zu verkleinern oder zu kündigen, bleibt eine menschliche. In der Praxis scheitert der Schritt von der Erkenntnis zur Handlung meist an einem von zwei Punkten: Entweder ist unklar, wer entscheiden darf, oder niemand traut sich, weil der Zweck der Ressource nicht mehr rekonstruierbar ist.
Beides ist ein Zuordnungsproblem, kein Werkzeugproblem. Ein Ablaufdatum im Tag löst den zweiten Fall vollständig: Was ein Enddatum hat, wird ohne Diskussion abgeschaltet. Für den ersten Fall genügt eine Regel, die einmal schriftlich festgehalten wird — etwa dass die im Tag genannte Person bis zu einem festgelegten Monatsbetrag allein entscheidet und darüber die Geschäftsführung.
Mit diesen beiden Festlegungen wird aus der Auswertung ein Prozess. Ohne sie bleibt sie ein Bericht, den man einmal im Quartal ansieht und dann wieder schließt.
Häufige Fragen
Was sind Cost Allocation Tags?
Schlüssel-Wert-Paare, die an Cloud-Ressourcen gesetzt werden und in der Abrechnung als Auswertungsdimension erscheinen — etwa Projekt, Kostenstelle oder verantwortliche Person. Sie sind der einzige Weg, Cloud-Kosten einem Zweck zuzuordnen, weil der Anbieter selbst nur weiß, was verbraucht wurde, nicht wofür.
Kann man Kosten nachträglich zuordnen?
Nur sehr eingeschränkt. Tags wirken ab dem Zeitpunkt, an dem sie gesetzt werden; für zurückliegende Abrechnungszeiträume lässt sich die Zuordnung nicht rekonstruieren. Deshalb ist eine Tagging-Regel vom ersten Tag an mehr wert als jedes Auswertungswerkzeug, das später hinzukommt.
Wie viele Tags sind sinnvoll?
Drei als Pflicht: Projekt oder Anwendung, verantwortliche Person, Ablaufdatum. Umfangreichere Schemata werden in der Praxis nicht gepflegt, und halb gepflegte Tags sind schädlicher als gar keine — sie erzeugen den Eindruck einer Zuordnung, die es nicht gibt.
Wo sollte der Budgetalarm ausgelöst werden?
Nicht beim Erreichen des Monatsbudgets, sondern bei einer auffälligen Veränderung gegenüber dem Vormonat — etwa plus 20 Prozent. Ein Alarm beim fast verbrauchten Budget kommt zu spät, um im laufenden Monat noch zu reagieren. Empfänger sollte die im Tag hinterlegte Person sein, keine Sammeladresse.
Braucht der Mittelstand ein Multi-Cloud-Kostenwerkzeug?
Meist nicht. Zwei getrennte Auswertungen, die monatlich in dieselbe Übersicht übertragen werden, liefern dieselbe Erkenntnis mit deutlich weniger Aufwand als eine technische Zusammenführung. Entscheidend ist, dass am Ende eine Zahl steht — nicht, dass sie aus einem einzigen Werkzeug kommt.
