AWS DataZone EU Alternative 2026: Art.30 RoPA-as-CLOUD-Act-Target, Data Lineage Intelligence Exposure, and the Art.25 Discovery-Discoverability Paradox

Post #802 in the sota.io EU Compliance Series

AWS DataZone is the managed data governance and data management platform that helps organizations catalog, discover, share, and govern data assets across business units and accounts. The value proposition addresses a universal enterprise data problem: organizations accumulate data in dozens of systems — data warehouses, data lakes, operational databases, SaaS exports, and third-party feeds — but analysts and data scientists cannot find what data exists, cannot determine who owns it, cannot understand how it was produced, and cannot request access to it without navigating organizational silos. DataZone provides a business-facing data portal where data producers publish data products, consumers search and subscribe to data, and governance teams enforce access policies and track data lineage.

For organizations scaling their data platform, implementing data mesh architectures, or trying to make self-service analytics possible across business units, DataZone's operational value is substantial. It replaces ad-hoc Confluence documentation, email-based access request processes, and undocumented tribal knowledge about which S3 bucket contains which version of which dataset.

It is not in the AWS European Sovereign Cloud service catalog.

That ESC absence is particularly significant for DataZone because DataZone is, structurally, a documentation system for your data processing activities. Your data catalog describes what personal data you hold, where it lives, how it flows between systems, who accesses it, and what transformations have been applied to it. Under GDPR Art. 30, organizations are required to maintain exactly this documentation as a Record of Processing Activities. When that documentation lives in a US-controlled system, GDPR Art. 30 compliance and CLOUD Act compelled disclosure risk become the same problem.

What AWS DataZone Does

AWS DataZone provides enterprise data governance, cataloging, and self-service data access across AWS accounts and regions.

Core components:

• Data Domains: DataZone organizes data governance around domains — logical groupings of related data assets corresponding to business units or subject areas. A retail organization might have domains for Customer Data, Product Catalog, Inventory, Transactions, and Marketing Analytics. Each domain has designated data owners, stewards, and consumers with domain-specific governance policies.
• Data Catalog: DataZone automatically crawls connected data sources — Amazon S3, Amazon Redshift, AWS Glue Data Catalog, Amazon Athena, RDS, and external sources — and ingests metadata about each data asset: schema, sample data, statistics, and technical lineage. This technical metadata is enriched with business metadata: data owners, descriptions, data quality scores, and business glossary term associations.
• Business Glossary: DataZone supports a centralized business glossary where governance teams define and own canonical business terms (e.g., "Customer" means the entity with a verified billing relationship, as distinct from "Prospect" or "Lead"). Business glossary terms are linked to data assets, creating a semantic layer between technical metadata and business meaning.
• Data Products and Publishing: Data producers publish data assets as "data products" — curated, governed datasets with documented ownership, descriptions, quality indicators, and access policies. A data product can be a single table, a collection of related tables, a materialized view, or a set of files with defined semantics. Publishing makes the data product discoverable in DataZone's business portal.
• Subscription Workflows: Data consumers discover data products through the portal and submit access requests (subscriptions). DataZone routes subscription requests to designated approvers — typically the data product owner or domain steward — who review and approve or deny requests. Approved subscriptions grant IAM-based access to the underlying data resource.
• Data Lineage: DataZone captures and displays data lineage — the provenance chain from source data through transformations to derived datasets. Lineage is captured automatically from AWS Glue jobs, Amazon EMR, Amazon Redshift, and other integrated AWS services. The lineage graph shows which datasets were used to produce which derived datasets and which transformations were applied.
• Metadata Enrichment and Search: DataZone provides a full-text search interface over all cataloged data assets, enabling analysts to find relevant datasets by business term, schema field name, description keyword, or domain. ML-powered recommendations suggest related data assets based on access patterns and metadata similarity.
• Governance Policies: DataZone integrates with AWS Lake Formation for fine-grained column-level access control, enabling governance teams to define policies that restrict which data columns specific consumer roles can access in approved data products.

Scale context: A financial services organization with 15 AWS accounts across three business units deploys DataZone to create a unified data governance layer. Data engineers publish 800 data products across domains for Risk, Finance, Customer Intelligence, and Operations. 350 data analysts and scientists use the DataZone portal to discover and request access to data. DataZone's subscription workflow replaces a manual ticket-based process that took 5-7 days per request with a governed self-service process that completes in hours.

ESC status: AWS DataZone is not in the AWS European Sovereign Cloud service catalog.

GDPR Issue 1 — Art. 30: Your Record of Processing Activities Is a CLOUD Act Disclosure Target

GDPR Art. 30 requires organizations to maintain a Record of Processing Activities (RoPA) — a comprehensive register documenting each processing activity, its purpose, the categories of personal data involved, data transfers, and retention periods. Organizations deploying AWS DataZone as their data governance and cataloging infrastructure create a structural inversion: the platform they use to achieve Art. 30 compliance is itself a US-controlled system where that compliance documentation is subject to CLOUD Act compelled disclosure.

How DataZone becomes your de facto RoPA: As organizations deploy DataZone and catalog their data assets, the metadata that accumulates in DataZone directly corresponds to what Art. 30 requires. Data product descriptions document the purpose of data processing. Domain ownership records document controllers and responsible parties. Business glossary associations identify which data assets contain which categories of personal data. Access subscription records document internal data transfers between business units. Lineage graphs document the provenance and transformation of personal data across systems.

An organization using DataZone systematically as its data governance layer will, over time, accumulate in DataZone most of what their Art. 30 documentation requires. The convenience of having a searchable, automatically maintained catalog is precisely why governance teams adopt it — but that convenience comes with the consequence that their Art. 30-equivalent documentation is stored in AWS infrastructure subject to US law.

CLOUD Act compelled disclosure of Art. 30 metadata: Under the CLOUD Act, US law enforcement agencies can compel AWS to disclose data stored or accessible on AWS infrastructure, regardless of where the data is physically located. A DataZone catalog describing an organization's personal data assets — what customer data they hold, where it lives, how it's used, who accesses it — is, from a law enforcement perspective, a comprehensive map of the organization's data processing. The Art. 30 documentation that organizations create for GDPR compliance simultaneously creates a high-value disclosure target for US legal process.

The circular compliance problem: Organizations cannot resolve this tension by keeping their Art. 30 documentation in DataZone while claiming GDPR compliance. The Art. 30 obligation requires maintaining records that document compliance. Storing those records in a system where they are subject to US compelled disclosure does not satisfy Art. 30's purpose, which is to enable supervisory authority audits and demonstrate accountability. A supervisory authority conducting an Art. 30 audit would appropriately question whether the organization's data governance documentation is operationally secure.

GDPR Issue 2 — CLOUD Act: Data Lineage Graphs Are Complete Business Process Intelligence

DataZone's data lineage feature tracks the provenance of data assets through the organization's processing pipeline — from source ingestion through transformations, aggregations, and derived dataset creation. For personal data, data lineage is not merely operational metadata: it is a structured representation of every processing step that personal data has undergone, which is precisely the information that GDPR's accountability principle and Art. 30 documentation require organizations to maintain and protect.

What lineage graphs reveal: A complete data lineage graph in a production DataZone deployment encodes the organization's entire data architecture and processing logic. Source lineage shows which external data feeds, API integrations, and internal operational systems generate personal data. Transformation lineage shows which ETL jobs, SQL transformations, and ML pipelines process personal data and what business logic is applied. Derived dataset lineage shows which analytical and operational datasets are produced from personal data and which downstream systems consume them. Access lineage shows which teams and applications have consumed each dataset.

This lineage graph is, simultaneously, a complete technical audit trail of personal data processing (which is what GDPR accountability requires) and a comprehensive map of the organization's data architecture and business processing logic (which is what competitors, regulators, and law enforcement want).

CLOUD Act exposure of lineage intelligence: Under CLOUD Act compelled disclosure, AWS could be required to produce DataZone lineage graphs that reveal the complete data flow architecture of an organization's personal data processing. For a financial institution, this might reveal risk modeling methodologies, fraud detection logic, credit scoring pipelines, and customer segmentation approaches. For a healthcare organization, it might reveal patient data flows, clinical data processing pipelines, and research data derivation chains. The competitive and regulatory intelligence value of this information is substantial.

Art. 30 and lineage: The GDPR accountability principle requires that the organization can demonstrate the lawfulness of each processing step when requested. DataZone lineage potentially satisfies this requirement technically — but it satisfies it in a system where the demonstration is accessible to US legal process. This creates a situation where the more thoroughly an organization documents its data processing for GDPR accountability purposes in DataZone, the larger the CLOUD Act exposure surface becomes.

GDPR Issue 3 — Art. 28: Data Product Subscription Creates Undocumented Controller Relationships

DataZone's subscription model for data products — where consumers discover and request access to data products published by producers — creates data sharing arrangements that may require formal data processing agreements under Art. 28, but DataZone provides no mechanism to establish, document, or enforce these agreements as part of the subscription workflow.

The data product sharing model and Art. 28: When a data producer in Domain A publishes a data product containing personal data, and a consumer in Domain B subscribes to and accesses that data product, a data sharing relationship has been created. The compliance analysis of that relationship depends on the organizational structure: if producer and consumer are different legal entities (common in conglomerate structures, joint ventures, or partner data sharing via DataZone), the sharing relationship may constitute a personal data transfer requiring an Art. 28 processing agreement or Art. 26 joint controller arrangement. DataZone's subscription workflow facilitates the technical access grant but does not require or document any legal basis review, data processing agreement, or transfer impact assessment.

Cross-account sharing and jurisdictional complexity: DataZone supports cross-account data sharing, allowing organizations to grant partner organizations or subsidiary entities access to data products. When a data product containing personal data is shared cross-account — particularly across organizational boundaries — the Art. 28 analysis must address whether the recipient is a processor acting on behalf of the controller, a separate controller receiving a lawful transfer, or a joint controller with shared responsibility. DataZone's access model does not distinguish between these legal relationships, creating governance gaps where data is shared with technical controls but without the legal structure that GDPR requires.

Subscription approval as inadequate consent documentation: DataZone's subscription approval workflow records that a data product owner approved a consumer's access request, but does not record the legal basis for the sharing, the scope of permitted processing by the consumer, or any limitations on further transfer or processing. For personal data products, the subscription record is operationally complete but legally insufficient as documentation of a lawful data sharing arrangement.

GDPR Issue 4 — Art. 25: The Discovery-Discoverability Paradox

DataZone's core value proposition is maximizing the discoverability and accessibility of data assets across the organization. GDPR Art. 25 requires that data processing be designed, by default, to use the minimum personal data necessary (data minimization) and to make personal data accessible only to those who need it (privacy by design and default). These requirements are structurally in tension with DataZone's design goal.

The paradox in practice: DataZone makes data assets discoverable through full-text search, metadata browsing, domain navigation, and ML-powered recommendations. This discoverability applies to all cataloged data assets, including those containing personal data. An analyst who searches for "customer email" in DataZone's portal discovers every data product across every domain that contains customer email fields — including data products that the analyst would never have found through targeted investigation. DataZone's discoverability feature turns personal data assets from effectively obscure resources (known only to those who built the pipelines that produce them) into visible, searchable, requestable resources accessible to the entire organization.

Privacy by design requirement: Art. 25(2) requires that personal data is not made available to an indefinite number of natural persons without the data subject's intervention. DataZone's catalog makes the existence, structure, and sample content of personal data assets available to all users who can access the portal, even before they have requested or been granted access to the data itself. A data product preview showing schema and sample data may itself constitute personal data exposure, and the organization-wide discoverability of personal data assets is difficult to reconcile with the Art. 25 requirement that access is restricted to those with a documented need.

Data minimization tension: DataZone's value increases with the completeness of its catalog — the more data assets cataloged, the more useful the discovery and governance functions become. This creates an organizational incentive to catalog all data assets, including personal data assets that might not need to be discoverable organization-wide. The organizational pressure toward catalog completeness runs counter to the GDPR principle that only necessary personal data should be processed, and that access to personal data should be restricted by default.

GDPR Issue 5 — Art. 35: Organization-Wide Personal Data Catalog Requires DPIA

GDPR Art. 35 requires a Data Protection Impact Assessment for processing that is likely to result in high risk to data subjects, explicitly including large-scale processing of personal data and systematic processing using new technologies. An organization-wide data catalog that enables discovery, access, and sharing of personal data across the entire enterprise — potentially enabling hundreds of analysts to discover and request access to personal data assets they would otherwise not have found — is precisely the kind of large-scale, systematic, technology-enabled processing that Art. 35's DPIA requirement addresses.

DPIA triggers in DataZone deployments: Multiple Art. 35 indicators are typically present in DataZone deployments. Scale: cataloging personal data assets accessible to hundreds or thousands of internal users constitutes large-scale processing of personal data categories. Systematic nature: DataZone's automated crawling and cataloging applies systematic processing to all connected data sources. New technologies: ML-powered metadata extraction, automated business glossary matching, and recommendation-based data discovery are new technologies applied systematically to personal data metadata. Evaluation of persons: DataZone's quality scoring and subscription tracking create systematic evaluation of data assets and their consumers.

DPIA gap in DataZone's deployment pattern: Organizations deploying DataZone to "improve data governance" often do not recognize that the deployment itself may trigger Art. 35 DPIA obligations. DataZone is positioned as a governance tool (implying it helps with compliance), which creates a deployment pattern where organizations implement it without the DPIA that the implementation itself may require.

EU-Sovereign Data Governance Alternatives

Three open-source data catalog and governance platforms deliver DataZone-equivalent functionality deployable on EU-sovereign infrastructure:

Apache Atlas

Apache Atlas is the data governance and metadata management platform from the Apache Software Foundation, originally developed for the Hadoop ecosystem but now deployed broadly for enterprise data governance.

Architecture: Atlas uses a graph-based metadata store (JanusGraph over Apache Cassandra or HBase as the storage backend, with Apache Solr for search indexing) to represent entities, their attributes, and their relationships as a typed graph. This graph model naturally represents data lineage, classification hierarchies, and entity relationships with high fidelity.

Core capabilities: Atlas provides entity type definitions (table, column, process, dataset, schema — extensible with custom types), classification (tag) propagation through lineage (a tag applied to a sensitive source table propagates to all derived tables), data lineage visualization from ETL job outputs, and a REST API for programmatic metadata management. Atlas integrates with Apache Hive, HBase, Kafka, Storm, Falcon, and Sqoop natively and provides a generic REST hook for custom integrations.

GDPR governance use cases: Atlas's classification propagation is directly applicable to GDPR data category management: tag a source table as "contains personal data — Art. 9 special category" and the tag propagates through all derived datasets automatically, maintaining data category awareness as the lineage grows. The Art. 30 documentation can be built from Atlas's entity and lineage graph through its REST API, with the metadata stored entirely on EU-sovereign infrastructure.

EU deployment: Apache Atlas is a standard Apache project deployable on any infrastructure. JanusGraph and Cassandra/HBase can be deployed on EU cloud providers (Hetzner, OVH, Scaleway, IONOS, Deutsche Telekom) with no US-parent cloud dependency. Typical deployment uses Kubernetes with persistent volumes on EU block storage.

Production readiness: Atlas is mature (Apache graduated project since 2017), widely deployed in financial services and healthcare data platforms, and actively maintained. The operational complexity is higher than managed alternatives — operating JanusGraph and Solr requires infrastructure expertise — but the governance capabilities are comprehensive.

OpenMetadata

OpenMetadata is a modern open-source data catalog and data governance platform built for a post-Hadoop data stack, providing DataZone-comparable functionality with a contemporary API-first architecture.

Architecture: OpenMetadata uses a REST API-first design with a PostgreSQL or MySQL storage backend, Elasticsearch for search, and a React-based frontend. The architecture is significantly simpler than Atlas's graph database stack and more accessible to teams with standard relational database operations expertise.

Core capabilities: OpenMetadata provides data discovery across 60+ integrations (Snowflake, BigQuery, Redshift, dbt, Airflow, Kafka, Looker, Tableau, and more), automated metadata ingestion through a Python-based ingestion framework, data lineage from SQL query parsing and pipeline execution, business glossary management, data quality integration (Great Expectations, dbt tests), and a conversational search interface (OpenMetadata Collate's AI-assisted discovery, optionally deployed on-premise).

GDPR-relevant features: OpenMetadata provides a PII classification framework where data stewards can tag columns containing personal data categories, with support for automated PII detection in column name patterns. The governance tier system allows classification of data assets by sensitivity. The fine-grained access control model supports role-based access where the discoverability of sensitive personal data assets can be restricted to authorized roles — partially addressing the Art. 25 discoverability concern.

EU deployment: OpenMetadata is deployable as a Docker Compose stack or on Kubernetes with Helm charts. All storage (PostgreSQL, Elasticsearch) runs on infrastructure you control. The EU deployment removes all US-jurisdiction dependencies and enables Art. 30 documentation to be maintained on EU-sovereign infrastructure.

Production readiness: OpenMetadata is production-ready with active development and a growing enterprise user base. The 1.x release series introduced significant stability improvements. Commercial support is available through Collate, the company behind OpenMetadata.

DataHub

DataHub is LinkedIn's open-source data discovery and metadata management platform, now maintained as a standalone project by the DataHub community and Acryl Data.

Architecture: DataHub uses a streaming-first architecture built on Apache Kafka for metadata change events, with Elasticsearch for search and graph queries, and MySQL or PostgreSQL for metadata storage. The streaming architecture enables real-time metadata updates from data pipeline events, making lineage tracking more operationally accurate than batch-catalog approaches.

Core capabilities: DataHub provides metadata ingestion across 50+ data sources, real-time data lineage from Spark, Airflow, dbt, and custom integrations, a GraphQL API for programmatic metadata access, a React-based discovery portal, data quality observability through DataHub assertions, and an actions framework for triggering governance workflows on metadata change events.

GDPR governance use cases: DataHub's metadata change event stream enables governance automation: a new dataset containing PII fields triggers an automatic governance workflow that assigns a data steward, requests Art. 30 documentation, and blocks the dataset from catalog publication until governance documentation is complete. This automation-via-event-stream approach enables GDPR-by-design data governance workflows not available in the managed alternatives.

EU deployment: DataHub is deployable on Kubernetes with Helm charts, with all persistence (MySQL, Elasticsearch, Kafka) running on EU-sovereign infrastructure. Acryl Data provides managed DataHub as a service, though EU-sovereign deployment requires self-hosting.

Production readiness: DataHub is production-ready and actively developed. LinkedIn, Airbnb, Pinterest, and Etsy have deployed DataHub at large scale. The open-source community is active and the roadmap is driven by real enterprise requirements.

Compliance Architecture for EU-Sovereign Data Governance

An EU-sovereign data governance stack built on open-source alternatives can provide DataZone-equivalent functionality with Art. 30-compliant documentation storage:

Infrastructure stack:

• Catalog: OpenMetadata or DataHub deployed on Kubernetes (Hetzner Cloud or IONOS)
• Storage: PostgreSQL 16 on managed EU PostgreSQL (or self-hosted), Elasticsearch 8 on dedicated EU nodes
• Lineage streaming (DataHub): Apache Kafka on dedicated EU Kafka cluster
• Pipeline integration: Python-based metadata ingestion from dbt, Airflow, Spark
• Access control: Keycloak (EU-deployable IAM) for authentication and RBAC, integrated with catalog's permission model

Art. 30 integration: Automate Art. 30 RoPA generation from catalog metadata: a scheduled job queries the catalog API for all data assets tagged as containing personal data, extracts ownership, purpose description, data category, retention period, and access subscription records, and generates a structured Art. 30 register stored in your EU infrastructure. The RoPA documentation is built from the same metadata that drives data discovery — maintained as a byproduct of governance operations rather than as a separate manual exercise.

Subscription governance: Extend the subscription approval workflow with a legal basis review step: before approving a subscription to a personal data product, require the approver to document the legal basis under Art. 6, confirm whether an Art. 28 processor agreement is required, and record the permitted processing scope. Store this documentation in your EU-sovereign catalog as structured metadata associated with each approved subscription.

Discoverability controls: Configure catalog visibility to require authentication before any data asset metadata is shown, restrict personal data asset discovery to roles with documented data access need, and hide sample data previews for Art. 9 special category personal data. These controls address the Art. 25 discoverability concern while preserving the operational benefits of self-service data discovery for authorized users.

Migration Path from AWS DataZone

Organizations currently using DataZone who need to migrate to EU-sovereign data governance can take a phased approach that preserves operational continuity:

Phase 1 — Metadata export: DataZone provides API access to its metadata catalog. Export all domain definitions, data product metadata, business glossary terms, lineage relationships, and subscription records through the DataZone API. This metadata export becomes the seed data for the EU-sovereign catalog.

Phase 2 — Parallel deployment: Deploy OpenMetadata or DataHub on EU infrastructure and import the exported metadata. Run both systems in parallel for 60-90 days to validate metadata accuracy and allow teams to migrate their workflows.

Phase 3 — Ingestion pipeline migration: Migrate automatic metadata ingestion from DataZone crawlers to OpenMetadata or DataHub connectors. Most connectors are configuration-based (providing connection credentials and ingestion schedules) rather than requiring code changes.

Phase 4 — Portal migration: Update internal documentation and team workflows to use the EU-sovereign portal for data discovery and access requests. Decommission DataZone access after confirming that subscription workflows and access control have been fully migrated.

Art. 30 documentation migration: The migration is an opportunity to formalize Art. 30 documentation. As each data product is migrated to the EU-sovereign catalog, add the Art. 30 fields (legal basis, data categories, retention period, controller identity) that DataZone's product model did not require. The migration converts an operationally useful but compliance-incomplete catalog into a catalog that supports formal Art. 30 documentation.

Summary

AWS DataZone is not in the AWS European Sovereign Cloud service catalog. For organizations subject to GDPR, deploying DataZone as their data governance infrastructure creates five structural compliance failures: the Art. 30 RoPA-as-CLOUD-Act-target problem that makes your data processing documentation a compelled disclosure risk, CLOUD Act exposure of data lineage graphs that represent complete business process intelligence, Art. 28 data product subscription arrangements that create undocumented data sharing relationships, the Art. 25 discovery-discoverability paradox that inverts privacy by design, and the Art. 35 DPIA obligation for organization-wide personal data catalogs that the governance tool framing masks.

Apache Atlas, OpenMetadata, and DataHub provide EU-sovereign data governance alternatives that deliver catalog, lineage, subscription, and governance capabilities without US-jurisdiction control over your data governance metadata. For organizations whose Art. 30 RoPA is their most sensitive GDPR documentation, keeping that documentation on EU-sovereign infrastructure is not a compliance optimization — it is a structural requirement that AWS DataZone, by its architecture, cannot satisfy.

sota.io is a European PaaS for teams that need GDPR-compliant deployment infrastructure with data residency guarantees. Deploy your data governance stack — OpenMetadata, DataHub, Apache Atlas — on EU-sovereign infrastructure with no US-parent cloud dependency.