Cloud-Kosten senken durch clevere Architektur-Entscheidungen

Warum Architektur der größte Kostenhebel ist

Viele Sparinitiativen fokussieren sich auf Reservierungen, Rabatte oder sogar den Wechsel des Cloud-Anbieters. Das hilft kurzfristig, allerdings verfehlt es oft den Kern. Denn letztlich bestimmen Bewegung, Speicherung und Verarbeitung der Daten bis zu 80 % der Rechnung. Deshalb genügen drei Leitfragen, um große Potenziale freizulegen:

• Plattform-Konsolidierung: Nutzen wir mehrere Systeme für denselben Zweck (z. B. zwei analytische Speicher)?
• Datenbewegung: Kopieren wir zu viele Daten, zu häufig oder zu früh in teure Schichten?
• Compute-Nutzung: Laufen Cluster dauerhaft, obwohl sie nur zeitweise gebraucht werden?

Die Antworten entscheiden, ob Ihre Cloud ein Effizienz-Enabler oder eine Kostenfalle ist.

Die häufigsten Kostenfaktoren in modernen Data-Architekturen

1) Doppelte Datenhaltung statt „Golden Copy“

Parallel betriebene analytische Speicher (z. B. Data Warehouse und Lakehouse) erzeugen doppelte Speicher-, Abfrage- und Synchronisationskosten. Häufig bleibt aus historischen Gründen ein zweites System aktiv, obwohl alle Use Cases bereits auf dem neueren Stack laufen. Best Practice: Eine zentrale Golden Copy im Lakehouse (z. B. Delta Lake) sowie klare Schnittstellen für BI und AI.

2) Always-On-Compute

Dauerhaft laufende Cluster sind ein klassischer Kostenfresser. Besonders teuer wird es, wenn Entwicklungs-, Test- und Produktionsressourcen parallel durchlaufen. Best Practice: Job-basierte Cluster, Auto-Termination (z. B. 10–15 Minuten Inaktivität) sowie Spot/Preemptible-Instanzen für nicht-kritische Workloads.

3) Ungefilterte Datenströme

Marktplätze, IoT und Log-Quellen erzeugen Milliarden von Events. Wer jedoch alles ungefiltert repliziert, bezahlt für Daten, die nie genutzt werden. Best Practice: Pre-Processing am Rand (Edge/On-Prem/Staging), Deduplikation sowie Change-Only-Replikation.

4) Lizenz- und Tool-Wildwuchs

Mehrere BI-Tools parallel, zu viele Creator-Lizenzen und Schatten-Dashboards fressen Budget. Zudem steigt der Betriebsaufwand. Best Practice: Ein Primär-BI-Tool, Viewer-/Explorer-Rollen wo immer möglich und Governance gegen „Dashboard-Drift“.

5) Ineffiziente ML-Workflows

Wiederholte Volltrainings, zu große Feature-Sätze und fehlendes Experiment-Tracking treiben Compute-Kosten unnötig hoch. Außerdem verlängern sie Laufzeiten. Best Practice: Inkrementelles Training, Feature-Selektion, MLflow für Reproduzierbarkeit sowie klare Stopp-Kriterien.

6) Teure Abfragen durch schwaches Datenlayout

Kleine, fragmentierte Dateien und fehlendes Clustering erhöhen Scan-Volumina und Laufzeiten. Folglich steigen sowohl Kosten als auch Latenzen. Best Practice: Compaction, sinnvolle Partitionierung, Clustering (z. B. Z-Ordering im Delta Lake) sowie die Trennung von Hot und Cold Storage.

3-Phasen-Plan: Von Quick Wins bis Nachhaltigkeit

Der folgende Plan lässt sich in den meisten Data-Landschaften direkt anwenden – und zwar unabhängig vom konkreten Cloud-Anbieter.

Phase 1 – Quick Wins (0–3 Monate)

• Redundante Plattformen deaktivieren: Liegen die Daten im Lakehouse, bleibt ein separates DWH nur für zwingende Spezialfälle bestehen – ansonsten abschalten.
• Cluster-Kosten sofort senken: Job-Cluster, Auto-Termination sowie Spot/Preemptible-Instanzen einführen.
• Lizenz-Audit: BI-Lizenzen auf Viewer/Reader konsolidieren; Schatten-Dashboards gezielt stilllegen.

