Zusammenfassung
Es ist eine bekannte Geschichte: Die Cloud-Plattform funktioniert – aber die Rechnung passt nicht. Als ich in dieses Projekt einstieg, hatte der Kunde – ein mittelständisches E-Commerce-Unternehmen – bereits in eine solide, AWS-basierte Analyseplattform investiert. Das System lief stabil, lieferte die erwarteten Business-Insights und nutzte gängige AWS-Dienste.
Auf dem Papier sah alles gut aus. In der Praxis war es jedoch viel zu teuer.
Als wir die Datenlasten und geschäftlichen Anwendungsfälle überprüften, wurde schnell klar: Die Nutzung rechtfertigte die hohen Kosten nicht. Es lag nicht an Unwissenheit oder absichtlicher Überprovisionierung – sie hatten die Architektur seit dem Go-live nie mehr überdacht.
Was folgte, war ein fokussiertes, dreimonatiges Projekt, das die Plattform schlanker, intelligenter und deutlich kosteneffizienter machte.

Wohin das Geld floss
Der Analytics-Stack basierte auf einer typischen modernen Data-Lake-Architektur. Daten wurden täglich in S3 eingespielt, mit AWS Glue verarbeitet, mit Athena abgefragt und in Redshift für aggregiertes Reporting geladen. Dashboards in QuickSight und Drittanbieter-BI-Tools riefen Daten aus mehreren Schichten dieses Stacks ab.
Alles war logisch sinnvoll – aber betrieblich ineffizient.
Die AWS Glue Jobs liefen jede Nacht, unabhängig davon, ob neue Daten eingetroffen waren. Jeder Job nutzte relativ teure Workertypen, selbst bei trivialen Transformationen. Athena-Abfragen scannten vollständige Datensätze, da die Daten unpartitioniert waren und in ausführlichen Formaten wie CSV gespeichert wurden. Redshift lief derweil rund um die Uhr – auch wenn keine Analyst:innen angemeldet waren. Und schließlich war der S3-Bucket mit Roh-Logs und Zwischen-Dateien überfüllt, die nie in günstigere Speicherklassen verschoben wurden.
Die Architektur an sich sowie getroffene Entscheidungen waren nicht katastrophal. Aber zusammen verursachten sie einen schleichenden Verlust durch unnötige Kosten.

Effizient gestalten – nicht nur funktional
Anstatt alles abzureißen und von vorne zu beginnen, konzentrierte ich mich darauf, die bestehende Infrastruktur weiterzuentwickeln – zu behalten, was funktionierte, und zu überarbeiten, was nicht.
Der erste Schritt bestand darin, die fest geplanten, zeitbasierten Glue Jobs durch ereignisgesteuerte Verarbeitung zu ersetzen. Mithilfe einer Kombination aus Lambda und Step Functions führten wir eine schlanke Orchestrierung ein, die ETL-Jobs nur dann auslöste, wenn tatsächlich neue Daten in S3 ankamen. Die Jobdefinitionen wurden angepasst: Aufwendige Transformationen nutzten weiterhin Standard-Worker, einfache Aufgaben wurden auf kostengünstigere Konfigurationen umgestellt.
Dann richteten wir unsere Aufmerksamkeit auf Athena. Der größte Gewinn bestand hier in der Umstrukturierung des S3-Layouts und der Neuformatierung der Daten. Wir konvertierten Rohdateien in Parquet-Format mit Snappy-Komprimierung und führten Hive-artige Partitionierung nach Importdatum ein. Dadurch wurde die gescannte Datenmenge bei Abfragen drastisch reduziert – was sowohl Zeit als auch Kosten sparte – und das Dataset deutlich wartungsfreundlicher machte.
Redshift wurde so umkonfiguriert, dass es sich während der Nebenzeiten mithilfe von EventBridge pausieren ließ. Ein Teil der Reporting-Logik wurde vollständig nach Athena verlagert, wodurch die Bedeutung und Laufzeit des Clusters reduziert wurde. Wir führten auch QuickSight-Dashboards ein, die direkt auf Athena basierten, für leichtere Anwendungsfälle – was unnötige Duplizierung von Speicher und Rechenleistung eliminierte.
Abschließend kümmerten wir uns um das Lifecycle-Management von S3. Lifecycle-Regeln wurden eingeführt, um kalte Daten automatisch nach Glacier zu verschieben und temporäre Verarbeitungsdateien nach einem definierten Aufbewahrungszeitraum zu löschen. Dies hatte sofortige Auswirkungen auf die monatlichen Speicherkosten, die zuvor unbemerkt geblieben waren.

Messbarer Effekt
Am Ende des Projekts lieferte die Plattform die gleichen Erkenntnisse – aber zu einem Bruchteil der Kosten. Die monatliche Rechnung sank um über 65 %. Und genauso wichtig: Das Team gewann ein klareres Verständnis dafür, wie ihre Workloads Cloud-Ressourcen verbrauchten.
Das System wurde ereignisgesteuert statt zeitgesteuert, reaktiv statt dauerhaft aktiv. Die Architektur hatte nicht ihren Zweck verändert, aber ihr Verhalten – und genau das war entscheidend.
Was dieses Projekt erfolgreich machte, war keine radikale neue Technologie oder ein kompletter Austausch. Es ging darum, die Architektur im geschäftlichen Kontext zu verstehen und technische Entscheidungen neu an die tatsächlichen Anforderungen auszurichten. Wir jagten nicht dem neuesten Service oder Muster hinterher – wir machten das bestehende System einfach intelligenter.

Möchten Sie mehr erfahren?

Wenn Ihre AWS-Infrastruktur schneller gewachsen ist als Ihre Kostenkontrolle – Sie sind nicht allein. Dieses Projekt erforderte keinen kompletten Neuaufbau oder eine neue Plattform. Es brauchte nur ein Umdenken.
Wenn Sie mit steigenden AWS-Rechnungen, unklarer Nutzung oder veralteten Datenprozessen zu kämpfen haben – lassen Sie uns sprechen. Die besten Cloud-Lösungen sind nicht immer neu – sondern einfach bessere Versionen dessen, was Sie bereits haben.