Fragen zu Cloud-Kosten klingen meist einfach.
- Was kostet uns dieser Kunde?
- Wie teuer ist der Betrieb dieses Features?
- Welche Teams oder Produkte treiben die Ausgaben?
In kleinem Maßstab lassen sich diese Fragen mit groben Schätzungen leicht beantworten. Mit wachsenden Systemen werden sie unmerklich zu den schwierigsten Fragen im Unternehmen.
Nicht, weil den Teams die Daten fehlen – sondern weil sich die Funktionsweise moderner Infrastruktur grundlegend verändert hat.
Kosten lassen sich nicht mehr sauber auf Verantwortlichkeiten abbilden
In frühen Phasen deckt sich Kostenverantwortung meist mit klarer Zuständigkeit. Ein Service gehört zu einem Team. Eine Datenbank stützt ein Produkt. Eine Umgebung ist einer Funktion zugeordnet.
Mit wachsender Infrastruktur bricht dieses Denkmodell auseinander.
Heutige Systeme sind:
- stark team- und produktübergreifend geteilt
- auf Plattformschichten aufgebaut, die viele Nutzer bedienen
- zunehmend von Grund auf mandantenfähig
Kosten lassen sich nicht mehr einem einzelnen Verantwortlichen zurechnen. Sie verteilen sich über Nutzungsmuster. An diesem Punkt ist die Frage "Wer ist dafür zuständig?" nicht mehr die richtige.
Geteilte Infrastruktur verschleiert den tatsächlichen Verbrauch
Die wesentlichen Cloud-Kosten stecken in geteilten Schichten:
- Datenpipelines
- Streaming-Plattformen
- Datenbanken
- Netzwerk- und Inter-Service-Traffic
- Plattform-Services, die viele workloads bedienen
Diese Komponenten lassen sich selten 1:1 einem Team, Feature oder Kunden zuordnen.
Stattdessen bündeln sie Nutzung aus dem gesamten Unternehmen – und das oft ungleichmäßig. Einige Teams verbrauchen deutlich mehr als andere, doch dieses Ungleichgewicht bleibt schwer erkennbar.
Das Ergebnis: intransparente Kosten, auch wenn die Gesamtausgaben sichtbar sind.
Warum Unit Economics mit zunehmender Größe verschwimmen
Wenn sich Kosten nicht mehr direkt mit der Nutzung verknüpfen lassen, leiden die Unit Economics darunter.
Teams tun sich schwer damit,
- Margen pro Kunde oder Produkt zu erklären
- zu erkennen, welche Features profitabel sind
- Ausgaben präzise zu prognostizieren
- fundierte Architektur- oder Preisentscheidungen zu treffen
Finance sieht Zahlen, die sich nicht abgleichen lassen. Engineering sieht eine Komplexität, die in den Reports nicht abgebildet ist.
Die Lücke spüren alle.
Das eigentliche Problem ist die Zuordnung – nicht die Sichtbarkeit
Das eigentliche Problem ist nicht die Sichtbarkeit. Es ist das Modell.
Jedes Unternehmen kann seine Cloud-Rechnung einsehen.
Woran es scheitert, ist die Zuordnung zwischen Cloud-Ressourcen und den geschäftlichen Fragen, die Ihnen gestellt werden.
Cloud-Tags sind bei einfachen Zuständigkeiten nützlich. Doch Fragen auf Unit-Ebene sind selten 1:1:
- Ein Kunde nutzt viele Services.
- Ein Service bedient viele Kunden.
- Ein Plattform-Team unterstützt viele Produkte.
- Geteilte Infrastruktur und Netzwerkverkehr lassen sich keinem einzelnen Verantwortlichen zurechnen.
Selbst mit vorbildlicher Tagging-Disziplin können Tags diese m:n-Realität nicht abbilden – und auch nicht die Allokationslogik, die für Fragen wie "Kosten pro Kunde", "Kosten pro Feature" oder "Welches Team subventioniert welches?" nötig ist.
Deshalb verschwimmen Unit Economics mit zunehmender Größe: Die Daten sind vorhanden, aber das Kostenmodell passt nicht dazu, wie das System tatsächlich genutzt wird. Genau deshalb ist unser Ansatz "FinOps ohne Tagging" so anders.
Wie führende Teams anders vorgehen
Teams, die in großem Maßstab arbeiten, denken die Kostenmodellierung neu:
- Bottom-up von der Nutzung her statt Top-down von der Zuständigkeit
- ausgehend von geteilten Systemen statt von isolierten Ressourcen
- auf Basis des tatsächlichen Verbrauchs statt auf Basis von Annahmen
Dieser Perspektivwechsel macht Kosten auf Unit-Ebene wieder erklärbar – auch in komplexen Umgebungen.
Wie das in der Praxis aussieht, zeigt diese Case Study darüber, wie Akamai Kosten auf Unit-Ebene über eine geteilte Infrastruktur hinweg erklärt – ganz ohne Tagging:
Oder Sie sehen direkt, wie sich das auf Ihre Umgebung übertragen lässt, und vereinbaren hier eine Demo.