Cloud-Kosten senken - 15 sofort umsetzbare FinOps-Strategien für KMUs

Die Cloud sollte günstiger sein als On-Premise. Ist sie oft nicht – weil Ressourcen laufen, die niemand mehr braucht, Instanzen zu gross dimensioniert sind, und niemand die Rechnung wirklich versteht. Mit ein paar gezielten Massnahmen kannst du 20-40% sparen. Und zwar ziemlich schnell.

"Warum zahlen wir 50.000 Franken pro Monat für... was genau?"

Das ist die Frage, die irgendwann kommt. Vom CFO. Oder vom CEO. Oder von jemandem, der die Cloud-Rechnung zum ersten Mal wirklich anschaut.

Und dann stehst du da. Und die ehrliche Antwort ist oft: "Gute Frage."

(Keine Sorge. Du bist nicht allein. Wir sehen das ständig.)

Warum Cloud-Kosten ausser Kontrolle geraten

Die Cloud macht es verdammt einfach, Ressourcen hochzufahren. Ein paar Klicks, ein Terraform-Script – zack, 50 neue Instanzen.

Runterfahren? Das vergisst man gerne.

Oder der Developer, der die Instanz erstellt hat, ist im Urlaub. Oder hat gekündigt. Oder weiss nicht mehr, wofür das war.

Und so sammeln sich die Zombies. Instanzen, die laufen. Volumes, die niemand braucht. Snapshots von vor zwei Jahren. Alle kosten. Jeden Monat. Automatisch.

Studien zeigen: Durchschnittlich 30% der Cloud-Ausgaben sind pure Verschwendung. Nicht "könnte man optimieren" – sondern Geld für Dinge, die niemandem nützen.

Die gute Nachricht? Das kannst du zurückholen.

7 Strategien, die wirklich funktionieren

Hier sind die Massnahmen, die bei unseren Kunden am schnellsten wirken. Sortiert nach "kannst du morgen anfangen" bis "brauchst etwas Vorlauf".

1. Zombie-Ressourcen finden und killen

Was: Alle ungenutzten Cloud-Ressourcen identifizieren und löschen.

Warum's funktioniert: 10-20% deiner Ressourcen laufen wahrscheinlich ohne echte Nutzung. Einfach... vergessen.

Wie viel du sparst: 10-25% der Gesamtkosten. Sofort.

Was du tun solltest:

EC2/VM-Instanzen mit <5% CPU über 30 Tage? Kandidaten.
Volumes ohne Attachment? Weg damit.
Snapshots älter als 90 Tage? Wirklich noch nötig?
Dev/Test-Umgebungen, die 24/7 laufen? Nachts ausschalten.

Ein Schweizer Fintech, mit dem wir gearbeitet haben, hat allein durch Zombie-Hunting 18.000 Franken pro Monat gespart. In zwei Wochen umgesetzt.

(Der CTO war... überrascht. Und ein bisschen peinlich berührt.)

2. Right-Sizing: Ressourcen an die Realität anpassen

Was: Instanzen auf die tatsächliche Nutzung verkleinern.

Warum's funktioniert: Die meisten Ressourcen sind over-provisioned. "Lieber zu gross als zu klein" ist teuer.

Wie viel du sparst: 15-30% auf Compute-Kosten.

Was du tun solltest:

CPU, Memory, Disk über 30 Tage analysieren
Instanzen mit durchschnittlich <40% Auslastung? Candidates für Downsizing
In Non-Prod testen, dann in Prod ausrollen

Vorsicht: Nicht nur Durchschnitt anschauen. Peak-Last muss noch funktionieren. Und manche Workloads brauchen Headroom.

AWS Compute Optimizer und Azure Advisor geben dir direkt Empfehlungen. Kostenlos. Nutze das als Startpunkt.

3. Reserved Instances für stabile Workloads

Was: 1-3 Jahre Laufzeit vereinbaren, 40-60% Rabatt bekommen.

Warum's funktioniert: Für Workloads, die sowieso 24/7 laufen, ist Pay-as-you-go einfach teuer.

Wie viel du sparst: 40-60% auf die betroffenen Instanzen.

Was du tun solltest:

Production-Datenbanken, Core Services – alles was konstant läuft
Mindestens 6 Monate historische Nutzung analysieren
RIs für ~70-80% der Baseline kaufen (nicht 100% – Flexibilität behalten)

Vorsicht: RIs sind Commitment. Wenn du die Instanz nicht mehr brauchst, zahlst du trotzdem. Also konservativ starten.

4. Spot Instances für flexible Workloads

Was: Überschüssige Cloud-Kapazität zu 70-90% Discount nutzen.

Warum's funktioniert: Cloud-Provider haben Überkapazität. Du kannst sie günstig nutzen – aber sie können jederzeit weg sein.

Wie viel du sparst: 70-90% auf geeignete Workloads.

Geeignet für:

Batch Processing
Data Analytics
CI/CD Build Jobs
Machine Learning Training
Dev/Test-Umgebungen

