Fabric + Mesh auf AWS — LakeFormation, DataZone und eine Governance-Ebene

Begleitbeitrag zum Data-Engineering-Grundpfeiler. Der Grundpfeiler führt die Argumentation für den Fabric + Mesh Hybrid auf der Ebene was zu bauen ist und warum. Dieser Beitrag setzt genau dort an, wo der Grundpfeiler aufhört: bei der Frage, wie man das auf AWS baut — in der Syntax, die man tatsächlich in Git einchecken würde.

Was der Grundpfeiler offen ließ

Der Grundpfeiler benannte eine leitende Architektur-Entscheidung und ging dann bewusst darüber hinweg: die Fabric braucht genau eine Governance-Ebene pro Fachbereich — und die Wahl ist die Entscheidung, an der die gesamte Architektur hängt. Reine AWS-Häuser wählen LakeFormation + DataZone — AWS' Ebene für feingranulare Zugriffskontrolle auf Data-Lake-Tabellen plus den Datenprodukt-Katalog darüber. Multi-Cloud-Häuser mit starkem Databricks-Fußabdruck wählen Unity Catalog — die Cross-Workspace-Governance-Ebene von Databricks. Die Falle, die die meisten Fabric-Programme scheitern lässt, ist zwei Ebenen parallel über denselben Daten zu betreiben in der Hoffnung, „Governance föderiert sich später schon". Das passiert nie.

Dieser Beitrag geht die AWS-native Hälfte dieser Entscheidung durch. Cordatas Team liefert Terraform und Terragrunt über den AWS-Bestand seit 2021 aus — durch DACH-Mandate in Banking, Versicherung, Telekommunikation und Enterprise-Software — mit LakeFormation, Glue, DMS, EMR und Redshift als täglichen Bausteinen, und DataZone kam mit seiner Reife dazu. Wir haben die genaue Fabric + Mesh Komposition unten noch nicht Ende-zu-Ende bei einem einzelnen Kunden geliefert; jedes Mandat deckte einen Teilausschnitt ab. Was folgt, ist die Zusammenstellung, die wir heute liefern würden, in der Syntax, die wir seit fünf Jahren liefern — die Abwägungen sind die, mit denen wir leben, nicht die, von denen wir auf einer Konferenz gehört haben.

§ 1 — Die Topologie

Das Leitprinzip für eine AWS-native Fabric + Mesh offenbart sich erst nach der zweiten oder dritten Migration: Fachbereiche besitzen Konten, keine Ordner in einem gemeinsamen Bucket. Shared-Bucket-„Mesh" ist das, wozu ein Fabric-Programm degeneriert, wenn das Plattformteam unterbesetzt ist und IAM sich zu aufwendig anfühlt. An Tag eins sieht es identisch aus; im zweiten Jahr reduziert sich jede Prüfung auf „wer hat s3:GetObject auf diesem Präfix" — und die Antwort dauert eine Woche.

Konto-Eigentum bedeutet aber keine Freifahrt. Jedes Fachbereichs-Konto wird aus einem Plattform-eigenen Blueprint erzeugt — die Kontenstruktur, die Netzwerk-Topologie, die IAM-Baseline, die KMS-Key-Policy, die Logging-Ziele und der Terraform-Modulsatz kommen alle vom Plattformteam. Der Fachbereich verantwortet den Inhalt des Kontos (seine Tabellen, seine Pipelines, seine SLAs, seine Abonnement-Entscheidungen); die Plattform verantwortet die Form (wie das Konto gebootstrappt, abgesichert, überwacht und mit geteilten Diensten verbunden wird). Ohne diese Trennung folgt eines von zwei Fehlermustern: Fachbereiche ohne Infra-Expertise verheddern sich in Konsolen-Klicks, oder jeder Fachbereich baut sein Konto so unterschiedlich, dass der Bestand innerhalb eines Jahres unregierbar wird — dieselbe Shared-Bucket-Fäulnis in anderem Gewand.

