Cloud-Kosten senken: FinOps-Praktiken für den Mittelstand

Die Cloud-Rechnung kommt Anfang des Monats per E-Mail, ist wieder ein paar hundert Euro höher als im Vormonat, und niemand im Unternehmen kann auf Anhieb sagen, woran das liegt. Genau dieses Muster sehen wir bei mittelständischen Kunden immer wieder: Vor zwei, drei Jahren wurde in die Cloud migriert, seitdem wächst die Rechnung leise mit — unabhängig davon, ob das Geschäft im gleichen Tempo wächst.

Das Problem ist selten technischer Natur. Es fehlt schlicht ein Prozess, der Cloud-Kosten regelmäßig hinterfragt. Genau das beschreibt FinOps: keine neue Software, sondern eine Reihe wiederkehrender Praktiken, mit denen Technik- und Finanzverantwortliche gemeinsam dafür sorgen, dass Cloud-Ausgaben zum Geschäftswert passen. Für Unternehmen mit 50 bis 500 Mitarbeitenden lassen sich damit in der Praxis 20 bis 40 Prozent der laufenden Cloud-Kosten einsparen, ohne dass Leistung oder Verfügbarkeit leiden.

Warum Cloud-Kosten im Mittelstand unbemerkt wachsen

Cloud-Ressourcen lassen sich in Minuten anlegen, aber selten in der gleichen Geschwindigkeit wieder abbauen. Ein Entwickler startet eine Testumgebung für einen Sprint, das Projekt wird abgeschlossen, die Instanz läuft weiter. Ein IT-Leiter bestellt Server “eine Nummer größer” für den Blackfriday-Ansturm im November und vergisst, im Januar wieder zu verkleinern. Nach zwei, drei Jahren ohne dedizierten Kostenverantwortlichen hat sich so ein beachtlicher Anteil ungenutzter oder überdimensionierter Ressourcen angesammelt.

Der zweite Grund ist strukturell: In den meisten Mittelstandsunternehmen liegt die Cloud-Rechnung bei der IT, das Budget bei der Geschäftsführung, und dazwischen gibt es keine regelmäßige Abstimmung. Die Rechnung wird bezahlt, aber niemand fragt systematisch, ob jede Position noch gebraucht wird. FinOps schließt genau diese Lücke — mit klaren, wiederholbaren Routinen statt einmaligen Aufräumaktionen.

Rightsizing: der größte Hebel, der am seltensten gezogen wird

Der wirkungsvollste erste Schritt ist fast immer das Rightsizing bestehender Instanzen. In unseren Analysen bei Mittelstandskunden lag die durchschnittliche CPU-Auslastung produktiver Server häufig zwischen 8 und 15 Prozent — bestellt wurde aber “auf Nummer sicher”, oft eine oder zwei Größenklassen über dem tatsächlichen Bedarf.

Als Faustregel gilt: Eine Instanz ist ein Rightsizing-Kandidat, wenn sie über einen Beobachtungszeitraum von mindestens zwei bis vier Wochen (um saisonale Spitzen wie Monatsabschluss oder Lohnläufe mit abzudecken) durchgehend unter 20 Prozent CPU- und Speicherauslastung bleibt. AWS Compute Optimizer, Azure Advisor und Google Cloud Recommender liefern diese Auswertung kostenfrei und automatisiert — die Empfehlungen liegen in der Regel innerhalb weniger Tage nach Aktivierung vor.

Wie Rightsizing in der Praxis abläuft

Wichtig ist die richtige Reihenfolge: zuerst nicht-produktive Umgebungen (Test, Staging, Entwicklung), dann unkritische Produktionssysteme, erst zuletzt geschäftskritische Workloads mit einem Wartungsfenster und Rollback-Plan. Eine verkleinerte Instanz lässt sich bei den meisten Anbietern innerhalb weniger Minuten wieder hochskalieren, falls die neue Größe doch nicht ausreicht — das Risiko ist also überschaubar, wenn man iterativ vorgeht statt alles auf einmal umzustellen.

Ein oft übersehener Zusatzeffekt: Rightsizing deckt regelmäßig auch komplett verwaiste Ressourcen auf — Testserver, deren Projekt vor einem Jahr endete, oder Datenbank-Replikate, die niemand mehr abfragt. Das Abschalten dieser “Zombie-Ressourcen” kostet nichts und bringt oft überraschend viel.

Reserved Instances und Savings Plans gegen On-Demand

Wer seine Grundlast kennt, zahlt zu viel, wenn er sie weiterhin zu On-Demand-Preisen bezieht. Reserved Instances (AWS, Azure) und Compute Savings Plans bieten für eine ein- oder dreijährige Nutzungszusage Rabatte von typischerweise 30 bis 60 Prozent gegenüber dem On-Demand-Tarif, bei dreijähriger Vorauszahlung teils deutlich mehr.

