Cloud-Kosten senken — FinOps-Leitfaden für den Mittelstand 2026

Die meisten mittelständischen Unternehmen entdecken FinOps in dem Moment, in dem die zweite Cloud-Rechnung doppelt so hoch ausfällt wie die erste. Das ist kein Zufall, sondern systematisch — die Cloud belohnt Geschwindigkeit, bestraft aber Sorglosigkeit. Wer ohne Kostendisziplin migriert, sieht Ausgaben in den ersten 18 Monaten typischerweise um 60 bis 120 Prozent über dem Business-Case-Plan landen. Für Geschäftsführung und CFO ist das schmerzhaft, weil Cloud-Kosten anders als Hardware-Investitionen nicht aktiviert werden, sondern direkt das Betriebsergebnis treffen. Die gute Nachricht: ein strukturiertes FinOps-Programm holt die meisten dieser Überschreitungen wieder herein — typische Einsparungen liegen im ersten Jahr zwischen 20 und 40 Prozent, ohne dass eine einzige Workload abgeschaltet werden muss. Dieser Leitfaden zeigt, wie ein FinOps-Programm im deutschen Mittelstand realistisch aussieht — Phasen, Tagging, konkrete Spar-Hebel, Tool-Landschaft und fünf reale Cases mit Zahlen. Für die Einordnung in die Gesamtstrategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Warum Cloud-Kosten explodieren

Cloud-Rechnungen wachsen aus Gründen, die mit der Architektur der Cloud-Plattformen selbst zu tun haben. Erstens: Self-Service. Entwicklerinnen können in Minuten Ressourcen anlegen, die in der klassischen IT Wochen gedauert hätten — Beschaffung, Genehmigung, Inbetriebnahme. Diese Geschwindigkeit ist gewollt und ein zentraler Wert der Cloud, sie führt aber dazu, dass Ressourcen schneller entstehen als sie wieder verschwinden. Test-Cluster für ein vergessenes Proof of Concept laufen monatelang weiter, ungenutzte EBS-Volumes überleben gelöschte EC2-Instanzen, vergessene Snapshots akkumulieren sich.

Zweitens: Pay-per-use mit hoher Granularität. Jedes Service-Quotient — Gigabyte-Stunde, Million-Anfragen, Vier-Stunden-Block — sieht für sich klein aus, summiert sich aber über hunderte Services und tausende Ressourcen zu erheblichen Beträgen. Eine einzelne NAT-Gateway-Stunde kostet 4,5 Cent, aber 24 Gateways über 365 Tage produzieren rund 4.000 Euro Sockel-Kosten plus Datenverarbeitung. Niemand würde diese Kosten genehmigen, wenn sie als Einzelposten auf den Tisch kämen — sie entstehen durch Akkumulation hinter den Kulissen.

Drittens: Komplexität der Preismodelle. AWS hat über 200 Services mit individuellen Preisstrukturen, dynamischen Tarifen für Spot-Instanzen, regionalen Unterschieden, Reservations- und Savings-Plans-Varianten. Selbst Cloud-Architekten überblicken nicht jede Preisseite. Die Folge: technische Entscheidungen werden ohne Kostentransparenz getroffen, weil die Kostenfolge erst Wochen später in der Rechnung sichtbar wird.

Viertens: Architektur-Drift. Eine ursprünglich saubere Cloud-Architektur entwickelt sich durch hunderte kleine Änderungen weg vom Optimum. VMs werden zur Sicherheit eine Nummer größer gewählt, Datenbanken auf SSD-Storage gelegt obwohl HDD reichen würde, Logs landen im teuren CloudWatch statt im günstigeren S3, alte Snapshots werden nie aufgeräumt. Jede einzelne Entscheidung ist nachvollziehbar, das Gesamtergebnis ist trotzdem teuer.

Eine Beobachtung aus Audits: in den ersten FinOps-Analysen finden wir typischerweise zwischen 22 und 38 Prozent direkte Verschwendung — Ressourcen ohne Geschäftsnutzen, die sofort abgeschaltet werden können, ohne dass irgendjemand es bemerkt. Das ist nicht Inkompetenz, sondern die natürliche Folge von Cloud-Tempo ohne Kostengegengewicht.

