Databricks auf Azure, AWS und GCP: Was sich wirklich unterscheidet

Das Kernerlebnis von Databricks, also Spark-Laufzeit, Delta Lake, Notebooks, MLflow und SQL-Analyse, ist auf allen drei Clouds dasselbe. Was sich unterscheidet, ist die Schicht der Anbindung: wie Databricks an das Identitätssystem, den Speicher, das Netz, die Abrechnung und die eigenen Dienste der jeweiligen Cloud andockt.

Die meisten Unternehmen wählen ihre Cloud für Databricks danach, wo sie ohnehin schon Infrastruktur betreiben, und nicht nach Databricks-eigenen Funktionen. Ein Unternehmen mit 200 Azure-Abonnements, Active Directory für Identitäten und Power BI für Berichte wird Databricks nicht auf GCP ausrollen, um 3 % Rechenkosten zu sparen. Die Wahl der Cloud ist eine Entscheidung über Infrastruktur, und dieser Leitfaden behandelt die Unterschiede, die den Alltag, die Kosten und die Data Governance tatsächlich berühren.

Was über die Clouds hinweg gleich bleibt

Die Spark-Laufzeit, das Speicherformat Delta Lake, Unity Catalog, MLflow, Databricks SQL, die REST-API und das Arbeiten mit Notebooks sind unabhängig von der Cloud identisch. Ein PySpark-Job, der auf Azure entwickelt wurde, läuft auf AWS mit kleinen Anpassungen der Konfiguration (ADLS-Pfade gegen S3-Pfade tauschen, AAD-Token gegen IAM-Rollen). Teams, die mehrere Clouds betreiben oder einen Wechsel erwägen, können sich auf diese Übertragbarkeit verlassen: Die Plattformschicht von Databricks abstrahiert die cloudspezifischen Unterschiede bei Speicher und Rechenleistung darunter weg.

Databricks auf Azure: Anbindung als eigener Microsoft-Dienst

Azure Databricks ist die einzige Cloud, in der Databricks ein eigener nativer Dienst des Anbieters ist. Sie richten es über das Azure-Portal ein, es erscheint auf Ihrer Azure-Rechnung, und es bindet sich von Haus aus an Azure Active Directory für SSO und rollenbasierte Zugriffskontrolle an.

Die Anbindung an das Ökosystem von Microsoft reicht tief. Power BI DirectQuery verbindet sich nativ mit SQL-Warehouses von Databricks. Azure Data Factory orchestriert dbt- und Spark-Jobs. ADLS Gen2 dient als voreingestellte Speicherschicht mit feingranularen ACL. Azure Key Vault verwaltet Geheimnisse. Microsoft Purview liefert Katalogmetadaten, allerdings mit einem Geltungsbereich, der auf das Ökosystem von Azure begrenzt ist.

Für ein Unternehmen, das Databricks, Power BI und Purview unter einem einzigen Azure Enterprise Agreement betreibt, ergibt das eine Rechnung, ein Identitätssystem und eine Supportbeziehung. Diese betriebliche Einfachheit ist das stärkste Argument für Azure Databricks, und deshalb prüfen die meisten Microsoft-lastigen Häuser die anderen Clouds für ihre Databricks-Installation gar nicht ernsthaft.

Databricks auf AWS: Reife und Vielfalt der Instanzen

AWS war die erste Cloud, auf der Databricks startete, und bleibt die am gründlichsten erprobte Installation. Das Ökosystem bindet S3 für Speicher an, IAM für Zugriffskontrolle, Glue für die Verträglichkeit mit dem Metastore (auch wenn Unity Catalog das ablöst) und AWS PrivateLink für sichere Netzverbindungen.