Die Bindung lohnt sich für den Teil der Infrastruktur, der nachweislich rund um die Uhr läuft: das ERP-System, die Produktivdatenbank, den zentralen Fileserver. Für schwankende oder saisonale Lasten — den Onlineshop im Weihnachtsgeschäft, die Batch-Verarbeitung am Monatsende — bleibt On-Demand oder Auto-Scaling die bessere Wahl, weil eine ungenutzte Reservierung genauso viel kostet wie eine genutzte.

Wann sich die Bindung lohnt – und wann nicht

Praktikabler Einstieg: Zunächst nur die Workloads committen, die seit mindestens drei Monaten konstant laufen, und dabei mit einem einjährigen statt dreijährigen Vertrag beginnen. Das begrenzt das Risiko, sich an eine Instanzgröße zu binden, die in zwei Jahren nicht mehr passt. AWS und Azure bieten inzwischen auch flexible Varianten (Compute Savings Plans, Azure Reservations mit Instanzgruppen-Flexibilität), die einen Wechsel der Instanzfamilie innerhalb der Vertragslaufzeit erlauben — das nimmt einen Großteil des Bindungsrisikos.

Eine grobe Orientierung aus der Praxis: Sobald mehr als 60 Prozent der Rechenkapazität nachweislich dauerhaft benötigt werden, amortisiert sich eine einjährige Reservierung in der Regel bereits nach vier bis sechs Monaten gegenüber dem On-Demand-Preis.

Egress-Kosten: die Rechnung, die niemand einplant

Der am häufigsten unterschätzte Kostenblock ist der Datenausgang, das sogenannte Egress. Anders als der Traffic in die Cloud hinein ist jedes Gigabyte, das die Cloud-Umgebung verlässt, kostenpflichtig — bei einigen Anbietern mit Preisen zwischen 0,08 und 0,12 Euro pro Gigabyte, abhängig von Zielregion und Volumen. Bei Unternehmen mit Video-Content, großen Reporting-Exports oder Backup-Replikation in eine zweite Region summiert sich das schnell auf mehrere hundert bis tausend Euro im Monat.

Drei typische Egress-Fallen begegnen uns immer wieder: erstens Cross-Region-Replikation, die aus Datenschutz- oder Verfügbarkeitsgründen eingerichtet wurde, aber deutlich mehr Daten spiegelt als nötig. Zweitens Backups, die in eine andere Cloud oder einen anderen Anbieter exportiert werden, ohne dass die Bandbreite vorher geprüft wurde. Drittens ausgelieferte Inhalte (Bilder, Videos, Downloads) direkt aus dem Storage-Bucket statt über ein Content Delivery Network — ein CDN reduziert nicht nur die Ladezeit für Kunden, sondern häufig auch die Egress-Kosten um 30 bis 50 Prozent, weil wiederkehrende Anfragen aus dem Cache statt aus dem Ursprungssystem bedient werden.

Praktischer Test: Wer seine monatliche Cloud-Rechnung nach der Kostenkategorie “Data Transfer” oder “Network” filtert und dort mehr als 5 bis 8 Prozent der Gesamtkosten findet, hat vermutlich ungenutztes Sparpotenzial in der Netzwerkarchitektur.

Tagging und Kostenstellen: Transparenz als Voraussetzung

Keine der genannten Maßnahmen funktioniert dauerhaft ohne eine Antwort auf die einfache Frage: Wer im Unternehmen verursacht welche Kosten? Ohne konsequentes Tagging landet die gesamte Cloud-Rechnung als ein einziger Posten in der Buchhaltung — niemand kann sie einer Abteilung, einem Projekt oder einem Produkt zuordnen, und damit fühlt sich auch niemand dafür verantwortlich.

Ein praktikables Tagging-Schema kommt mit wenigen Pflichtfeldern aus: Kostenstelle, Umgebung (Produktion, Test, Entwicklung), Projekt oder Anwendung, sowie ein Verantwortlicher. Diese vier Tags reichen aus, um im Kostenreport nach Abteilung oder Projekt aufzuschlüsseln, ungenutzte Testumgebungen automatisiert zu identifizieren und am Monatsende ein Kostenstellen-gerechtes Reporting an die Fachbereiche zu liefern. Wichtig ist, das Tagging technisch zu erzwingen — etwa über eine Richtlinie, die das Anlegen ungetaggter Ressourcen verhindert — statt es dem guten Willen der Entwickler zu überlassen. Erfahrungsgemäß versanden freiwillige Tagging-Vorgaben innerhalb weniger Monate.

Der monatliche Kosten-Review: FinOps als Prozess statt Projekt

Eine einmalige Aufräumaktion senkt die Rechnung für ein, zwei Quartale — danach wächst sie unbemerkt wieder, weil sich der gleiche Mechanismus wiederholt, der die Kosten ursprünglich hat anwachsen lassen. Der entscheidende Unterschied zwischen einem Einmalprojekt und echtem FinOps ist ein fester monatlicher Termin, an dem IT-Leitung und ein Vertreter aus Finanzen oder Controlling gemeinsam die Kostenentwicklung durchgehen.

