Databricks Cluster Policies für Cost Control: Praktischer Guide

TL;DR: Cluster Policies sind das wirksamste FinOps-Tool in Databricks. Erzwinge Auto-Termination, Spot-Instances und Größenlimits, plus verpflichtende Tags für Chargeback. Realistisch 35–50 % weniger Compute-Spend nach Einführung in einem 15-Personen-Team.

Databricks ist mächtig. Es ist auch bemerkenswert einfach, versehentlich einen 32-Node-Standard_E64s_v3-Cluster hochzufahren und zu vergessen, ihn zu terminieren. Wer einen Databricks-Workspace länger als einen Monat gemanagt hat, hat eine Story dazu.

Cluster Policies sind Databricks' Mechanismus, um diese teuren Fehler zu verhindern, ohne die Flexibilität deines Teams zu killen. Richtig gemacht sind sie unsichtbare Guardrails — deine Engineers arbeiten frei innerhalb einer sicheren Grenze.

Was sind Cluster Policies?

Eine Cluster Policy ist ein JSON-Dokument, das die Werte einschränkt, die User beim Erstellen oder Editieren von Clustern setzen dürfen. Policies können:

• Fest einen Wert setzen (z. B. immer Auto-Termination aktiviert)
• Begrenzen auf eine Range oder Liste (z. B. max 8 Workers)
• Defaults setzen (z. B. Default auf Spot-Instances)
• Felder verstecken im UI (Creation-Experience vereinfachen)
• Werte erzwingen (z. B. Cluster müssen mit Cost-Center getaggt sein)

Policies werden Usern, Gruppen oder Service-Principals zugewiesen. Ein User kann nur Cluster mit den Policies erstellen, auf die er Zugriff hat (außer er ist Workspace-Admin).

Warum Cluster Policies zählen (mit Zahlen)

Ein Team aus 10 Data-Engineers. Ohne Policies:

Ein einzelner vergessener Cluster, der über ein Wochenende läuft = ~150 $ Waste. Mal 10 Engineers über ein Jahr und du redest über Tausende vermeidbaren Spend.

Mit Cluster Policies, die Auto-Termination und Spot-Instances durchsetzen:

• Auto-Termination nach 30 min = ~1,50 $ vergeudet statt 30 $
• Nutzt Spot-Instances = ~60 % günstigerer Baseline

Policy-Definition-Language

Policies sind JSON-Dokumente. Jedes Attribut mappt auf einen Constraint-Typ:

{
  "attribute_name": {
    "type": "fixed | range | allowlist | blocklist | regex | unlimited | forbidden",
    "value": "...",
    "minValue": 0,
    "maxValue": 10,
    "values": [],
    "defaultValue": "...",
    "hidden": true
  }
}

Policy-Beispiele

1. Basis-Cost-Control-Policy (für alle Data Engineers)

{
  "autotermination_minutes": {
    "type": "range",
    "minValue": 10,
    "maxValue": 120,
    "defaultValue": 30
  },
  "num_workers": {
    "type": "range",
    "minValue": 1,
    "maxValue": 8
  },
  "node_type_id": {
    "type": "allowlist",
    "values": [
      "Standard_DS3_v2",
      "Standard_DS4_v2",
      "Standard_DS5_v2",
      "Standard_E4s_v3",
      "Standard_E8s_v3"
    ],
    "defaultValue": "Standard_DS3_v2"
  },
  "azure_attributes.availability": {
    "type": "fixed",
    "value": "SPOT_WITH_FALLBACK_AZURE",
    "hidden": true
  },
  "spark_version": {
    "type": "regex",
    "pattern": "^(14|15)\\.[0-9]+\\.x-scala2\\.12$",
    "defaultValue": "15.4.x-scala2.12"
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "data-engineering"
  },
  "custom_tags.cost_center": {
    "type": "allowlist",
    "values": ["harbinger", "research", "infra"]
  }
}

Diese Policy:

• Erzwingt Auto-Termination zwischen 10–120 Minuten (Default 30)
• Limitiert Cluster-Größe auf 8 Workers max
• Beschränkt auf kosten-effiziente Instance-Typen
• Erzwingt Spot-Instances (transparent für den User)
• Stellt LTS-Spark-Versionen sicher
• Fordert Cost-Center-Tagging für Chargeback

2. Single-Node-Policy (für interaktive Entwicklung)

Für leichte Exploration und Tests hält eine Single-Node-Policy die Kosten minimal:

{
  "num_workers": {
    "type": "fixed",
    "value": 0,
    "hidden": true
  },
  "spark_conf.spark.databricks.cluster.profile": {
    "type": "fixed",
    "value": "singleNode",
    "hidden": true
  },
  "autotermination_minutes": {
    "type": "fixed",
    "value": 60,
    "hidden": true
  },
  "node_type_id": {
    "type": "allowlist",
    "values": ["Standard_DS3_v2", "Standard_DS4_v2"],
    "defaultValue": "Standard_DS3_v2"
  }
}

3. Production-Job-Policy (für automatisierte Workflows)

Produktive Jobs brauchen Zuverlässigkeit über Cost-Saving. Diese Policy erlaubt größere Cluster, aber auf Spot mit Fallback:

{
  "num_workers": {
    "type": "range",
    "minValue": 2,
    "maxValue": 32
  },
  "autotermination_minutes": {
    "type": "fixed",
    "value": 0,
    "hidden": true
  },
  "azure_attributes.availability": {
    "type": "fixed",
    "value": "SPOT_WITH_FALLBACK_AZURE",
    "hidden": true
  },
  "azure_attributes.spot_bid_max_price": {
    "type": "fixed",
    "value": -1,
    "hidden": true
  },
  "custom_tags.environment": {
    "type": "fixed",
    "value": "production"
  }
}

4. Unrestricted Policy (nur für Workspace-Admins)

Gib deinem Platform-Team volle Flexibilität, aber tracke trotzdem die Nutzung:

{
  "custom_tags.team": {
    "type": "fixed",
    "value": "platform"
  }
}

Policies via CLI erstellen

# Create a policy from a JSON file
databricks cluster-policies create \
  --name "Data Engineers - Cost Controlled" \
  --definition @policies/engineer_policy.json

# Update an existing policy
databricks cluster-policies edit \
  --policy-id ABCD1234 \
  --name "Data Engineers - Cost Controlled" \
  --definition @policies/engineer_policy.json

# List all policies
databricks cluster-policies list

Policies via Terraform erstellen

Wenn du Databricks-Infrastruktur mit Terraform managst:

resource "databricks_cluster_policy" "engineer_policy" {
  name = "Data Engineers - Cost Controlled"
  definition = jsonencode({
    "autotermination_minutes" = {
      type         = "range"
      minValue     = 10
      maxValue     = 120
      defaultValue = 30
    }
    "num_workers" = {
      type     = "range"
      minValue = 1
      maxValue = 8
    }
    "azure_attributes.availability" = {
      type   = "fixed"
      value  = "SPOT_WITH_FALLBACK_AZURE"
      hidden = true
    }
    "custom_tags.cost_center" = {
      type   = "allowlist"
      values = ["harbinger", "research", "infra"]
    }
  })
}

resource "databricks_permissions" "engineer_policy_access" {
  cluster_policy_id = databricks_cluster_policy.engineer_policy.id

  access_control {
    group_name       = "data-engineers"
    permission_level = "CAN_USE"
  }
}

Policies bei Scale durchsetzen

Default-Policy-Zugriff entfernen

Standardmäßig haben Workspace-User Zugriff auf die "Unrestricted"-Policy. Um deine Custom-Policies zu erzwingen, schränke die auf Admins ein:

databricks permissions set \
  --resource-type cluster-policies \
  --resource-id 0 \
  --access-controls '[{"group_name": "admins", "permission_level": "CAN_USE"}]'

Policy-Compliance monitoren

Databricks System-Tables nutzen, um Cluster-Erstellung und Policy-Adhärenz zu tracken:

-- Find clusters created without a policy (ungoverned spend)
SELECT
  cluster_id,
  cluster_name,
  created_by,
  create_time,
  node_type_id,
  num_workers,
  autotermination_minutes
FROM system.compute.clusters
WHERE policy_id IS NULL
  AND create_time >= CURRENT_TIMESTAMP - INTERVAL 30 DAYS
ORDER BY create_time DESC;

-- Total DBU consumption by policy
SELECT
  c.policy_id,
  cp.name AS policy_name,
  SUM(u.dbu_consumption) AS total_dbus,
  SUM(u.cloud_cost) AS total_cloud_cost_usd
FROM system.billing.usage u
JOIN system.compute.clusters c ON u.cluster_id = c.cluster_id
LEFT JOIN system.compute.cluster_policies cp ON c.policy_id = cp.policy_id
WHERE u.usage_date >= CURRENT_DATE - INTERVAL 30 DAYS
GROUP BY 1, 2
ORDER BY total_dbus DESC;

