AWS · FinOps
15.000 → 2.500 Euro AWS-Kosten im Monat.
Ohne weniger zu leisten.
Zwei gewachsene AWS-Accounts für Produktion und Staging. Dieselben Anwendungen, dieselben Nutzer, dieselbe Produktionsverfügbarkeit, aber rund 12.500 Euro weniger Kosten pro Monat. Erreicht über zwölf Monate, Maßnahme für Maßnahme und mit gemessenem Vorher-Nachher.
Die Ausgangssituation
Kein einzelner Fehler. Vier Jahre Sediment.
Produktion und Staging kosteten zusammen rund 15.000 Euro netto im Monat. Die Infrastruktur war nicht fahrlässig gebaut. Sie war gewachsen: neue Metriken blieben dauerhaft, Daten wurden nie gelöscht, Kapazität war gegen Lastspitzen dimensioniert und Staging lief rund um die Uhr. Ein typischer FinOps-Ausgangspunkt.
Im Team galt eine Einsparung von zehn bis fünfzehn Prozent als realistisch. Das eigentliche Problem war zunächst nicht die Höhe der Rechnung, sondern ihre fehlende Erklärung. Niemand konnte eine Kostensteigerung sicher einem Workload, einer Datenmenge oder einer konkreten Entscheidung zuordnen.
Die Herausforderung
Sparen, ohne den Betrieb gegen die Rechnung auszuspielen.
Eine niedrige Rechnung ist kein Erfolg, wenn dafür Verfügbarkeit, Wiederherstellbarkeit oder Lieferfähigkeit sinken. Jede Änderung brauchte deshalb einen Rückweg und eine Beobachtungsphase. Gemessen wurden nicht nur Euro, sondern auch Verbrauch, Last und fachliche Bezugsgrößen.
Ebenso wichtig war die Reihenfolge. Commitments wirken schnell, schreiben aber die bestehende Grundlast für ein bis drei Jahre fest. Auf eine aufgeblähte Infrastruktur angewendet hätten sie die Verschwendung rabattiert und gleichzeitig jede spätere Optimierung entwertet.
Mein Ansatz
Messen.
Bereinigen.
Optimieren.
Eine belastbare Kostenbasis schaffen
Cost and Usage Report aktiviert und mit Athena nach Verbrauchsart und Ressource ausgewertet. Daraus entstand eine priorisierte Liste mit erwarteter Ersparnis, Aufwand und Betriebsrisiko für jede Maßnahme.
Löschen und Aufbewahrung begrenzen
Log-Gruppen ohne Retention, alte Snapshots, Backups und Datenreste identifiziert. Erst gestoppt oder archiviert, zwei Wochen beobachtet und erst dann gelöscht. Ergebnis: rund 1.200 Euro weniger pro Monat bei praktisch keinem Risiko.
Beobachtbarkeit und Daten neu zuschneiden
Ungenutzte, hochkardinale CloudWatch-Metriken entfernt, Athena-Daten partitioniert und Aufbewahrung in S3 an den tatsächlichen Bedarf angepasst. Diese beiden Bereiche brachten zusammen rund 5.800 Euro weniger pro Monat.
Kapazität an die echte Last anpassen
ECS-Tasks durch Rightsizing anhand von 14-Tage-Metriken stufenweise verkleinert, Lambda-Speicher gegen Laufzeit gemessen und unterbrechbare Last auf Fargate Spot verschoben. Keine Schätzung, jede Stufe mit einer Woche Beobachtung.
Teure Grundlast aus der Architektur nehmen
Staging außerhalb der Arbeitszeit gestoppt, wiederholte Datenbankabfragen gecacht und Polling durch Ereignisse ersetzt. Kleine Eingriffe mit dauerhaftem Effekt, weil die zugrunde liegende Arbeit nicht mehr anfällt.
Commitments auf die bereinigte Grundlast
Erst als die verbleibende Last stabil war, kamen Reserved Instances, Reserved Capacity und ein Compute Savings Plan mit jeweils einem Jahr Laufzeit hinzu. Ergebnis: weitere rund 2.700 Euro weniger pro Monat.
Eine AWS-Rechnung, die niemand mehr erklären kann?
Die Kostenanalyse liefert Kostentreiber und priorisierte Maßnahmen, bevor jemand Ihre Infrastruktur verändert.
Was schwierig war
Eine Einsparung ist erst real, wenn der Vergleich stimmt.
Credits, Wechselkurse, Steuern, Einmaleffekte und Vorauszahlungen können die Rechnung bewegen, ohne dass sich der Verbrauch ändert. Nach den ersten Commitments sah RDS in der unamortisierten Ansicht plötzlich fast kostenlos aus. Für den Vergleich zählte deshalb die amortisierte Sicht, ergänzt um Stunden, Gigabyte, gescannte Terabytes und Requests.
Der zweite schwierige Teil war organisatorisch: Kostenarbeit konkurriert mit Feature-Arbeit. Eine Maßnahme pro Woche machte das Vorhaben unterbrechbar. Jede Änderung wurde abgeschlossen und gemessen, bevor die nächste begann. So gab es keine halbfertigen Umbauten und nach drei Monaten eine Ergebnisliste, die weitere Entscheidungen mit Daten statt Meinungen ermöglichte.
Das Ergebnis
Weniger Rechnung. Weniger Komplexität. Gleicher Betrieb.
AWS-Kosten
Von rund 15.000 auf rund 2.500 Euro netto im Monat, amortisiert gerechnet.
ohne Architekturänderung
Mehr als die Hälfte der Ersparnis kam aus Bereinigung, Beobachtbarkeit und Daten.
Abstriche am Leistungsumfang
Dieselben Anwendungen, dieselben Nutzer und keine geringere Produktionsverfügbarkeit.
Die Kosten fielen nicht, weil ein Werkzeug einen Rabatt gefunden hat. Sie fielen, weil ungenutzte Arbeit entfernt, verbleibende Last passend dimensioniert und erst danach gebunden wurde. Der vollständige Praxisbericht zeigt alle sechs Phasen mit Beträgen, Messmethoden und den Sackgassen des Projekts.
Eingesetzte Technologien
Kosten verstehen. Verbrauch verändern.
- Cost & Usage Report
- Cost Explorer
- Athena
- AWS Glue
- ECS Fargate
- Fargate Spot
- Lambda
- RDS
- DynamoDB
- S3 Lifecycle
- CloudWatch
- EventBridge
- SQS
- Terraform
- Savings Plans
- Reserved Instances
- Reserved Capacity
Häufig gefragt
Was Auftraggeber vorher wissen wollen.
Wie kamen 83 Prozent weniger AWS-Kosten zustande?
Nicht durch einen einzelnen Rabatt. Rund 7.000 Euro monatlich entfielen bereits durch Aufräumen, passend begrenzte Aufbewahrung, weniger ungenutzte CloudWatch-Metriken sowie bessere Datenhaltung und Athena-Abfragen. Danach folgten Rightsizing, kleinere Architekturänderungen und erst zuletzt Commitments auf die bereinigte Grundlast.
Wurde dafür Funktionalität oder Verfügbarkeit geopfert?
Nein. Dieselben Anwendungen liefen für dieselben Nutzer weiter, ohne Abstriche an der Produktionsverfügbarkeit. Entfernt wurde ungenutzte Arbeit: Daten ohne Abnehmer, Metriken ohne Leser, überdimensionierte Kapazität und Grundlast ohne fachlichen Nutzen.
Warum dauerte die Optimierung zwölf Monate?
Sie lief neben dem Tagesgeschäft in einem sicheren Rhythmus: eine Maßnahme umsetzen, eine Woche beobachten, Ergebnis dokumentieren, dann die nächste. Vollzeit wäre ein kürzerer Zeitraum möglich gewesen. Ein einzelner Sprint wäre für die betrieblich wirksamen Änderungen nicht seriös gewesen.