Die Topologie „Konto pro Fachbereich" löst das strukturell. Producer-Konten halten die Speicherung und den Glue-Katalog (AWS' Metadaten-Registry für Tabellen und Schemata) für einen Fachbereich. Ein zentrales Governance-Konto hält die LakeFormation-Admin-Ebene und die DataZone-Domäne. Consumer-Konten abonnieren Datenprodukte über DataZone; Zugriff wird über LakeFormation-kontoübergreifende Berechtigungen provisioniert; Audit erfolgt über AWS CloudTrail im Governance-Konto für die Grant-Ereignisse und CloudTrail im Producer-Konto für die Data-Plane-Lesezugriffe.

Diagramm-Erläuterung. Drei Kontoschichten, von unten nach oben. Producer-Konten (unten) halten jeweils die Speicherung (S3) und den Glue-Katalog eines Fachbereichs — ein Konto pro Business-Domäne (fraud, policy, claims). Producer veröffentlichen Assets in das zentrale Governance-Konto (Mitte) über die DataZone-APIs CreateAssetType und PublishAsset, die das Datenprodukt mit Schema, Business-Glossar-Begriffen und Eigentümer registrieren. Das Governance-Konto hält drei Dinge: die LakeFormation-Admin-Ebene (die die kontoübergreifenden Grants besitzt), die DataZone-Domäne und ihre Projekte (die den Publish- und Subscribe-Workflow besitzen) und die LF-Tag-Ontologie — das kleine kontrollierte Vokabular von Tags wie domain=fraud, sensitivity=high, residency=eu, gegen das Richtlinien geschrieben werden. Consumer-Konten (oben) abonnieren Datenprodukte über DataZone; ein genehmigtes Abonnement materialisiert sich als kontoübergreifende LakeFormation-Berechtigung, und die IAM-Rolle des Konsumenten kann die Tabelle dann via Athena, Redshift Spectrum oder EMR abfragen.

Drei Eigenschaften, die diese Topologie einkauft — keine davon erhält man von Shared-Bucket-Mesh:

1. Der Blast Radius ist ein Konto. Eine kompromittierte Rolle im Fraud-Konto kann Claims-Daten nie berühren, egal wie viele fehlkonfigurierte Richtlinien anderswo existieren.
2. Kostenzuordnung ist geschenkt. Producer-Konto-Kosten = Fachbereichskosten. Keine Tag-basierte Zuordnungsakrobatik.
3. Regulatorische Grenzen decken sich mit technischen Grenzen. BaFin, FINMA und DSGVO argumentieren alle über „wer verarbeitet welche Daten" — die Kontogrenze ist die Antwort in einer Sprache, die Prüfer bereits sprechen.

§ 2 — Terraform: das Fachbereichs-Konto-Gerüst

Voraussetzung, bevor irgendetwas unten zählt: Infrastructure-as-Code (IaC) einsetzen, ohne Ausnahme. Konsolen-geklickte Konten sind nicht überprüfbar, nicht reproduzierbar, nicht Disaster-Recovery-fähig — und sie überleben keinen Personalwechsel. Alles Weitere in diesem Beitrag — reproduzierbare Umgebungen, Prüffähigkeit, DORAs Asset-Inventar, das Leitplanken-statt-Gates-Versprechen aus dem Grundpfeiler — hängt an dieser einen Entscheidung. Welches IaC-Werkzeug ist deutlich weniger wichtig als die Disziplin selbst: Terraform, OpenTofu, Pulumi, AWS CDK, alle in Ordnung; nehmen Sie das, das Ihr Team ohnehin liest.

Wichtiger als das Werkzeug ist die Form, die es erzwingt: die Trennung der Verantwortlichkeiten zwischen Infrastruktur-Code (was ein Modul bereitstellt) und Umgebungskonfiguration (welche Werte es erhält, pro Umgebung, pro Fachbereich). Terraform + Terragrunt ist eine Möglichkeit, diese Trennung durchzusetzen; Pulumi mit einer Stack-Ebene, Terraform CDK mit Konfiguration pro Umgebung oder pures Terraform mit tfvars pro Umgebung würden dieselbe Form erzielen. Der Wert liegt in der Trennung, nicht in der Werkzeugwahl.

