The short answer
In traditional Amazon S3 data lakes, access control relies primarily on AWS policies and S3 bucket policies. However, IAM policies operate strictly at the coarse object prefix level (such as s3://bucket/sales/*).
If a compliance regulation requires restricting European analysts from viewing North American revenue rows, or masking credit card columns from marketing teams, engineers previously had to build separate pipelines to export sanitized bucket subsets.
How AWS Lake Formation modernizes lake governance
AWS Lake Formation provides a centralized, relational-style security layer on top of Amazon S3 and the AWS Glue .
Instead of writing sprawling IAM documents with hundreds of bucket paths, data administrators grant granular permissions using familiar database primitives:
-- Grant select on specific columns only
GRANT SELECT (order_id, customer_id, order_date)
ON TABLE analytics.fact_orders
TO ROLE marketing_analyst;Row filters and cell-level security
Lake Formation allows administrators to define Data Filters:
- Column-level filtering: Specify an explicit list of columns or exclude sensitive attributes (like social security numbers).
- Row-level filtering: Define an open-standard SQL expression (such as
region = 'EMEA' AND order_status = 'COMPLETED'). - Cell-level security: Combine both row and column restrictions into a single reusable policy rule.
When an analyst queries the table using Amazon Athena, Amazon EMR, or Amazon Redshift Spectrum:
- The query engine requests authorization from the Lake Formation service.
- Lake Formation evaluates user identity against registered filters.
- Lake Formation vends short-lived temporary S3 credentials directly to the engine and enforces filtering inline during data scanning.
This eliminates the need to maintain duplicate sanitized buckets and provides audited, unified data governance across all analytical engines.