If I revoke a principal's direct SELECT grant on a table, does that fully remove their access?

Not necessarily, if the same principal also has access via an LF-Tag policy that happens to match that table (say, they're granted access to all tables tagged DataClassification=internal, and this table carries that tag), they retain access through that separate grant path. Revoking one grant mechanism doesn't automatically revoke access granted through the other, always check both direct and tag-based grants when auditing or trying to fully remove a principal's access to a resource.

Does a DataCellsFilter's ColumnNames list included or excluded columns?

It's an inclusion list, ColumnNames specifies exactly which columns the filter exposes, any column not listed is excluded from what the filtered view shows, this is the mechanism for hiding PII or sensitive columns from a broader table grant, list only the safe-to-see columns rather than trying to enumerate columns to hide.

Can a single principal be granted access via both a Table-scoped permission and a Database-scoped permission?

Yes, Lake Formation permissions can be granted at the catalog, database, or table (and even column) level, and a principal's effective access is the union of whatever grants apply across all these levels plus any matching LF-Tag policies, this layered model is powerful for centralized governance but requires checking multiple grant sources to fully understand a given principal's actual effective access, not just the most specific-looking grant.

AWS Lake Formation Permission Builder

MonitoringAWS

Build Lake Formation permission configurations with LF-Tags, data cell filters, and column/row-level security.

AWS Lake Formation Configuration

Build Lake Formation permission configurations with LF-Tags, data cell filters, and column/row-level security.

Required Fields

CatalogIdPrincipal.DataLakePrincipalIdentifierPermissions

{
  "CatalogId": "123456789012",
  "Principal": {
    "DataLakePrincipalIdentifier": "arn:aws:iam::123456789012:role/DataAnalystRole"
  },
  "Resource": {
    "Table": {
      "CatalogId": "123456789012",
      "DatabaseName": "analytics_db",
      "Name": "customer_events"
    }
  },
  "Permissions": [
    "SELECT",
    "DESCRIBE"
  ],
  "PermissionsWithGrantOption": [],
  "LFTags": [
    {
      "CatalogId": "123456789012",
      "TagKey": "DataClassification",
      "TagValues": ["public", "internal"]
    },
    {
      "CatalogId": "123456789012",
      "TagKey": "Department",
      "TagValues": ["analytics", "marketing"]
    }
  ],
  "LFTagPolicy": {
    "CatalogId": "123456789012",
    "ResourceType": "TABLE",
    "Expression": [
      {
        "TagKey": "DataClassification",
        "TagValues": ["public", "internal"]
      }
    ]
  },
  "DataCellsFilter": {
    "Name": "exclude-pii-columns",
    "DatabaseName": "analytics_db",
    "TableName": "customer_events",
    "ColumnNames": ["event_type", "event_date", "product_id", "session_id"],
    "RowFilter": {
      "FilterExpression": "event_date >= '2024-01-01'"
    }
  }
}

Generated Output

Output will appear here...

What This Tool Does

Build a Lake Formation permission grant combining direct resource-level permissions (Permissions on a specific Table) with tag-based access control (LFTagPolicy matching resources by LF-Tag key/value rather than by name) and DataCellsFilter for column- and row-level security on top of table-level grants. LF-Tag-based permissions and named-resource permissions aren't mutually exclusive, they compose: a principal can gain access to a table both because they're directly granted on it AND because it happens to match an LF-Tag policy they have access to, meaning removing one grant doesn't necessarily fully revoke access if the other grant path still applies, a real gotcha when auditing 'does this principal still have access after I revoked X'.

Technical Details

The builder validates that CatalogId, Principal.DataLakePrincipalIdentifier, and Permissions all resolve before accepting the JSON as a valid GrantPermissions request, the fields Lake Formation needs to know who's being granted what; it can't verify the referenced table or database actually exists in the catalog, or compute a principal's full effective access across all grant mechanisms (direct, tag-based, inherited), that requires querying the live Lake Formation permission model directly.

Common Use Cases

1Granting SELECT and DESCRIBE (read-only) on a specific table to a DataAnalystRole, explicitly leaving PermissionsWithGrantOption empty so that role can query the data but can't re-grant access to others, keeping permission delegation centrally controlled.
2Defining an LFTagPolicy matching DataClassification in [public, internal] rather than naming specific tables, so newly-created tables automatically inherit the correct access grants the moment they're tagged appropriately, without needing a new named-resource grant for every new table.
3Attaching a DataCellsFilter that excludes specific PII columns (via ColumnNames listing only the non-sensitive columns to include) and a RowFilter limiting visible rows by date, so an analyst role sees a governed, filtered view of a table rather than the full raw dataset.
4Auditing a principal's actual effective access to a table by checking both direct table-level grants AND any LF-Tag policies matching that table which the principal also has access to, since either path alone can grant access.

Common Questions

If I revoke a principal's direct SELECT grant on a table, does that fully remove their access?: Not necessarily, if the same principal also has access via an LF-Tag policy that happens to match that table (say, they're granted access to all tables tagged DataClassification=internal, and this table carries that tag), they retain access through that separate grant path. Revoking one grant mechanism doesn't automatically revoke access granted through the other, always check both direct and tag-based grants when auditing or trying to fully remove a principal's access to a resource.
Does a DataCellsFilter's ColumnNames list included or excluded columns?: It's an inclusion list, ColumnNames specifies exactly which columns the filter exposes, any column not listed is excluded from what the filtered view shows, this is the mechanism for hiding PII or sensitive columns from a broader table grant, list only the safe-to-see columns rather than trying to enumerate columns to hide.
Can a single principal be granted access via both a Table-scoped permission and a Database-scoped permission?: Yes, Lake Formation permissions can be granted at the catalog, database, or table (and even column) level, and a principal's effective access is the union of whatever grants apply across all these levels plus any matching LF-Tag policies, this layered model is powerful for centralized governance but requires checking multiple grant sources to fully understand a given principal's actual effective access, not just the most specific-looking grant.