Der praktische Vorteil ist die Vielfalt der Instanzen. AWS bietet die breiteste Auswahl an EC2-Instanztypen, darunter Graviton-Instanzen auf ARM-Basis, die bei Spark-Arbeitslasten rund 20 % Rechenkosten gegenüber gleichwertigen x86-Instanzen sparen. Für Teams mit großem Data Engineering gibt die Möglichkeit, genau das passende Rechenprofil zu wählen, also speicheroptimiert für Verknüpfungen, speicherplatzoptimiert für Shuffles und GPU-Instanzen für das Training von Modellen, AWS einen spürbaren Vorsprung.

Databricks auf AWS ist über den AWS Marketplace verfügbar, was bedeutet, dass der Verbrauch auf bestehende Abnahmeverpflichtungen bei AWS angerechnet werden kann. Für Unternehmen mit großen Rabattprogrammen bei AWS kann Databricks dadurch auf AWS tatsächlich günstiger sein als derselbe DBU-Satz auf Azure oder GCP.

Databricks auf GCP: das Ökosystem aus BigQuery und Vertex AI

GCP ist die jüngste Installation von Databricks. Sie bindet Google Cloud Storage an, Cloud IAM, Cloud Composer (verwaltetes Airflow) und die Netzinfrastruktur von Google.

Das Unterscheidungsmerkmal ist die Föderation mit BigQuery. Teams können in Databricks Abfragen ausführen, die Tabellen im Delta Lake mit Datensätzen aus BigQuery verknüpfen, ohne Daten zwischen den Systemen zu bewegen. Für Unternehmen, die bereits in BigQuery für SQL-Analyse investiert haben, ergibt Databricks für Spark-Arbeitslasten und das Training von Modellen einen ergänzenden statt eines ersetzenden Stapels.

Die Anbindung an Vertex AI verbindet in Databricks trainierte Modelle mit der Inferenzinfrastruktur von Google. Ein Team kann ein Modell in Databricks MLflow trainieren, es exportieren und an Vertex-KI-Endpunkten ausliefern, behält also das Training im Ökosystem von Databricks und die Inferenz auf der verwalteten Plattform von Google.

GCP gewährt außerdem automatisch Rabatte bei dauerhafter Nutzung. Reservierte Instanzen müssen nicht im Voraus gekauft werden, Google senkt den Stundensatz, während die kumulierte monatliche Nutzung steigt. Davon profitieren Arbeitslasten mit schwankender, aber gleichmäßiger Nutzung.

Unterschiede beim Preis je Cloud

Databricks berechnet auf allen drei Clouds dieselben DBU-Sätze. Der Kostenunterschied entsteht aus den Preisen der zugrunde liegenden virtuellen Maschinen, den Speicherkosten und den Gebühren für ausgehenden Datenverkehr, die jeder Cloud-Anbieter erhebt.

Bei gleichwertigen Instanztypen, also AWS m5.xlarge gegen Azure Standard_D4s_v3 gegen GCP n2-standard-4, liegt der Preisunterschied typischerweise bei 5 bis 15 %, je nach Region und Umfang der Zusage. Die Speicherkosten bei S3, ADLS und GCS liegen bei den Standardstufen wenige Prozent auseinander.

Der eigentliche Kostenunterschied ist die Einbindung in die Abrechnung. Kunden von Azure mit einem Enterprise Agreement erhalten ausgehandelte Sätze, die sowohl für die Azure-Infrastruktur als auch für die DBU von Databricks gelten. Kunden von AWS können Databricks über den Marketplace laufen lassen und damit bestehende Abnahmeverpflichtungen abbauen. Die Rabatte von GCP bei dauerhafter Nutzung greifen automatisch und ohne Zusage im Voraus. Welche Cloud die günstigste ist, hängt weniger an den Listenpreisen als daran, mit welchem Anbieter Ihr Unternehmen bereits eine kommerzielle Beziehung hat.

Die Kosten für ausgehenden Datenverkehr verdienen bei Architekturen über mehrere Regionen oder in hybriden Aufbauten Aufmerksamkeit. GCP ist innerhalb einer Region tendenziell am günstigsten. AWS und Azure berechnen für regionsübergreifenden Verkehr und Verkehr ins Internet ähnliche Sätze. Wenn Ihre Architektur große Datenmengen zwischen Databricks und anderen Diensten bewegt, rechnen Sie diese Kosten ausdrücklich durch: Bei datenintensiven Arbeitslasten können sie die Rechenkosten übersteigen.

