Governing a lakehouse with AWS Lake Formation: four controls in one place

A data lakehouse earns its keep by being shared. Analysts query it with Amazon Athena, data engineers process it with AWS Glue and Amazon EMR, and the warehouse team reaches into it from Amazon Redshift. That shared access is the whole point, and it is also the moment governance gets hard. The question stops being “can this one application read this one bucket” and becomes “who, across the whole organisation, is allowed to see which data, and can we prove it.”

This article is about answering that question in one place. AWS Lake Formation gives you a single control plane over the data in a lakehouse, and it changes the unit of permission from the storage object to the table, the column, and the row.

Governance is a layer, not a bolt-on

The instinct, early on, is to govern the lakehouse with the tools you already have: an IAM policy here, an Amazon S3 bucket policy there. For a single team and a single bucket that works. It stops working the moment the data is shared, because those controls govern storage, not data. A bucket policy can say “this role may read this prefix.” It cannot say “this analyst may read the orders table but not the customer email column.”

So the controls scatter. Permissions end up spread across dozens of IAM policies and bucket policies, each written by a different team, none of them aware of the others. Nobody can answer “what can Finance actually see” without reading every policy in the account. That is the symptom of governance bolted on rather than designed in. A shared lakehouse needs the opposite: one control plane that sits over the data and is reasoned about as a single thing.

AWS Lake Formation: grant the table, not the bucket

Lake Formation provides that control plane. It manages permissions centrally over the AWS Glue Data Catalog, the metadata layer that already describes your lakehouse as databases, tables and columns. Instead of granting a role access to an S3 path, you grant a principal access to a catalog resource:

# grant SELECT on a table, not s3:GetObject on a prefix
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/analyst \
  --resource '{"Table":{"DatabaseName":"sales","Name":"orders"}}' \
  --permissions SELECT

Underneath, Lake Formation still mediates access to the S3 location, but you no longer write the bucket policy. You describe intent at the level people actually think in, databases, tables and columns, and Lake Formation enforces it. The grant above is readable on its own: an analyst role may select from the orders table. No prefix, no path, no object permission to reverse-engineer.

Fine-grained access: columns, rows and cells

Because the unit of control is the table, Lake Formation can go finer than a bucket ever could. It supports access at three levels below the table:

• Column-level: grant on a subset of columns, so a role sees the orders table but not the customer_email or tax_file_number columns. The columns it cannot see simply do not appear in its results.
• Row-level: attach a filter so a principal only sees rows that match a predicate, for example region = 'APAC' or tenant_id = current_tenant(). Two analysts query the same table and each sees only their slice.
• Cell-level: combine the two, restricting both rows and columns in one data filter, so a role sees certain columns only for certain rows.

Tag-based access control: grant on policy, not per table

Granting table by table is precise, but it does not scale. A lakehouse with hundreds of tables and dozens of teams turns into thousands of individual grants, and every new table is a new round of administration. Tag-based access control, using LF-Tags, solves this by separating the data from the policy.

You define tags, for example classification=pii or domain=finance, and attach them to catalog resources: databases, tables, even individual columns. Then you grant permissions on the tag expression rather than on the resource. A grant such as “the finance team may select where domain=finance and classification != restricted” applies to every matching table that exists now and every one created later. New data inherits the right access the moment it is tagged. Permissions scale by policy, not by per-table grant, which is what makes governance maintainable as the lakehouse grows.

The catalog as the control plane

The reason a single grant is worth making is that a single grant is enforced everywhere. The Glue Data Catalog is the shared metadata layer, and the engines that sit on top of the lakehouse defer to Lake Formation when they read it. Athena, Redshift Spectrum, EMR and Glue all enforce the same Lake Formation permissions:

This is the property that makes the control plane real. You write the column restriction on the orders table once, and it holds whether the user arrives through Athena, through Redshift or through a Glue job. There is no second place where the rule could be forgotten, and no engine that quietly sees more than it should.

Cross-account sharing without copying

Larger organisations rarely keep a lakehouse in one account. Domains own their own accounts, and the temptation is to copy data between them so each team has a local copy, which is how you end up with stale duplicates and no idea which is authoritative. Lake Formation lets a producing account grant access to a database, table or column to a consuming account, and the consumer queries it in place. No copy is made.

That capability is what enables a data-mesh style of ownership: each domain owns and governs its own datasets in its own account, and publishes governed access to others through Lake Formation grants rather than through pipelines that replicate data around the business. Ownership stays where the knowledge is, and there is one authoritative copy of each dataset.

Audit and lineage: the evidence a regulator expects

Access control is only half of governance. The other half is being able to show, after the fact, who accessed what. AWS CloudTrail records Lake Formation activity, the grants made and the data accessed, so the record exists whether or not anyone was watching at the time. When a regulator or an internal auditor asks “who could see this customer data, and who actually did,” the answer is a query, not a project.

For Australian organisations carrying obligations under the Privacy Act and frameworks such as the APRA standards, that audit trail is not a nicety; it is the evidence that least privilege was real and enforced, not just asserted in a policy document.

The shift: from “lock the bucket” to “grant the table”

Pulled together, Lake Formation represents a single change in posture. The old model secures the lakehouse by locking down storage: tighten the bucket policy, hope no one needs anything more granular, and re-derive the whole picture by reading every policy when someone asks. The lakehouse model secures the data: grant access to the table, the column, the row, by policy through tags, enforced consistently across every engine, shared across accounts without copying, and logged for audit.

That is least privilege expressed where it belongs, at the level of the data itself. It is more precise, it scales by policy rather than by hand, and it produces the evidence governance has always needed. For data and security architects standing up a shared lakehouse on AWS, treating governance as its own layer, with Lake Formation as the control plane, is the design decision that makes the rest of the platform safe to share.