FinOps - Cloud-Kostenoptimierung in der Praxis

Mehr als nur Kosten – Das Risiko aufgeblähter Cloud-Infrastruktur

In der Cloud kann man unendlich skalieren. Man kann aber auch unendlich Geld viel verbrennen und sich eine tickende Zeitbombe bauen. Alles begann bei einem Kunden mit einer absurd hohen Azure-Rechnung: fast eine Million Euro Jahreskosten für eine Kubernetes-Plattform (AKS) mit vier Apps in früher Entwicklung – ohne einen Endkunden. Ein irrsinniger Preis, geboren aus der Devise „Bauen, optimieren später“, typisch wenn Time-to-Market über Kostenkontrolle siegt.

Kein Einzelfall: Studien zeigen: Explodierende Cloud-Kosten sind Alltag. Viele Unternehmen zahlen ca. 35 % zu viel (Quelle: CloudComputing-Insider), oft wegen Fehlplanung, mangelnder Optimierung oder fehlendem Know-how. Bis zu 80 % kämpfen mit unerwartet hohen Kosten (Quellen: Gartner, AP-Verlag). Das Problem unseres Kunden war also symptomatisch.

Doch die Kosten waren nur die Spitze des Eisbergs. Das wahre Drama lauerte tiefer: Eine massiv überdimensionierte, komplexe Infrastruktur barg erhebliche Risiken für Stabilität und Verfügbarkeit. Fehleranfällige Deployments konnten alles lahmlegen. Diese Kosten waren ein Alarmsignal für tiefgreifende technische und organisatorische Schieflagen.

Wie also diesen Berg an Technik-Schulden und Kosten abtragen, ohne das Wachstum zu gefährden?

Dieser Beitrag zeigt unseren Weg – von Quick Wins zu tiefgreifenden Analysen und etablierten FinOps-Praktiken. Eine Reise, die zeigt: Gezielte Kostenoptimierung führt oft direkt zu höherer technischer Qualität und Stabilität.

Das Ergebnis: Cloud-Kosten halbiert, während Apps und Teams wuchsen (von 4 auf 10+), und eine Infrastruktur, die man nicht mehr in die Knie zwingen konnte.

Die Ausgangslage: Wildwuchs in Azure und Kubernetes

Vor der Optimierung glich die Infrastruktur einem digitalen Dschungel, gewachsen unter der Maxime "Wachstum um jeden Preis". Eine zentrale Kubernetes-Plattform (AKS) auf Azure, verteilt über vier Umgebungen, beherbergte vier Produktteams mit internen Apps. Die Basis: rund 100 VMs für AKS-Cluster – eine beeindruckende Zahl für wenige, teils kaum genutzte Anwendungen.

Wie kam es dazu? Die Plattform entstand mit Fokus auf schnelle Entwicklung, Skalierbarkeit und Features, während Kosten ignoriert wurden. Das Motto "Großer Spielplatz, Details später" führte zu grundlegenden Problemen:

• Systemische Überprovisionierung: Pods erhielten Ressourcen nach dem "Viel hilft viel"-Prinzip, nicht nach Bedarf. Entwickler forderten großzügig, ohne den realen Bedarf zu kennen – Frontends mit 2 GB statt 200 MB RAM waren üblich. Multipliziert über vier Umgebungen ergab das einen enormen, ungenutzten Ressourcenhunger.
• Architektonische Fehlentscheidungen: Die "Einfach mal Machen"-Kultur führte zu bizarren Lösungen, wie Pod-RAM als improvisierter, teurer In-Memory Key-Value-Store (8 GB pro Pod). Solche Muster offenbarten Mängel in Infrastruktur und Anwendungsarchitektur.
• Ignorierte Cloud-Sparmechanismen: AKS-Node-VMs liefen fast nur zu teuren On-Demand-Preisen. Azure Reserved Instances (RIs) oder Savings Plans wurden nicht genutzt – ein klassischer Fehler für konstante Grundlasten.
• Ineffiziente, riskante Datenbanknutzung: Azure-DBs waren oft massiv überdimensioniert, weil ineffiziente Abfragen die CPU belasteten. Statt Query-Optimierung wurde hochskaliert. Fataler noch: Geteilte Datenbanken bedeuteten ein enormes Risiko – ein fehlerhaftes Release konnte so die Datenbank für alle Teams lahmlegen, zusätzlich zu den Kosten potenter Instanzen.

