Viele Teams sind überrascht, wenn die Cloud-Rechnung plötzlich explodiert – obwohl keine großen neuen Features live gegangen sind. Der Grund liegt oft nicht in „zu vielen Servern“, sondern in unsichtbaren Kostentreibern: Datenverkehr (Egress), unkontrollierte Storage-Wachstumsraten, zu große Instanzen, kurzlebige Testumgebungen und eine fehlende Tagging-Disziplin. FinOps-Teams berichten, dass sich die größten Einsparungen häufig durch das Aufräumen kleiner Details erzielen lassen – nicht durch radikale Architekturwechsel.
1) Egress: Der unterschätzte Kostenblock
Datenverkehr aus der Cloud (Egress) ist in vielen Setups der teuerste „Überraschungsposten“ – besonders wenn Logs, Backups, Medien oder Analytics-Daten zwischen Regionen, Accounts oder sogar zwischen Cloud-Anbietern bewegt werden. Je mehr Services verteilt sind, desto öfter zahlen Teams für „Datenbewegung“ statt für Rechenleistung.
- Cross-Region-Traffic: Replikation, Failover, globale Apps.
- Cross-Account/Service: Microservices mit viel interner Kommunikation.
- Multi-Cloud-Transfers: Datensynchronisation zwischen Plattformen.
- CDN/Downloads: Medien, Artefakte, große Kundenexports.
2) Storage wächst „still“ – und wird teuer
Storage ist günstig – bis er es nicht mehr ist. Logs, Snapshots, alte Backups, Build-Artefakte, Data-Lake-Rohdaten: Viele Daten werden geschrieben, aber selten gelöscht. Ohne Lifecycle-Regeln wachsen Kosten linear mit der Zeit, oft ohne sichtbaren Nutzen.
Typische „Storage-Leaks“
- Logs ohne Retention-Policy (oder „unendlich“).
- Snapshots/Backups ohne automatisches Aufräumen.
- Mehrfache Kopien derselben Daten (Dev/Test/Prod).
- Build-Artefakte und Container-Images, die nie gelöscht werden.
Cloud-Kosten steigen selten wegen eines großen Fehlers – meist wegen hundert kleiner „Standard-Einstellungen“.
3) Overprovisioning: „Sicher ist sicher“ kostet
Instanzen werden häufig zu groß gewählt, weil niemand Performance-Risiken eingehen will. Dazu kommen dauerhaft laufende Umgebungen, die eigentlich nur tagsüber oder für kurze Tests gebraucht werden. Eine einfache Rightsizing- und Scheduling-Strategie spart oft sofort – ohne Functional Impact.
- Rightsizing: CPU/RAM an echte Auslastung anpassen.
- Autoscaling richtig konfigurieren: nicht zu konservativ, nicht zu aggressiv.
- Non-Prod abschalten: Dev/Test nachts und am Wochenende stoppen.
4) Tagging, Ownership und Budgets: Ohne Governance keine Kontrolle
Viele Kosten entstehen, weil niemand sicher sagen kann, wem ein Ressourcenblock gehört. Wenn Tags fehlen oder inkonsistent sind, kann man weder Teams belasten noch Budgets definieren. Das führt zu einem bekannten Muster: Alle wollen sparen – aber niemand weiß, wo.
Minimal-Set, das in der Praxis funktioniert
- Owner (Team/Person),
- Environment (prod/stage/dev),
- Service (Produkt/Komponente),
- Cost Center (optional, für Finance),
- Data Class (optional, für Security/Compliance).
5) Die ersten drei FinOps-Maßnahmen, die fast immer wirken
- Egress-Heatmap: wo fließen Daten? Welche Workloads verursachen Transferkosten?
- Lifecycle-Policies: Logs/Backups/Artefakte automatisch löschen oder archivieren.
- „Stop Non-Prod“: zeitgesteuertes Abschalten + Exceptions für Teams, die es brauchen.
Fazit
Cloud-Kosten geraten selten wegen „zu viel Compute“ außer Kontrolle, sondern wegen Egress, Storage-Wachstum und fehlender Governance. Wer Transparenz (Tags/Owner), Automatisierung (Lifecycle/Scheduling) und ein FinOps-Review als Routine etabliert, bekommt Budgets wieder in den Griff – ohne die Cloud-Vorteile zu verlieren.