Umgebungen werden bewusst getrennt. Jedes Fachbereichs-Konto existiert dreimal: dev, staging, prod. Diese Parität ist das, was DORAs kritisches ICT-Asset-Inventar pflegbar macht — eine in staging bewährte Änderung ist dieselbe Änderung, die Tage später mit derselben Konfigurationsdatei in prod angewandt wird. Ohne dies wird DORAs Fenster für Meldungen (was bricht bei Ausfall von Komponente X, in Stunden) aus dem Gedächtnis und mit Raten beantwortet statt mit einem Plan, den man bereits getestet hat.

Das Terragrunt-Layout, das wir dafür bei Mandaten nutzen, sieht wie der Block unten aus. _envcommon/domain-account/terragrunt.hcl hält die Infrastruktur-Modul-Verdrahtung; jede live/prod/domains/<domain>/terragrunt.hcl ist eine ~20-zeilige Konfigurations-Datei, die die Eingaben des Fachbereichs liefert — das ist die Trennung auf der Festplatte.

# live/prod/domains/fraud/terragrunt.hcl
include "root" { path = find_in_parent_folders() }
include "common" { path = "${get_parent_terragrunt_dir()}/_envcommon/domain-account.hcl" }
 
inputs = {
  domain_name          = "fraud"
  domain_owner_email   = "[email protected]"
  data_residency       = "eu-central-1"
  sensitivity_default  = "high"    # PII-schwerer Fachbereich
  works_council_review = true      # AVR-Meldung bei Tag-Änderungen erforderlich
}

Das gemeinsame Modul provisioniert den S3-Bucket, den KMS-CMK, die Glue-Katalog-Datenbank des Producer-Kontos und registriert diese Glue-Datenbanken (kritisch) bei LakeFormation als verwaltet. Sobald eine Datenbank unter LakeFormation-Verwaltung steht, ist der reine IAM-Zugriff für ihre Tabellen deaktiviert — jede Abfrage durchläuft eine LF-Berechtigungsprüfung. Das ist der Schalter, den die meisten Fabric-Programme nie umlegen; ohne ihn ist LakeFormation dekorativ.

# _envcommon/domain-account.hcl → data-lake-Modul (Auszug)
resource "aws_lakeformation_resource" "domain_bucket" {
  arn                     = aws_s3_bucket.domain.arn
  use_service_linked_role = true
}
 
resource "aws_glue_catalog_database" "domain" {
  name = "${var.domain_name}_curated"
  location_uri = "s3://${aws_s3_bucket.domain.id}/curated/"
}
 
# Übergabe der Glue-Datenbank an LakeFormation. Ohne dies gewinnt weiterhin IAM.
resource "aws_lakeformation_permissions" "revoke_iam_default" {
  principal   = "IAM_ALLOWED_PRINCIPALS"
  permissions = ["ALL"]
  database { name = aws_glue_catalog_database.domain.name }
}
# ...gekoppelt mit einer äußeren Ressource mit lifecycle { prevent_destroy = true },
# die das IAM_ALLOWED_PRINCIPALS-Default entfernt. Doppelt hält besser.

§ 3 — Die LF-Tag-Ontologie, und warum Berechtigungen dagegen geschrieben werden

Grant-Wildwuchs ist der Killer jedes LakeFormation-Programms im zweiten Jahr, den wir gesehen haben. Im ersten Jahr schreibt jemand aws_lakeformation_permissions pro Tabelle. Im zweiten Jahr gibt es 4.000 davon, niemand weiß, welche noch nötig sind, und jede Zugriffsüberprüfung ist ein Full-Scan.

Die eigentliche Ursache ist Prozess, nicht Werkzeug: niemand terminiert eine wiederkehrende Prüfung des Grant-Sets, also wächst es nur. Zwei Gewohnheiten halten es gesund — beide anwenden. Erstens eine vierteljährliche Zugriffsprüfung, die jeden Grant widerruft, der im Prüfzeitraum nicht in CloudTrail ausgeübt wurde; das ist zugleich das Artefakt, das DORA- und SOC-2-Prüfer erwarten. Zweitens jeden Grant über einen Terraform-PR anlegen, damit neue Grants bei der Erstellung Peer-reviewt werden und ein Widerruf ein Einzeilen-Diff ist, nicht eine Konsolen-Jagd.

Die Werkzeug-Ergänzung — die verhindert, dass sich der Wildwuchs neu bildet — ist, Berechtigungen gegen LF-Tag-Ausdrücke zu schreiben, nicht gegen Tabellennamen, und neue Tabellen ihre Berechtigungen von ihren Tags erben zu lassen.

Die Ontologie ist bewusst klein. Unsere, bei den meisten Mandaten:

resource "aws_lakeformation_lf_tag" "domain" {
  key    = "domain"
  values = ["fraud", "policy", "claims", "marketing", "finance"]
}
 
resource "aws_lakeformation_lf_tag" "sensitivity" {
  key    = "sensitivity"
  values = ["public", "internal", "confidential", "high"]
}
 
resource "aws_lakeformation_lf_tag" "residency" {
  key    = "residency"
  values = ["eu", "ch", "us", "global"]
}

Drei Schlüssel. Zwölf Werte. Jede Berechtigung wird gegen Ausdrücke wie domain=fraud AND sensitivity<=confidential AND residency=eu geschrieben. Neue Tabellen erhalten den richtigen Zugriff im Moment ihrer Markierung; das Setzen von Tags ist die einzige Operation, die Prüfer interessiert; und das gesamte Berechtigungsmodell passt auf ein Whiteboard.

Die konsumentenseitige Berechtigung sieht dann so aus. Beachtenswert: die Ressource referenziert keinerlei Tabellennamen:

resource "aws_lakeformation_permissions" "analyst_read_fraud_low_pii" {
  principal   = aws_iam_role.fraud_analyst.arn
  permissions = ["SELECT", "DESCRIBE"]
 
  lf_tag_policy {
    resource_type = "TABLE"
    expression {
      key    = "domain"
      values = ["fraud"]
    }
    expression {
      key    = "sensitivity"
      values = ["public", "internal", "confidential"]  # nicht "high"
    }
    expression {
      key    = "residency"
      values = ["eu"]
    }
  }
}

Und Spalten-Redaktion — was jede Prüfung in jeder Branche verlangt — schrumpft auf einen einzigen Tag an der Spalte:

resource "aws_lakeformation_resource_lf_tags" "iban_column_high" {
  database { name = "policy_curated" }
  table    { name = "customer" }
  column   { name = "iban" }
 
  lf_tag {
    key    = "sensitivity"
    values = ["high"]
  }
}

Die Analyst-Rolle oben, die sensitivity=high ausschließt, sieht die customer-Tabelle nun weiterhin — aber mit redaktierter iban. Keine View. Keine Masking-Funktion. Keine Tabelle-pro-Rolle-Duplikation. Die Spalte ist unsichtbar, weil der Grant-Ausdruck sie nicht erreichen kann.

Ausblick — agentischer Zugriff auf die Ontologie. Die nächste Affordanz, die diese Ontologie verdient, ist ein via MCP freigegebenes Katalog-Werkzeug: Fachbereichs-Engineers fragen einen Assistenten — „welche Sensitivitätsstufe gilt für eine Spalte, die eine EU-IBAN speichert?" — und das Werkzeug antwortet aus der lebenden LF-Tag-Policy, nicht aus einem veralteten Wiki. Das ist Defense in Depth: die Ontologie ist klein genug, um darüber nachzudenken, und ein Assistent macht sie im Moment des Tag-Setzens abfragbar. Dasselbe Werkzeug wird später zu dem Weg, wie agentische Konsumenten den Katalog, auf den sie gerichtet werden, verstehen, statt zu raten. Ein naturgemäßer nächster Schritt; noch nicht Teil der Referenzimplementierung.

§ 4 — DataZone: ein Datenprodukt veröffentlichen

LakeFormation ist die Durchsetzungs-Ebene. DataZone ist die Produkt-Ebene — wo Fachbereichsteams ein Asset mit Business-Glossar veröffentlichen und Konsumenten es über einen Workflow anfordern, statt den Datenverantwortlichen auf Slack anzupingen.

DataZone in zwei Schichten segmentieren. Die Form, die sauber auf die Konto-Topologie aus § 1 abbildet, ist eine Plattform-eigene Wurzel und Fachbereichs-eigene Zweige:

• Plattform-Schicht — eine zentrale DataZone-Domäne, verantwortet vom Plattformteam. Hält das LF-Tag-Vokabular (§ 3), die Environment-Blueprints (§ 2), die IAM-Namenskonventionen, die Konfiguration des Genehmigungs-Workflows und die geteilten Business-Glossar-Begriffe, die im ganzen Unternehmen verwendet werden.
• Fachbereichs-Schicht — eine DataZone-Sub-Domäne pro Business-Fachbereich (fraud, policy, claims), verantwortet vom Team des Fachbereichs. Sub-Domänen halten die Projekte des Fachbereichs — die Arbeitseinheiten, in denen Assets veröffentlicht werden — und der Fachbereich verantwortet die Abonnement-Entscheidungen innerhalb seiner Sub-Domäne.

Verantwortung auf einen Blick:

Hinweis zum DataZone-Datenmodell: die aktuelle DataZone-API bietet keine Sub-Domänen als First-Class-Ressource — die Zwei-Schichten-Trennung lebt in Konvention (Projekt-Namensgebung, IAM-Grenzen, Ownership), nicht im Schema. Die Konvention hält an den Stellen, an denen es zählt: Plattform- und Fachbereichsteams bearbeiten unterschiedliche Terragrunt-Dateien, mit unterschiedlichen Reviewern, und treten sich bei Grants nicht auf die Füße.

Das Terraform, um die zentrale Domäne (Plattform-verantwortet) und die Fraud-Sub-Domäne + das Fraud-Projekt (Fraud-Team-verantwortet) aufzuziehen:

# Plattform-verantwortet: die zentrale Domäne
resource "aws_datazone_domain" "cordata" {
  name                  = "cordata-analytics"
  domain_execution_role = aws_iam_role.datazone_execution.arn
  kms_key_identifier    = aws_kms_key.datazone.arn
}
 
# Fachbereichs-verantwortet: die Fraud-Sub-Domäne, ausgedrückt als DataZone-Projekt
resource "aws_datazone_project" "fraud" {
  domain_identifier = aws_datazone_domain.cordata.id
  name              = "fraud-domain"
  description       = "Fraud-Detection-Datenprodukte — verantwortet vom Fraud-Team"
}
 
# Producer-Konto assoziieren, damit sein Glue-Katalog auffindbar ist
resource "aws_datazone_environment_blueprint_configuration" "fraud_aws" {
  domain_id                = aws_datazone_domain.cordata.id
  environment_blueprint_id = data.aws_datazone_environment_blueprint.default_data_lake.id
  enabled_regions          = ["eu-central-1"]
  provisioning_role_arn    = aws_iam_role.datazone_provisioning.arn
}

Der Publish-Flow, vom Tastendruck des Producers bis zur Abfrage des Konsumenten:

Diagramm-Erläuterung. Producer veröffentlicht ein Asset mit angehängten Glossar-Begriffen; DataZone katalogisiert es. Ein Konsument sucht, reicht eine Abonnement-Anfrage ein, und DataZone routet die Genehmigung an das verantwortende Team der Sub-Domäne — nicht an das Plattformteam. Bei Genehmigung löst DataZone einen kontoübergreifenden LakeFormation-Grant gegen den LF-Tag-Ausdruck aus, der zur Rolle des Konsumenten passt; kein Engineer berührt IAM. Zur Abfragezeit erzwingt LakeFormation die LF-Tag-Richtlinie und wendet Spalten-Redaktion transparent an.

Derselbe Flow, in einer Zeile pro Schritt:

1. Producer — Fachbereichs-Engineer ruft create-asset + publish-asset auf einer Glue-Tabelle auf und hängt Business-Glossar-Begriffe an (Transaction, PII-EU).
2. Consumer — entdeckt das Asset in der DataZone-Suche, reicht eine Abonnement-Anfrage mit fachlicher Begründung ein.
3. Genehmigung — DataZone routet die Anfrage an die Sub-Domänen-Owner. Genehmigung ist ein Klick und erzeugt einen prüffähigen Eintrag.
4. Provisionierung — Genehmigung löst eine kontoübergreifende LakeFormation-Berechtigung gegen den LF-Tag-Ausdruck aus, der zur Rolle des Konsumenten passt. Kein Engineer bearbeitet IAM. Die Berechtigung wird protokolliert und ist über denselben Workflow widerrufbar.
5. Abfrage — Konsument führt Athena aus; LakeFormation prüft die LF-Tag-Richtlinie pro Abfrage; Spalten-Redaktion greift transparent.

Die Ebene, die DataZone nicht liefert. DataZone katalogisiert Assets — Tabellen, Schemata, Beispieldaten, Aktualitätsmetadaten. Es katalogisiert keine Metriken — die fachlichen Definitionen („monthly recurring revenue", „Policy Attach Rate", „Fraud Recall bei 30 Tagen"), nach denen Konsumenten tatsächlich fragen. Der aktuelle beste Kandidat für diese fehlende Ebene auf dem AWS-nativen Stack ist dbt Semantic Layer, ausgeliefert gegen dieselben LF-Tag-regierten Tabellen und veröffentlicht typisierte Metriken, die BI-Werkzeuge, Notebooks und LLM-Agenten über die semantische API abfragen, statt SQL neu zu erfinden. Das zählt am stärksten für den KI-Konsumenten: rohes SQL gegen einen regierten Lake ist unsicher für Agenten; eine semantische Schicht darüber ist das, was agentischen Konsum eines Datenprodukts ohne Halluzination erst ermöglicht. Cordata behandelt die semantische Schicht als eigene Ebene und eigene Entscheidung — ein Begleitbeitrag geht in die Tiefe.

Das ist die Self-Service-Hälfte des Data-Fabric-Vertrags aus dem Grundpfeiler: das Plattformteam baute das Fundament; Fachbereichsteams veröffentlichen darüber; Konsumenten abonnieren darüber; niemandes Slack-DMs liegen auf dem kritischen Pfad des Workflows.

§ 5 — Die Katalog-über-Katalogen-Falle

Die härteste Fehlerform für ein Fabric-Programm ist nicht die Werkzeugwahl — es ist der Moment, in dem ein zweiter Governance-Katalog über denselben Daten erscheint. Zwei Branchen, in denen wir dieses Muster beginnen sahen: Banken, die Databricks zuerst für ihre Data-Science-Teams einführten und dann später für die Gruppe AWS-native Governance dazuholten; Versicherer, die einen zweiten Katalog über eine Tochtergesellschaft geerbt und nie konsolidiert haben. Unity Catalog ist der häufigste Gegenspieler, weil Databricks in vielen DACH-Data-Science-Teams zuerst ankam — aber die Falle verallgemeinert sich. Jede zweite Katalog-Ebene über denselben S3-Objekten erzeugt dieselbe Fehlerform: Unity Catalog, Microsoft Purview, Snowflake Horizon oder ein Alt-Collibra mit harten Grants.

Die Versuchung ist immer, es als zukünftige Arbeit zu formulieren: „Katalog A regiert die Assets unter Werkzeug A, Katalog B regiert die Assets unter Werkzeug B — wir föderieren später."

Föderation passiert nicht. Was stattdessen passiert:

Diagramm-Erläuterung. Dieselben S3-Objekte sitzen unter zwei Katalog-Ebenen gleichzeitig. Jede Ebene glaubt, die Wahrheit darüber zu besitzen, wer was sehen kann. Wenn Katalog A den Zugriff eines Analysten widerruft, ist das Objekt weiterhin über Katalog B erreichbar — weil Katalog B den Widerruf nicht beobachtet hat. Prüfer, die „wer hat diese Tabelle gelesen" rekonstruieren, müssen zwei Audit-Pfade zusammensetzen und hoffen, dass sie sich überlappen; das tun sie selten.

Die Fehlerformen im Detail:

• Doppelte Grants driften auseinander. Dasselbe zugrundeliegende S3-Objekt wird von zwei getrennten ACL-Systemen regiert. Wenn ein Fachbereich den Zugriff eines Analysten in Katalog A widerruft, widerruft diese Ebene; Katalog B nicht, weil er davon nichts weiß. Der Analyst kann dieselbe Tabelle weiterhin über die Engine von Katalog B abfragen.
• Audit-Pfade spalten sich. Die BaFin fragt „wer hat die Kundentabelle in den letzten 90 Tagen gelesen?" Man antwortet zweimal — einmal aus jedem Audit-Pfad — und hofft, dass sich die beiden Listen zusammensetzen lassen. Das tun sie selten.
• IAM-Rollen bekommen Doppelaufträge. Die Engine von Katalog B (das Instance-Profil eines Databricks-Clusters, eine Purview-Scan-Rolle) erhält s3:GetObject-Grants, die den Berechtigungssatz von Katalog A duplizieren. In dem Moment, in dem diese Duplikate auseinanderlaufen, hat man eine Berechtigung, die die eigene primäre Governance-Ebene nicht sieht.
• Die Ontologie forkt. Das Tag-Vokabular jedes Katalogs wird zu einem überlappenden Dialekt, der fast dasselbe bedeutet wie die anderen. Niemand dokumentiert die Deltas. Jede neue Tabelle stellt zwei oder drei Fragen statt einer.

Was ist mit „Katalog-über-Katalogen"-Föderation? Unity Catalog kann einen Glue-Katalog föderieren — read-only anhängen, Namen auflösen, aber Grants bleiben auf AWS-Seite. Auf dem Papier sieht das wie der Ausweg aus: einen Katalog als „Katalog über Katalogen" wählen und die anderen lesen lassen, ohne ihre Policies zu besitzen. In der Praxis kollabiert das Muster, weil „read-only" ein Versprechen ist, das ein Daten-Engineer in fünfzehn Minuten brechen kann, indem er eine Databricks-Tabelle auf den föderierten S3-Pfad schreibt — und sobald dieser Schreibzugriff existiert, hat Katalog B faktische Policy-Autorität, ob man sie ihm gewährt hat oder nicht. Read-only-Föderation ist nur dann sicher, wenn beide Kataloge und der zugrundeliegende Speicher die Read-only-Grenze durchsetzen — was fast kein reales Deployment tut.

Die Absage ist architektonisch, nicht politisch: eine Governance-Ebene pro Fachbereich, immer. Wenn ein Fachbereich auf Databricks lebt, lebt er Ende-zu-Ende unter Unity Catalog; wenn ein Fachbereich auf dem AWS-nativen Stack lebt, lebt er Ende-zu-Ende unter LakeFormation + DataZone. Fachbereiche dürfen sich untereinander unterscheiden — das ist in Ordnung. Was nicht passieren darf: die Daten eines einzelnen Fachbereichs von zwei Ebenen regiert.

§ 6 — Drei DACH-Compliance-Prüfpunkte, auf dem Weg mitgenommen

Die Topologie oben verdient ihre Komplexität, indem sie drei DACH-spezifische Compliance-Gespräche handhabbar macht, die sonst langsam, teuer oder unbeantwortbar sind.

Auslagerungsregister (BaFin § 25b KWG · FINMA-Rundschreiben Outsourcing). Die Domäne-zu-Konto-Abbildung von DataZone ist ein prüffähiges Auslagerungsregister frei Haus. Jedes Producer-Konto ist ein Dienstleister (AWS), jedes Consumer-Konto ist eine konsumierende Fachfunktion, jedes Abonnement ist ein dokumentierter Datenfluss zwischen ihnen mit Eigentümer und Genehmigungsspur. Wenn BaFin oder FINMA das Auslagerungsinventar der Datenverarbeitungstätigkeiten anfragt, ist die Antwort ein DataZone-Export, kein aus dem Gedächtnis rekonstruiertes Excel.

DSGVO Art. 28 (Auftragsverarbeiter). AWS ist Auftragsverarbeiter; die Residenz-Fixierungshälfte der Compliance-Antwort lebt im residency=eu-LF-Tag kombiniert mit einem regionsgebundenen Glue-Katalog und S3-Bucket. Der LF-Tag ist die Durchsetzung — eine Berechtigung mit residency=eu kann rechnerisch nicht zu einer Tabelle aufgelöst werden, die außerhalb eu-central-1 registriert ist. Das verwandelt das Auftragsverarbeiter-Grenzgespräch von „vertrauen Sie uns" in „hier ist das Terraform, und hier ist der LakeFormation-Ausdruck, der scheitern würde, hätten wir das gebrochen".

Betriebsratsprüfung von RBAC-Änderungen (AVR-Meldung). Die DACH-spezifische Falle des naiven LakeFormation ist, dass jede einzelne Berechtigung zur Betriebsratsmeldung wird — was niemand über den dritten Monat hinaus durchhält. Die LF-Tag-Ontologie behebt das auf der Primitivebene: einzelne Berechtigungen sind von der AVR-Prüfung ausgenommen, weil sie gegen einen vorab genehmigten Richtlinienausdruck operieren; nur Änderungen an der Tag-Ontologie selbst — Hinzufügen einer neuen Sensitivitätsstufe, Neudefinition von residency=eu, Erweiterung des Tag-Vokabulars — erfordern Betriebsratsprüfung. Das ist ein Prüfzyklus, den der Betriebsrat tatsächlich durchführen kann, in einer Kadenz, die ehrlich bleibt, ohne dass eine Seite ausbrennt.

Löschung, Maskierung und DSGVO Art. 17 über ein Mesh hinweg. Das eine DACH-Gespräch, das dieser Beitrag bewusst nicht schließt, ist das Recht auf Löschung. Wenn ein Kunde nach DSGVO Art. 17 die Löschung verlangt, leben seine Daten in acht Producer-Konten, wurden in ML-Feature-Stores gejoint, sind in analytischen Extrakten gecacht und wurden in Audit-Logs abgefragt. Die Architektur oben unterstützt es — LF-Tags tragen die Kunden-Domänen- und Residency-Dimensionen, die der Löschjob zur Aufzählung braucht — aber die Mechanik der verteilten Löschung (Tombstoning, vergessene Indizes, Ablauf von Backups, erneute Aufnahme in Embedding-Stores, Maskierung versus Purge) verdient eine eigene Behandlung. Ein Begleitbeitrag ist geplant: DSGVO Art. 17 in einem Data Mesh — wie Löschung wirklich funktioniert, wenn Daten in acht Konten liegen.

§ 7 — Was das nicht leistet

Die Topologie oben ist die Fabric-Hälfte. Sie erzeugt aus sich heraus kein Data Mesh — ein Self-Service-Fundament ohne Fachbereichsteams, die darüber veröffentlichen, ist immer noch ein verlassenes Museum. Die Fachbereichsteams dazu zu bringen, ihre Daten zu besitzen, über DataZone zu veröffentlichen, ihre eigenen SLAs zu erfüllen und am Prüfzyklus teilzunehmen, ist die Mesh-Hälfte: die kulturelle Adoption, das Betriebsmodell, die Rechenschaftspflicht. Das ist Gegenstand des nächsten Cordata-Grundpfeilers — Data Governance — und dafür gibt es kein Terraform.

Sie erzeugt aus sich heraus auch nicht die semantische Schicht über den Datenprodukten — die versionierten Metrik-Definitionen, die es einem BI-Dashboard, einem Notebook und einem LLM-Agenten erlauben, „monthly recurring revenue" auf dieselbe Weise zu berechnen, aus derselben regierten Quelle. Diese Ebene liegt über DataZone, nicht darin, und verdient eine eigene Entscheidung — einen eigenen Begleitbeitrag.

Was fair über den Code oben zu behaupten ist: Es ist die Zusammenstellung, nach der die Komponenten seit DataZones Feature-Parität für kontoübergreifende Abonnements verlangen, sie komponiert sauber mit den Config-versus-Infra-Trennungs-Mustern, die wir bei DACH-Klienten in den letzten fünf Jahren angewandt haben, und sie hält den drei regulatorischen Gesprächen stand, die in DACH am meisten zählen. Was nicht fair zu behaupten ist: dass dies ein Ersatz für die schwierigere Hälfte des Problems wäre. Die schwierigere Hälfte sind Menschen.

Zurück zum Grundpfeiler: Data Engineering — der Fabric + Mesh Hybrid. Weitere Begleitbeiträge geplant: die semantische Schicht als eigene Ebene über den Datenprodukten; DSGVO Art. 17 über ein Mesh hinweg — wie Löschung wirklich funktioniert, wenn Daten in acht Konten liegen; ein reiner DataEng-Begleitbeitrag zur Pipeline-Hälfte (ETL, OpenLineage, Great Expectations); und der Governance-Grundpfeiler zur Mesh-Hälfte — kulturelle Adoption, Ownership, DORAs Berichtskette.