Your Lakehouse is Not a Data Strategy

I've sat in a lot of data platform steering meetings. The good ones argue about ownership. The bad ones argue about file formats.

A few months after one platform went live, an analyst asked a simple question in the steering meeting: could her team use the customer table to train a new model? Three teams said they maintained that table. None of them would approve the request. The meeting closed with an action to "confirm data ownership", and two quarters later that action was still open.

That silence is what this post is about. AWS has built a very good lakehouse: Iceberg on S3, zero-ETL feeds, a catalog, fine-grained permissions and AI assistants on top. None of it tells you who owns the customer table, what "active customer" means, or how good the data has to be before an AI model is allowed to read it. Those are decisions. The platform only enforces them. If nobody makes them, it enforces nothing, very efficiently.

So I want to pull the two apart: what AWS actually gives you in 2026, what only your organisation can decide, and the framework I now use to connect them, the EDM Council's CDMC.

First, get the names right

AWS renamed a lot in 2025, and half the confusion in governance conversations comes from people using old names for new things.

The business layer is Amazon SageMaker Catalog, built on Amazon DataZone (AWS). It's where domains, projects, business glossaries, metadata forms and access requests live. DataZone isn't dead: existing DataZone domains can be upgraded to SageMaker Unified Studio, and both portals keep working afterwards (AWS, June 2025). If you're starting fresh, start in Unified Studio.

The technical layer is the AWS Glue Data Catalog for schemas and tables, with AWS Lake Formation handling permissions. What used to be called "SageMaker Lakehouse" is now documented as the lakehouse architecture of Amazon SageMaker (AWS docs). The part that matters is that Lake Formation checks permissions when the query runs, so a row or column grant defined once is honoured by Athena, EMR, Glue and Redshift Spectrum alike.

Two newer features matter for governance. Domain owners can set rules that stop an asset being published until it carries the glossary terms or metadata forms they require (AWS News Blog, Nov 2025). And lineage is OpenLineage-compatible, so it isn't locked into one tool (AWS docs).

That's a genuinely useful toolkit. But a toolkit isn't a standard, which brings me to the two frameworks I lean on.

DAMA tells you what. CDMC tells you what to prove.

Most data people know DAMA-DMBOK. It puts Data Governance at the hub of the wheel and treats everything else (quality, metadata, security, architecture and the rest) as spokes.

What DAMA doesn't give you is a checklist you can test a cloud platform against. That's the gap CDMC fills. CDMC, the Cloud Data Management Capabilities framework, comes from the EDM Council. Work started in May 2020 with the major cloud providers and more than 100 organisations involved (Forbes Tech Council). It's organised into six areas: governance and accountability, cataloguing and classification, accessibility and usage, protection and privacy, the data lifecycle, and data and technical architecture. Underneath sit 14 key controls, and what I like about them is how blunt they are. The ownership field in the catalog must be populated for all sensitive data, or the gap reported to a defined workflow. Classification must be automated at the point of creation or ingestion, and always on. Access to sensitive data must default to the creator and owner, and must be tracked (EDM Council).

That's the difference. DAMA says you need data ownership. CDMC says prove it's populated for every sensitive asset, automatically, and show me the exceptions.

CDMC also treats the catalog as a live control surface rather than a static inventory (Snowflake). That's exactly how SageMaker Catalog and Lake Formation are meant to be used, and it's why CDMC maps onto AWS so naturally.

There's an AWS proof point too. An AWS Glue reference architecture was externally assessed against all 14 controls, and AWS says it was the first cloud provider to complete both an internal and external assessment (AWS for Industries). Quote that carefully. The assessment was in 2023 and covered a Glue blueprint, not today's SageMaker stack, and certainly not your platform. It shows the controls are achievable on AWS. It doesn't mean you've achieved them.

CDMC is also vendor-neutral. Google has published a BigQuery implementation (Google Cloud) and Microsoft one for Purview (Microsoft). If you run AWS and Azure side by side, as plenty of NZ agencies do, that makes it a fair yardstick for both.

The 14 controls, on AWS

This is my own mapping, not an official AWS one. The last column is the honest bit.

#	CDMC control	Where it lives on AWS	What AWS won't do for you
1	Data control compliance	A report you build from catalog metadata through the APIs	Give you a CDMC score out of the box
2	Ownership	Asset and project owners in SageMaker Catalog; publish rules can require an owner form	Pick the owner
3	Authoritative sources and provisioning points	A metadata form field or glossary term marking the authoritative copy	Decide which copy is authoritative
4	Sovereignty and cross-border movement	Region choice, Region-deny guardrails, CloudTrail	Stop AI features sending metadata offshore (see below)
5	Cataloguing at creation or ingestion	Glue Data Catalog registration; automated catalog data source runs	Stop people creating data outside the pipeline
6	Classification at creation or ingestion	The AWS Glue Detect PII transform; Amazon Macie for S3 where the Region supports it	Know NZ identifiers: Glue's built-in types are US-centric, so add custom patterns for things like IRD numbers
7	Entitlements and access	Lake Formation grants and LF-Tags, subscription approvals, CloudTrail	Decide who should have access
8	Consumption purpose	Subscription requests carry a written justification the approver reviews (AWS docs)	Check the stated purpose is true
9	Security controls	KMS encryption, S3 Block Public Access, Security Hub	Close the side doors (see below)
10	Data protection impact assessments	Nothing native	Run the privacy impact assessment; this is a process
11	Retention, archiving and purging	S3 Lifecycle, Object Lock, Iceberg snapshot expiry	Actually purge: deleting from Iceberg means rewriting files and expiring snapshots
12	Data quality measurement	AWS Glue Data Quality, visible in the catalog	Set the thresholds
13	Cost metrics	Cost allocation tags, Cost Explorer	Attribute cost per dataset, which is harder than it sounds
14	Lineage	SageMaker Catalog lineage, OpenLineage-compatible	Get every pipeline emitting lineage events

Look down the right-hand column. Almost every gap is a decision or a process. That's the argument of this whole post in one table.

Here's how I draw it for clients:

The loop on the right is the part people skip. CDMC isn't satisfied by configuring controls once. It wants ongoing evidence that they still hold.

Where I'd start

Don't try to hit all 14 controls across the whole estate. Pick one domain that feeds one AI or analytics outcome someone has actually funded, and go deep.

In the first few weeks, name the data owner and a steward. That's controls 2 and 3, and it's the step everyone wants to skip. Get the stewards to write down twenty or thirty business terms and agree a sensitivity scheme; for NZ government, the NZ Government Security Classification System under the Protective Security Requirements is the obvious starting point. Build that scheme into Lake Formation as LF-Tags, and add a publish rule so nothing enters the catalog without a classification.

Then turn on automated classification in the ingestion pipelines, with custom patterns for NZ identifiers. Route every consumer through subscription requests with a stated purpose, and leave approval switched on. Grant by tag rather than by table, so a new table inherits access from its classification instead of from a ticket. Finish by putting Glue Data Quality rules on the tables your AI use case reads, and get lineage flowing from the pipelines.

Keep the glossary, metadata forms and LF-Tags in Terraform alongside the infrastructure. Governance that only exists in a console drifts quietly and then surprises you in an audit.

What I wouldn't do in the first ninety days: onboard every source through zero-ETL, turn on every AI assistant, or promise anyone a data mesh.

What worries me

Sovereignty is the one NZ teams underestimate. The AWS New Zealand Region (ap-southeast-6) is live, but SageMaker Unified Studio isn't on its supported Regions list yet (AWS docs), so for now your domain probably sits in Sydney. In a Sydney domain, the SageMaker Data Agent uses cross-region inference within Australia, and AWS says prompts, code context and Glue Data Catalog metadata may be sent to Sydney or Melbourne (AWS docs). Even Amazon Bedrock called from Auckland isn't purely local: it runs through cross-region inference, with the ANZ geographic profile routing across Auckland, Sydney and Melbourne and the global profile routing worldwide (AWS Machine Learning Blog, Mar 2026). Column names and table descriptions can be sensitive in themselves, and CDMC control 4 says cross-border movement must be recorded and controlled. Read that line before you switch anything on.

The NZ Region also doesn't have everything yet. Amazon Macie wasn't listed for ap-southeast-6 in its endpoints table when I checked (AWS docs), which is why I lean on Glue's PII detection for NZ-resident data. Check the Regional services list for every service in your design before you commit to it.

Then there's the side door. Lake Formation only protects data reached through Lake Formation-aware engines. An IAM role with direct S3 read on the bucket walks straight past every row and column filter, so audit for that before trusting any grant.

Approval can be quietly switched off. When an asset is published without requiring approval, subscription requests are approved automatically (AWS docs). Convenient for a sandbox, a hole for sensitive data.

Publish rules only apply at publish time. Anything already in the catalog was never checked, so plan a backfill.

AI-written metadata needs a human. SageMaker Catalog can generate names and descriptions using Amazon Bedrock, and AWS designed that as a draft for someone to review (AWS docs). If nobody reviews it, a plausible wrong definition becomes the one your RAG app retrieves.

Finally, costs arrive through the controls, not the studio. Glue Data Quality runs, PII scans, lineage-emitting pipelines, Redshift Serverless and Athena scans all add up. CDMC control 13 asks for cost metrics anyway, so tag every project to a cost centre from the start.

For NZ public sector readers

The Public Service AI Framework is worth reading alongside all of this. It isn't binding, but agencies are encouraged to align with it, and it sits within the National AI Strategy launched in July 2025, which relies on existing law such as the Privacy Act 2020 rather than new AI regulation (digital.govt.nz). In practice that makes your data governance your AI guardrail. If the lakehouse can't show who owns a dataset and where it's processed, the AI built on top can't either.

Outside government, ISO/IEC 42001 or the NIST AI Risk Management Framework play the same role.

The short version

DAMA decides. CDMC tells you what to prove. AWS enforces. Skip the first two and you've built an expensive, well-lit room that nobody's in charge of.