Die vier FinOps-Phasen

Die FinOps Foundation, der von Linux Foundation getragene Branchenverband, definiert vier Phasen, die zyklisch durchlaufen werden. Mittelständische Unternehmen verschieben oft die Reihenfolge oder überspringen Phasen — beides funktioniert nicht. Die vier Phasen bauen aufeinander auf und gehören in jede FinOps-Roadmap.

Phase 1: Inform. Bevor irgendetwas optimiert werden kann, muss Transparenz herrschen. Inform bedeutet: jeder Cloud-Euro ist einem Team, einem Produkt oder einer Umgebung eindeutig zugeordnet. Tagging-Strategie, Cost-Allocation, Showback-Berichte. Ohne saubere Inform-Phase ist jede Optimierung Bauchgefühl. In der Praxis bedeutet Inform: 95 Prozent aller Ressourcen sind getaggt, jede Woche gibt es einen automatischen Kostenbericht pro Team, und jede Person mit Cloud-Konto-Zugang versteht ihre Verantwortlichkeit.

Phase 2: Optimize. Mit der Transparenz aus Phase 1 lassen sich konkrete Hebel ziehen. Right-Sizing überdimensionierter VMs, Commitment-Käufe für stabile Grundlasten, Spot-Instanzen für Batch-Workloads, Storage-Tiers für selten genutzte Daten, Egress-Reduktion durch CDN und VPC-Endpoints. Optimize ist die Phase, in der die größten Einsparungen entstehen — typischerweise 60 bis 70 Prozent der Gesamt-Einsparungen eines FinOps-Programms fallen in den ersten zwölf Monaten dieser Phase an.

Phase 3: Operate. Optimierungen werden nur dann nachhaltig, wenn sie in Routinen, Tools und Prozesse eingebettet sind. Operate bedeutet: Anomalie-Erkennung läuft täglich, Budgets sind in CI/CD-Pipelines integriert, Drift wird automatisch erkannt, Reserved-Instances werden vor Ablauf erneuert. Ohne Operate-Phase fallen Unternehmen typischerweise innerhalb von neun Monaten in den alten Zustand zurück.

Phase 4: Improve. Der Zyklus startet erneut, aber auf höherem Niveau — bessere Forecasting-Modelle, granularer Showback bis auf Produkt-Ebene, Chargeback statt Showback, Cost-as-a-Code in Terraform-Modulen, FinOps-KPIs in Bonus-Strukturen. Improve ist das, was reife FinOps-Programme von ersten Versuchen unterscheidet.

Die meisten mittelständischen Unternehmen, die wir begleiten, brauchen für Phase 1 bis 2 etwa vier bis sechs Monate, für Phase 3 weitere sechs bis neun Monate. Phase 4 ist eine Daueraufgabe ohne Endzustand.

Tagging-Strategie und Showback/Chargeback

Eine konsistente Tagging-Strategie ist die Grundlage jedes FinOps-Programms. Ohne Tags lässt sich keine einzige Kosten-Frage beantworten — weder „Wie viel kostet uns Produkt X?“ noch „Welches Team verursacht den Mehrbedarf?“. In der Praxis hat sich ein Minimal-Set aus fünf Pflicht-Tags bewährt, die für jede Ressource gelten:

• environmentWert aus einer geschlossenen Liste: prod, staging, dev, test, sandbox. Erlaubt sofortige Filterung auf Produktiv- vs. Nicht-Produktiv-Kosten und ist Voraussetzung für Scheduling-Automatisierungen.
• ownerName eines Teams oder einer verantwortlichen Person, nicht eine E-Mail-Alias-Wolke. Verantwortung muss persönlich zuordenbar sein, sonst kümmert sich niemand.
• cost-centerBuchhaltungs-Kostenstelle für die Verrechnung. Wichtig, weil ohne Cost-Center keine saubere monatliche Cost-Allocation möglich ist.
• applicationName des Produkts oder der Anwendung, zu der die Ressource gehört. Erlaubt Produkt-Profitabilität zu rechnen.
• data-classificationOptional, aber wertvoll: public, internal, confidential, restricted. Hilft bei Storage-Tier-Entscheidungen und ist Compliance-relevant.

Wichtig: Tags müssen erzwungen werden, nicht erbeten. AWS Service Control Policies, Azure Policies und GCP Organization Policies können Ressourcen-Erstellung blockieren, wenn Pflicht-Tags fehlen. Wer Tags nur empfiehlt, hat nach zwölf Monaten 40 bis 60 Prozent untaggte Ressourcen — Erfahrungswert aus zahlreichen Audits.

Auf Basis sauberer Tags lassen sich zwei Verrechnungs-Modelle umsetzen. Showback zeigt Teams transparent ihre Verbräuche, ohne sie zu verrechnen — gut als Einstieg, weil ohne Budget-Diskussionen. Chargeback verrechnet die Kosten echt auf die Kostenstelle des Teams — wirksamer, aber politisch anspruchsvoller. In der Mittelstands-Praxis ist ein Stufen-Modell sinnvoll: erst sechs Monate Showback zur Akklimatisierung, dann Chargeback mit klaren Spielregeln.

Schnell-Optimierungen mit hohem Hebel

Die folgenden sechs Optimierungen liefern in fast jedem mittelständischen Cloud-Setup messbare Einsparungen innerhalb von 30 bis 90 Tagen. Sie sind nach Aufwand-Nutzen-Verhältnis geordnet.

Right-Sizing. CPU- und Speicher-Auslastung der laufenden VMs prüfen — AWS Compute Optimizer, Azure Advisor und GCP Recommender liefern fertige Empfehlungen. VMs, die seit 30 Tagen unter 20 Prozent CPU-Auslastung laufen, sind Kandidaten für die nächstkleinere Größe oder eine Burstable-Instance. Typischer Hebel: 8 bis 15 Prozent.

Reserved Instances und Savings Plans. Stabile Grundlast über Ein- oder Drei-Jahres-Commitments abdecken. Compute Savings Plans bei AWS sind für die meisten mittelständischen Unternehmen die beste Wahl, weil sie Instance-Familie und Region flexibel halten. Faustregel: 60 bis 70 Prozent der durchgängigen Last über Commitments. Typischer Hebel: 10 bis 20 Prozent.

Spot-Instanzen. Unterbrechbare Workloads — Batch-Jobs, CI-Builds, ML-Training, Daten-Verarbeitung, Renderings — auf Spot-Kapazitäten verlagern. Spot ist 60 bis 90 Prozent günstiger als On-Demand, kann aber jederzeit zurückgefordert werden. Für CI-Runner und Kubernetes-Worker mit nicht-kritischen Pods ist Spot fast immer die richtige Wahl. Typischer Hebel: 5 bis 15 Prozent.

Storage-Tiers. S3 Intelligent-Tiering, Azure Blob Lifecycle und GCS Autoclass verschieben selten genutzte Objekte automatisch in günstigere Tiers. Lifecycle-Regeln für Logs und Backups: nach 30 Tagen in Infrequent Access, nach 90 Tagen in Glacier oder Archive Storage. EBS gp2-Volumes auf gp3 migrieren — gleiche Performance bei 20 Prozent niedrigeren Kosten. Typischer Hebel: 3 bis 8 Prozent.

Egress- und NAT-Reduktion. VPC-Endpoints für S3, DynamoDB und andere AWS-interne Services vermeiden NAT-Gateway-Kosten. CloudFront für ausgehenden Web-Traffic. Cross-AZ-Traffic minimieren, indem zusammenarbeitende Pods in derselben AZ scheduled werden. Typischer Hebel: 2 bis 7 Prozent.

Aufräumen vergessener Ressourcen. Ungenutzte EBS-Volumes, alte Snapshots, ungenutzte Elastic IPs, gelöschte Lambda-Funktionen mit zurückgebliebenen CloudWatch-Log-Gruppen, Load-Balancer ohne Targets. AWS Trusted Advisor und vergleichbare Tools listen diese in Minuten. Typischer Hebel: 2 bis 5 Prozent in der ersten Aufräum-Welle.

Auto-Scaling und Scheduling