Diese Mischung aus massiver Überprovisionierung, fragwürdigen Architekturen, riskanten Shared Resources und Ignoranz gegenüber Sparpotenzialen zeigte: Hier musste grundlegend aufgeräumt werden.

Phase 1: Quick Wins – Aufräumen mit System (Erste 30% Einsparung)

Nach der Bestandsaufnahme war klar: Zeit für die Machete und die "Low-Hanging Fruits". Wir konzentrierten uns darauf, die offensichtlichste Verschwendung zu beseitigen und schnell erste Erfolge zu erzielen, um Vertrauen zu gewinnen.

Maßnahme 1: Kubernetes Right-Sizing – Schrumpfen mit Lerneffekt

Das Hauptproblem war die massive Überprovisionierung der Pods (GBs an RAM, Dutzende CPU-Kerne reserviert, kaum genutzt). Statt Bauchgefühl brauchten wir Daten.

• Analyse mit Goldilocks: Das Tool Goldilocks (basiert auf Vertical Pod Autoscaler) lief wochenlang in den Clustern, sammelte Daten zur CPU-/Speichernutzung und lieferte konkrete Empfehlungen für requests und limits. (Auch manuell via Monitoring möglich, Goldilocks bot aber schnellen Überblick).
• Iterative Anpassung & Beobachtung: Wir folgten den Empfehlungen nicht blind, sondern reduzierten Ressourcen (requests/limits) schrittweise (erst Dev/Staging), in Absprache mit den Teams, und beobachteten die Anwendungen genau auf Stabilität und Performance.
• Qualitätsgewinn durch Kostendruck: Dieses "langsame Daumenschrauben-Anziehen" offenbarte Probleme in den Apps selbst! Memory Leaks, vorher im Überfluss unbemerkt, traten zutage; CPU-Spitzen deuteten auf ineffizienten Code hin. Der Kostendruck zwang die Teams indirekt zur Qualitätsverbesserung ihrer Software – ein wichtiger Nebeneffekt!
• Anpassung der Replicas: Nachdem die Pods richtig dimensioniert waren und stabil liefen, reduzierten wir die oft unnötig hohe Anzahl (z.B. 3+) an Replicas, da keine Last dafür sprach und HPA fehlte.

Ergebnis: AKS-Nodes waren besser ausgelastet, die Gesamtzahl der Nodes sank deutlich.

Maßnahme 2: Azure Reserved Instances – Schluss mit On-Demand-Verschwendung

Parallel nahmen wir uns die Azure-VMs vor. Die verbleibende, nun besser genutzte Grundlast der AKS-Nodes lief noch zu teuren On-Demand-Preisen.

• Identifikation & Umstellung auf RIs: Wir ermittelten die konstante VM-Basislast nach der Optimierung und erwarben dafür Azure Reserved Instances (1 Jahr Laufzeit für Flexibilität). Das brachte erhebliche Rabatte für ohnehin benötigte Rechenleistung.

Zwischenergebnis: Die ersten 30% sind geschafft!

Allein durch Kubernetes Right-Sizing und RIs sanken die monatlichen Azure-Kosten um rund 30%. Dieser Erfolg war wichtig: Er bewies Machbarkeit, schaffte Akzeptanz und gab Energie für die komplexeren, restlichen 70% der Kosten. Das war erst der Anfang.

Phase 2: Detektivarbeit – Den versteckten Kosten auf der Spur