Einen FinOps-Review-Prozess aufsetzen

Cluster Policies sind eine technische Kontrolle. Sie funktionieren am besten mit einem schlanken Prozess gekoppelt:

1. Wöchentlicher Cost-Review — system.billing.usage abfragen und mit Team-Leads teilen
2. Tag-Erzwingung — cost_center und owner als Tags pflicht; für Chargeback-Reports nutzen
3. Policy-Review-Kadenz — Policy-Limits quartalsweise reviewen; an Team-Bedürfnisse anpassen
4. Alert bei Spend-Anomalien — Databricks-SQL-Alerts auf system.billing.usage für unerwartete Spikes setzen

-- Alert query: daily spend over $50 (adjust threshold for your team)
SELECT
  usage_date,
  SUM(list_price * usage_quantity) AS daily_cost_usd
FROM system.billing.usage
WHERE usage_date = CURRENT_DATE - INTERVAL 1 DAY
HAVING daily_cost_usd > 50;

Policy-Hierarchie: Job- vs Interactive-Cluster

Häufige Verwirrung: Cluster Policies wirken anders auf interaktive Cluster (manuell erstellt) als auf Job-Cluster (von Databricks Workflows erstellt).

• Interaktive Cluster — voll von Policies regiert; User müssen eine Policy wählen
• Job-Cluster — die Job-Definition enthält eine Cluster-Spec; Policy ist optional, aber empfohlen
• Shared-Job-Cluster — wiederverwenden laufende Cluster; keine Policy-Erzwingung beim Spin-up

Für Job-Cluster: Policies in deinen Job-Definitionen und in der CI/CD-Pipeline durchsetzen:

{
  "job_clusters": [
    {
      "job_cluster_key": "default",
      "new_cluster": {
        "policy_id": "ABCD1234",
        "spark_version": "15.4.x-scala2.12",
        "num_workers": 4
      }
    }
  ]
}

Den Impact messen

Nach Einführung von Policies in einem mid-sized Team (15 Engineers), das ändert sich typischerweise:

FAQ

Sollten Cluster Policies in jedem Workspace aktiv sein?

Ja. Selbst Single-Person-Workspaces profitieren von verpflichtender Auto-Termination und Spot-Instances. Ein vergessener Cluster kostet schnell mehr als die 30 Minuten Setup.

Wie behandle ich Ausnahmefälle (z. B. Memory-intensive ML-Training)?

Eine separate Policy für ML-Workloads anlegen — größere Worker, längere Auto-Termination, dediziertes Cost-Center-Tag. Zugriff auf benannte Personen oder eine ML-Gruppe beschränken.

Greifen Policies auch bei SQL Warehouses?

Nein, SQL Warehouses haben eigene Konfigurationen (Auto-Stop, Cluster-Größe). Für deren Cost Control: das Auto-Stop-Intervall niedrig halten und Concurrency-Scaling vorsichtig nutzen.

Wie behandle ich Service-Principal-Cluster?

Service-Principals brauchen explizite Policy-Zuweisung. Häufiges Pattern: separate Policies pro Domain (z. B. prod-ingest, prod-ml) mit unterschiedlichen Limits.

Lassen sich Tags rückwirkend erzwingen?

Nein — Policies wirken nur bei Cluster-Create/Edit. Für Legacy-Cluster: Re-Create unter neuer Policy oder manuell taggen. Daher: früh erzwingen.

Wrap-up

Cluster Policies sind eines der höchst-ROI Governance-Investments, die du in einem Databricks-Workspace machen kannst. Ein paar Stunden Setup übersetzen sich in kontinuierliche Cost-Savings, bessere Standardisierung und weniger 2-Uhr-morgens-Alerts wegen unerwarteter Cloud-Rechnungen.

Mit den Basics starten: verpflichtende Auto-Termination, Spot-Instances und Größen-Limits. Dann Tagging-Anforderungen und Monitoring drauflegen, sobald das Fundament steht.

Bei Harbinger Explorer läuft unser Databricks-Workspace voll policy-governed. Jeder Cluster, den unser Team hochfährt, ist innerhalb von Guardrails — damit die Infrastrukturkosten schlank bleiben und wir uns aufs Bauen konzentrieren können, nicht aufs Rechnungs-Managen.

Stand: 14. Mai 2026.