Data Mesh Implementation: Cloud-Patterns für AWS, Azure und GCP

Dein Plattform-Team ertrinkt. Marketing, Finance, Logistics — jede Domain reicht Tickets für neue Pipelines ein, und das zentrale Team ist der Bottleneck, den alle anrufen, aber niemand staffen will. Data Mesh verspricht das zu fixen, indem Ownership zu den Domains verschoben wird, die ihre Daten wirklich verstehen. Zwischen Zhamak Dehghanis Vision und deinem Cloud-Stack klafft eine Lücke voller harter Architekturentscheidungen.

TL;DR

• Data Mesh ist ein Operating Model, keine Technologie.
• Vier Säulen: Domain-Ownership, Data as a Product, Self-Serve-Platform, Federated Governance.
• Drei Isolations-Patterns in der Cloud: Account-pro-Domain, Workspace-pro-Domain, Schema-pro-Domain.
• Pures Decentralization (jede Domain wählt Stack) scheitert in der Praxis.
• Unter 30 Data-Praktiker:innen lohnt Mesh meist nicht.

Die vier Säulen in Cloud-Architektur

Pattern 1: Account-pro-Domain (Strong Isolation)

Jede Domain bekommt eigenen Cloud-Account (AWS), Project (GCP) oder Subscription (Azure). Plattform-Team liefert IaC-Templates.

Wann: Regulierte Branchen (Blast Radius zählt), Domains mit verschiedenen Compliance-Anforderungen, Organisationen mit 50+ Data-Engineers über 5+ Domains.

Wann nicht: Teams kleiner als 3 Data-Engineers pro Domain — der Ops-Overhead erschlägt sie.

Trade-Offs:

• Starke Security-Grenzen, unabhängige Skalierung, klare Kostenattribution

• Cross-Domain-Queries werden Netzwerk- und Governance-Problem
• Duplizierte Infra-Kosten (jeder Account braucht eigenes Monitoring, IAM)

Cloud-spezifisch:

• AWS: Organizations mit SCPs für Guardrails. Cross-Account-Sharing via Lake Formation oder S3-Bucket-Policies. AWS RAM für Shared Resources.
• Azure: Management Groups + Azure Policy. Databricks UC spannt sich nativ über Workspaces.
• GCP: Folders in Resource Hierarchy. BigQuery Authorized Datasets für Cross-Project. Analytics Hub für Data-Product-Publishing.

Pattern 2: Workspace-pro-Domain (Shared Account)

Alle Domains teilen sich einen Cloud-Account, kriegen aber isolierte Workspaces.

Wann: Mid-Size-Organisationen (20–50 Praktiker:innen), Domains mit ähnlicher Infrastruktur und Compliance.

Wann nicht: Wenn Security-Incident in einer Domain die andere kompromittieren darf.

Trade-Offs:

• Niedrigerer Ops-Overhead, einfacherer Cross-Domain-Zugriff

• Noisy-Neighbor-Risiko, Kostenattribution braucht Tagging-Disziplin

Implementation: Databricks Unity Catalog passt hier besonders gut. Ein Metastore über mehrere Workspaces — catalog.schema.table mappt natürlich auf domain.data_product.asset.

Pattern 3: Schema-pro-Domain (Logical Isolation)

Alle teilen eine Plattform-Instanz, eigene Schemas/Datasets pro Domain.

Wann: Kleine Orgs (< 20 Praktiker:innen), Migration von Monolith, PoC-Phase.

Wann nicht: Echte Compute-Isolation nötig.

Trade-Offs:

• Minimaler Overhead, schnell, einfache Cross-Domain-Joins

• Keine Compute-Isolation, Governance ist Konvention nicht Infra-erzwungen
• "Mesh in Name Only" Risiko

Entscheidungs-Framework

Start Data Mesh
   ↓