Dreißig Prozent Einsparung waren ein großartiger erster Erfolg, aber die Reise war noch lange nicht zu Ende. Die verbleibenden Kosten von fast einer halben Million Euro jährlich fühlten sich für eine wachsende Plattform mit internen Anwendungen immer noch exorbitant an. Es musste also weitere, weniger offensichtliche Kostentreiber geben. Die Frage war: Wo versteckten sie sich?

Maßnahme 3: Die Kostenfalle Speicher – Ein überraschend teurer Posten

Bei der Analyse der Azure-Kosten stießen wir auf eine Auffälligkeit: Die Ausgaben für Cloud-Speicher waren signifikant und erschienen unerwartet hoch. Speicherplatz selbst ist meist günstiger, also suchten wir die Ursache für das hohe Volumen.

Eine tiefere Analyse zeigte: Haupttreiber war die schiere Menge an Log- und Tracing-Daten unserer Elasticsearch/Kibana-Lösung, besonders in den Development- und Staging-Umgebungen. Ungefilterte Terabytes an Daten, oft aus Entwicklungsexperimenten, verursachten Speicher- und Transferkosten im mittleren fünfstelligen Eurobereich jährlich und belasteten das Logging-System.

Gegenmaßnahmen & Ergebnis: Wir überarbeiteten die Log-Strategien: Klare Vorgaben für Log-Level je Umgebung, angepasste Aufbewahrungsfristen und eine von Entwicklern getriebene „Community of Practice“ für bewussteres Logging waren zentral. Das reduzierte Log-Volumen senkte direkt die Kosten und entlastete das Elasticsearch-Cluster.

Maßnahme 4: Granulare Kostentransparenz – Wissen, wer was verbraucht

Parallel gingen wir die mangelnde Kostenzuordnung an. Für echtes FinOps mussten wir die Frage beantworten: "Welches Team/Produkt verursacht welche Kosten?". Nur so entstehen Verantwortlichkeit und Optimierungsanreize.

Herausforderung & Umsetzung:

Die Zuordnung war nicht trivial (Shared Resources). Wir setzten auf:

• Konsequentes Azure Tagging: Verbindliches Schema (Team, Produkt, Umgebung etc.), durchgesetzt via Azure Policies.
• Kubernetes Namespaces: Klare Trennung der Workloads pro Team/Produkt in AKS.
• Dedizierte Log-Indizes: Eigene Elasticsearch-Indizes pro Team/Produkt für Kostenzuordnung, Analysen und Retention Policies.
• Auflösung von Shared Services: Migration zu dedizierten Datenbanken pro Kernanwendung/Team. Das verbesserte Transparenz, Stabilität und Autonomie drastisch. Verbleibende Shared Services wurden über Schlüssel verteilt.
• Kubecost/OpenCost: Implementierung zur granularen Kostenaufschlüsselung innerhalb der Kubernetes-Cluster nach Ressourcennutzung (CPU, RAM, Storage) pro Pod/Namespace, verrechnet mit den Azure-Kosten der Nodes/Volumes.

Maßnahme 5: Reporting und Einsichten – Daten in Entscheidungen verwandeln

Die gesammelten Daten aus Azure Cost Management, Kubecost etc. mussten nutzbar gemacht werden.

• Automatisierte Reports & Visualisierung: Monatliche, detaillierte Kostenreports pro Team/Produkt wurden erstellt und in Grafana sowie dem zentralen BI-Tool visualisiert. Jedes Team konnte jederzeit live seine Kosten, Treiber und Entwicklung sehen.
• Empowerment der Teams: Diese Transparenz war der Schlüssel. Teams und Product Owner hatten eine faktische Grundlage für Kostendiskussionen. Sie konnten finanzielle Auswirkungen neuer Features abschätzen ("Feature X kostet uns Y Euro mehr bei der DB"). Die Diskussion verlagerte sich von Schuldzuweisungen zu konstruktiven Überlegungen: "Ist uns das Feature die Kosten wert oder investieren wir in Optimierungen?".

