DataModerne Datenarchitektur

Cloud-Datenkosten senken, ohne die Analytics zu ruinieren

Cloud-Rechnungen für Dateninfrastruktur gehören inzwischen zu den am schnellsten wachsenden Posten in IT-Budgets von Unternehmen, und die meisten Organisationen zahlen zu viel, ohne es zu merken. Dieses Playbook gibt CDOs eine konkrete Abfolge von Maßnahmen, um die Ausgaben deutlich zu senken und die analytische Leistungsfähigkeit zu erhalten.

🎙️

Podcast anhören

4 min

Das Muster ist bekannt. Eine Datenplattform wird unter Druck aufgebaut, Teams stapeln Compute, Storage verteilt sich über drei Clouds, und irgendwann nach 18 Monaten ruft der CFO an. Cloud-Datenkosten haben die Eigenschaft, sich leise aufzusummieren: Snowflake-Query-Kosten, BigQuery-Slot-Reservierungen, S3-Storage für Daten, die niemand mehr abfragt, Databricks-Cluster, die nachts im Leerlauf laufen. Laut Gartner (Stand der Auswertung 2024, in Budgetgesprächen 2026 noch breit zitiert) liegt Cloud-Waste über alle Unternehmens-Workloads hinweg bei 30 bis 35 Prozent der Gesamtausgaben. Für Datenteams ist der Wert oft höher, weil Dateninfrastruktur weniger überwacht wird als Anwendungsinfrastruktur.

Besonders schmerzhaft ist das jetzt, weil viele Organisationen in der Expansionsphase 2021-2023 mehrjährige Cloud-Verträge abgeschlossen haben und diese nun mit deutlich weniger Verhandlungsmacht neu verhandeln oder verlängern als erwartet. Gleichzeitig werden LLM-getriebene Analytics-Workloads auf die bestehende Infrastruktur gelegt, wodurch neue Kostentreiber entstehen, bevor die alten unter Kontrolle sind. CDOs, die hier nicht bewusst handeln, sehen ihre Budgets von Infrastruktur aufgezehrt, bevor irgendein Wert nachgewiesen ist.

Eine konkrete Abfolge zur Kostensenkung

Schritt 1: Ein ehrliches Inventar erstellen, bevor Sie irgendetwas anfassen

Die meisten Kostensenkungsprogramme scheitern, weil Teams mit der Optimierung beginnen, bevor sie verstehen, was sie eigentlich betreiben. Nehmen Sie sich zwei Wochen Zeit für einen vollständigen Katalog der aktiven Compute-Cluster, Storage-Buckets, Datenpipelines und Query-Muster. In Snowflake liefert das Schema ACCOUNT_USAGE den Credit-Verbrauch der Warehouses pro Nutzer und pro Query für das vergangene Jahr. In BigQuery zeigt die View INFORMATION_SCHEMA.JOBS den Slot-Verbrauch und die abgerechneten Bytes pro Query. Exportieren Sie das in ein einfaches Dashboard. Sie suchen nach drei Dingen: Compute im Leerlauf oder nahe daran, Storage, der seit über 90 Tagen nicht gelesen wurde, und teure Queries auf nicht optimierten Tabellen.

Schritt 2: Zuerst Compute angehen, das bewegt am schnellsten etwas

Compute im Leerlauf ist die größte einzelne Verschwendungsquelle. Die Auto-Suspend-Einstellungen von Snowflake-Warehouses bleiben häufig auf dem Default (10 Minuten) oder sind ganz deaktiviert. Setzen Sie sie in Entwicklungsumgebungen auf 60 Sekunden und prüfen Sie, ob XL-Warehouses und größer durch tatsächliche Concurrency-Daten gerechtfertigt sind, nicht durch Annahmen. Auditieren Sie bei Databricks die Cluster-Policies, damit für Batch-Workloads Jobs-Cluster genutzt werden und nicht All-Purpose-Cluster, die durchlaufen. Ein großer europäischer Händler hat seine Databricks-Ausgaben in einem einzigen Quartal um 40 Prozent gesenkt, einfach indem er Cluster-Auto-Termination nach 15 Minuten erzwang und nächtliche Batch-Jobs von interaktiven Clustern auf Jobs-Cluster migrierte.

Schritt 3: Storage richtig in Tiers aufteilen

Nicht alle Daten sollten in derselben Storage-Klasse liegen. Heiße analytische Tabellen, die täglich abgefragt werden, gehören in Performance-Storage. Daten, die älter als 18 Monate sind und aus Compliance- oder Audit-Gründen existieren, gehören in Cold Storage, auf AWS S3 also Glacier Instant Retrieval oder Glacier Flexible Retrieval, je nachdem, welche Zugriffszeiten Sie akzeptieren. Der Kostenunterschied zwischen S3 Standard und S3 Glacier Flexible Retrieval liegt bei rund 80 Prozent pro GB und Monat. Richten Sie eine automatisierte Lifecycle-Policy ein, die Daten anhand des letzten Zugriffszeitstempels durch die Tiers verschiebt. Das ist unspektakuläre Arbeit, bringt aber bei Organisationen, die das noch nie gemacht haben, verlässlich 20 bis 30 Prozent weniger Storage-Kosten.

Schritt 4: Die Query-Muster reparieren, die Geld verbrennen

