Cluster Policies auf Databricks: Compute, Kosten und Governance zentral steuern
Die Kernaussagen auf einen Blick.
- Cluster Policies sind workspacebezogene JSON-Regeln, mit denen sich zulässige Compute-Typen, Instanzfamilien und Autoscaling-Grenzen verbindlich vorgeben lassen.
- Im Mittelpunkt steht die Balance zwischen ausreichendem Spielraum für Entwicklungsteams und kontrollierbaren Compute-Kosten: Ohne technische Leitplanken zeigen sich ungeeignete Clusterkonfigurationen häufig erst in der Cloud-Abrechnung.
- Vor der Einführung sollten drei grundlegende Entscheidungen getroffen werden: Welche Parameter müssen verbindlich festgelegt werden (Tags, Photon, Auto-Termination), bei welchen Parametern Teams aus einer freigegebenen Auswahl wählen dürfen (Instanzfamilien, DBR-Versionen), wie Policies sinnvoll nach Workload-Klasse und gegebenenfalls Team zugeschnitten werden.
- Empfehlenswert ist ein kleines Standardset für produktive Jobs, interaktive Notebooks, ML-Workloads und Sandbox-Nutzung, das vollständig als Code verwaltet wird. Die verpflichtenden Tags sollten unmittelbar in die Kostenberichte auf Basis von system.billing.usage einfließen.
Inhaltsverzeichnis
Cluster Policies sind mehr als Templates
Drei Monate nach dem Go-live liegen die Compute-Kosten deutlich über dem geplanten Budget. Der Verbrauch lässt sich nicht zuverlässig den verantwortlichen Teams zuordnen. Ein Teil der Cluster wurde vor Einführung verbindlicher Tags angelegt und ist entsprechend unvollständig klassifiziert. Entwicklungsteams können sehr große Instanztypen auswählen, auch wenn der Workload sie nicht benötigt. Im Audit muss anschließend nachgewiesen werden, welchem Cost Center jeder Cluster zugeordnet ist, die vorhandenen Metadaten reichen für eine vollständige Zuordnung jedoch nicht aus.
Eine solche Situation entsteht häufig, sobald mehrere Teams denselben Workspace und unterschiedliche Compute-Profile nutzen, wenn vorher keine verbindlichen Grenzen für Clusterkonfigurationen definiert wurden. Darauf folgen häufig dieselben organisatorischen Maßnahmen: ein interner Ticket-Prozess, eine Excel-Tabelle mit erlaubten Instanztypen, ein monatlicher FinOps-Review. Diese Maßnahmen erhöhen den Abstimmungsaufwand, verhindern ungeeignete Konfigurationen aber nicht technisch.
Welche Compute-Varianten dürfen die einzelnen Teams verwenden? Welche Instanzfamilien sind für produktive Jobs vorgesehen und welche nur für explorative Nutzung? Wie wird die Kostenstelle eines Clusters verbindlich und nachvollziehbar gesetzt? Welche Unter- und Obergrenzen gelten für das Autoscaling?
Cluster Policies setzen diese Vorgaben direkt bei der Erstellung eines Clusters durch. Damit werden Fehlkonfigurationen verhindert, bevor sie sich in Kostenberichten oder Audits bemerkbar machen.
Was ist eine Cluster Policy bei Databricks?
Eine Cluster Policy ist eine im Workspace verwaltete JSON-Definition für zulässige Clusterparameter. Sie legt für einzelne Felder fest, welche Werte erlaubt, vorgeschrieben oder ausgeblendet sind: welche Werte erlaubt sind, welche festgeschrieben werden, welche Optionen dem Nutzer bei der Konfiguration gar nicht angeboten werden. Microsoft Learn beschreibt sie als Compute-Policy für Workspace-Admins. Der Funktionsumfang unterscheidet sich je nach Compute-Typ und ist bei klassischen Clustern am umfassendsten. Für Serverless stehen andere Governance- und Kostenmechanismen zur Verfügung, dazu gleich mehr.
Cluster Policies gelten jeweils für den Workspace, in dem sie angelegt wurden. Sie werden Nutzern oder Gruppen per Policy-ACL zugewiesen. Wird uneingeschränkte Clustererstellung entzogen, können Nutzer nur noch Compute über eine ihnen zugewiesene Policy anlegen. Für produktive Plattformen ist dies häufig das gewünschte Zielmodell: Jeder neue Cluster wird dadurch anhand einer definierten Policy validiert. Nicht freigegebene Werte können nicht verwendet werden.
Für die Plattformarchitektur ergibt sich daraus eine zentrale Gestaltungsentscheidung. Ein kleines workloadbezogenes Policy-Set (Job-Cluster, Ad-hoc-Notebook, Sandbox) führt zu einem anderen Betriebsmodell als individuell gepflegte Policies für jedes Team. Der Zuschnitt der Policies beeinflusst Tagging, Kostenallokation und Verantwortlichkeiten unmittelbar. Welche Konsequenzen das im Detail hat, ordnet der Überblick zur Databricks-Plattform ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie Policies Clusterparameter einschränken
Jede Regel definiert, wie ein bestimmter Clusterparameter eingeschränkt wird. Die offizielle Compute-Policy-Reference listet sechs Varianten. Die folgende Übersicht zeigt die wichtigsten Regeltypen und ihre typische Verwendung.
| Typ | Wirkung | Beispiel-Feld | Typischer Einsatz |
|---|---|---|---|
| fixed | Der Wert ist verbindlich vorgegeben und kann optional in der Oberfläche ausgeblendet werden. | runtime_engine | Photon erzwingen, data_security_mode setzen |
| allowlist | Wert muss aus einer Liste stammen | node_type_id | Auswahl auf freigegebene Instanztypen beschränken |
| blocklist | Bestimmte Werte sind ausgeschlossen | spark_version | Nicht mehr zugelassene Runtime-Versionen ausschließen |
| regex | Wert muss einem Muster folgen | custom_tags.cost_center | Schreibweise und Format eines Tags validieren (z. B. CC-\d{4}) |
| range | Numerischer Wert in min/max | autoscale.max_workers | Unter- und Obergrenze für das Autoscaling festlegen |
| unlimited | Frei wählbar, optional mit Default | cluster_name | Freie Eingabe mit optionalem Standardwert |
Mit diesen Regeltypen wird der zulässige Konfigurationsrahmen beschrieben. fixed eignet sich für Parameter, bei denen keine Abweichung zugelassen werden soll, die plattformweit einheitlich gesetzt werden müssen: Tag-Pflicht, Photon für SQL- und ETL-Jobs, Auto-Termination, data_security_mode für Unity Catalog. allowlist und range erlauben Teams Auswahlmöglichkeiten innerhalb kontrollierter Kosten- und Größenlimits. regex sorgt dafür, dass frei eingegebene Tags einem einheitlichen Format folgen.
Ein typisches Snippet für eine Job-Cluster-Policy sieht so aus:
Das Beispiel kombiniert vier unterschiedliche Arten der Einschränkung. Teams behalten innerhalb der vorgegebenen Grenzen ausreichend Konfigurationsspielraum: DBR-Wahl, Worker-Größe innerhalb des Korridors, Autoscaling im Rahmen. Kosten- und Governance-Vorgaben werden dennoch technisch durchgesetzt.
Policy Families oder eigene Policies?
Databricks liefert vordefinierte Policy-Familien aus: Personal Compute, Shared Compute, Power User Compute, Job Compute. Sie können über policy_family_id als Basis verwendet und durch Databricks weiterentwickelt werden.
Policy Family nutzen, wenn
- Die Plattform steht in einer frühen oder einfachen Ausbaustufe
- Kein eigenes Tag-Schema oder organisationsspezifisches Format nötig ist
- Kein Compliance-Constraint Regionen oder Instanzfamilien vorschreibt
Custom Policy bauen, wenn
- Verbindliche eigene Tags oder Formate durchgesetzt werden müssen
- Die Kostenallokation auf organisationsspezifischen Tags basiert
- Compliance bestimmte Regionen oder Instanzfamilien vorgibt
In vielen Plattformen eignet sich ein hybrider Ansatz: die Custom-Policy übernimmt die Familie als Basis (policy_family_id) und erweitert sie über policy_family_definition_overrides um die eigenen Felder. Die allgemeinen Grundeinstellungen können weiter aus der Databricks-Familie übernommen werden. Unternehmensspezifische Vorgaben bleiben dagegen versioniert im eigenen Repository.
Wo Policies wirken: All-Purpose, Job-Cluster, SQL Warehouses, Serverless
Der Umfang der Policy-Steuerung unterscheidet sich je Compute-Typ. Diese Unterschiede sollten bei Kosten- und Governance-Auswertungen ausdrücklich berücksichtigt werden.
| Compute-Typ | Policy-Wirkung | Hebel |
|---|---|---|
| All-Purpose-Cluster | Umfassende Steuerung der Clusterkonfiguration | alle Felder steuerbar |
| Job-Cluster | Umfassende Steuerung der Clusterkonfiguration | über policy_id im Job referenziert |
| SQL Warehouses (Classic/Pro) | Eingeschränkt | Separate Warehouse-Einstellungen mit abweichendem Funktionsumfang |
| Serverless Compute | Steuerung über workloadbezogene Policies, Tags und Budgets | Budgets, Tag-Inheritance auf Workspace-Ebene |
Job-Cluster sind für viele automatisierte Workloads die zentrale Einsatzform. Ein Job mit einer policy_id startet seinen Cluster gegen genau diese Policy. Dadurch lassen sich automatisierte Jobs besonders konsistent und reproduzierbar konfigurieren. SQL Warehouses stellen andere und weniger infrastrukturspezifische Konfigurationsparameter bereit, da Databricks einen größeren Teil des Betriebs übernimmt; die klassische node_type_id-Steuerung greift dort nicht. Bei Serverless übernimmt Databricks die Worker- und Infrastrukturkonfiguration. Kostensteuerung erfolgt deshalb stärker über Tags, Budgets und Workload-Konfigurationen. Wie diese Abgrenzung sauber gezogen wird, klären wir im Sibling-Artikel zu Serverless-Compute auf Databricks.
Permissions und Workspace-Identität
Erst durch ACLs wird festgelegt, welche Identitäten eine Policy verwenden dürfen. Jede Policy bekommt eine Liste von Nutzern, Gruppen oder Service Principals, die sie nutzen dürfen. Die ACL ergänzt damit die inhaltlichen Einschränkungen der Policy: Die Policy definiert zulässige Werte; die ACL bestimmt, welche Nutzer und technischen Identitäten sie auswählen dürfen.
Drei Zuordnungsmodelle sind in produktiven Plattformen besonders verbreitet:
Teamspezifische Policy
Bei tatsächlich abweichenden Anforderungen, ACL auf die Team-Gruppe (z. B. `engineering-data-platform`, `ml-team-fraud`).
Gemeinsame Workload-Policy
Für vergleichbare Workload-Klassen, ACL auf gemischte Gruppen (z. B. `job-cluster-prod` für alle Production-Service-Principals).
Sandbox-Policy
Restriktiv für breitere Nutzergruppen, ACL auf alle Workspace-Mitglieder, aber mit harten Auto-Termination- und Worker-Limits.
Technische Identitäten müssen ebenfalls zur Verwendung der jeweiligen Job-Policy berechtigt sein, weil sie Jobs starten und nicht über Nutzer-Gruppen wirken. Dieser Schritt sollte in den Onboarding- und Deploymentprozess neuer Service Principals integriert werden.
An diesen Parametern zeigt sich, ob Policies tatsächlich Kosten steuern oder lediglich Konfigurationen vereinheitlichen.
Tag-Pflicht
Über `custom_tags` muss jeder Cluster `cost_center`, `team` und `environment` tragen. Das Format steht über `regex` fest, der Wert kommt vom Nutzer oder ist über `fixed` festgeschrieben. Ohne verbindliche Tags bleibt die Kostenallokation unvollständig und fehleranfällig.
Tag-Weitergabe an Cloud
Über `aws_attributes.custom_tags`, `azure_attributes.custom_tags` oder `gcp_attributes.custom_tags` werden die Tags auf die EC2-/VM-Instanzen propagiert. Dadurch können Databricks- und Infrastrukturkosten über dieselben Dimensionen ausgewertet werden.
Instanzfamilien-Allowlist
Über `node_type_id` deckt eine kleine Auswahl freigegebener Instanzfamilien häufig den Großteil der Workloads ab: eine `Standard_D`-Familie für CPU-Jobs, eine `Standard_E`-Familie für Memory-Workloads, eine `Standard_NC`-Familie für ML-Training. Spezielle Instanztypen sollten über klar begründete Ausnahmepolicies freigegeben werden.
Autoscaling-Bandbreite
`autoscale.min_workers` und `autoscale.max_workers` werden über `range` gedeckelt. Für viele Standardjobs genügt ein begrenzter Autoscaling-Korridor. Größere Skalierungsgrenzen sollten separat genehmigt und dokumentiert werden.
DBR-Version-Allowlist
Über `spark_version` sollten nur wenige aktiv unterstützte Runtime-Versionen gleichzeitig zugelassen sein (aktueller LTS, vorheriger LTS, optional aktuelle DBR-Version). Nicht mehr unterstützte Versionen können dadurch gezielt ausgeschlossen werden.
Auto-Termination
Über `autotermination_minutes` als `fixed` oder enger `range`: 30 Minuten für All-Purpose, 60 Minuten für ML-Notebooks, deaktiviert für Streaming-Jobs.
Mit diesen Parametern lässt sich ein großer Teil des Kosten- und Risikoprofils eines Clusters beeinflussen. Fehlen diese Leitplanken, können einzelne Konfigurationsentscheidungen zu unnötig hohen oder dauerhaft laufenden Ressourcen führen.
Governance- und Compliance-Hebel: Security Mode, Region, Init Scripts
Cluster Policies können zusätzlich zentrale Governance- und Security-Vorgaben durchsetzen.
Data Security Mode
`data_security_mode` als `fixed` auf `USER_ISOLATION` oder `SINGLE_USER` erzwingt Unity-Catalog-konforme Cluster und verhindert nicht-konforme Cluster in produktiven Umgebungen.
Region-Restriktion
`aws_attributes.availability` oder `azure_attributes.availability` beschränken die Bereitstellung auf zulässige Regionen oder Verfügbarkeitszonen und reduzieren das Risiko unbeabsichtigter Bereitstellung.
Init-Script-Kontrolle
`init_scripts` per `blocklist` oder `regex` beschränkt Init Scripts auf geprüfte Speicherorte und freigegebene Inhalte, in regulierten Umgebungen Bestandteil der verbindlichen Sicherheitskontrollen.
Spot-Instance-Politik
`aws_attributes.first_on_demand` und `spot_bid_price_percent` als `fixed` legen fest, wie viele Worker garantiert On-Demand laufen, bevor Spot greift: etwa 1 On-Demand-Worker (Driver), Rest bevorzugt als Spot-Instanzen mit definiertem Fallback.
Policy-Schnitt pro Team und Workload-Typ
Die zentrale Designfrage betrifft weniger einzelne Regeltypen als den Zuschnitt der Policies. Dabei sind vor allem Workload-Klasse und tatsächlicher Sonderbedarf des Teams relevant.
| Policy | Workload | Fixed-Felder | Allowlist-Felder | Typischer Konsument |
|---|---|---|---|---|
| Job-Cluster Prod | ETL-Jobs in Production | Photon, Tags, Keine automatische Beendigung während des Jobs | DBR (2 Versionen), node_type | Service Principals |
| Ad-hoc-Notebook | Exploration, Reporting | Tags, Auto-Term 30 Min | DBR (1 Version), node_type (kleine Familie) | Daten-Engineering-Teams |
| ML-Training | Modell-Training mit GPU | Tags, USER_ISOLATION | Aktuell freigegebene Runtime-Version (ML-Runtime), GPU-node_type | ML-Workload-Owner |
| Sandbox | Lernen, Try-Out | Tags, Auto-Term 60 Min, max_workers=2 | Aktuell freigegebene Runtime-Version | alle Workspace-Mitglieder |
| Streaming | DLT, Structured Streaming | Photon, Tags, Keine automatische Beendigung während des Jobs | DBR, node_type | Streaming-Job-Owner |
Mit wenigen workloadbezogenen Standard-Policies lassen sich viele Plattformen ausreichend abdecken. Teamspezifische Policies sollten nur bei dauerhaft abweichenden technischen oder regulatorischen Anforderungen eingeführt werden (eigene Cost-Center-Logik, GPU-Quota, regulatorische Anforderung). Zu viele nahezu identische Policies erhöhen den Pflegeaufwand und erschweren die Übersicht.
Policies als Code: Terraform und Asset Bundles
Ausschließlich manuell gepflegte Policies lassen sich nur schwer reproduzieren, reviewen und über mehrere Workspaces synchron halten. Produktive Policies sollten über einen versionierten Deploymentprozess verwaltet werden.
Der Terraform-Provider bietet die Resource databricks_cluster_policy für genau diesen Zweck. Eine Policy-Definition liegt als JSON-Datei im Repo, die Resource setzt sie deklarativ in den Workspace. Änderungen durchlaufen denselben Review- und Freigabeprozess wie andere Plattformressourcen. Dadurch werden Änderungen nachvollziehbar und reproduzierbar. Regelmäßige Terraform-Pläne können Abweichungen zwischen Repository und Workspace sichtbar machen.
Asset Bundles können Policy-Referenzen gemeinsam mit Jobs und Pipelines durch die Umgebungen transportieren. Eine Policy kann als Bundle-Resource zusammen mit Jobs und Pipelines versioniert deployt werden. Promotion von Dev nach Test und Prod läuft über die Bundle-Target-Mechanik. Der Vorteil: Jobs und ihre Policy-Referenz wandern als Einheit durch die Stages, ohne Policy-IDs oder Zuordnungen in jeder Umgebung manuell anpassen zu müssen.
Versionierung bedeutet: jede Policy-Änderung läuft durch einen Pull-Request. Die Policy erhält damit eine nachvollziehbare Versions- und Änderungshistorie, wer wann welches Limit verändert hat und mit welcher Begründung. Diese Historie erleichtert den Nachweis, wann und aus welchem Grund Limits oder Freigaben geändert wurden.
Tag-Strategie und FinOps-Report über System Tables
Tags schaffen erst dann einen operativen Nutzen, wenn sie konsequent in Kostenberichte und Verantwortungsprozesse einfließen.
Databricks stellt mit system.billing.usage und system.billing.list_prices eine System-Tables-Sicht auf den DBU-Verbrauch bereit. Die Cluster-Tags landen in usage.custom_tags als Map. Eine standardisierte SQL-Auswertung auf cost_center aggregiert den DBU-Verbrauch pro Kostenstelle, ein Join auf list_prices übersetzt den Verbrauch unter Berücksichtigung der Preiszeiträume in einen geschätzten Geldwert.
Dadurch entsteht eine durchgängige Verbindung zwischen Konfigurationsvorgabe und Kostenbericht:
Policy erzwingt Tag
Tag-Pflicht über `custom_tags` in der Cluster Policy, z. B. `cost_center` als `regex`-Feld.
Tag landet auf Cluster
Das Tag wird beim Cluster-Start gesetzt und über `aws_attributes.custom_tags` oder `azure_attributes.custom_tags` an die Cloud-Ressourcen weitergegeben.
Verbrauch landet in System Tables
`system.billing.usage` erfasst den DBU-Verbrauch inklusive der Cluster-Tags in `usage.custom_tags`.
Report ordnet Kostenstellen zu
Ein Join mit `system.billing.list_prices` übersetzt den Verbrauch in einen geschätzten Geldwert pro Kostenstelle.
Eine separate manuelle Zuordnung kann dadurch weitgehend entfallen. Voraussetzung ist eine einheitliche Policy- und Tag-Bezeichnung über alle Workspaces hinweg. Uneinheitliche Policy- und Tag-Namen führen dagegen zu fragmentierten und schwer vergleichbaren Auswertungen.
Abgrenzung zwischen Clusterkonfiguration und Gesamtausgaben
Cluster Policies begrenzen die technische Konfiguration einzelner Compute-Ressourcen. Sie setzen jedoch kein Gesamtbudget für einen Workspace, ein Team oder ein Produkt. Für ein vollständiges FinOps-Modell müssen deshalb zusätzliche Budget- und Verbrauchskontrollen ergänzt werden.
Spend-Limits laufen über Databricks-Budgets oder Cloud-Provider-Quoten. Die Wahl zwischen Classic und Serverless bleibt eine Entscheidung der jeweiligen Workload-Architektur, also außerhalb der Cluster-Policy. Die Policy definiert den zulässigen technischen Rahmen, Budgets, Alerts und Architekturstandards steuern Gesamtausgaben und Compute-Modell.
Grenzen
Keine Query-Optimierung
Cluster Policies verhindern keine ineffizienten Abfragen oder ungeeignete Datenmodelle. Eine Policy zwingt Photon und eine DBR-Version durch, sie zwingt keinen effizienten Join. Ein kleiner Cluster mit ineffizientem Code kann teurer sein als ein größerer Cluster mit gut optimierter Verarbeitung.
SQL Warehouses & Serverless separat
Der umfassendste Wirkungsbereich von Cluster Policies liegt bei klassischem Compute. Für Warehouses gibt es SQL-Warehouse-Policies mit reduziertem Feldsatz, für Serverless wirken Budgets und Tag-Vererbung auf Workspace-Ebene.
Wirksam erst bei Neustart
Geänderte Policies werden in der Regel erst bei Erstellung oder Neustart eines Clusters vollständig wirksam. Bestehende Cluster behalten ihre Konfiguration bis zum Restart. Für sicherheitskritische Änderungen sollte deshalb ein verbindliches Refresh- und Umstellungsfenster geplant werden.
Eine Policy pro Workload-Klasse
Eine einzelne Policy für sehr unterschiedliche Workloads wird schnell unübersichtlich und widersprüchlich. Zu viele kombinierte Sonderregeln erschweren Wartung, Tests und Fehlersuche. Ein Zuschnitt nach technischen Workload-Klassen ist häufig stabiler als eine reine Teamstruktur.
Policy-Family-Updates wirken durch
Wenn Custom-Policies auf `policy_family_id` aufsetzen, kommen Updates der Familie je nach Änderung auch ohne unmittelbare Anpassung der eigenen Overrides automatisch durch. In stark regulierten Umgebungen kann eine vollständig explizite und kontrollierte Definition besser geeignet sein.
Cluster-Policies sind ein gezielter Plattform-Hebel mit klarer Wirkungsgrenze. Sie setzen verbindliche Grenzen für die Parameter, die der Clusterkonfiguration zur Verfügung stehen. Gesamtbudgets, Codequalität und Workload-Architektur müssen durch ergänzende Prozesse und Werkzeuge gesteuert werden.
Das ist auch der Grund, warum Policies ein guter Indikator für die Plattform-Reife sind. Gut strukturierte Policies sind ein Hinweis auf etablierte Standards für Compute, Kosten und Governance. Fehlende Leitplanken werden häufig erst durch steigende Kosten oder konkrete Audit-Anforderungen sichtbar.
Fazit
Cluster Policies werden relevant, sobald mehrere Teams und unterschiedliche Workload-Klassen denselben Workspace nutzen.
In kleinen oder frühen Setups können die vordefinierten Policy Families zunächst ausreichen. Mit wachsender Nutzung steigt jedoch der Bedarf nach verbindlichen Größen-, Tagging- und Runtime-Vorgaben. Ohne technische Durchsetzung werden Fehlkonfigurationen häufig erst über Kostenberichte oder Betriebsprobleme erkannt.
Besonders wichtig sind Policies bei interner Kostenallokation, regulatorischen Compute-Vorgaben und mehreren automatisiert verwalteten Workspaces.
Typische Ausgangssituationen für einen Policy-Rollout sind:
- Historisch gewachsene Workspaces mit unvollständigen oder uneinheitlichen Tags
- Kostenberichte ohne verlässliche Zuordnung zu Teams und Kostenstellen
- Verbindliche Vorgaben für Region, Security Mode, Instanzfamilien oder Init Scripts
- Neue Plattformen, bei denen Compute-Standards vor dem ersten produktiven Workload festgelegt werden sollen
- Migrationen von Legacy-Cluster-Setups mit gemischten DBR-Versionen
Wenn der Workspace klein ist und sämtliche Cluster zentral durch ein einzelnes Plattformteam eingerichtet werden, kann ein umfangreiches Policy-Modell zunächst unnötigen Pflegeaufwand verursachen. Dann liegt die eigentliche Baustelle bei der Plattform-Größe, die Policy folgt später.
Mein Vorschlag: So sind die zulässigen Compute-Parameter und Kostenmerkmale definiert, bevor die Plattform breiter genutzt wird.
Ziel ist nicht, jede technische Entscheidung zentral vorzugeben. Ziel ist ein klar definierter Spielraum, innerhalb dessen Teams selbstständig arbeiten können, dessen Kosten- und Governance-Grenzen technisch durchgesetzt werden.
Als Ausgangspunkt eignen sich wenige klar getrennte Policies für produktive Jobs, interaktive Notebooks, ML-Training und Sandbox-Nutzung. Die Definitionen und ACLs sollten vollständig versioniert und automatisiert ausgerollt werden, und die durchgesetzten Tags sollten unmittelbar in die Kostenallokation über `system.billing.usage` eingehen.
Ob eure Policy-Foundation den FinOps- und Governance-Druck wirklich trägt, lässt sich in einem ersten Databricks Plattform Assessment gut einordnen.
- welche Policies für eure Team-Struktur und Workload-Mischung tragfähig sind und wo Familie oder Custom-Policy passt
- wie Tag-Pflicht, Cost-Center-Vererbung und FinOps-Reporting über System Tables zusammengezogen werden
- welcher IaC-Pfad (Terraform, Asset Bundles) für eure Foundation passt und wie Drift-Erkennung im CI läuft
FAQ
Eine Cluster-Policy ist eine JSON-Definition pro Workspace, die einzelne Felder eines Cluster-Schemas einschränkt. Sie legt fest, welche Werte erlaubt sind, welche festgeschrieben werden und welche Felder Nutzer gar nicht setzen dürfen. Wirkungsbereich sind All-Purpose-Cluster, Job-Cluster und in Teilen SQL Warehouses. Damit wird die Cluster-Erstellung auf einen bewusst gewählten Konfigurations-Korridor begrenzt.
