7 Min. Lesezeit

Ein nordrhein-westfälischer Logistiker hat seine Multi-Cloud-Rechnung um 31 Prozent reduziert. Nicht durch einen neuen Vendor, nicht durch eine Migration, sondern durch drei Quartale FinOps-Disziplin, ein Team mit echter Budget-Verantwortung und eine Tagging-Verfassung, die auf keiner Konferenz Applaus bekäme.

Das Wichtigste in Kürze

• Multi-Cloud zahlt sich nicht von selbst: Wer drei Hyperscaler parallel betreibt, ohne Cost-Allocation auf Workload-Ebene, finanziert vor allem Intransparenz. Verträge, Reserved Instances und Storage-Tiers laufen sonst gegeneinander statt zusammen.
• Cost-Intelligence ist ein Team, kein Tool: Tagging-Strategien scheitern selten an der Software. Sie scheitern daran, dass niemand verbindlich entscheidet, welche Dimension Geld bekommt und welche nicht.
• Logistik macht den Druck früher sichtbar: Saisonale Lastspitzen und niedrige Margen erlauben keinen FinOps-Mittelweg. Was Versender in Wochen lernen müssen, schieben andere Branchen jahrelang vor sich her.

Verwandt:38 Prozent weniger Cloud-Kosten im Maschinenbau  /  FinOps-Studie 2026: Brokerage als Defaultpfad

Wo die Multi-Cloud-Rechnung still explodiert

Der Logistiker, von dem ich hier rede, fährt Workloads auf AWS, Azure und einer kleineren europäischen Plattform für regulierte Lieferantendaten. Drei Verträge, drei Abrechnungsperioden, drei unterschiedliche Tagging-Semantiken. Die Rechnung lag Ende 2024 bei rund 4,2 Millionen Euro pro Jahr, Tendenz steigend, weil mehr Sendungen mehr Telemetrie produzieren.

Das Problem war nicht der Preis einzelner Instances. Das Problem war, dass niemand mit Sicherheit sagen konnte, welche Sparte welchen Anteil verursacht. Reserved Instances liefen aus, ohne dass jemand reagierte. Storage in einer Region wuchs jeden Monat um sechs Prozent, ohne dass jemand fragte, ob die Datenklasse noch stimmt. Ein Team bestellte für ein Migrationsprojekt sechs Wochen lang doppelte Compute-Kapazität, weil die Verantwortung für das Herunterfahren nicht eindeutig war.

Die konkreten Lücken im Ist-Zustand waren beziffert: 27 Prozent der laufenden Compute-Instances hatten kein verwertbares Tag für Kostenstelle oder Produkt. 14 Prozent der Storage-Volumes lagen seit über 90 Tagen ohne Zugriff in der teuersten Klasse. 1,9 Millionen Euro betrug der jährliche Anteil an Egress- und Cross-Region-Kosten, die niemand einer Anwendung zuordnen konnte. Das sind keine Schätzungen, das war die Ausgangslage in den ersten Reports.

Wie das Team Cost-Intelligence ohne neues Tool aufgebaut hat

Die erste Idee im Haus war, ein zusätzliches Tool zu kaufen. Es gibt Anbieter, deren Pitches in diesem Segment sehr gut sind. Das Team hat zwei davon evaluiert und sich am Ende bewusst dagegen entschieden. Nicht weil die Tools schlecht waren, sondern weil sie das Grundproblem nicht lösen: Wer entscheidet im Konzern verbindlich, welche Dimension getaggt wird.

Stattdessen sind sie in drei Schritten vorgegangen. Erstens eine Tagging-Verfassung auf einer Seite: vier Pflicht-Tags (Kostenstelle, Produkt, Umgebung, Owner), plus drei optionale für Compliance-Workloads. Alles andere wurde gelöscht. Wer ein neues Tag erfinden wollte, brauchte die Freigabe der Finance-Liaison. Zwei Seiten Dokument, freigegeben vom CIO, akzeptiert vom Vorstand.

Zweitens das Sammelkonto-Prinzip. Ein Cron-Job markiert seit Quartal 2 alle Ressourcen ohne Pflicht-Tags. Nach sieben Tagen werden deren Kosten auf ein internes Sammelkonto gebucht, das das Plattform-Team verantwortet. Plötzlich hatte das Plattform-Team einen Anreiz, hinter den Sparten herzutelefonieren, statt höflich darum zu bitten. Drittens monatliche Cost-Reviews mit Ownern, nicht mit Tools: jede Sparte sieht in einem einseitigen PDF ihre Kosten der letzten 60 Tage, segmentiert nach Produkt und Region. Kein Dashboard, kein Drill-Down. Bewusst reduziert, weil das Gespräch wichtiger ist als die Visualisierung.

Klingt unspektakulär. Ist es auch. Die Wirkung lag nicht in der Methode, sondern darin, dass die Methode nach fünf Monaten noch existierte.

Was Tagging allein nicht löst

Tagging ist die Eintrittskarte. Es bringt Transparenz in die Bestandsaufnahme, es bringt aber wenig, wenn die Entscheidungen über Commitments und Reservierungen weiter im Einkauf verbleiben, der die Workload nicht kennt. In unserem Beispiel war das die zweite Reformwelle: Reserved Instances und Savings Plans wurden an die Plattform-Owner übertragen, nicht mehr an den zentralen IT-Einkauf. Begründung: Wer das technische Risiko trägt, soll auch das kommerzielle Risiko bewerten dürfen.