Diese zweite Phase der Detektivarbeit und radikalen Transparenz war entscheidend. Sie deckte versteckte Kostentreiber wie Logging auf und etablierte Werkzeuge für nachhaltiges Kostenmanagement. Die Grundlage für die angestrebte Kostenhalbierung war gelegt, und die Teams wurden befähigt, Verantwortung für ihre Cloud-Ausgaben zu übernehmen.

Herausforderungen: Technik, Teams und Kultur – Der steinige Pfad zur Effizienz

Klang nach einem glatten Plan? Weit gefehlt! Trotz guter Ergebnisse war der Weg zur Effizienz kein Sonntagsspaziergang durch die Cloud. Jede Optimierung forderte Diskussionen, Überzeugungsarbeit und das Überwinden technischer wie kultureller Blockaden.

• Der Mensch im Maschinenraum: Zwischen Angst und Gewohnheit Die größte Hürde war oft der Mensch. An Ressourcenüberfluss gewöhnte Entwickler reagierten skeptisch auf Sparvorgaben („Hält das?“). Viel Kommunikation, Tests und sanfter Druck waren nötig, um Gewohnheiten aufzubrechen. Aufgedeckte Memory Leaks durch Right-Sizing zeigten zudem: Optimierung steigert Qualität. Dennoch blieb das Ringen um jedes Megabyte oft zäh.
• Wenn die Technik (noch) nicht mitspielt: Der fehlende Autoscaler Manchmal fehlte schlicht die Technik, wie das Horizontal Pod Autoscaling (HPA). Ohne automatische Anpassung mussten wir teure, überdimensionierte Replicas fahren – Fixkosten, die erst spätere Architekturanpassungen wie HPA senkten. Ein klares Zeichen: Kostenoptimierung und Modernisierung gehen Hand in Hand.
• Der lange Atem für den Kulturwandel: FinOps ist ein Prozess Die nachhaltigste Herausforderung war, echtes Kostenbewusstsein im Unternehmen zu verankern. Transparenz war der erste Schritt, doch es dauerte, bis Teams die Daten aktiv nutzten. FinOps ist kein Projekt, sondern ein kontinuierlicher Kulturwandel, der ständige Aufmerksamkeit braucht, damit Kostenbewusstsein zur zweiten Natur wird.

Diese Hürden zu meistern war ebenso wichtig wie die Technik selbst. Nur im Zusammenspiel von Technik, Teams und Kultur erntet man die Früchte der Optimierung nachhaltig. Und die Ergebnisse zeigten: Der Aufwand hat sich gelohnt.

Die Ergebnisse: Halbierte Kosten, doppelte Qualität?

Nach intensiver Analyse und Optimierung lagen die Ergebnisse vor – beeindruckend auf dem Papier und in der Praxis.

Harte Fakten: Mission Kostenhalbierung erfüllt!

Das Ziel, die Azure-Kosten im hohen 6-stelligen Bereich zu halbieren, wurde übertroffen. Durch Right-Sizing, Reserved Instances, Log-Optimierung und Transparenz sanken die Ausgaben um mehr als die Hälfte – trotz Wachstums von vier auf über zehn Applikationen!

Unerwartete Gewinne: Mehr als nur Sparen

Der Clou: Die Optimierung entpuppte sich als kostenloses Qualitätssteigerungsprogramm.

