Das Cloud-Kostenparadox
Die Cloud sollte Kosten senken. In der Praxis passiert oft das Gegenteil: Unternehmen migrieren in die Cloud und zahlen nach 18 Monaten mehr als zuvor — bei gleicher Leistung.
Der Grund ist nicht die Cloud selbst, sondern die fehlende Kostendisziplin. On-Premise zwingt zu Budgetplanung vor dem Kauf. In der Cloud ist jede Ressource einen API-Call entfernt — und die Rechnung kommt am Monatsende.
Die drei größten Kostentreiber
1. Überdimensionierte Instanzen
Die häufigste Verschwendung: Instanzen, die für Spitzenlast dimensioniert sind, aber 90 % der Zeit bei 10 % Auslastung laufen. Eine m5.2xlarge (8 vCPU, 32 GB) kostet ~$280/Monat. Wenn die Auslastung selten über 20 % steigt, reicht eine m5.large (2 vCPU, 8 GB) für ~$70/Monat.
Maßnahme: CPU- und Memory-Auslastung über 2 Wochen messen. Instanzen mit unter 30 % Durchschnittsauslastung um eine Größe reduzieren.
2. Vergessene Ressourcen
Entwicklungsumgebungen, die abends und am Wochenende laufen. Test-Cluster, die nach dem Sprint nicht abgebaut werden. Snapshots, die sich über Monate ansammeln.
Maßnahme: Tagging-Pflicht für alle Ressourcen (Team, Umgebung, Ablaufdatum). Automatisches Herunterfahren von Dev/Test außerhalb der Arbeitszeiten.
3. Fehlende Commitment-Nutzung
On-Demand-Preise sind die teuerste Option. Reserved Instances (AWS) oder Reservierungen (Azure) sparen 30-60 % — aber nur, wenn die Baseline-Last vorhersehbar ist.
Maßnahme: Baseline-Last identifizieren (die Last, die immer da ist). Für diese Last 1-Jahres-Reservierungen buchen. Für variable Last Spot/Preemptible Instances nutzen.
FinOps in vier Schritten
Schritt 1: Transparenz schaffen
Ohne Sichtbarkeit keine Optimierung:
- Cost Allocation Tags auf allen Ressourcen (Projekt, Team, Umgebung)
- Monatliches Cloud-Kosten-Dashboard mit Trend und Anomalie-Erkennung
- Budgets mit Alerts — nicht am Monatsende überrascht werden
Schritt 2: Verschwendung eliminieren
Die Quick Wins, die in jedem Unternehmen existieren:
- Ungenutzte Elastic IPs, Load Balancer, leere Storage-Buckets löschen
- Dev/Test-Umgebungen automatisch abschalten (19:00–07:00, Wochenende)
- Alte Snapshots und AMIs aufräumen
- Übergroße Instanzen rightsizen
Schritt 3: Architektur optimieren
Mittelfristige Maßnahmen mit höherem Hebel:
- Auto Scaling korrekt konfigurieren (nicht nur einrichten, sondern tunen)
- Spot Instances für fehlertolerante Workloads (Batch, CI/CD, Datenverarbeitung)
- Serverless für sporadische Workloads (Lambda/Functions statt dauerhaft laufender Server)
- Storage Tiering — nicht alle Daten brauchen S3 Standard oder Premium SSD
Schritt 4: Kultur etablieren
FinOps ist kein einmaliges Projekt:
- Monatliches FinOps-Review mit Engineering und Finance
- Team-Budgets — jedes Team sieht und verantwortet seine Cloud-Kosten
- Cost-aware Engineering — Architekturentscheidungen berücksichtigen Kosten
Einsparpotenziale nach Kategorie
| Maßnahme | Typische Einsparung | Aufwand |
|---|---|---|
| Rightsizing | 20-30 % | Niedrig |
| Dev/Test abschalten | 60-70 % dieser Kosten | Niedrig |
| Reserved Instances | 30-40 % der Baseline | Mittel |
| Spot Instances | 60-90 % für geeignete Workloads | Mittel |
| Storage Tiering | 40-60 % der Storage-Kosten | Niedrig |
| Architektur-Redesign | 30-50 % | Hoch |
Fazit
Cloud-Kosten optimieren ist keine Raketenwissenschaft. Die größten Einsparungen kommen aus drei einfachen Prinzipien: nicht mehr bezahlen als nötig (Rightsizing), nicht bezahlen wenn nicht gebraucht (Scheduling), und weniger pro Einheit bezahlen (Commitments). Die Herausforderung liegt nicht im Wissen, sondern in der Disziplin — und genau dafür gibt es FinOps.