Das hat zwei Effekte. Erstens entstand zum ersten Mal eine ehrliche Diskussion darüber, welche Workloads tatsächlich planbar sind und welche nicht. Zweitens fielen Reserved Instances weg, die ein früherer Einkäufer aus Konformitätsgründen verlängert hatte, obwohl die Sparte das Produkt eingestellt hatte.

Das war einer dieser stillen Wins, die in keiner Pressemitteilung auftauchen. Eingesparte Summe: rund 380.000 Euro pro Jahr. Keine neue Technologie, kein Architektur-Wechsel. Nur jemand, der endlich die Verantwortung trug.

Die drei Trade-offs, die niemand offen anspricht

Multi-Cloud-FinOps wird in vielen Decks als Effizienz-Programm verkauft. In Wahrheit ist es eine Folge von Trade-offs, die ein Konzern bewusst eingeht. Standardisierung gegen Geschwindigkeit ist der erste: Wer Tagging-Verfassung und Commit-Steuerung zentral durchzieht, verlangsamt einzelne Teams. Wer Geschwindigkeit will, akzeptiert Streuverluste. Es gibt keinen Mittelweg, der beides liefert. Wer ihn verspricht, hat ihn noch nie betreut.

Der zweite Trade-off ist Tool-Coverage gegen Eigenverantwortung. Spezialisierte FinOps-Tools entlasten das Team, aber sie verlagern Wissen ins Werkzeug statt in die Köpfe. Wenn der Vertrag mit dem Tool-Anbieter endet, ist Cost-Intelligence sehr schnell wieder weg. Der dritte: Reserved-Commit gegen Flexibilität. Ein dreijähriger Savings Plan spart Geld, fesselt das Unternehmen aber an eine Architektur-Annahme, die in drei Jahren falsch sein kann. Wer Reservierungen aggressiv fährt, sollte ehrlich kalkulieren, was eine vorzeitige Auflösung kostet.

Diese Trade-offs lassen sich nicht weg-automatisieren. Eine FinOps-Praxis, die sie ehrlich benennt, ist deutlich belastbarer als eine, die alle drei gleichzeitig versprechen will.

Was bleibt, wenn der Hype vorbei ist

FinOps ist seit zwei Jahren das Modethema in jeder Cloud-Konferenz. Vieles davon ist berechtigt, einiges überzeichnet. Was am Beispiel des Logistikers stehen bleibt, ist überraschend wenig methodisch und überraschend viel organisatorisch. Eine Tagging-Verfassung, die nicht ausgehöhlt wurde. Ein Plattform-Team, das Owner für untaggierte Ressourcen wurde. Owner-Verantwortung für Commitments. Monatliche Reviews mit Menschen, nicht mit Dashboards.

Das Ergebnis nach drei Quartalen: 31 Prozent geringere Multi-Cloud-Kosten, eine bessere Vorhersagegüte im Forecast und eine spürbar nüchternere Diskussion über neue Cloud-Initiativen. Wenn jemand jetzt ein Projekt vorschlägt, muss er die Frage beantworten, wer den Reserved-Commit trägt, falls die Annahme nicht hält. Diese Frage gab es vorher nicht.

Wer auf eine Silver-Bullet hofft, wird sie hier nicht finden. Wer akzeptiert, dass Cost-Intelligence vor allem eine Frage von Verantwortung ist, hat einen realistischen Pfad.

Häufige Fragen

Wann lohnt sich ein dediziertes FinOps-Tool gegenüber Bordmitteln?

Sobald drei Bedingungen zusammenkommen: mehr als zwei Hyperscaler, mehr als 50 verantwortliche Owner und ein Cloud-Budget jenseits von rund fünf Millionen Euro jährlich. Darunter ist die Eigenlösung mit den nativen Cost-Explorern und einer disziplinierten Tagging-Verfassung in der Regel günstiger und nachhaltiger.

Wie schnell zeigt eine Tagging-Verfassung Effekt?

Die ersten messbaren Einsparungen sieht man nach acht bis zwölf Wochen, weil das Sammelkonto-Modell die Plattform-Owner zwingt, untaggierte Ressourcen schnell zuzuordnen. Strukturelle Effekte über Reserved Instances und Storage-Klassen kommen erst nach zwei bis drei Quartalen.

Wer sollte die Owner-Verantwortung für Reserved Instances tragen?

Die Plattform- oder Produktverantwortlichen, die die Workload technisch kennen. Ein zentraler IT-Einkauf ohne Workload-Kontext fährt Commitments häufig defensiv und verlängert Verträge mit nicht mehr betriebenen Sparten. Das ist der teuerste Fehler in der Praxis.

Wie viele Pflicht-Tags sind sinnvoll?

Vier bis fünf Pflicht-Tags reichen für die meisten Konzerne. Mehr führt zu Lücken, weil niemand alle Felder konsequent pflegt. Sinnvoll sind in der Regel Kostenstelle, Produkt, Umgebung und Owner, plus eines für Compliance-Klasse, wenn regulierte Workloads dabei sind.

Was passiert mit Egress- und Cross-Region-Kosten?

Egress ist die unbequemste Position, weil sie meist zwei Eigentümer hat: das aussendende und das empfangende System. Die Praxis-Lösung ist, Egress dem aussendenden Workload zuzuschlagen und in den Monats-Reviews explizit als eigene Zeile zu führen. Sonst verschwindet er als unsichtbarer Posten im Gesamtbudget.

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt