Governance: DataZone and its on-prem counterparts#

How the platform governs data on each side (plan0 D10): on AWS, Amazon DataZone is the reference and is used as it is; on-prem, each of its jobs has a self-hosted counterpart where one exists, and a gap is listed rather than rebuilt. This page describes what DataZone does, what the platform feeds it, and what an on-prem install has instead, part by part.

Status markers: built means in the repository and tested; planned means decided but not yet built.

What DataZone is#

DataZone is AWS’s governance layer for data: a business catalog, data sharing and access. Since 2025 it is also the engine under Amazon SageMaker Catalog: SageMaker Unified Studio and SageMaker Catalog run on DataZone’s back end and APIs, and DataZone’s own portal remains for older (“V1”) domains. Its main parts:

  • Domains and projects. An organization’s catalog is a domain, divided into business domains. People work in projects, each with members and its own environments (Glue databases, Redshift, Athena workgroups).

  • The business catalog. Tables are published as assets or bundled into data products, with a glossary, required metadata forms, AI-written descriptions, data quality scores and search.

  • Publish and subscribe. A consumer asks for access to an asset, the owner approves, and DataZone grants it automatically through Lake Formation (Glue tables) or Redshift. This is DataZone’s distinctive feature.

  • Lineage. It accepts OpenLineage events and draws the graph.

  • Recent additions (2026). Metadata sync with Collibra, Atlan and Alation (March); governance features for IAM-based domains (May to July).

  • Cost. It is priced per use, so it is a cost risk to scope tightly and run on demand (see Costs).

What the platform feeds it#

On AWS the platform builds only the thin layer that feeds DataZone, and lets DataZone do the rest (the lineage graph, glossary, domains, data products, and subscription grants through Lake Formation):

Feed

What it gives DataZone

Status

Required metadata on every table: owner, domain, tier, sensitivity (Asset metadata)

Ownership and business domains, and the tags Lake Formation’s LF-Tags are driven by

Built

Registration of each table in the Glue Data Catalog

The physical catalog DataZone publishes from

Planned (Phase 1). The same registration runs on-prem against Trino today (below); Glue is a second implementation of the same resource

An OpenLineage emitter

The lineage graph

Planned (Phase 6). The off-the-shelf Dagster integration is abandoned, so the platform emits its own events

The on-prem counterparts#

DataZone does

On-prem

Status

The physical catalog under it (Glue)

A Hive Metastore and Trino, under the optional sql compose profile (SQL over the lake). Every core table is lake.<layer>.<table>, read-only to everyone. Dagster registers each new table and unregisters one whose files are gone, with a sensor that compares the lake and the catalog every minute

Built

Business catalog, search, descriptions

The portal’s catalog: every table with its description, owner, domain, tier badges, profile, how it is written, and how to read it (including its Trino name when sql is on)

Built

Lineage graph

Dagster’s asset lineage plus column lineage parsed from the SQL, shown in the portal

Built; OpenLineage export planned (Phase 6)

Glossary, data products, a richer business catalog

OpenMetadata, as an optional add-on. It needs several GiB of memory, so it would likely run on demand

Planned, optional (plan0 open question 6)

Who may access what (roles)

Groups at the identity provider (bundled Keycloak, or one the install already runs) mapped to permissions in roles.yml (Identity)

Built

Column and row rules

Trino with OPA, driven by the same sensitivity tags that drive Lake Formation’s LF-Tags

Planned (Phase 6); Trino’s built-in OPA plugin is confirmed

Subscribe, approve, grant

None: on-prem grants are made by hand

A known gap, by design

Data quality scores

Dagster asset checks, including blocking checks, and dbt tests

Built

In short#

On-prem already covers DataZone’s catalog and lineage roles at a basic level. Fine-grained enforcement comes with Phase 6 (OPA), and OpenMetadata adds the glossary and data products for an install that wants them. The one part deliberately not reproduced is DataZone’s self-service subscription workflow: D10’s rule is to list the gap, not to rebuild AWS.

Because the platform’s side of the contract is standard (Delta files, the required metadata, OpenLineage events), an install can move from the on-prem counterparts to DataZone, or run both, without changing pipeline code.

Sources#