Cloud-Kosten senken im Mittelstand: AWS, Azure & GCP

Kurzantwort

Cloud-Kosten wachsen im Mittelstand vor allem deshalb unkontrolliert, weil technische Entscheidungen dezentral getroffen werden, Ressourcen schnell erstellt, aber selten wieder entfernt werden und Kostenverantwortung nicht eindeutig zugeordnet ist. Die wichtigsten Hebel sind Right-Sizing, Abschalten ungenutzter Ressourcen, Zeitpläne für Dev- und Staging-Systeme, passende Commitments beziehungsweise Reservierungen, Storage- und Backup-Regeln sowie eine FinOps-Governance, die Kosten und technische Nutzung gemeinsam steuert.

Warum Cloud so leicht teurer wird als geplant

Die Cloud ist schnell. Genau das ist ihr Vorteil – und ihr Kostenrisiko. Ein Entwickler kann innerhalb weniger Minuten eine Instanz, Datenbank, Testumgebung oder zusätzliche Speicherressource bereitstellen. Für das Projekt ist das effizient. Für die Kostensteuerung entsteht jedoch ein Problem: Das Anlegen ist einfach, das systematische Abschalten und Bereinigen ist organisatorisch deutlich weniger attraktiv.

Bei klassischen Rechenzentren war Kapazität sichtbar und knapp. In der Public Cloud skaliert sie nahezu unsichtbar. Die Rechnung kommt später. Deshalb entsteht Cloud-Verschwendung selten durch einen einzelnen großen Fehlkauf. Sie entsteht durch hunderte kleine Entscheidungen ohne gemeinsame Governance.

Die sechs typischen Ursachen wachsender Cloud-Rechnungen

1. Overprovisioning

Instanzen und Datenbanken werden vorsichtshalber größer dimensioniert als notwendig. Monate später ist die tatsächliche Auslastung deutlich geringer, aber die Größe bleibt unverändert.

2. Dev- und Staging-Umgebungen laufen 24/7

Viele Entwicklungs- und Testsysteme werden nur werktags genutzt. Wenn sie nachts und am Wochenende weiterlaufen, zahlt das Unternehmen für Kapazität ohne produktiven Nutzen.

3. Alte Ressourcen bleiben bestehen

Snapshots, Volumes, IP-Adressen, Testdatenbanken, Load Balancer und Storage-Buckets haben häufig keinen aktiven Eigentümer mehr. Einzeln sind sie klein, in Summe relevant.

4. Commitments passen nicht zum Verbrauch

Reserved Instances, Savings Plans, Committed Use Discounts oder vergleichbare Modelle können günstig sein, wenn die Grundlast stabil ist. Sie werden teuer, wenn Unternehmen zu früh oder zu hoch binden.

5. Daten und Traffic werden unterschätzt

Nicht nur Compute kostet. Storage, Backups, Datenbank-I/O, Netzwerkverkehr und Egress können in datenintensiven Architekturen zu wesentlichen Kostenblöcken werden.

6. Niemand besitzt die Cloud-P&L

Die IT verantwortet Stabilität, Finance die Rechnung und Produktteams die Nutzung. Ohne gemeinsame Steuerung optimiert jeder seine eigene Perspektive – aber niemand den Gesamtpreis.

Right-Sizing: Leistung an reale Nutzung anpassen

Right-Sizing bedeutet, Ressourcen nach realem Bedarf zu dimensionieren. Das klingt banal, ist aber einer der zuverlässigsten Cloud-Hebel. Relevant sind CPU, Arbeitsspeicher, I/O, Laufzeit, Peak-Verhalten und Service-Level.

AWS stellt beispielsweise mit Compute Optimizer und Cost Optimization Hub Empfehlungen für Right-Sizing, inaktive Ressourcen und Commitments bereit. Ähnliche Werkzeuge existieren bei Azure und Google Cloud. Entscheidend ist jedoch nicht, jede Empfehlung automatisch umzusetzen. Technische Risiken, Lastspitzen, Redundanz und Wachstum müssen berücksichtigt werden.

Ein guter Prozess priorisiert Ressourcen mit hohen Kosten und niedriger Auslastung. Danach folgt ein kontrollierter Test, nicht die blinde Verkleinerung im Produktivsystem.

Abschalten statt nur kleiner machen

Eine ungenutzte Ressource ist auch in der kleinsten Größe noch zu teuer. Deshalb sollte jede Cloud-Ressource einen Eigentümer, einen Zweck und eine erwartete Laufzeit besitzen.

Für Dev- und Staging-Umgebungen eignen sich automatische Zeitpläne. Wenn ein System beispielsweise werktags von 7 bis 20 Uhr benötigt wird, muss es außerhalb dieser Zeit nicht zwingend laufen. Das Einsparpotenzial hängt vom konkreten Service ab, aber der Governance-Effekt ist immer derselbe: Nutzung wird zur bewussten Entscheidung.

Commitments: erst messen, dann binden

Cloud-Provider belohnen planbare Nutzung. AWS nennt für bestimmte Savings Plans oder Reservierungen erhebliche Rabatte gegenüber On-Demand. Trotzdem ist ein maximaler Rabatt nicht automatisch maximal wirtschaftlich.

Vor einem Commitment sollten Unternehmen mindestens folgende Fragen beantworten:

• Wie stabil ist die Grundlast über zwölf Monate?
• Welche Workloads werden migriert oder abgeschaltet?
• Welche Instanzfamilien beziehungsweise Services ändern sich?
• Wie hoch ist die bestehende Discount-Coverage?
• Welche Flexibilität verliert das Unternehmen durch die Bindung?

Die Reihenfolge ist wichtig: zuerst ungenutzte Ressourcen entfernen und Right-Sizing durchführen, danach die verbleibende stabile Grundlast rabattieren. Sonst bindet das Unternehmen sich an Verschwendung.

Storage, Backups und Logs als zweiter Cloud-Hebel

Daten werden selten aktiv gelöscht, weil Löschen riskanter wirkt als Speichern. Dadurch wachsen Snapshots, Backups, Logs und Testdaten über Jahre. Eine wirtschaftliche Datenstrategie definiert Aufbewahrungsfristen, Zugriffsfrequenz und passende Storage-Klassen.

Nicht jeder Datensatz benötigt denselben schnellen Speicher. Archivdaten können in günstigere Klassen verschoben werden. Gleichzeitig müssen Compliance- und Restore-Anforderungen beachtet werden. Kostenoptimierung bedeutet hier nicht „Daten löschen“, sondern Daten nach ihrem tatsächlichen Wert zu verwalten.

FinOps für den Mittelstand: kein neues Großprojekt

FinOps wird manchmal als komplexe Governance-Disziplin für Konzerne verstanden. Im Mittelstand reichen oft fünf einfache Regeln:

• Jede Ressource erhält Kostenstelle, Anwendung und Owner.
• Teams sehen monatlich ihre eigenen Cloud-Kosten.
• Abweichungen gegenüber Budget werden kommentiert.
• Unbenutzte Ressourcen werden regelmäßig bereinigt.
• Commitments werden zentral geprüft und freigegeben.

Damit wird Cloud von einer technischen Rechnung zu einer steuerbaren Betriebsausgabe.

Kennzahlen, die CFO und CTO gemeinsam betrachten sollten

• Cloud-Kosten pro Umsatz oder Transaktion.
• Kosten pro Kunde, Bestellung oder Produktinstanz.
• Anteil ungetaggter Ressourcen.
• Auslastung der teuersten Compute-Ressourcen.
• Commitment-Coverage und Commitment-Utilization.
• Storage-Wachstum pro Monat.
• Anteil nichtproduktiver Umgebungen an den Gesamtkosten.
• Forecast-Abweichung zum Budget.

Diese Kennzahlen verbinden Technologie und Wirtschaftlichkeit. Genau das ist der Kern von FinOps.

Unit Economics statt nur Cloud-Rechnung

Eine Cloud-Rechnung von 200.000 Euro kann teuer oder hervorragend sein. Ohne Bezug zur Geschäftsleistung sagt der absolute Betrag wenig aus. Wachstumsunternehmen sollten deshalb Unit Economics definieren: Cloud-Kosten pro Bestellung, pro aktivem Nutzer, pro API-Aufruf, pro verarbeitetem Datensatz oder pro Kunde.

Steigen Cloud-Kosten um 20 Prozent, während Transaktionen um 50 Prozent wachsen, verbessert sich die Effizienz. Steigen beide Größen gleich schnell, bleibt sie konstant. Wachsen die Kosten schneller als der Geschäftstreiber, sollte die Architektur geprüft werden. Diese Sicht verhindert, dass FinOps zu einem reinen Sparprogramm wird und notwendige Skalierung ausbremst.

Chargeback und Showback für Teams

Selbst wenn interne Verrechnung zu aufwendig ist, kann ein Showback helfen: Jedes Produktteam sieht monatlich, welche Kosten es verursacht, ohne dass sofort interne Rechnungen geschrieben werden. Tags, Accounts und Budgets machen die Verantwortung sichtbar.

Ein nächster Reifegrad ist Chargeback, bei dem Kosten tatsächlich auf Kostenstellen oder Produkte verteilt werden. Für viele Mittelständler reicht Showback zunächst aus. Entscheidend ist, dass technische Teams die wirtschaftliche Wirkung ihrer Architekturentscheidungen erkennen.

Checkliste: Cloud-Kosten in 30 Tagen strukturieren

• Kosten nach Account, Subscription oder Projekt exportieren.
• Top-20-Ressourcen nach Monatskosten identifizieren.
• Ressourcen ohne Owner oder Tag markieren.
• CPU-/Memory-Auslastung der teuersten Compute-Komponenten prüfen.
• Dev/Staging-Zeitpläne definieren.
• Alte Snapshots, Volumes und Testdatenbanken identifizieren.
• Storage-Klassen und Retention-Regeln prüfen.
• Egress- und Netzwerkverkehr analysieren.
• Erst nach Bereinigung Commitments bewerten.
• Monatliches FinOps-Review zwischen Finance und IT etablieren.

Häufige Fragen

Welche Cloud ist am günstigsten – AWS, Azure oder Google Cloud?

Das lässt sich pauschal nicht seriös beantworten. Architektur, Services, Volumen, Commitments, Datenverkehr und vorhandene Kompetenzen bestimmen den effektiven Preis. Ein Providerwechsel nur aus Preisgründen kann zusätzliche Migrationskosten erzeugen.

Wie viel kann man bei Cloud-Kosten sparen?

Das hängt stark von der Ausgangslage ab. Unternehmen mit wenig Governance haben häufig größere Potenziale als Teams, die FinOps bereits konsequent betreiben. Prozentwerte sollten deshalb immer aus konkreten Nutzungsdaten abgeleitet werden.

Braucht man dafür Zugriff auf den Quellcode?

Für eine erste Kostenanalyse meist nicht. Billing-Daten, Ressourceninventar und Nutzungsmetriken reichen häufig aus, um strukturelle Potenziale zu erkennen. Technische Änderungen müssen anschließend mit den verantwortlichen Teams abgestimmt werden.

Fazit

Cloud-Kosten steigen nicht, weil Cloud grundsätzlich teuer ist. Sie steigen, wenn Geschwindigkeit ohne Kosten-Governance wächst. Right-Sizing, Abschaltpläne, Datenhygiene, passende Commitments und klare Verantwortlichkeiten bringen Kontrolle zurück.

Für eine tiefere Einzelanalyse siehe auch Cloud-Kosten senken: 7 Hebel, Dev- und Staging-Umgebungen und Storage- und Backup-Kosten. Wenn Sie Ihre Cloud-Rechnung unabhängig benchmarken möchten, können Sie ein kostenfreies Erstgespräch vereinbaren.