Blog
FinOps: Die Cloud muss nicht so teuer sein!
Die Cloud sollte alles günstiger machen. Flexibler, skalierbarer, kosten-transparenter. Das war das Versprechen. Die Realität, die wir in Projekten immer wieder erleben, sieht anders aus: Unternehmen haben migriert, zahlen mehr als zuvor und wissen nicht genau, warum.
Die naheliegende Antwort ist meistens: falsches Tool, zu wenig Rightsizing, keine Reserved Instances. Aber das sind nur die Symptome, nicht die Ursache.
Cloud-Kosten sind in den letzten Jahren für viele Unternehmen zum ernsthaften Budget-Thema geworden. Die Unternehmensberatung Gartner schätzt, dass Unternehmen weltweit bis zu 30 Prozent ihrer Cloud-Ausgaben verschwenden, durch ungenutzte Ressourcen, falsch dimensionierte Instanzen und fehlende Kostenkontrolle.
Das deckt sich mit unseren Projekterfahrungen. Jedoch: Die Lösung liegt selten allein in besseren Tools.
Nach mehreren Jahren FinOps-Projekten für Unternehmen verschiedener Größe – mit AWS, Azure, STACKIT, Open Telekom Cloud und Hetzner – sind wir zu einer klaren Einschätzung gekommen:
Das eigentliche Problem ist fast immer organisatorischer Natur: fehlende Kostentransparenz, unklare Verantwortlichkeiten, kein Management Buy-in. Tools helfen grundsätzlich erst, wenn diese konkreten Grundlagen stehen.
Drei Situationen, die wir immer wieder sehen:
1. Die explodierende Rechnung
Ein Unternehmen erhält seine monatliche Cloud-Rechnung. Sie ist deutlich höher als erwartet, aber niemand kann auf Anhieb sagen, welches Team, welche Anwendung oder welcher Service die hohen Kosten verursacht. Das Tagging der Ressourcen ist entweder nicht vorhanden, inkonsistent oder wurde nie konsequent durchgesetzt.
Das Resultat: Statt einer klaren Kostenzuordnung gibt es eine große graue Masse. Der Ops-Bereich bezahlt pauschal, die Entwicklungsteams optimieren nicht, weil sie die Konsequenzen ihrer Entscheidungen nicht sehen.
2. Lift & Shift hat nicht gespart
Viele Cloud-Migrationen folgen dem gleichen Muster: On-Premise-Server werden 1:1 in virtuelle Maschinen in der Cloud gehoben. Kein Refactoring, kein Rightsizing, keine Anpassung an cloud-native Abrechnungsmodelle. Mitgenommen wird alles, einschließlich der Überdimensionierung, die man sich im Rechenzentrum noch leisten konnte.
Hinzu kommen neue Kosten, die on-premise nicht existierten: Datentransfer, Managed Services, Lizenzen. Und in heterogenen Umgebungen, wie wir sie häufig sehen – z. B. ein Provider-Mix aus AWS oder Azure für bestehende Workloads und europäischen Providern wie STACKIT, Open Telekom Cloud oder Hetzner für neue oder compliance-kritische Anwendungen – fehlt oft die einheitliche Kostensicht über alle Provider hinweg.
3. Multi-Cloud-Chaos
Mehrere Anbieter, unterschiedliche Abrechnungsmodelle, kein gemeinsames Dashboard. Was funktional als sinnvolle Multi-Cloud-Strategie begann (AWS für spezifische Managed Services hier, Hetzner für kostengünstige Compute-Workloads dort, STACKIT für DSGVO-konforme Datenhaltung etc.) wird zur Kostenfalle, wenn niemand den Überblick behält. Kosten lassen sich nicht mehr sinnvoll nach Business Units oder Teams sortieren, Budget-Verantwortliche erhalten fragmentierte Reports, Optimierungspotenziale bleiben unsichtbar.
Was FinOps wirklich ist und was nicht
An dieser Stelle lohnt sich eine kurze Einordnung. Die FinOps Foundation, ein CNCF-Projekt, definiert FinOps als eine operative Praxis, die Engineering, Finance und Business zusammenbringt, um gemeinsam bessere Entscheidungen über Cloud-Kosten zu treffen.
- Crawl: Erste Sichtbarkeit herstellen, grundlegendes Reporting aufsetzen.
- Walk: Verantwortlichkeiten zuweisen, Optimierungsprozesse etablieren.
- Run: Vollständig automatisierte, kontinuierliche Kostenkontrolle mit teamübergreifender Ownership.
Was FinOps nicht ist: ein Tool, das man installiert und das dann automatisch spart. Rightsizing-Empfehlungen, Reserved Instances oder Saving Plans sind Maßnahmen innerhalb eines FinOps-Ansatzes, aber kein Ersatz dafür. Wer zuerst ein Tool kauft und hofft, dass sich der Rest dann von selbst ergibt, wird enttäuscht.
Herausforderung Management Buy-in
Hier der Punkt, der in technischen FinOps-Diskussionen am häufigsten fehlt: Technisch ist FinOps lösbar, organisatorisch nicht ohne weiteres.
In der Praxis scheitern FinOps-Initiativen selten an den Tools. Sie scheitern daran, dass niemand wirklich das Steuer übernimmt. Und dass die Strukturen, in denen Cloud-Kosten entstehen, nicht zu denen passen, in denen sie verantwortet werden.
In unseren Projekten beobachten wir drei immer wiederkehrende Muster, wenn FinOps scheitert oder auf der Stelle tritt:
„Das optimieren wir später.“
Cloud-Kosten werden als Betriebskosten betrachtet, nicht als Entwicklungsentscheidung. Solange Budgets vorhanden sind, wird Optimierung zurückgestellt. „Später“ kommt dann, wenn die Rechnung nicht mehr ignoriert werden kann und der Druck von oben zu groß wird. Bis dahin wurde Potenzial verschenkt.
Kosten landen beim falschen Team
Typisch: Die Infrastruktur-Abteilung oder ein zentrales Ops-Team trägt die Cloud-Kosten, die Entwicklungsteams sehen davon nichts. Es ist also kein Anreiz da, ressourcenschonend zu entwickeln. Überdies fehlt oft ein Feedback-Loop zwischen technischen Entscheidungen und wirtschaftlichen Konsequenzen. Ein Entwickler, der einen neuen Service in einem zu groß dimensionierten Kubernetes-Cluster deployt, merkt das nicht. Der Ops-Lead hingegen schon, aber erst beim Monatsabschluss.
Niemand fühlt sich zuständig
FinOps braucht einen Owner. Jemanden, der das Thema treibt, Prioritäten setzt, Teams einbindet und Ergebnisse verantwortet. Ohne einen dedizierten FinOps-Champion, oder zumindest eine klare Rollenzuweisung, verläuft jede Initiative im Sand. Das Thema wandert von Meeting zu Meeting, ohne dass sich etwas ändert.
Was hilft
Hier ein paar praktische Tipps, wie Sie Abhilfe schaffen können:
- Einen Executive Sponsor benennen, der FinOps als strategisches Thema trägt. Nicht als IT-Projekt, sondern als Unternehmensentscheidung.
- Kostenverantwortung direkt den Teams übergeben, die sie durch ihre Architektur- und Entwicklungsentscheidungen beeinflussen.
- Und: Klein anfangen, schnell sichtbare Ergebnisse zeigen. Das schafft Vertrauen und hält das Momentum aufrecht.
Unser Ansatz: Vom Chaos zur Kostentransparenz
Wenn wir in ein Projekt einsteigen, folgen wir einem dreistufigen Ansatz. Nicht weil er der einzig richtige ist, sondern weil er sich als pragmatisch und iterierbar erwiesen hat.
Schritt 1: Sichtbarkeit herstellen
Bevor gespart werden kann, muss sichtbar sein, wer welche Aufwände verursacht. Das klingt trivial, ist es aber nicht.
Der erste Schritt ist eine konsistente Tagging-Strategie: Welche Tags sind verpflichtend? Was identifiziert ein Team, eine Anwendung, eine Umgebung (Produktion, Staging, Dev)? Typische Pflicht-Tags in unseren Projekten: team, environment, project, cost-center.
Diese Strategie muss dann auch durchgesetzt werden. Idealerweise über Infrastructure as Code (Terraform, Pulumi, CloudFormation), so dass Ressourcen ohne korrekte Tags gar nicht erst provisioniert werden können. Bei AWS lässt sich das über Service Control Policies erzwingen, bei Azure über Azure Policy. Wer das nicht tut, kämpft dauerhaft gegen Inkonsistenz.
Für Kubernetes-Umgebungen setzen wir regelmäßig OpenCost ein. Das CNCF-Projekt ermöglicht eine granulare Kostenallokation auf Namespace-, Deployment- oder Pod-Ebene. Open Source, kein Vendor Lock-in, und direkt in bestehende Prometheus-Infrastrukturen integrierbar.
Die Kostendaten werden anschließend in Grafana visualisiert. In vielen Teams ist Grafana ohnehin vorhanden. Der Aufwand, Kostendaten als weiteren Datenstream einzubinden, ist damit gering. Das Ergebnis: Ein Dashboard, das Kosten genauso sichtbar macht wie CPU-Auslastung oder Response-Zeiten.
Schritt 2: Verantwortung zuweisen. Showback und Chargeback
Sobald Kosten zuordenbar sind, kommt der nächste Schritt: Teams müssen diese Kosten auch sehen. Also weg von „Was ich nicht weiß macht mich nicht heiß“ hin zu Transparenz und Verantwortungsübernahme.
- Showback ist der erste Schritt: Teams erhalten regelmäßige Reports über ihre Kosten, ohne dass diese direkt verrechnet werden. Ziel ist es, ein Bewusstsein zu schaffen. Was kostet unser Service im Monat? Was hat das letzte Feature-Deployment an Infrastrukturkosten erzeugt?
- Chargeback geht einen Schritt weiter: Teams tragen die Kosten tatsächlich aus ihrem Budget. Das erhöht den Optimierungsdruck deutlich und verändert, wie Architekturentscheidungen getroffen werden.
Welcher Ansatz der richtige ist, hängt vom Reifegrad der Organisation ab. Showback ist der pragmatischere Einstieg, Chargeback setzt organisatorische Reife und stabile Prozesse voraus.
Schritt 3: Iterativ optimieren
Erst wenn Sichtbarkeit und Verantwortlichkeit hergestellt sind, lohnt sich die Arbeit an konkreten Optimierungsmaßnahmen.
Der einfache Einstieg: Ernten Sie tiefhängende Früchte. Ob nicht genutzte Ressourcen (Idle-Instanzen, Snapshots ohne referenzierende Volumes, verwaiste Load Balancer), offensichtliches Oversizing oder Development-Umgebungen, die nachts laufen, obwohl niemand sie braucht. In fast jedem Projekt, das wir gesehen haben, lassen sich durch diese einfachen Maßnahmen schnell erste Einsparungen erzielen – ohne eine einzige Architekturentscheidung anzufassen.
Ein wichtiger Hinweis für Multi-Cloud-Umgebungen: Die Preismodelle von AWS und Azure unterscheiden sich grundlegend von denen europäischer Provider wie STACKIT, Open Telekom Cloud oder Hetzner. Committed-Use-Modelle, Spot-Instanz-Mechanismen, Datentransfer-Preise, Abrechnungsintervalle: All das ist unterschiedlich geregelt. Hetzner etwa rechnet stündlich ab und bietet keine klassischen Reserved Instances. Dafür sind die Grundpreise so niedrig, dass sich andere Optimierungslogiken lohnen. AWS Savings Plans hingegen sind komplex, aber bei konstantem Workload deutlich günstiger als On-Demand. Eine Optimierungsstrategie, die für einen Provider funktioniert, lässt sich nicht 1:1 auf einen anderen übertragen. Provider-spezifisches Wissen ist hier kein Nice-to-have, sondern Voraussetzung.
Das Ziel ist keine einmalige Optimierungsaktion, sondern ein kontinuierlicher Zyklus: Inform → Optimize → Operate. Dieser FinOps-Grundgedanke klingt abstrakt, bedeutet in der Praxis aber: regelmäßige Kosten-Reviews, automatisierte Anomalieerkennung, Prozesse, die Optimierung zur Gewohnheit machen.
Tools: Was wirklich hilft
OpenCost ist für Kubernetes-Umgebungen unsere erste Empfehlung. Es ist ein CNCF-Projekt, Open Source, gut dokumentiert mit direkter Prometheus-Integration. Wer Kubernetes betreibt und noch kein Kostentool hat, sollte hier anfangen.
Grafana + Prometheus sind in vielen Teams bereits vorhanden. Kostendaten als Metriken zu erfassen und zu visualisieren, ist mit überschaubarem Aufwand möglich. Anomaly Detection über Alerting-Regeln, monatliche Budget-Alerts, Team-spezifische Dashboards – das ist alles machbar, ohne ein neues Tool einzuführen. Der Vorteil: Kosten erscheinen im gleichen Kontext wie Performance-Metriken. Wenn ein neues Feature gleichzeitig die Latenz erhöht und die Cloud-Kosten verdoppelt, sieht das Team beides sofort.
Native Cloud-Tools wie AWS Cost Explorer, Azure Cost Management oder der STACKIT Cost Explorer sind sinnvolle Ergänzungen für provider-spezifische Analysen. Für einen schnellen Einstieg in einem Single-Cloud-Setup reichen sie oft aus. Als echte Multi-Cloud-Lösung taugen sie nicht, denn jeder Provider hat sein eigenes Interface, seine eigene Datenstruktur, seine eigene Definition von „Kosten“.
Spezialisierte Drittanbieter-Plattformen (Spot by NetApp, Apptio Cloudability, CAST AI etc.) können ab einer gewissen Komplexität und Teamgröße sinnvoll sein, etwa wenn automatisiertes Rightsizing oder Spot-Instanz-Management im Vordergrund stehen. Für den Einstieg sind sie meistens zu viel. Und: Kein Tool löst das zugrunde liegende Kulturproblem. Das ist die wichtigste Aussage dieses Abschnitts.
Was bleibt: Lessons Learned
Sechs Erkenntnisse, die wir aus FinOps-Projekten immer wieder mitnehmen:
- Fangen Sie mit Sichtbarkeit an, nicht mit Sparen. Wer optimieren will, ohne zu wissen, was was kostet, optimiert im Blindflug. Kostentransparenz ist keine Vorstufe zu FinOps – sie ist FinOps.
- Holen Sie sich den Management-Sponsor, bevor Sie anfangen. Ohne Rückendeckung von oben wird FinOps zum Hobby-Projekt, das nach der ersten Priorisierungsrunde verloren geht. Das ist nicht übertrieben, wir haben es oft genug erlebt.
- Tagging ist Pflicht, keine Kür. Erzwingen Sie es technisch, wenn nötig. Ohne konsistentes Tagging ist alles andere Makulatur. Und weil niemand freiwillig konsequent taggt: Bauen Sie es in Ihre Pipelines ein.
- OpenCost + Grafana reichen für 80 % der Fälle. Statt komplexe Drittanbieter-Tools einzuführen, lohnt es sich, das Potenzial bestehender Infrastruktur auszuschöpfen. Das spart Lizenzkosten und senkt die Hürde zur Adoption im Team.
- Multi-Cloud braucht eine Multi-Provider-Strategie. Wer AWS, Azure und Hetzner gleichzeitig betreibt, muss für jeden Provider separate Optimierungslogik entwickeln. Einheitliche Kostensicht ist das Ziel, einheitliche Optimierungsstrategie oft nicht möglich.
- FinOps ist kein Projekt, das irgendwann endet. Es ist eine dauerhafte Praxis. Wer FinOps als einmalige Initiative startet, wird nach sechs Monaten wieder beim gleichen Problem stehen. Der FinOps-Zyklus muss in den normalen Engineering-Rhythmus integriert werden, genauso wie Code Reviews oder Deployment-Prozesse.
Wollen Sie FinOps angehen? Wir helfen.
Ob Sie gerade vor der ersten unerwarteten Cloud-Rechnung stehen, mitten in einer Migration feststellen, dass die Kosten nicht sinken, oder in einem Multi-Cloud-Umfeld die Übersicht verloren haben: Wir kennen diese Situationen und helfen, sie strukturiert anzugehen.
Wir unterstützen bei der technischen Umsetzung: Tagging-Strategien, OpenCost-Setup, Grafana-Dashboards, Showback-Konzepte, Provider-spezifische Optimierungen für AWS, Azure, STACKIT, Open Telekom Cloud und Hetzner. Aber auch bei den organisatorischen Fragen: Wie baut man ein FinOps-Ownership auf? Wie holt man das Management ins Boot?
Melden Sie sich. Wir schauen uns Ihre Situation an und sagen Ihnen direkt, wo die größten Hebel liegen.