Nicht-produktive Umgebungen verbrauchen in vielen mittelständischen Unternehmen 25 bis 40 Prozent der Cloud-Rechnung — Test- und Entwicklungs-Cluster, Demo-Umgebungen, Staging. Diese Umgebungen sind die offensichtlichsten Kandidaten für Scheduling: nachts und am Wochenende ausschalten, am Werktag-Morgen automatisch hochfahren. Eine Test-Umgebung, die nur Montag bis Freitag von 8 bis 19 Uhr läuft, kostet rund 33 Prozent eines 24/7-Betriebs.

Tools dafür sind etabliert: AWS Instance Scheduler, Azure Automation Start/Stop, GCP Instance Scheduler, oder herstellerunabhängig nOps und ParkMyCloud. Auch native Auto-Scaling-Gruppen lassen sich für nicht-produktive Workloads mit Schedule-basierten Scaling-Policies konfigurieren — minimum 0 in der Nacht, minimum 2 am Tag.

Für produktive Lasten ist Auto-Scaling der wichtigere Hebel. Statisch dimensionierte Produktiv-Cluster werden für Lastspitzen ausgelegt und laufen 80 Prozent der Zeit deutlich unterausgelastet. Horizontal Pod Autoscaler in Kubernetes, EC2 Auto-Scaling-Gruppen oder Lambda für Event-Workloads passen die Kapazität dynamisch an die tatsächliche Nachfrage an. Wichtig: Skalierungs-Grenzen realistisch setzen — ein Auto-Scaler ohne sinnvolle Obergrenze ist eine Kosten-Bombe bei Last-Anomalien.

Die Egress-Kostenfalle

Egress — also Datentransfer aus der Cloud heraus — ist die meist unterschätzte Kostenposition. AWS, Azure und GCP berechnen Egress mit Tarifen zwischen 8 und 12 Cent pro Gigabyte für die ersten 10 Terabyte pro Monat, gestaffelt günstiger danach. Das wirkt unscheinbar, summiert sich aber bei datenintensiven Workloads schnell.

Drei Falltypen sehen wir regelmäßig. Erstens: NAT-Gateway-Traffic. Jeder Container in einem privaten Subnetz, der mit S3 oder DynamoDB spricht, läuft ohne VPC-Endpoint über das NAT-Gateway. Die NAT-Gateway-Datenverarbeitung kostet 4,5 Cent pro Gigabyte zusätzlich zum eigentlichen Egress. Ein Cluster mit 10 Terabyte Monats-Traffic über NAT zahlt allein für NAT rund 460 Euro extra.

Zweitens: Cross-Region- und Cross-AZ-Traffic. 1 Cent pro Gigabyte in jede Richtung klingt günstig, aber bei replizierenden Datenbanken zwischen Regionen oder Microservices, die unbedacht über AZ-Grenzen kommunizieren, akkumulieren sich Beträge im fünfstelligen Bereich.

Drittens: Cloud-Exit-Schock. Wer einen Anbieter wechselt, sieht die Egress-Kosten der Migration auf einen Schlag. Ein Petabyte Migrationsdaten kostet bei AWS Listenpreise rund 50.000 Euro. Wer Cloud-Exit plant, sollte diese Kosten in den Business-Case einrechnen und mit dem aktuellen Anbieter über Migration-Egress-Waiver verhandeln — beide Hyperscaler haben in den letzten 18 Monaten begonnen, Exit-Egress zu reduzieren oder zu erstatten. Mehr dazu in unserem Cluster zur Cloud-Exit-Strategie.

FinOps-Tools im Überblick

Die Tool-Landschaft ist 2026 reif, aber unübersichtlich. Die folgende Übersicht ordnet die wichtigsten Kategorien — sie ist als Orientierung gedacht, nicht als Detail-Vergleich.

