skip to content

In AWS Lake Formation, why does an IAM role with full Glue and S3 access still get access denied in Athena?

level: seniorimportance: nice to knowfreq 32%

answer

  1. two gates, not one
  2. the catalog got its own permission system
  3. admin in IAM is nobody here
  4. a legacy grant hides the enforcement
  5. credentials are vended, not the caller's own

basics

~20 s

Lake Formation adds a second authorization layer over Data Catalog databases, tables and columns. Once a location is registered with it, IAM alone is not enough — the principal also needs an explicit Lake Formation grant such as SELECT on that table.

solid answer

~50 s

When an S3 location is **registered** with AWS Lake Formation, Lake Formation takes over data access for it: the querying engine no longer uses the caller's own S3 permissions but asks Lake Formation to vend temporary credentials for the scanned objects. Authorization therefore becomes two-sided. The principal still needs IAM permission to call the APIs — Athena, Glue metadata reads, and crucially `lakeformation:GetDataAccess` — **and** it needs a Lake Formation grant (`DESCRIBE`, `SELECT`, optionally restricted to specific columns or rows) on the database and table. A role with `AdministratorAccess` and no grant is denied. The other classic cause is the legacy `IAMAllowedPrincipals` grant: while it sits on a table, Lake Formation defers to IAM and everything appears to work; the moment someone removes it to start enforcing, every principal without an explicit grant loses access at once.

code

bash · 10 lines
bash
# what does this principal actually hold on the table?
aws lakeformation list-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/analyst \
  --resource '{"Table":{"DatabaseName":"analytics","Name":"events"}}'

# grant read on specific columns only
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/analyst \
  --resource '{"TableWithColumns":{"DatabaseName":"analytics","Name":"events","ColumnNames":["user_id","action","dt"]}}' \
  --permissions SELECT

go deeper

for a junior

Recall that Lake Formation is a separate permission layer over the Glue Data Catalog, so being allowed by IAM is not by itself enough to read a governed table.

for a middle

Explain the mechanics: a registered location means credentials are vended by Lake Formation after it checks its own grants, and both the IAM side and the grant side must allow.

for a senior

Debug in order — is the location registered, does the principal hold a grant, is GetDataAccess allowed, can the registration role decrypt — and know the IAMAllowedPrincipals migration trap before you trip it.

for a principal

Decide whether centralized governance earns its complexity for your organization, and design the model — tag-based grants, cross-account sharing, an owner for every grant — so it survives thousands of tables.

## Two permission systems over one catalog The AWS Glue Data Catalog can be governed in two ways at the same time, and the confusion in this question comes from not knowing which one is in force. **IAM only.** Access to catalog metadata is controlled by Glue API permissions (`glue:GetTable`, `glue:GetPartitions`, …) and access to the data by the caller's own S3 permissions. The engine reads S3 as the caller. **Lake Formation.** You *register* an S3 location with Lake Formation, handing it a service role that can read that prefix. From then on Lake Formation is the authority for that location. An integrated engine — Athena, Redshift Spectrum, EMR, Glue ETL — calls `GetDataAccess`, Lake Formation checks its own grants for the principal, and if satisfied returns short-lived credentials scoped to the objects the query may read. The caller's personal S3 permissions stop being the deciding factor. ## Why full IAM access is not enough Lake Formation permissions are **granted, not inherited**. They are separate objects: `SELECT`, `DESCRIBE`, `ALTER`, `DROP`, `CREATE_TABLE`, `DATA_LOCATION_ACCESS`, granted to a principal on a catalog resource. Nothing in an IAM policy creates one. A role with `AdministratorAccess` therefore has every API permission and still no `SELECT` on the table, so a query is denied — and Lake Formation's denial can be terse, sometimes appearing as "insufficient Lake Formation permission(s)" or as the table simply not being visible. The reverse also holds and is worth saying explicitly: a Lake Formation grant does not replace IAM. The principal still needs IAM permission to call Athena, to read catalog metadata, and to call `lakeformation:GetDataAccess`. Both must allow. This is the checklist to work down when debugging: IAM API permissions, Lake Formation grant on database and table, the location actually registered, and the registration role able to read the prefix and decrypt with its KMS key. ## The IAMAllowedPrincipals trap To keep existing lakes working when Lake Formation appeared, AWS added a virtual group named `IAMAllowedPrincipals`. When it holds `Super` permission on a database or table, Lake Formation does not enforce and access falls back to IAM exactly as before. New catalog objects can be created with that grant automatically, depending on the catalog's default settings. This produces the signature migration incident. Everything works for months. Someone revokes `IAMAllowedPrincipals` on one database to begin real enforcement, and every consumer of every table in it — jobs, dashboards, notebooks — is denied simultaneously, because nobody ever held an explicit grant. The safe sequence is the opposite: grant explicitly to every known principal first, verify each consumer still works, and only then remove the legacy grant, one database at a time. ## What Lake Formation buys you It is worth knowing why a team accepts this complexity: - **Table- and column-level grants** without writing S3 prefix policies, so you can expose a table while hiding a salary column. - **Row-level filters and cell-level security** through data filters. - **LF-Tags** — tag-based access control, where you tag databases, tables and columns and grant on tags instead of on hundreds of individual resources. This is what makes the model scale past a few dozen tables. - **Cross-account sharing** of catalog resources without copying data or maintaining bucket policies per consumer. - A single audit surface for who was granted what. ## Practical debugging order 1. Is the table's S3 location registered with Lake Formation? If not, this is an ordinary IAM/S3 problem and you are looking in the wrong place. 2. Does the principal hold an explicit grant on the database *and* the table? Check what Lake Formation reports for that principal. 3. Does the principal's IAM policy allow `lakeformation:GetDataAccess` alongside the Athena and Glue actions? 4. Can the **registration role** read the prefix and decrypt the objects? If the location's own service role lacks `kms:Decrypt`, credential vending fails for everyone regardless of grants. 5. Does `IAMAllowedPrincipals` still hold `Super` here? If it does, enforcement is not really on, and whatever you are testing is not what production will do once it is removed. Answering with that ordered list — rather than "add more IAM" — is what distinguishes someone who has actually run a governed lake.

  • What does removing IAMAllowedPrincipals from a database actually change?
    It switches that database from IAM-only fallback to real Lake Formation enforcement. Every principal that lacks an explicit grant loses access at that moment — jobs, dashboards and notebooks alike. Migrate the other way round: grant explicitly to every known consumer, verify each one, then revoke the legacy grant per database rather than catalog-wide.
  • Why are LF-Tags preferred over granting on individual tables?
    Because per-resource grants do not scale: a lake with thousands of tables and dozens of teams becomes an unmanageable grant matrix. With tag-based access control you tag catalog resources — for example a sensitivity or domain tag — and grant permissions on tag values, so a new table inherits the right access simply by being tagged correctly at creation.
  • If Lake Formation vends the credentials, what does the caller's own S3 permission still do?
    For a registered location, essentially nothing for that read path — the engine uses the vended credentials, not the caller's. What still matters is the caller's IAM permission to invoke the engine and Glue metadata APIs plus `lakeformation:GetDataAccess`, and the registration role's own ability to read the prefix and decrypt with its KMS key.

Registering a location with Lake Formation is like putting a receptionist in front of a filing room: your building pass still gets you into the building, but the receptionist decides which drawers you may open, and being the CEO is not on her list.

saying these in an interview costs you the question

  • Assuming AdministratorAccess implies Lake Formation permissions
  • Fixing a Lake Formation denial by widening the S3 bucket policy
  • Revoking IAMAllowedPrincipals catalog-wide before granting explicitly
  • Forgetting lakeformation:GetDataAccess in the caller's IAM policy
  • Thinking Lake Formation replaces IAM rather than adding to it

context

resolving links…