Cloud-Data-Platform-Kosten: Praxis-Guide für FinOps (2026)

Cloud-Data-Platform-Rechnungen sind berüchtigt für ihre Überraschungen. Ein Team, das einen neuen Databricks-Workspace „kurz zum Explorieren" hochzieht, kann innerhalb von zwei Wochen 40k$ Monatsspend erzeugen. Eine schlecht geschriebene BigQuery-Query, die ganze Tabellen scannt, kostet pro Run mehr als der Stundensatz des Analysten. Dieser Guide gibt dir die Frameworks und konkreten Techniken, um diese Kosten in den Griff zu bekommen.

TL;DR

• Compute frisst meist 50%+ der Rechnung — fast immer durch Cluster, die nicht runter-skalieren.
• Aggressive Auto-Termination (≤ 60 Min) ist der ROI-Hammer Nr. 1.
• Storage-Lifecycle-Policies: 100 TB richtig getiert spart ~1.500 $/Monat.
• SELECT * vermeiden in BigQuery: eine einzige Query-Änderung kann 56k$/Jahr sparen.
• FinOps-Reife in drei Phasen: Visibility → Optimization → Operations.

Kostenanatomie einer Daten-Plattform

Wer Geld kontrollieren will, muss wissen, wo es hinfließt:

pie title Typische Cost-Verteilung Data Platform
    "Compute (Warehouses/Cluster)" : 52
    "Storage (Raw + Processed)" : 18
    "Networking (Egress/Transfer)" : 12
    "Streaming (Kafka/Kinesis)" : 10
    "Sonstiges (Monitoring/Catalog)" : 8

Die meisten Teams sind überrascht, dass Compute selbst dann dominiert, wenn sie sich „eigentlich idle" fühlen. Schuld ist fast immer Auto-Scaling, das hochskaliert aber nicht runter — plus Long-Running-Cluster, die ihre Workloads überleben.

Compute-Optimierung

1. Aggressive Auto-Termination

Die einzelne Änderung mit dem höchsten ROI für die meisten Plattformen. Default-Auto-Termination steht oft auf „nie" oder „4 Stunden", weil Entwickler nicht auf Cold-Starts warten wollen.

Databricks:

# Via API oder Terraform setzen — über Cluster-Policy erzwingen
cluster_policy = {
    "autotermination_minutes": {
        "type": "range",
        "minValue": 10,
        "maxValue": 60,
        "defaultValue": 20,
        "hidden": False
    }
}

# Laufende Cluster ohne aktiven Workload auditieren
databricks clusters list --output json |   jq '.[] | select(.state == "RUNNING") | 
      {id: .cluster_id, name: .cluster_name, 
       last_activity: .last_activity_time}'

BigQuery: Slot-Reservations vs. On-Demand ist die Schlüsselentscheidung:

Der Break-Even zwischen On-Demand und Reservation liegt bei rund 400 Slot-Stunden/Monat. Profile deinen Workload, bevor du dich bindest.

2. Spot / Preemptible Instances für Batch

Die meisten Data-Engineering-Workloads (ELT, Training-Data-Prep, Model-Batch-Scoring) tolerieren Unterbrechungen, wenn Checkpointing sauber sitzt. Spot-Instances reduzieren Compute-Kosten um 60–80%.

# Databricks — Spot mit Fallback
resource "databricks_job_cluster" "etl_spot" {
  new_cluster {
    num_workers = 4
    node_type_id = "m5d.2xlarge"
    
    aws_attributes {
      availability           = "SPOT_WITH_FALLBACK"
      spot_bid_price_percent = 80
      first_on_demand        = 1  # Driver immer on-demand
    }
    
    spark_conf = {
      "spark.sql.adaptive.enabled"                = "true"
      "spark.sql.adaptive.coalescePartitions.enabled" = "true"
    }
  }
}

3. Compute-Rightsizing

Das häufigste Verschwendungsmuster: Teams fordern große Cluster „für alle Fälle" und skalieren nie zurück.