Kategorie	Werkzeuge	Geeignet für
Native Cloud-Tools	AWS Cost Explorer + Budgets, Azure Cost Management, GCP Billing Reports	Erster Schritt, kostenlos, ausreichend bis 500.000 Euro Cloud-Spend
Multi-Cloud-FinOps-Plattformen	CloudHealth (Broadcom), Apptio Cloudability, Flexera One	Mehr-Cloud-Setups, Konzern-Strukturen, ab 1 Mio. Euro Cloud-Spend
Moderne SaaS-FinOps	Vantage, CloudZero, Finout, Anodot	Mittelstand mit AWS-Fokus, schnelles Onboarding, attraktive Preise
Automatisierte Optimierung	Cast.ai (K8s), Spot.io (Spot-Mgmt), nOps	Aktive Kosten-Senkung statt nur Reporting
Kubernetes-Kosten	Kubecost, OpenCost, StormForge	Container-Workloads, Pod-genaue Kosten-Attribution

Eine pragmatische Empfehlung für mittelständische Unternehmen unter einer Million Euro Cloud-Spend: starten mit den nativen Tools und einem Showback-Dashboard in einem BI-Tool wie Metabase oder Power BI. Erst bei höherem Spend oder Multi-Cloud-Setup lohnt sich eine Plattform-Lizenz.

Kubernetes-spezifische Kosten

Kubernetes-Cluster sind aus FinOps-Sicht ein Sonderfall, weil die Kosten-Attribution auf Pod-Ebene nicht aus den nativen Cloud-Rechnungen ablesbar ist. Die Cloud-Rechnung zeigt nur die EC2-Knoten oder AKS-Worker, nicht aber, welcher Pod welches Team verursacht. Ohne Kubecost oder OpenCost bleibt Kubernetes eine schwarze Box.

Zwei Hebel sind in Kubernetes besonders wirksam. Node-Right-Sizing: die Knoten-Pool-Größen so wählen, dass Pods sich gut packen lassen. Ein Pool aus großen Knoten verschwendet Kapazität, weil kleine Pods Knoten exklusiv blockieren; ein Pool aus zu kleinen Knoten erzeugt Overhead durch Kubelet und kube-system. Cast.ai und Karpenter wählen Knoten-Typen dynamisch nach Pod-Bedarf — typische Einsparungen 30 bis 50 Prozent gegenüber statischen Knoten-Pools.

Bin-Packing und Resource-Requests: die CPU- und Memory-Requests der Pods müssen realistisch gesetzt sein. Pods, die 4 CPU requesten aber nur 0,5 nutzen, blockieren Kapazität, ohne sie zu verbrauchen. Vertical Pod Autoscaler im Recommend-Modus liefert Vorschläge für realistische Requests. Wer das in der gesamten Cluster-Flotte sauber macht, gewinnt typischerweise 20 bis 30 Prozent zusätzliche Knoten-Effizienz. Detailliert dazu in unserem Cluster zu Kubernetes im Mittelstand.

Org-Modell: FinOps-Team oder FinOps-Champion?

Die organisatorische Verankerung entscheidet, ob ein FinOps-Programm Bestand hat. Drei Modelle haben sich im Mittelstand bewährt, je nach Größe und Cloud-Spend.

FinOps-Champion (bis ~500.000 Euro Cloud-Spend). Eine einzelne Person — typischerweise aus dem Cloud-Engineering-Team mit 20 bis 30 Prozent Stellenanteil — übernimmt die Rolle. Sie pflegt Tagging, erstellt monatliche Showback-Berichte, koordiniert Optimierungs-Initiativen und ist Ansprechpartner für CFO und Geschäftsführung. Das Modell ist günstig, aber abhängig von einer Person.

FinOps-Trio (500.000 bis 2 Millionen Euro Spend). Drei Personen aus Engineering, Finance und Operations bilden ein virtuelles Team. Engineering bringt technische Optimierungs-Expertise, Finance liefert die Verrechnungs- und Budget-Sicht, Operations sichert die Prozess-Einbettung. Jeder mit 10 bis 20 Prozent Stellenanteil. Wirksamer als der Solo-Champion, weil die Disziplinen vereint sind.

Dediziertes FinOps-Team (über 2 Millionen Euro Spend). Eine bis drei Vollzeit-Stellen, eingebettet in eine Cloud-CoE-Struktur. Lohnt sich erst, wenn die direkten Einsparungen das Personal mehrfach finanzieren — Faustregel: 5 Prozent des Cloud-Spend als FinOps-Personalbudget rechnet sich, wenn FinOps mindestens 15 Prozent Einsparung liefert.

