6 Min. Lesezeit
Ein mittelständischer Maschinenbauer aus Baden-Württemberg, rund 600 Mitarbeitende, senkte seine monatliche Cloud-Rechnung in einem halben Jahr um 38 Prozent. Kein neuer Provider, keine Migration, kein Stellenabbau in der IT. Nur vier Hebel, konsequent gezogen. Dieser Fall ist verdichtet aus mehreren FinOps-Projekten der vergangenen zwei Jahre, die Größenordnungen sind branchentypisch und decken sich mit den Benchmarks der FinOps Foundation.
Das Wichtigste in Kürze
- 38 Prozent in sechs Monaten sind realistisch, nicht spektakulär. Die FinOps Foundation nennt für vollständige Programme 30 bis 50 Prozent Einsparung. Der Fall liegt im unteren Mittelfeld, weil konservativ gerechnet wurde.
- Vier Hebel tragen die Einsparung. Savings Plans, Rightsizing, das Abschalten von Dev- und Test-Umgebungen sowie das Aufräumen verwaister Ressourcen. Keiner davon ist neu.
- Der Hebel ist die Reihenfolge. Ohne saubere Kostentransparenz greift jede Optimierung ins Leere. Die Inventur ist kein Vorgeplänkel, sie ist der erste Schritt.
Verwandt:Die Inferenz-Rechnung, die niemand budgetiert hat / KI-Ausgaben treiben FinOps Teams in neue Budget-Fallen
Der Ausgangspunkt: eine Rechnung, die niemand mehr las
Der Betrieb fertigt Sondermaschinen, betreibt seit etwa fünf Jahren produktiv in der Cloud und hatte zuletzt eine monatliche Rechnung in der Größenordnung von 80.000 Euro. Gewachsen ist die Summe nicht durch eine Fehlentscheidung, sondern durch viele kleine. Ein Workload hier, eine Datenbank dort, eine Test-Umgebung, die nach dem Projekt niemand abschaltete. Die Rechnung kam monatlich, sie wurde bezahlt, sie wurde nicht gelesen.
Das ist der Normalzustand, nicht die Ausnahme. Branchenübergreifend gilt ein erheblicher Teil der Cloud-Ausgaben als Verschwendung auf ungenutzten oder überdimensionierten Ressourcen. Die IT-Abteilung des Maschinenbauers wusste das im Groben, hatte aber kein Mandat und kein Werkzeug, um es zu beziffern. Der erste Schritt war deshalb kein technischer.
Was FinOps in diesem Fall konkret bedeutete
Was ist FinOps? FinOps ist die betriebliche Disziplin, Cloud-Kosten als gemeinsame Verantwortung von Technik, Finanzen und Fachbereich zu steuern. Sie verbindet Kostentransparenz pro Workload mit klaren Entscheidungsregeln, wann eingekauft, verkleinert oder abgeschaltet wird. FinOps ist kein Werkzeug, sondern eine Routine.
Im Maschinenbau-Fall hieß das zunächst: eine Person bekam einen Tag pro Woche freigeräumt und das Mandat, die Cloud-Rechnung pro Kostenstelle und pro Workload aufzuschlüsseln. Kein eigenes Team, keine Zertifizierung, keine Plattform-Beschaffung. Ein Tagungsraum, die Abrechnungsdaten der Provider und ein Tabellenblatt reichten für den Anfang. Nach drei Wochen lag die erste belastbare Zuordnung vor. Sie zeigte, dass knapp ein Drittel der Ausgaben auf Ressourcen entfiel, die entweder zu groß dimensioniert waren oder außerhalb der Geschäftszeiten ungenutzt liefen.
Erst mit dieser Zahl entstand der Druck, der ein FinOps-Programm trägt. Eine abstrakte Aufforderung zum Sparen verpufft. Eine konkrete Zeile, die belegt, dass eine bestimmte Test-Umgebung im Quartal 14.000 Euro kostet und an 19 von 24 Stunden nichts tut, verpufft nicht.
Die vier Hebel, die den Unterschied machten
Die 38 Prozent verteilen sich auf vier Maßnahmen. Die Reihenfolge ist kein Zufall, sie folgt dem Risiko: Was die Architektur am wenigsten anfasst, kam zuerst.
Erstens: Savings Plans und Reserved Instances. Der größte Einzelbeitrag, rund 16 Prozentpunkte. Für stabil laufende Grundlast ist der Einkauf zu On-Demand-Preisen die teuerste Variante. Wer einen Teil der Last für ein bis drei Jahre vorab bindet, zahlt je nach Modell deutlich weniger, in der Spitze über 60 Prozent unter dem On-Demand-Tarif. Der Maschinenbauer band bewusst nur die Grundlast, die er seit Jahren konstant fuhr. Damit blieb das Commitment-Risiko klein.
Zweitens: Rightsizing. Rund 10 Prozentpunkte. Ein großer Teil der Server war auf Verdacht zu groß bestellt worden, oft beim ersten Aufsetzen, als niemand die echte Last kannte. Die Auslastungsdaten der Provider zeigten Instanzen, die monatelang unter 15 Prozent CPU-Last liefen. Verkleinern um ein bis zwei Größenstufen senkte die Kosten, ohne dass die Anwendungen es merkten.
Drittens: Dev- und Test-Umgebungen abschalten. Rund 7 Prozentpunkte. Nicht-produktive Umgebungen müssen nachts und am Wochenende nicht laufen. Ein einfacher Zeitplan, der sie abends herunterfährt und morgens wieder startet, halbiert ihre Laufzeit beinahe. Diese Maßnahme kostet fast nichts und ist trotzdem die, die am häufigsten liegen bleibt, weil sie niemandem gehört.
Viertens: verwaiste Ressourcen aufräumen. Rund 5 Prozentpunkte. Nicht zugeordnete Speichervolumes, alte Snapshots, Datenbanken aus abgeschlossenen Projekten, ungenutzte IP-Adressen. Einzeln sind das kleine Beträge. In Summe war es der Aufwand eines Nachmittags für einen messbaren Effekt.
Sechs Monate, drei Phasen
Der Zeitrahmen war nicht ehrgeizig gesetzt, er ergab sich aus der Reihenfolge. Manche Hebel wirken sofort, andere brauchen Beobachtung, bevor man sie zieht.
Die häufigste Reihenfolge-Fehler in der Praxis: zuerst Savings Plans kaufen, weil der Rabatt verlockt, dann rightsizen. Dann ist die Bindung auf eine Instanzgröße abgeschlossen, die man kurz darauf verkleinert. Das Commitment läuft weiter, der Rabatt zeigt auf eine Last, die es nicht mehr gibt.
Was die Einsparung wieder auffrisst
Eine FinOps-Einsparung ist kein Einmaleffekt, sie ist ein Zustand, der gehalten werden muss. Diese Muster haben in Projekten den Erfolg getragen oder ihn binnen eines Quartals wieder kassiert.
Was die Einsparung kassiert
- Kein fester Verantwortlicher, der die Rechnung weiter monatlich liest
- Neue Workloads ohne Kostenstellen-Zuordnung, die wieder unsichtbar wachsen
- Savings Plans, die nach Ablauf ungeprüft verlängert oder vergessen werden
- Dev-Zeitpläne, die ein einzelner Entwickler dauerhaft aushebelt, weil es bequemer ist
Was den Effekt hält
- Ein monatlicher Kosten-Review als feste, kurze Routine
- Pflicht-Kostenstelle für jede neue Ressource, technisch erzwungen
- Ein Kalendereintrag für jedes auslaufende Commitment
- Eine Kennzahl, die im Management-Report neben Umsatz und Marge steht
Auffällig oft scheitert der zweite Teil, nicht der erste. Die Einsparung zu erzielen ist ein Projekt mit klarem Ende. Sie zu halten ist eine Gewohnheit ohne Ende. Der Maschinenbauer löste das pragmatisch: Die Cloud-Kostenkennzahl steht seitdem im monatlichen Geschäftsführungs-Report. Was dort steht, wird gelesen.
Cloud-Kosten sinken nicht durch ein besseres Werkzeug, sondern durch eine Person mit Mandat und einen Termin im Kalender.
Was sich auf andere Betriebe übertragen lässt
Die 38 Prozent sind kein Versprechen. Ein Betrieb, der bereits diszipliniert einkauft, holt weniger heraus. Einer, der nie hingeschaut hat, oft mehr. Übertragbar ist nicht die Zahl, sondern das Vorgehen.
Der Einstieg kostet keine Plattform und kein Team. Er kostet einen Tag pro Woche einer Person, die rechnen kann und ein Mandat hat. Die Abrechnungsdaten liegen bei jedem Provider bereit, die Auslastungsmetriken ebenfalls. Wer damit anfängt, hat nach drei Wochen eine Zahl. Und eine Zahl ist der Anfang jeder Cloud-Kosten-Diskussion, die nicht im Ungefähren endet.
Häufige Fragen
Sind 38 Prozent Cloud-Einsparung ein realistischer Wert?
Ja, für einen Betrieb, der seine Cloud-Kosten bisher kaum gesteuert hat. Die FinOps Foundation nennt für vollständige FinOps-Programme eine Spanne von 30 bis 50 Prozent. Betriebe, die bereits commit-basiert einkaufen und rightsizen, liegen deutlich darunter. Die Zahl hängt vom Ausgangszustand ab, nicht von der Branche.
Braucht ein Mittelständler ein eigenes FinOps-Team?
Für den Einstieg nicht. Eine Person mit einem freigeräumten Wochentag, einem klaren Mandat und Zugriff auf die Abrechnungsdaten reicht, um die ersten beiden Phasen zu tragen. Ein dediziertes Team lohnt sich erst, wenn die Cloud-Ausgaben so groß sind, dass die laufende Steuerung mehr als einen Tag pro Woche bindet.
Welcher Hebel bringt am schnellsten Geld?
Das Aufräumen verwaister Ressourcen und das Abschalten nicht-produktiver Umgebungen. Beide wirken sofort, brauchen keine Vorlaufzeit und tasten die Produktivumgebung nicht an. Savings Plans bringen den größeren Betrag, sollten aber erst nach dem Rightsizing eingekauft werden.
Was ist das größte Risiko bei Savings Plans?
Ein Commitment auf eine Last, die sich kurz darauf ändert. Wer Savings Plans vor dem Rightsizing kauft, bindet sich an eine zu große Instanzgröße. Der Rabatt läuft dann auf eine Konfiguration, die es nicht mehr gibt. Deshalb gilt: erst verkleinern, dann binden und nur die stabile Grundlast.
Mehr aus dem MBF Media Netzwerk
Bildquelle: KI-generiert (Mai 2026), C2PA-Zertifikat im Bild hinterlegt