In spaltenorientierten Systemen wie BigQuery und Redshift sind Full-Table-Scans auf breiten Tabellen eine teure Angewohnheit. Partitionieren Sie große Tabellen nach Datum oder nach einer Filterspalte mit hoher Kardinalität, die Ihre Analysten tatsächlich nutzen. In BigQuery können partitionierte Tabellen in Kombination mit Clustering die abgerechneten Bytes pro Query bei gängigen analytischen Mustern um 60 bis 90 Prozent reduzieren, laut Googles eigener Dokumentation (Google ist hier der Anbieter, behandeln Sie die Spanne also als optimistisch und validieren Sie sie an Ihren echten Workloads). Arbeiten Sie mit Ihrem Data-Engineering-Team daran, in Ihrem BI-Tool oder der Notebook-Umgebung ein Query-Cost-Gate einzubauen, das Nutzer warnt, wenn eine Query mehr als einen definierten Schwellenwert scannt.

Schritt 5: Reservierte Kapazitätszusagen überprüfen

Wenn Sie Snowflake, BigQuery oder Redshift nutzen, haben Sie mit hoher Wahrscheinlichkeit die Möglichkeit, reservierte Kapazität mit Rabatt gegenüber On-Demand-Preisen zu kaufen. Das Problem: Die meisten Organisationen haben Reservierungen auf Basis von Peak-Nutzungsprognosen gekauft, die zu hoch angesetzt waren. Ziehen Sie 90 Tage echte Verbrauchsdaten heran, bevor Sie eine Zusage verlängern oder ausweiten. Ein Snowflake-Enterprise-Vertrag, der auf Basis gemessener Nutzung von einer Reservierung über 200 Credits auf 120 Credits angepasst wird, kann bei mittleren bis großen Deployments Hunderttausende Dollar Ersparnis pro Jahr bedeuten.

Fallstricke, über die Sie stolpern werden

Der häufigste Fehler ist, Entwicklungs- und Staging-Umgebungen aggressiv zu optimieren und die Produktion unangetastet zu lassen, weil „wir nicht riskieren können, etwas kaputt zu machen“. In der Produktion liegt das meiste Geld. Holen Sie Ihre Data-Engineering-Leads dazu und etablieren Sie einen Change-Control-Prozess für die Optimierung in der Produktion, statt sie zu vermeiden.

Die zweite Falle ist, Kostensenkung als einmaliges Projekt zu behandeln. Cloud-Kosten driften kontinuierlich nach oben, weil neue Pipelines dazukommen und Query-Volumen wachsen. Verankern Sie Kostenmetriken in den Sprint-Reviews Ihres Datenteams, so wie Anwendungsteams Latenz verfolgen. Benennen Sie einen namentlichen Owner, kein Komitee.

Achten Sie auf die Ausrede „das macht das FinOps-Team“. FinOps-Teams sind sehr gut bei Anwendungs- und Infrastrukturkosten, aber die Optimierung einer Datenplattform verlangt domänenspezifisches Wissen: verstehen, warum ein bestimmtes dbt-Modell täglich läuft, obwohl es nur wöchentlich laufen müsste, oder warum ein Fivetran-Connector eine Tabelle im 15-Minuten-Intervall synchronisiert, wenn sie stromabwärts einmal pro Tag konsumiert wird. CDOs müssen dieses Problem selbst verantworten und nicht vollständig an eine finanznahe Funktion delegieren.

Und schließlich: Senken Sie die Kosten nicht, indem Sie die Datenverfügbarkeit für analytische Teams einschränken. Das ist keine Optimierung, das ist reine Verschlechterung. Jede Kostenmaßnahme sollte daran geprüft werden, ob sie Query-SLAs oder die Datenaktualität für produktive Dashboards beeinträchtigt.

Quick Wins für diese Woche

  • Ziehen Sie Ihre 50 teuersten Queries der letzten 30 Tage und markieren Sie alle, die Full-Table-Scans auf Tabellen über 100 GB machen
  • Setzen Sie heute Auto-Suspend auf 60 Sekunden für alle Snowflake-Warehouses außerhalb der Produktion
  • Identifizieren Sie Storage-Buckets oder Datasets ohne Leseaktivität in den letzten 90 Tagen und terminieren Sie ein Review-Meeting mit den Data Ownern
  • Prüfen Sie, ob Ihre Sync-Zeitpläne in Fivetran oder Airbyte zur tatsächlichen Konsumfrequenz stromabwärts passen und nicht einfach den Default-Einstellungen folgen

Die Organisationen, die Cloud-Datenkosten 2026 gut steuern, geben nicht zwangsläufig weniger aus als ihre Wettbewerber, sie geben bewusst aus. Genau zu wissen, was jede Pipeline und jede Query kostet, und diese Kosten an nachgewiesenen Business-Wert zu binden, verschafft einem CDO die Glaubwürdigkeit, wenn er Budget für etwas Neues fordert.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1Data FinOps: Cloud-Datenkosten im GriffModerne Datenarchitektur
  2. 2Performance & Skalierbarkeit: Partitionierung, Clustering & KostenoptimierungModerne Datenarchitektur
  3. 3Cloud-Dateninfrastruktur: Services, Kosten & MigrationModerne Datenarchitektur
  4. 4Chargeback- & Showback-ModelleDatenprodukte & Monetarisierung
  5. 5Die Daten-P&LDatenprodukte & Monetarisierung

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.