Wie viele Data-Engineers pro Domain?
   ├─ < 3 → Compliance variiert pro Domain?
   │           ├─ JA → Account-pro-Domain
   │           └─ NEIN → Schema-pro-Domain
   ├─ 3–8 → Workspace-pro-Domain
   │           ↓
   │       Compute-Isolation nötig?
   │           ├─ JA → Account-pro-Domain
   │           └─ NEIN → Workspace
   └─ > 8 → Account-pro-Domain

• Start mit Team-Größe — stärkster Prädiktor.
• Compliance ist Override — bei differenzierten Anforderungen ist Strong Isolation Pflicht.
• Du kannst hochupgraden — Schema → Workspace → Account. Andere Richtung schmerzhaft.

Data-Product-Architektur

Kritischer Fehler: Die meisten Teams überspringen die SLA-Definition. Ohne ist ein "Data Product" nur eine Tabelle mit README.

Self-Serve: Build vs Buy

Federated Governance

Das Pattern, das sich durchsetzt: zentrale Policy-Definition, verteilte Enforcement.

Zentral:

• Globale Klassifikations-Taxonomie (PII, vertraulich, public, intern)
• Naming-Conventions und Schema-Standards
• Cross-Domain-Sharing-Agreements
• Audit- und Compliance-Reporting

Domain-Ebene:

• Klassifikationen auf eigene Data-Products anwenden
• Domain-spezifische Quality-Checks
• Access innerhalb der Domain
• SLAs definieren

Anti-Patterns

1. "Data Mesh" ohne organisatorische Änderung. Zentral-Team in "Plattform-Team" umbenennen, aber Pipelines weiter zentral bauen = Rebranded Monolith.
2. Self-Serve-Plattform überengineeren. AWS-Komplexität nachbauen, bevor eine Domain ein Data-Product produziert.
3. Keine Data-Product-Standards. Wenn jede Domain "Data Product" anders definiert, kann niemand vertrauen. DATSIS oder FAIR.
4. Mesh als Tech-Migration behandeln. Tech = 20 % des Aufwands, Org-Rewiring = 80 %.
5. Domain-Identifikation skippen. Domains sollen Business-Capabilities sein, keine Org-Chart-Boxes.

Cloud-Plattform-Vergleich

Meinung: Anfang 2026 bietet Azure + Databricks mit UC die kohärenteste Mesh-Experience out-of-the-box. AWS gibt dir maximale Flexibilität, aber du baust das Framework selbst.

6-Monats-Roadmap

Monat 1–2: Foundation

• 2–3 Pilot-Domains identifizieren
• Shared Catalog deployen
• Minimum Data-Product-Standard definieren
• IaC-Templates für Workspace-Provisioning

Monat 3–4: Erste Data-Products

• Pilot-Domains publishen 2–3 Products
• Cross-Domain-Consumption-Patterns
• Automatisches Quality-Monitoring
• Product-Registry

Monat 5–6: Skalieren

• 2–3 weitere Domains
• Federated Governance formalisieren
• Cost-Chargeback pro Domain
• Retrospective

Wann Data Mesh nicht die Antwort ist

• Org hat weniger als 30 Data-Praktiker:innen.
• Ein dominanter Use Case (80 % Workload für eine Funktion).
• Data-Kultur ist unreif (keine Tests = keine Quality-Checks).
• Regulierte Branche mit uniformer Compliance.

FAQ

Was kostet Data Mesh in der Praxis? Plattform-Team von 3–5 Engineers ist Minimum. Plus Catalog (UC, Atlan, DataHub) ab 12k €/Jahr.

Lohnt sich Mesh für ein DACH-Mittelstand-KMU? Selten. Unter 100 Personen ist zentralisierte Plattform meist effizienter.

Welches Cloud-Setup passt am besten? Azure + Databricks mit Unity Catalog. EU-Region (West Europe / North Europe) für Compliance.

Können Domains unterschiedliche Tools wählen? Theoretisch ja, praktisch scheitert es meist. Plattform-Standards mit Wahl innerhalb sind realistischer.

Stand: 14. Mai 2026.