# Databricks-Cluster finden, die dauerhaft < 20% CPU nutzen
databricks clusters list --output json |   jq -r '.[].cluster_id' | while read id; do
    # Metriken aus Ganglia oder Custom-Logging ziehen
    echo "Cluster: $id"
    databricks clusters get --cluster-id "$id" |       jq '.default_tags, .node_type_id, .num_workers'
done

Etabliere ein Quartals-Rightsizing-Review — vergleiche reale CPU/Memory-Nutzung mit der provisionierten Kapazität bei jedem persistenten Cluster.

Storage-Optimierung

1. Lifecycle-Policies

graph LR
    Ingest[Raw Ingest] -->|Tag 0| Hot[S3 Standard / Hot<br/>$0.023/GB/Mo]
    Hot -->|Tag 30| Warm[S3 Intelligent-Tiering<br/>$0.0125/GB/Mo]
    Warm -->|Tag 90| Cold[S3 Glacier Instant<br/>$0.004/GB/Mo]
    Cold -->|Tag 365| Archive[S3 Glacier Deep Archive<br/>$0.00099/GB/Mo]

Bei einem 100-TB-Datensatz mit 1 TB/Tag Ingest ist die Differenz zwischen „alles in Standard" und einer sauberen Lifecycle-Policy ca. 1.500 $/Monat.

2. Table-Format-Compaction

Delta Lake und Apache Iceberg sammeln Small Files aggressiv an. 10.000 Dateien à 1 MB kosten beim Lesen (und bei S3-LIST-Operationen) mehr als 100 Dateien à 100 MB.

# Delta Lake — wöchentlich als geplanter Job laufen lassen
from delta.tables import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate()

# Optimieren und Z-Order auf häufigste Filter-Spalten
dt = DeltaTable.forPath(spark, "s3://lakehouse/silver/events/")
dt.optimize().executeZOrderBy("event_date", "user_id")

# Alte Versionen aufräumen (Default-Retention = 7 Tage)
dt.vacuum(retentionHours=168)

3. Column Pruning und Compression

-- BigQuery: SELECT * in Production-Queries vermeiden
-- Das scannt 500 GB:
SELECT * FROM events WHERE date = '2024-01-01';

-- Das scannt 8 GB (gleiches Ergebnis):
SELECT user_id, event_type, properties
FROM events
WHERE date = '2024-01-01';

Bei BigQuerys On-Demand-Pricing (6,25 $/TB) spart diese eine Query-Änderung 3,07 $ pro Ausführung. Bei 50 Ausführungen/Tag sind das 56k$/Jahr aus einer einzigen Query.

Query-Cost-Management

BigQuery: Query-Kosten schätzen

Immer schätzen, bevor du ausführst:

# Dry-Run — zeigt verarbeitete Bytes, kostet nichts
bq query   --use_legacy_sql=false   --dry_run   'SELECT user_id, COUNT(*) as sessions
   FROM `project.dataset.sessions`
   WHERE date BETWEEN "2024-01-01" AND "2024-03-31"
   GROUP BY 1'
# Output: Query successfully validated. Assuming the tables are not modified,
# running this query will process 47,832,918,016 bytes.
# Cost: ~$0.30

Snowflake — Warehouse-Sizing und Suspension

-- Warehouse, das nach 1 Min Idle auto-suspended
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE
  COMMENT = 'Analyst queries — suspend after 1 min idle';

-- Warehouse-Credit-Verbrauch monitoren
SELECT 
    warehouse_name,
    SUM(credits_used) as total_credits,
    SUM(credits_used) * 3.00 as estimated_cost_usd,  -- an euren Rate anpassen
    COUNT(DISTINCT query_id) as query_count
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY 2 DESC;

Query-Cost-Attribution

Jede Query mit Team- und Use-Case-Metadaten taggen:

-- Snowflake: Session-Level-Tags
ALTER SESSION SET QUERY_TAG = '{"team":"analytics","project":"q1-reporting","owner":"alice"}';

SELECT ... ;  -- Query ist getaggt

-- BigQuery: Job-Labels
-- Im Python-Client:
job_config = bigquery.QueryJobConfig(
    labels={
        "team": "analytics",
        "project": "q1-reporting",
        "owner": "alice"
    }
)

Das fließt direkt in deine FinOps-Cost-Allocation-Reports.

