FinOps: 30 Prozent Cloud-Kosten realistisch senken
Multi-Cloud-Kosten senken beginnt mit Sichtbarkeit: Tagging, Showback und die Hebel, mit denen 30 Prozent Einsparung realistisch werden.
Am Monatsende kommt die Cloud-Rechnung, sie liegt spürbar über dem Vormonat und niemand in der Runde kann auf Anhieb sagen, welcher Workload den Ausschlag verursacht hat. Diese Szene wiederholt sich gerade in vielen IT-Abteilungen, die parallel auf AWS, Azure und Google Cloud fahren. Das Geld ist ausgegeben, die Zuordnung fehlt. Wer FinOps ernst nimmt, dreht die Reihenfolge um: erst Sichtbarkeit, dann Sparen. Genau dann wird aus dem Marketing-Versprechen von 30 Prozent Einsparung ein belastbares Audit-Ergebnis.
Das Wichtigste in Kürze
- Sichtbarkeit kommt vor Sparmaßnahme: Ohne durchgängiges Tagging und EUR-Showback über alle drei Clouds optimieren Teams ins Blaue und zahlen im falschen Mandanten weiter.
- 30 Prozent sind realistisch, aber kein Automatismus: Der Wert gilt dort, wo Basis-Disziplin fehlt, also bei ungetaggtem, überdimensioniertem Spend ohne Commitments und ohne Storage-Tiering.
- Guardrails sichern den Erfolg: Budget-Limits, Anomalie-Alerts und feste Showback-Rituale verhindern, dass die Einsparung im nächsten Sprint wieder verpufft.
Verwandt:FinOps sieht alles, darf aber nichts / KI-Souveränität beginnt bei der Infrastruktur
Kosten sichtbar machen: Tagging, Showback und die EUR-Frage über drei Clouds
Die meisten Multi-Cloud-Rechnungen sind nicht zu hoch, weil die Preise zu hoch wären. Sie sind zu hoch, weil niemand sie liest. AWS Cost Explorer, Azure Cost Management und das Billing der Google Cloud liefern jeweils ihre eigene Sicht, in eigener Logik, oft in einer Fremdwährung. Wer diese drei Welten nicht zu einer konsolidierten Sicht zusammenführt, sieht nur Summen, keine Ursachen.
Der erste Hebel heißt deshalb nicht Rabatt, sondern Tagging. Jeder Workload braucht eine Kostenstelle, ein Team und einen Zweck als Tag. Erst dann lässt sich Showback betreiben, also jedem Bereich seine tatsächlichen Verbräuche zeigen. In der Praxis scheitert das selten an der Technik und fast immer an der Disziplin: Ein einziges ungetaggtes Projekt-Konto reicht, um den Blindflug fortzusetzen. Branchenerhebungen sehen regelmäßig rund ein Viertel bis ein Drittel des Cloud-Spends als vermeidbare Verschwendung, der größte Teil davon ist schlicht nicht zugeordnet.
In der DACH-Region kommt eine Frage hinzu, die in US-Ratgebern fehlt: die Währung. Die Rechnung kommt häufig in Fremdwährung, das interne Budget steht in Euro. Wer FX-Schwankungen nicht in die Planung einrechnet, vergleicht jeden Monat Äpfel mit Birnen. Dazu kommen Datenresidenz und EU-Regionen, die bewusst teurer sein dürfen, weil ein Datenschutz-konformes Setup eben einen Aufschlag hat. Dieser Aufschlag gehört budgetiert und ausgewiesen. Er ist Teil der Rechnung und kein Sparziel.
Die großen Hebel: wo die 30 Prozent wirklich liegen
Diese Verschwendung ist zugleich das Sparpotenzial. Wenn die Kosten sichtbar sind, beginnt die eigentliche Arbeit. Sie folgt einer festen Reihenfolge. Den größten Einzelhebel liefert Rightsizing samt Abschalten ungenutzter Ressourcen: Instanzen, die nachts und am Wochenende laufen, ohne dass jemand sie braucht, kosten in Summe 15 bis 25 Prozent des Compute-Budgets. Das gelingt nicht mit einmaligem Kleinerskalieren, es braucht zwei bis vier Wochen echter Nutzungsdaten.
Der zweite Block sind Commitments. Reserved Instances, Savings Plans, Azure Reservations und die Committed Use Discounts der Google Cloud senken den Preis stabiler Lasten um 20 bis 40 Prozent. Die Betonung liegt auf stabil: Wer vorhersehbare Workloads über zwölf Monate kennt, spart deutlich. Wer auf Verdacht kauft, zahlt am Ende mehr als On-Demand. Für fehlertolerante Jobs, also Batch, CI/CD oder Dev- und Test-Umgebungen, kommt Spot- beziehungsweise Preemptible-Kapazität dazu und drückt die Kosten dieser Jobs um 50 bis 70 Prozent.
Der dritte Block wird fast immer unterschätzt: Storage und Datentransfer. Lifecycle-Regeln, die kalte Daten automatisch in günstigere Klassen verschieben, etwa nach Glacier, in Azure Archive oder GCP Coldline, sparen 30 bis 60 Prozent auf der Storage-Zeile. Und der Egress-Verkehr ist der klassische Multi-Cloud-Killer: Daten ohne Business Case zwischen AWS, Azure und Google Cloud zu replizieren, treibt je nach Architektur die Gesamtrechnung deutlich nach oben, bei datenlastigen Aufbauten um bis zu ein Viertel. Diese Prozentwerte gelten je Kostenzeile, nicht aufaddiert. Wer den typischen Spend-Mix aus ungenutztem Compute, teurem Storage und vermeidbarem Egress zusammenrechnet, landet in Summe bei rund 30 Prozent, sofern bisher kaum optimiert wurde. Eine Garantie für jede Reifegrad-Stufe ist das nicht. Genau so gehört es dem Vorstand präsentiert.
Budget Controls einziehen: Guardrails, Alerts und Eskalation vor dem Monatsende
Einsparungen, die nicht abgesichert sind, halten genau einen Sprint. Ein häufiger Fehler in FinOps-Projekten ist, das Optimieren als Einmalaktion zu behandeln. Deshalb gehört am Ende der Kette die Governance: Budgets mit harten und weichen Grenzen, Policies gegen ungetaggte Ressourcen und Anomalie-Alerts, die die Abweichung melden, bevor die Rechnung kommt.
Genauso wichtig wie die Technik sind die Rituale. Ein monatlicher Showback-Termin, in dem jeder Bereich seine eigenen Zahlen sieht, verändert das Verhalten spürbar, oft mehr als jede technische Maßnahme. Wer einmal erklären musste, warum ein Test-Cluster drei Wochen lang lief, taggt beim nächsten Mal sauber. FinOps entscheidet sich an Daten und Verbindlichkeit, weniger am Werkzeug. Das Tool zeigt die Kosten. Ob daraus Marge wird, entscheidet die Organisation.
Häufige Fragen
Sind 30 Prozent Einsparung bei Multi-Cloud realistisch?
Ja, aber nicht überall. Der Wert gilt dort, wo Basis-Disziplin fehlt: ungetaggter Spend, überdimensionierte Instanzen, keine Commitments und kein Storage-Tiering. Wer schon optimiert hat, holt weniger heraus. Seriös ist die Aussage nur mit Spend-Baseline und Reifegrad-Einordnung.
Womit fängt ein FinOps-Projekt an?
Mit Sichtbarkeit, lange bevor es um Rabatte geht. Erst durchgängiges Tagging und eine konsolidierte Sicht über AWS, Azure und Google Cloud, dann Showback je Bereich. Ohne diese Grundlage optimiert das Team auf gut Glück und spart an der falschen Stelle.
Welcher Hebel bringt am meisten?
In den meisten Umgebungen Rightsizing samt Abschalten ungenutzter Ressourcen, mit 15 bis 25 Prozent des Compute-Budgets. Commitments und Spot-Kapazität liefern auf den passenden Workloads noch höhere Prozentwerte, gelten aber nur für stabile oder fehlertolerante Lasten.
Was ist beim Datentransfer in Multi-Cloud zu beachten?
Egress zwischen den Hyperscalern ist teuer und oft unnötig. Daten ohne klaren Business Case zwischen AWS, Azure und Google Cloud zu replizieren, kann die Gesamtrechnung bei datenlastigen Architekturen um bis zu ein Viertel erhöhen. Architektur und Datenflüsse gehören vor die Rabattjagd.
Welche DACH-spezifischen Faktoren spielen eine Rolle?
Vor allem die Währung und die Datenresidenz. Cloud-Rechnungen kommen oft in Fremdwährung, das Budget steht in Euro und Wechselkurs-Schwankungen gehören in die Planung. EU-Regionen und datenschutzkonforme Setups dürfen teurer sein. Dieser Aufschlag wird budgetiert und ausgewiesen, denn er gehört fest zur Rechnung.
Bildquelle: KI-generiert (Juli 2026)