Fünf Mittelstands-Spar-Cases mit Zahlen

Die folgenden fünf Cases stammen anonymisiert aus unserer Beratungs-Praxis. Sie zeigen, wie sich FinOps-Hebel in konkreten Mittelstands-Settings auswirken.

Case 1: Maschinenbau, AWS-Spend 420.000 Euro/Jahr. Right-Sizing der überdimensionierten Produktiv-VMs (12 Prozent), Compute Savings Plans für 65 Prozent der Grundlast (14 Prozent), Scheduling der Dev/Test-Umgebungen (8 Prozent), Aufräumen von 220 alten EBS-Snapshots und 18 ungenutzten Elastic IPs (3 Prozent). Gesamt-Einsparung im ersten Jahr: 156.000 Euro, also 37 Prozent.

Case 2: SaaS-Anbieter, AWS-Spend 1,2 Millionen Euro/Jahr. Migration des EKS-Clusters auf Karpenter mit Spot-First-Strategie (18 Prozent), VPC-Endpoints für S3 und ECR (4 Prozent), Storage-Tier-Migration der Logs nach S3 Glacier nach 30 Tagen (5 Prozent), Right-Sizing von 14 RDS-Instanzen (6 Prozent). Gesamt-Einsparung: 396.000 Euro, also 33 Prozent.

Case 3: Handelsunternehmen, Azure-Spend 280.000 Euro/Jahr. Reserved Instances für Datenbank-Server (16 Prozent), Auto-Shutdown aller Dev-VMs außerhalb der Arbeitszeit (11 Prozent), Migration von Premium- auf Standard-SSD-Disks für nicht-kritische Workloads (5 Prozent), Aufräumen verwaister Disks (2 Prozent). Gesamt-Einsparung: 95.000 Euro, also 34 Prozent.

Case 4: Versicherungs-IT, AWS-Spend 850.000 Euro/Jahr. Hier lag der Fokus auf Egress — ein zentraler Daten-Hub schickte täglich 4 Terabyte zwischen Regionen, weil eine alte Architektur-Entscheidung nie hinterfragt wurde. Konsolidierung in eine Region (9 Prozent), VPC-Endpoints (3 Prozent), Compute Savings Plans (12 Prozent), Right-Sizing (7 Prozent). Gesamt-Einsparung: 263.000 Euro, also 31 Prozent.

Case 5: E-Commerce-Mittelständler, GCP-Spend 540.000 Euro/Jahr. Committed Use Discounts für die GKE-Knoten (15 Prozent), Migration auf Standard-Persistent-Disks (4 Prozent), CDN-Optimierung für Bilder und Videos (8 Prozent), Auto-Scaling der Background-Worker auf Spot-VMs (10 Prozent). Gesamt-Einsparung: 199.000 Euro, also 37 Prozent.

Aggregiert über diese und vergleichbare Mandate liegt die durchschnittliche Erstjahres-Einsparung bei 32 bis 36 Prozent — mit einer Implementierungs-Aufwand von 30 bis 80 Personentagen, je nach Komplexität und Tooling. Die Amortisation erfolgt typischerweise innerhalb der ersten drei bis vier Monate.

Reepa-FinOps-Check

Für mittelständische Unternehmen, die einen strukturierten Einstieg in FinOps suchen, bietet Reepa Solutions einen kompakten FinOps-Check als Festpreis-Mandat. Er besteht aus drei Bausteinen: einer Datenanalyse der letzten drei Monats-Rechnungen mit automatisierter Erkennung der Top-20-Optimierungs-Kandidaten, einem zweitägigen Workshop mit Engineering und Finance zur Priorisierung und Verantwortungs-Klärung, und einem 90-Tage-Maßnahmenplan mit konkreten Spar-Zielen pro Hebel.

Der Check dauert insgesamt vier bis sechs Wochen und liefert typischerweise einen identifizierten Einspar-Pfad zwischen 18 und 35 Prozent der aktuellen Cloud-Rechnung. Im Anschluss begleiten wir die Umsetzung wahlweise als reine Beratung oder als Managed-FinOps-Service mit monatlichem Reporting an die Geschäftsführung.

Häufige Fragen