FinOps-Framework für Daten-Teams

Drei-Phasen-Reifemodell

graph LR
    P1[Phase 1: Visibility<br/>Wissen, was ihr ausgebt] --> 
    P2[Phase 2: Optimization<br/>Verschwendung reduzieren] --> 
    P3[Phase 3: Operations<br/>Kontinuierliche Effizienz]
    style P1 fill:#e74c3c,color:#fff
    style P2 fill:#e67e22,color:#fff
    style P3 fill:#27ae60,color:#fff

Phase 1 — Visibility (Woche 1–4):

• Detaillierte Billing-Exports ins Data-Warehouse aktivieren
• Cost-Dashboard bauen (nach Team, Environment, Service)
• Budget-Alerts bei 80% und 100% des Monatsbudgets

Phase 2 — Optimization (Monat 2–3):

• Top-10-Kostentreiber identifizieren
• Quick-Wins umsetzen: Auto-Termination, Lifecycle-Policies, Query-Optimierung
• Unit-Economics etablieren (Kosten pro Pipeline-Run, pro TB verarbeitet)

Phase 3 — Operations (laufend):

• Wöchentliche Anomalie-Erkennung
• Monatliches Rightsizing-Review
• Quartalsweise Commitment-Erneuerung (Reserved Instances / Committed Use)

Budget-Alerting mit Terraform

# AWS Budget Alert
resource "aws_budgets_budget" "data_platform" {
  name         = "data-platform-monthly"
  budget_type  = "COST"
  limit_amount = "15000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "TagKeyValue"
    values = ["team$data-platform"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["data-platform-lead@company.com"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["data-platform-lead@company.com", "cto@company.com"]
  }
}

Cost-Benchmarks nach Workload-Typ

Quick-Wins-Checkliste

Lauf diese Liste durch — 20–40% Kostenreduktion sind in den meisten Umgebungen sofort drin:

• Auto-Termination ≤ 60 Min auf allen Dev-Clustern
• S3 Intelligent-Tiering auf allen Buckets > 30 Tage alt
• Off-Hours-Shutdown für non-prod Warehouses scheduled
• SELECT * in den Top-20-Queries durch explizite Spalten ersetzen
• Delta/Iceberg-Compaction als Wochen-Job
• Alle Ressourcen mit team, env, project taggen
• Savings Plans / Committed Use für Baseline-Compute
• Development auf kleinere Instance-Typen
• Query-Result-Caching im Warehouse aktivieren
• Cross-AZ- und Cross-Region-Transfer auditieren

Tooling-Übersicht

FAQ

Was kostet ein Databricks-Cluster wirklich? Pro Stunde: ~0,15 $ DBU + EC2-Kosten. Ein i3.xlarge-Cluster mit 4 Workern kostet ca. 4 $/h all-in. Spot drückt das auf ~1,50 $.

Wann lohnen sich BigQuery Slot-Reservations? Ab ~400 Slot-Stunden/Monat. Darunter ist On-Demand günstiger.

Wie unterscheidet sich Snowflake-Pricing in der DACH-Region? Snowflake rechnet in Credits unabhängig vom Standort, aber EU-Regionen (Frankfurt, Dublin) sind ~10% teurer als US-East.

Lohnt sich Reserved Capacity für Streaming-Workloads? Bei vorhersehbarem Throughput: ja, 30–50% Ersparnis. Bei spiky Patterns lieber Auto-Scaling mit Spot.

Fazit

Cost-Management für Daten-Plattformen ist eine laufende operative Disziplin, kein One-Time-Projekt. Die größten Hebel: Compute-Auto- Termination (meist sofort wirksam), Storage-Lifecycle-Policies (zweithöchster ROI), Query-Optimierung (höchster Engineering-Aufwand, höchster Langzeit-Impact).

Erst Visibility, dann Optimization, dann Operationalisierung. Teams, die das gut machen, behandeln Unit-Economics — Kosten pro Pipeline-Run, pro Query, pro TB — als First-Class-Engineering-Metriken neben Latenz und Reliability.

Preisstand: April 2026. Cloud-Provider passen ihre Preise an — verifiziere kritische Annahmen direkt bei AWS, GCP und Azure.