"Es wird günstiger sein als das Rechenzentrum. Sie zahlen nur für das, was Sie nutzen. Sie werden sich vom Over-Provisioning verabschieden."

Wie oft haben Sie diese Versprechen gehört? Und wie oft haben Sie sich dabei ertappt, wie Sie Monat für Monat steigende Rechnungen Ihres Cloud-Providers (oder Ihrer Cloud-Provider) betrachtet haben, ohne wirklich zu verstehen, warum?

Im Jahr 2025 ist die Migration in die Cloud keine strategische Entscheidung mehr, sondern eine Voraussetzung, um wettbewerbsfähig zu bleiben. Doch für viele Unternehmen hat Cloud Computing seine grundlegenden Versprechen nicht erfüllt. Statt der erhofften wirtschaftlichen Effizienz sehen sie sich mit Folgendem konfrontiert:

• Unvorhersehbare Kosten mit Schwankungen von 30–40 % von einem Monat zum nächsten
• Unklare Rechnungen, bei denen kaum jemand erklären kann, warum eine bestimmte Ressource pro Monat so viel kostet
• Over-Provisioning, das in manchen Fällen sogar schlimmer ist als im Rechenzentrum (aber zumindest wusste man dort, wie viel verschwendet wurde)
• Konflikte zwischen Finance- und IT-Teams, die sich gegenseitig die Schuld geben, während die Kosten weiter steigen

FinOps ist nicht nur das nächste Buzzword, zu dem man Stellung beziehen muss, sondern der jüngste Versuch, das ursprüngliche Versprechen der Cloud zu retten. Doch es funktioniert nur, wenn man bereit ist, der Realität ins Auge zu sehen.

1. Kostenmanagement ist ein Finance-Problem

Der erste fatale Fehler, den viele Unternehmen machen, besteht darin anzunehmen, dass Cloud-Kostenmanagement ein finanzielles Problem sei. Das ist es nicht. Es ist ein Architekturproblem, das als Budgetproblem getarnt ist. Das ist keine Meinung, sondern eine Tatsache, die durch die Erfahrung derjenigen gestützt wird, die Hunderte von Rechnungen der grössten Cloud-Provider optimiert haben.

Warum geraten so viele Unternehmen in dieses Missverständnis? Finance betrachtet die Rechnung und sieht Zahlen. Technische Teams betrachten die Architektur und sehen Entscheidungen. Cloud-Kosten sind die Folge architektonischer Entscheidungen: Welche Instanz wird gewählt, wie werden Daten strukturiert, wann und wie wird skaliert, wie wird der Datenverkehr verwaltet?

Das Finance-Team kann die Rechnung erhalten und lesen, aber es kann keine Lambda-Architektur verändern, die pro Request 100 MB Logs erzeugt.

Warum also weiterhin vom CFO verlangen, Probleme zu lösen, die nur der CTO angehen kann?

Die Lösung ist brutal einfach und liegt in einer klaren Zuweisung der Verantwortlichkeiten und einem kontinuierlichen Austausch:

• Die Verantwortung für die Kosten dem Engineering-Team zuweisen, unterstützt durch Finance
• Finance sollte sich auf Verträge, Unit Economics und Forecasting konzentrieren
• Engineering sollte sich auf Architektur und Optimierung konzentrieren

2. Kostenoptimierung und Kostenmanagement sind dasselbe

Hören Sie auf, Kostenoptimierung mit Kostenmanagement zu verwechseln: Das ist so, als würde man eine ausgewogene, gut geplante Ernährung mit dem Auslassen einer Mahlzeit verwechseln, nur um sich kurzfristig besser zu fühlen. Die meisten Unternehmen betreiben ausschliesslich Kostenmanagement, obwohl sie dieses durch eine tiefgreifende Kostenoptimierung ergänzen sollten.

Kostenmanagement ist der erste Schritt: zu verstehen, wo, von wem und wie Geld ausgegeben wird:

• Tagging von Ressourcen
• monatliche Kosten-Dashboards
• Alerts bei Budgetüberschreitungen

Kostenoptimierung ist der nächste Schritt und kann bis zu einer grundlegenden Überarbeitung der architektonischen Entscheidungen reichen:

• Neugestaltung von Infrastruktur und Anwendungen
• Umstieg auf Serverless-Services
• Right-Sizing