• Mehr Stabilität: Das Right-Sizing legte Schwachstellen (Memory Leaks, Ineffizienzen) offen. Deren Korrektur führte zu deutlich weniger Ausfällen und messbar höherer Verfügbarkeit (99.995% über einen Zeitraum von 12 Monaten). Die schlanke Infrastruktur war robuster.
• Mehr Effizienz: Weniger Ressourcen bedeuteten weniger Komplexität, schnellere Deployments und einfacheres Management.
• FinOps-Mindset etabliert: Dank Transparenz verfolgten Teams die Kosten aktiv. Die Frage "Was kostet das?" floss in Entwicklung und Entscheidungen ein.
• Bewusstere Entwickler: Das Team lernte, ressourceneffizienter zu coden, zielgerichtet zu loggen und die Kostenfolgen zu verstehen.

Am Ende stand eine günstigere, bessere, stabilere und zukunftsfähigere Plattform. Kostenoptimierung war somit eine Investition in technische Exzellenz und Resilienz.

Nachhaltigkeit sichern: FinOps ist kein Projekt, sondern ein Fitnessprogramm

Kosten halbiert, Plattform stabil – Mission erfüllt? Nicht ganz. Erfolgreiche Optimierung ist wie ein Fitnessprogramm: Ohne Training landet man schnell wieder auf dem Sofa. FinOps ist keine einmalige Aktion, sondern eine kontinuierliche Aufgabe für den Alltag.

Wie also bleiben Erfolge von Dauer und das Kostenbewusstsein wach?

• Transparenz bleibt Trumpf: Dashboards sind der tägliche Kompass. Die Frage "Was kosten wir gerade?" muss jederzeit per Klick beantwortbar sein für datenbasierte Entscheidungen.
• Frühwarnsysteme aktivieren: Automatische Alerts schlagen Alarm, wenn Kosten aus dem Ruder laufen. So lassen sich ungewollte Kostenexplosionen (z.B. durch Debug-Logs) frühzeitig erkennen und stoppen, bevor sie die Monatsrechnung sprengen.
• Planung mit Weitblick: Kostendaten werden zur Grundlage für Budgets und Prognosen. Teams können finanzielle Auswirkungen neuer Features besser abschätzen und fundierte Diskussionen über Prioritäten führen.
• Verantwortung im Team verankern: Transparenz schafft Ownership. Teams sind auch für ihre Kosten verantwortlich. Der zentrale Architekt oder das FinOps-Team agiert als Coach, nicht als Kontrolleur, stellt Tools bereit und unterstützt. Regelmäßige Kosten-Reviews werden Routine.

FinOps dauerhaft zu etablieren bedeutet, eine Kultur zu schaffen, in der Kosten so selbstverständlich wie Performance oder Sicherheit sind. Es braucht die richtigen Werkzeuge, klare Verantwortlichkeiten und das Thema muss präsent bleiben. Nur so wird aus einem Projekt eine nachhaltige Verbesserung, die das Unternehmen langfristig stärkt – finanziell und technisch.

Fazit: Exzellenz statt nur Sparen

Unsere Reise begann mit einem Schock: Fast 1 Mio. € Cloud-Kosten für wenige interne Apps und eine riskante Infrastruktur. Das Ergebnis: Halbierte Ausgaben, stabile Plattform, >10 zufriedene Teams. Unser Learning: Cloud-Kostenoptimierung ist oft verdeckte Qualitätssteigerung. Dem Geld folgend, deckten wir technische Schulden und ineffiziente Prozesse auf – von Memory Leaks bis Log-Tsunamis. Der Kostendruck erzwang Disziplin, bessere Architektur und smarte Lösungen.

Das Ergebnis war mehr als eine schönere Azure-Rechnung: eine robustere, effizientere Plattform für produktivere Teams. Die „unerwarteten“ Gewinne an Stabilität und Know-how waren Gold wert.

Und wie sieht es bei euch aus? Verstehen Sie Ihre Cloud-Rechnung wirklich? Finden Sie Ihre Kostentreiber – und die technischen Leichen im Keller? Hinterfragen Sie den Status Quo, schaffen Sie Transparenz! Es lohnt sich doppelt: fürs Budget und die Technik. Denn Kosten im Griff heisst meist auch: Infrastruktur im Griff.