Nicht geeignet für: Alles, was nicht unterbrochen werden darf. Production-Datenbanken? Nein.

Viele CI/CD-Systeme (GitLab, Jenkins) unterstützen Spot Instances nativ. Das ist ein Easy Win.

5. Dev/Test automatisch ausschalten

Was: Entwicklungs- und Test-Umgebungen nachts und am Wochenende runterfahren.

Warum's funktioniert: Deine Entwickler arbeiten (hoffentlich) nicht 24/7. Warum sollten die Instanzen?

Wie viel du sparst: 60-70% auf Dev/Test-Kosten.

Was du tun solltest:

Scheduled Scaling: 08:00 hoch, 18:00 runter
Wochenenden komplett aus
Exceptions nur auf explizite Anfrage

Ein Handelsunternehmen, mit dem wir arbeiten, hat damit 12.000 Franken pro Monat gespart. Die Entwickler haben's nicht mal gemerkt.

(Okay, einer hat sich beschwert. Aber der hat auch nachts um 3 gearbeitet. Das ist ein anderes Problem.)

6. Tagging: Wissen, was was kostet

Was: Alle Ressourcen mit Owner, Project, Environment taggen.

Warum's funktioniert: Du kannst nur optimieren, was du messen kannst. Ohne Tags weisst du nicht, wer was verursacht.

Wie viel du sparst: Direkt: 0%. Aber es ermöglicht alles andere.

Was du tun solltest:

Tagging-Standard definieren (Owner, Project, Environment, Cost Center)
Policies durchsetzen (keine Ressource ohne Tags)
Kosten nach Tags reporten

Ohne Tagging ist FinOps fast unmöglich. Das ist das Fundament. Investiere hier Zeit.

7. Monatliche Cost-Reviews etablieren

Was: Regelmässig auf die Kosten schauen – nicht nur wenn's brennt.

Warum's funktioniert: Cloud-Nutzung ändert sich. Einmal optimiert ist nach 6 Monaten veraltet.

Wie viel du sparst: Erhält die anderen Savings langfristig.

Was du tun solltest:

Monatliches 30-60 Minuten Meeting (Finance + IT + Key Teams)
Top 10 Cost-Treiber reviewen
Neue Anomalien identifizieren
Quick Wins für nächsten Monat definieren

Das Ritual stirbt, wenn niemand dahintersteht. CFO oder CTO muss es wollen.

Die Reihenfolge, die funktioniert

Du musst nicht alles auf einmal machen. Hier ist die Reihenfolge, die wir empfehlen:

Woche 1-2: Zombie-Ressourcen killen, Dev/Test-Shutdown einrichten
→ Erste Savings, kein Risiko

Woche 3-4: Right-Sizing für die offensichtlichen Fälle
→ Mehr Savings, niedriges Risiko

Monat 2: Tagging einführen, Reserved Instances für stabile Workloads
→ Fundament für langfristige Optimierung

Monat 3+: Monatliche Reviews etablieren, Spot Instances wo sinnvoll
→ Kontinuierliche Verbesserung

Der häufigste Fehler

Der grösste Fehler, den wir sehen: Einmal optimieren und dann vergessen.

Ihr macht ein Projekt. Spart 30%. Feiert. Geht zum nächsten Thema.

Zwei Jahre später: Kosten wieder auf dem alten Level. Oder höher.

Warum? Weil Cloud-Nutzung nicht statisch ist. Neue Features, neue Teams, neue Workloads. Waste kommt zurück. Automatisch.

FinOps ist kein Projekt. Es ist ein Prozess. Wie Fitness. Du gehst nicht einmal ins Gym und bist für immer fit.

(Wäre schön. Ist aber nicht so.)

Was du diese Woche tun kannst

Hole dir die Cloud-Rechnung der letzten 6 Monate – Schau dir den Trend an. Steigt's? Warum?
Liste 5 Ressourcen auf, die du verdächtigst – Die Instanz, die "mal schnell" aufgesetzt wurde. Die Test-Umgebung von vor 2 Jahren.
Frag bei den Owners nach – "Brauchst du das noch?" Die Antwort ist öfter "nein" als du denkst.
Rechne den Effekt – 20% von eurer monatlichen Cloud-Rechnung. Das ist realistisches Einsparpotenzial. Lohnt sich das?

Der Punkt

Cloud-Kosten-Optimierung ist keine Raketenwissenschaft. Die meisten Ersparnisse kommen von offensichtlichen Dingen: Ressourcen, die niemand braucht. Instanzen, die zu gross sind. Dev-Umgebungen, die nachts laufen.

Das Schwierige ist nicht die Technik. Es ist die Disziplin, regelmässig hinzuschauen.

Die Unternehmen, die ihre Cloud-Kosten im Griff haben, sind nicht die mit den besten Tools. Es sind die, die jeden Monat 30 Minuten investieren, um draufzuschauen.

Das klingt unsexy. Ist es auch. Aber es funktioniert.