Verfügbarkeit neuer Funktionen und Regionen

Historisch bekommt AWS neue Funktionen von Databricks zuerst, Azure folgt binnen Wochen bis Monaten, und GCP hinkt weiter hinterher. Unity Catalog, serverlose Rechenleistung und Model Serving starteten allesamt auf AWS, bevor sie die anderen Clouds erreichten. Der Abstand ist kleiner geworden, doch Teams, die auf GCP installieren, sollten die Übersicht zur Verfügbarkeit von Funktionen für jede Fähigkeit prüfen, auf die sie angewiesen sind.

Die Abdeckung nach Regionen folgt einem ähnlichen Muster. AWS bietet Databricks in den meisten Regionen weltweit. Azure hat eine starke Abdeckung in Märkten mit großer Microsoft-Präsenz im Unternehmensgeschäft, einschließlich der Regierungsclouds (Azure Government, Azure China). Die Databricks-Regionen von GCP sind weniger zahlreich, wachsen aber stetig.

Für Unternehmen in regulierten Branchen kann die Unterstützung einer Regierungscloud ausschlaggebend sein. Azure Government und AWS GovCloud unterstützen beide Databricks für Arbeitslasten nach FedRAMP und für das DoD. GCP bietet derzeit keine gleichwertige, für Regierungsstellen zertifizierte Installation von Databricks.

Governance über Clouds hinweg mit Dawiso

Unity Catalog steuert Daten innerhalb eines einzelnen Databricks-Arbeitsbereichs oder -Kontos. Es übernimmt Zugriffskontrolle, Lineage und Metadaten für Delta-Tabellen und Modelle des maschinellen Lernens. Doch viele Unternehmen betreiben Databricks auf mehreren Clouds, oder daneben Snowflake, SaaS-Werkzeuge und Systeme auf eigenen Servern. Bis dorthin reicht Unity Catalog nicht.

Dawiso schließt diese Lücke, indem es die Metadaten aus Databricks-Arbeitsbereichen auf jeder Cloud in einen einzigen Datenkatalog aufnimmt. Ein Begriff im Business Glossary wie „monthly active users“ verweist auf seine Definition im Azure-Databricks-Arbeitsbereich, auf die Snowflake-Tabelle, in die er gespiegelt wird, und auf das Dashboard in Power BI, das ihn darstellt. Die Lineage verfolgt den gesamten Weg über Plattformen hinweg und nicht nur innerhalb eines Databricks-Kontos.

Über das Model Context Protocol (MCP) können KI-Agenten Datenbestände finden, unabhängig davon, auf welcher Cloud sie liegen. Eine Analystin, die einen KI-Copiloten fragt „Wo liegen unsere Daten zur Kundenabwanderung?“, erhält eine einzige Antwort, die die Databricks-Tabelle, ihren Ort in der Cloud, ihre Aktualität und die abhängigen nachgelagerten Berichte nennt, gleich ob die Daten auf Azure, AWS oder GCP liegen.

Fazit

Die Plattform Databricks ist von Grund auf cloudunabhängig entworfen. Die Unterschiede zwischen den Installationen auf Azure, AWS und GCP sind real, aber schmal: Sie laufen auf die Anbindung der Identität, die Konnektoren zu den eigenen Diensten, die Auswahl der Instanztypen und die Mechanik der Abrechnung hinaus. Wählen Sie die Cloud, auf der Ihr Unternehmen ohnehin arbeitet, und richten Sie Ihre Prüfung auf die Anbindungspunkte, die für Ihre konkrete Architektur zählen. In Umgebungen mit mehreren Clouds ist die Lücke in der Governance das schwerere Problem, und sie verlangt einen plattformübergreifenden Katalog, den Unity Catalog allein nicht liefert.