Expert Tips

TIP

When auditing or revoking a principal's access, check LF-Tag policy grants in addition to direct named-resource grants, a principal's effective access is the union of both paths, and forgetting to check tag-based grants is the most common reason a 'revoked' principal still has access.

TIP

DataCellsFilter's ColumnNames is inclusion-based, not exclusion-based, double-check the list actually contains every column you intend to expose, an incomplete inclusion list silently hides more than intended rather than erroring.

TIP

Prefer LF-Tag-based policies over per-table named grants for anything that should scale automatically as new tables are created and tagged, named-resource grants require a new grant action for every new table, which doesn't scale as a data lake's table count grows.

Related Learning Guides

DynamoDB Data Modeling28 min read
Cost Optimization Strategies26 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

AWS Lake Formation Permission Builder

MonitoringAWS

Build Lake Formation permission configurations with LF-Tags, data cell filters, and column/row-level security.

AWS Lake Formation Configuration

Build Lake Formation permission configurations with LF-Tags, data cell filters, and column/row-level security.

Required Fields

CatalogIdPrincipal.DataLakePrincipalIdentifierPermissions

Generated Output

Output will appear here...

What This Tool Does

Technical Details

Common Use Cases

1Granting SELECT and DESCRIBE (read-only) on a specific table to a DataAnalystRole, explicitly leaving PermissionsWithGrantOption empty so that role can query the data but can't re-grant access to others, keeping permission delegation centrally controlled.
2Defining an LFTagPolicy matching DataClassification in [public, internal] rather than naming specific tables, so newly-created tables automatically inherit the correct access grants the moment they're tagged appropriately, without needing a new named-resource grant for every new table.
3Attaching a DataCellsFilter that excludes specific PII columns (via ColumnNames listing only the non-sensitive columns to include) and a RowFilter limiting visible rows by date, so an analyst role sees a governed, filtered view of a table rather than the full raw dataset.
4Auditing a principal's actual effective access to a table by checking both direct table-level grants AND any LF-Tag policies matching that table which the principal also has access to, since either path alone can grant access.

Common Questions

If I revoke a principal's direct SELECT grant on a table, does that fully remove their access?: Not necessarily, if the same principal also has access via an LF-Tag policy that happens to match that table (say, they're granted access to all tables tagged DataClassification=internal, and this table carries that tag), they retain access through that separate grant path. Revoking one grant mechanism doesn't automatically revoke access granted through the other, always check both direct and tag-based grants when auditing or trying to fully remove a principal's access to a resource.
Does a DataCellsFilter's ColumnNames list included or excluded columns?: It's an inclusion list, ColumnNames specifies exactly which columns the filter exposes, any column not listed is excluded from what the filtered view shows, this is the mechanism for hiding PII or sensitive columns from a broader table grant, list only the safe-to-see columns rather than trying to enumerate columns to hide.
Can a single principal be granted access via both a Table-scoped permission and a Database-scoped permission?: Yes, Lake Formation permissions can be granted at the catalog, database, or table (and even column) level, and a principal's effective access is the union of whatever grants apply across all these levels plus any matching LF-Tag policies, this layered model is powerful for centralized governance but requires checking multiple grant sources to fully understand a given principal's actual effective access, not just the most specific-looking grant.

Expert Tips

TIP

Related Learning Guides

DynamoDB Data Modeling28 min read
Cost Optimization Strategies26 min read

Was this tool helpful?