Ein funktionierender Review dauert 30 bis 45 Minuten und folgt einer festen Agenda: Abweichung zum Vormonat und zum Budget, die drei größten Einzelposten, neu entdeckte Rightsizing-Kandidaten, ablaufende Reservierungen, sowie ein kurzer Blick auf ungewöhnliche Kostensprünge einzelner Tags oder Kostenstellen. Die meisten Cloud-Anbieter liefern die dafür nötigen Auswertungen bereits eingebaut (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing Reports); für Unternehmen mit mehreren Cloud-Konten oder Multi-Cloud-Setups lohnt sich zusätzlich ein Kosten-Dashboard, das Budget-Schwellenwerte automatisch per E-Mail oder Chat meldet, statt erst am Monatsende überrascht zu werden.

Rechenbeispiel: Was FinOps in einem typischen Mittelstandsunternehmen bringt

Um die Größenordnung greifbar zu machen, hier eine illustrative Beispielrechnung, wie sie einem typischen Fertigungsunternehmen mit rund 180 Mitarbeitenden entsprechen könnte (die Zahlen sind zur Veranschaulichung konstruiert, kein realer Kundenfall):

Ausgangslage: monatliche AWS-Rechnung von 22.000 Euro für rund 60 virtuelle Server, verteilt auf ERP-System, Onlineshop, eine Reporting-Datenbank und diverse Test- und Entwicklungsumgebungen.

Nach drei Monaten systematischer FinOps-Arbeit:

• Rightsizing überdimensionierter Instanzen: 18 Server verkleinert, dazu sechs verwaiste Testumgebungen abgeschaltet → Ersparnis rund 3.200 Euro pro Monat
• Compute Savings Plan für die Grundlast: einjährige Bindung für ERP- und Datenbankserver, die nachweislich seit über einem Jahr durchlaufen → Ersparnis rund 2.800 Euro pro Monat
• CDN vor den Onlineshop geschaltet, Cross-Region-Backup auf das Nötigste reduziert: → Ersparnis rund 900 Euro pro Monat
• Ungenutzte Ressourcen (verwaiste Snapshots, ungebundene IP-Adressen, alte Volumes): → Ersparnis rund 1.100 Euro pro Monat

Ergebnis: Die monatliche Rechnung sinkt von 22.000 auf rund 14.000 Euro — eine Reduktion um etwa 36 Prozent beziehungsweise knapp 96.000 Euro im Jahr, ohne dass eine einzige Anwendung langsamer wurde oder ausfiel. Der überwiegende Teil dieser Ersparnis (rund drei Viertel) stammt aus den ersten beiden Maßnahmen, Rightsizing und Reserved Capacity — das deckt sich mit dem, was wir branchenübergreifend beobachten: Wer nur diese zwei Hebel konsequent zieht, hat den Großteil der Arbeit bereits getan.

Handlungsempfehlungen für die ersten 90 Tage

Wer heute anfängt, muss nicht sofort ein komplettes FinOps-Team aufbauen. Ein realistischer Fahrplan sieht so aus: In den ersten zwei Wochen die kostenlosen Rightsizing-Tools des Cloud-Anbieters aktivieren und einen Beobachtungszeitraum von drei bis vier Wochen laufen lassen. Parallel ein einfaches Tagging-Schema mit den vier genannten Pflichtfeldern einführen und rückwirkend auf bestehende Ressourcen anwenden, so weit das automatisiert möglich ist. Nach sechs bis acht Wochen liegen genug Daten vor, um die ersten Rightsizing-Maßnahmen umzusetzen und zu entscheiden, welcher Anteil der Infrastruktur reif für eine Reservierung ist. Ab der zwölften Woche sollte der monatliche Kosten-Review als fester Termin im Kalender stehen — dauerhaft, nicht nur für das erste Quartal.

Fazit

Cloud-Kosten senken sich nicht durch ein einmaliges Projekt, sondern durch einen Prozess, der so lange läuft wie die Cloud-Nutzung selbst. Die vier Hebel — Rightsizing, Reserved Capacity, Egress-Kontrolle und Kostenstellen-Transparenz — lassen sich unabhängig voneinander einführen und zahlen sich fast immer innerhalb weniger Monate aus. Der schwierigere Teil ist selten die Technik, sondern die Disziplin, den monatlichen Review tatsächlich beizubehalten, wenn das Tagesgeschäft drängt.

Falls Sie unsicher sind, wo in Ihrer Cloud-Umgebung das größte Sparpotenzial steckt, oder einen unabhängigen Blick auf Ihre aktuelle Kostenstruktur brauchen: In einem ersten Gespräch schauen wir uns gemeinsam Ihre größten Kostenpositionen an und sagen ehrlich, wo sich eine tiefere Analyse lohnt. Vereinbaren Sie ein unverbindliches Gespräch.