Erwarteter Effekt: bis zu 30 % geringere monatliche Kosten.

Phase 2 – Mid Term (3–9 Monate)

• CDC vereinfachen: Eine einzige Replikationskette mit Ziel Golden Copy (Delta Lake). Keine doppelten Schreibvorgänge in verschiedene Speicher.
• Pre-Filtering & Aggregation: Nur relevante Änderungen (z. B. Preis-/Bestandsupdates) in die Cloud übernehmen.
• Speicher optimieren: Compaction, Clustering, Hot vs. Cold sowie Lebenszyklus-Regeln (Retention) etablieren.
• Transparenz schaffen: Kosten-Tags (Projekt/Abteilung/Use Case) und Dashboards für Verbrauch und Kosten.

Erwarteter Effekt: weitere 20–30 % Einsparung durch weniger Datentransfers und effizientere Abfragen.

Phase 3 – Long Term (9–18 Monate)

• Plattform konsolidieren: Eine Kernplattform (z. B. Databricks oder Snowflake oder reiner Delta-Lake-Stack) reicht in der Regel aus.
• FinOps verankern: Regelmäßige Reviews, Budget-Alerts, Chargeback/Showback sowie Governance für Daten und Dashboards.
• ML operationalisieren: MLflow Model Registry, reproduzierbare Pipelines, gezielte Trainingsfenster und klare Stoppkriterien.

Erwarteter Effekt: Nachhaltige Kostentransparenz und Vermeidung erneuter Kostenexplosionen.

Praxisbeispiel: Von 100.000 € auf 45.000 € pro Monat

Ein Handelsunternehmen betrieb sein Reporting parallel auf Data Warehouse und Lakehouse. Zusätzlich liefen mehrere Always-On-Cluster, und es gab breite Creator-Lizenzen im BI-Tool. Nach der Konsolidierung auf das Lakehouse, mit Job-Clustern und Auto-Termination sowie einem License-Right-Sizing, sanken die monatlichen Kosten von 100.000 € auf 45.000 € – bei gleichbleibender Datenqualität und kürzeren Laufzeiten.

Architektur-Checkliste für sofortige Einsparungen

• Golden Copy: Gibt es genau eine autoritative Datenhaltung für Analytics/AI?
• Compute-Automatisierung: Auto-Termination aktiv und Spot/Preemptible für Jobs genutzt?
• Datenfluss-Diät: Werden nur relevante Änderungen repliziert? Und sind Duplikate ausgeschlossen?
• Abfrageeffizienz: Compaction, Partitionierung und Clustering/Z-Ordering konsequent umgesetzt?
• BI-Lizenzmodell: Creator nur für Ersteller; Viewer/Explorer für Konsumenten?
• FinOps: Tags sowie Kosten-Dashboards vorhanden? Außerdem Budgets und Alerts definiert?
• ML-Disziplin: Inkrementelle Trainings, Feature-Selektion und reproduzierbare Pipelines?

FAQ: Häufige Fragen zur Kostenreduktion

Ist die Abschaltung eines Data Warehouses riskant?

Nein, sofern Sie schrittweise migrieren: Use Cases priorisieren, Tests automatisieren, eine längere Parallelphase einplanen und erst danach das Alt-System dekommissionieren.

Wie viel sparen Auto-Termination und Spot-Ressourcen wirklich?

In der Praxis sind 20–40 % bei Compute realistisch. Insbesondere in Batch-Szenarien mit Spot/Preemptible ist häufig noch mehr möglich.

Welche Metriken sollte ein FinOps-Dashboard zeigen?

Kosten je Projekt/Abteilung/Use Case, Compute-Auslastung, Storage-Wachstum, Scan-Volumen pro Abfrage, Pipeline-Laufzeiten sowie Budget-Alerts.

Was bringt die BI-Tool-Konsolidierung?

Ein Primär-Tool reduziert Lizenzen, Schulungsaufwände und Schatten-Dashboards. Zudem senken Viewer-Rollen die Kosten ohne Produktivitätsverlust.