Echtes FinOps integriert beide Ansätze, legt den Schwerpunkt jedoch auf die Optimierung. Es geht nicht darum, wie viel ausgegeben wird, sondern darum, wie viel Wert aus diesen Ausgaben entsteht.

3. Organisatorische Silos kosten Geld

"When organizations don't communicate across teams, share their business context, and work toward common goals, their cloud bill shows it." (FinOps Foundation)

Ein typisches Szenario, das Ihnen wahrscheinlich bekannt vorkommt:

• Der CFO möchte Transparenz und maximale Kostenvorhersehbarkeit
• Der CTO möchte Autonomie und hohe Entwicklungsgeschwindigkeit
• Das Produktteam wollte die neuen Features am liebsten schon gestern
• Der Verwaltungsrat möchte alles möglichst kostenlos

Die Konsequenz? Jedes Team optimiert Kosten und Aktivitäten für seine eigenen Ziele und ignoriert dabei die Auswirkungen auf den Rest der Organisation. Finance kürzt das Budget, ohne die technischen Konsequenzen vollständig zu verstehen. Engineering trifft architektonische Entscheidungen, ohne deren wirtschaftliche Auswirkungen zu berücksichtigen. Das Ergebnis ist eine Cloud-Rechnung, die die Geschichte eines Unternehmens erzählt, das nicht weiss, wohin es geht.

Die (nicht ganz) magische Formel, um der Silo-Hölle zu entkommen:

1. Eine gemeinsame Sprache zwischen Finance und Engineering schaffen
2. Gemeinsame Ziele definieren, die die verschiedenen Unternehmensfunktionen aufeinander abstimmen
3. Regelmässige Kommunikationsprozesse einführen (nicht nur dann, wenn die Rechnung explodiert!)
4. Bei jeder architektonischen Entscheidung müssen die erwarteten und tatsächlichen wirtschaftlichen Auswirkungen berücksichtigt werden

4. Interne Policies sind voller Lücken

Fast jedes Unternehmen verfügt über detaillierte Richtlinien für den Kauf eines Hefters, erlaubt Entwicklern aber gleichzeitig, GPU-Instanzen ohne jegliche Kostenkontrolle zu starten. Das ist das Paradox von Unternehmensrichtlinien im Cloud-Zeitalter.

Das Problem besteht darin, dass Cloud IaaS und SaaS noch immer mit der Denkweise und dem Ansatz eines Rechenzentrums verwaltet werden. Im Rechenzentrum war der Preis eines Servers nach dem Kauf bekannt. In der Cloud hingegen hat jeder API Call, jedes übertragene Byte und jede Mikrosekunde Compute einen Preis.

Die Lösung besteht darin, den FinOps-Ansatz in bestehende Policies zu integrieren. Aber wie?

• Procurement und Software Asset Management einbeziehen in die Cloud Governance
• Genehmigungsprozesse einführen für Ausgaben von Ressourcen, die definierte finanzielle Schwellenwerte überschreiten
• Automatische Alerts implementieren für ungewöhnliche Ausgaben
• Jedes technische Team für die von ihm verursachten Kosten verantwortlich machen

Es geht nicht darum, Innovation durch Bürokratie zu bremsen, sondern die wirtschaftlichen Konsequenzen technischer Entscheidungen sichtbar zu machen.

5. Das Gegenmittel ist Peer Review

Wie oft hat uns ein Code Review schon vor katastrophalen Bugs bewahrt, die sonst in Produktion gelangt wären? Dasselbe Prinzip gilt auch für Kostenentscheidungen. Ein gutes Peer Review sorgt für mehr Sicherheit und verhindert kostspielige Fehler.

Bevor man sich entscheidet, Folgendes zu implementieren:

• eine neue Microservices-Architektur
• eine NoSQL-Datenbank
• eine ML-Pipeline, die Terabytes an Daten verarbeitet

lohnt es sich immer, jemanden mit nicht technischem Hintergrund zu fragen: "Was denkst du, wie viel uns das kosten wird?".

Das ist keine Bürokratie, sondern verantwortungsbewusstes Engineering.

Ein strukturierter Peer-Review-Prozess für Kosten:

• Verhindert Tunnelblick, bei dem günstigere Alternativen ignoriert werden
• Teilt Wissen über Best Practices zur Kostenoptimierung
• Schafft Accountability bei architektonischen Entscheidungen
• Reduziert drastisch unangenehme Überraschungen auf der Rechnung

6. Die IT weiss alles

Technische Teams sind eine Goldgrube an Fachwissen. Oft wissen sie bereits, warum diese Lambda-Funktion so viel kostet, welcher Service Bandbreite verschwendet und wo Over-Provisioning stattfindet.

Doch wann wurden sie zuletzt in eine Diskussion über Kosten einbezogen? Wie oft wurden sie bei der Entscheidung einbezogen, ob in ein Refactoring-Projekt investiert werden sollte?

So lässt sich der Beitrag der IT in diesem Kontext optimieren:

• Technische Teams konsultieren, BEVOR wesentliche Änderungen am Cloud-Budget vorgenommen werden
• Technische Teams aktiv einbeziehen bei der Definition von Kostenmetriken und KPIs
• Die Expertise der Teams nutzen bei der Bewertung alternativer Lösungen
• Technische Teams zur Zusammenarbeit einladen bei der Entwicklung kosteneffizienter Architekturen

7. Cost-Management-Tools sind oft nutzlos (und kosten selbst Geld)

"Every byte counts, every AZ transfer costs, and somewhere, a cloud service team is probably inventing a new way to charge you for something you thought was free." (Eric Pullen — Cloud Economist & FinOps Expert)

Die meisten Cost-Management-Tools der verschiedenen Cloud-Provider zeigen klar, welche Ressourcen die Rechnung beeinflussen, erklären aber weder den Kontext noch den Wert. Was braucht es wirklich?

• Ein Tool, das die Analyse automatisiert, nicht nur die Visualisierung
• Dashboards, die operative Insights liefern, nicht nur bunte Grafiken
• Intelligente Alerts, die zwischen echten Anomalien und Hintergrundrauschen unterscheiden
• Tools, die sich in Engineering-Prozesse integrieren lassen, statt isolierter Lösungen für das Finance-Team
• Tools, die weniger technische Unternehmensbereiche unterstützen, Rechnungen zu verwalten und Kosten den richtigen Kostenstellen zuzuordnen

Natürlich muss all dies durch menschliche Analyse und Steuerung ergänzt werden. Ein Tool kann bessere Entscheidungen ermöglichen, doch der Beitrag und die Entscheidungen von Menschen bleiben unersetzlich.

Was sollen wir also tun? Aufgeben?

Wir haben gesehen, dass FinOps keine Modeerscheinung, kein Quartalsprojekt und keine einmalige Aktivität ist. Vielmehr handelt es sich um eine Praxis, die innerhalb der Organisation aufgebaut und langfristig gepflegt werden muss.

Der FinOps-Ansatz ist der einzige Weg, die Versprechen der Cloud wirklich einzuhalten in einer Welt, in der jede technische Entscheidung unmittelbare wirtschaftliche Konsequenzen hat.

Die Realität ist, dass Unternehmen, die sich gegen eine korrekte Implementierung von FinOps entscheiden, weiterhin die finanziellen Konsequenzen jeder falschen oder unüberlegten architektonischen Entscheidung tragen werden.

Glücklicherweise gibt es auch gute Nachrichten: Mit der richtigen Kombination aus:

• Klaren Verantwortlichkeiten
• Strukturierten Prozessen für die Zusammenarbeit
• Einem Tool, das Insights ermöglicht und nicht nur einfache Reports liefert
• Der Einführung einer Kultur wirtschaftlicher Verantwortung bei technischen Entscheidungen
• Und, falls erforderlich, einem Partner, der Sie bei Ihren Entscheidungen unterstützt

lässt sich die Cloud von einem schwer verständlichen Kostenfaktor in einen messbaren Wettbewerbsvorteil verwandeln.

Die entscheidende Frage lautet nicht: "Wie können wir die Cloud-Kosten senken?" sondern: "Wie können wir den Wert optimieren, den wir aus der Cloud erhalten?"

Die Cloud ist längst nicht mehr nur eine technische Frage. Sie ist ein strategischer Hebel. Und FinOps ist die gemeinsame Sprache, um diesen Hebel wirksam einzusetzen.