# Lake Formation best practices, considerations, and limitations
Use this section to quickly find best practices, considerations, and limitations within AWS Lake Formation.
See [Service quotas](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation) for the maximum number of service resources or operations for your AWS account.
**Topics**
+ [
# Cross-account data sharing best practices and considerations
](cross-account-notes.md)
+ [
# Service-linked role limitations
](service-linked-role-limitations.md)
+ [
# Cross-Region data access limitations
](x-region-considerations.md)
+ [
# Data Catalog views considerations and limitations
](views-notes.md)
+ [
# Data filtering limitations
](data-filtering-notes.md)
+ [
# Hybrid access mode considerations and limitations
](notes-hybrid.md)
+ [
# Limitations for bringing Amazon Redshift data warehouse data into the AWS Glue Data Catalog
](notes-ns-catalog.md)
+ [
# S3 Tables catalog integration limitations
](notes-s3-catalog.md)
+ [
# Hive metadata store data sharing considerations and limitations
](notes-hms.md)
+ [
# Amazon Redshift data sharing limitations
](notes-rs-datashare.md)
+ [
# IAM Identity Center integration limitations
](identity-center-lf-notes.md)
+ [
# Lake Formation tag-based access control best practices and considerations
](lf-tag-considerations.md)
+ [
# Attribute-based access control considerations, limitations, and supported regions
](abac-considerations.md)
# Cross-account data sharing best practices and considerations
Lake Formation cross-account capabilities allow users to securely share distributed data lakes across multiple AWS accounts, AWS organizations or directly with IAM principals in another account providing fine-grained access to the Data Catalog metadata and underlying data.
Consider the following best practices when using Lake Formation cross-account data sharing:
+ There is no limit to the number of Lake Formation permission grants that you can make to principals in your own AWS account. However, Lake Formation uses AWS Resource Access Manager (AWS RAM) capacity for cross-account grants that your account can make with the named resource method. To maximize the AWS RAM capacity, follow these best practices for the named resource method:
+ Use the new cross-account grant mode (**Version 3** and above under **Cross account version settings**) to share a resource with an external AWS account. For more information, see [Updating cross-account data sharing version settings](optimize-ram.md).
+ Arrange AWS accounts into organizations, and grant permissions to organizations or organizational units. A grant to an organization or organizational unit counts as one grant.
Granting to organizations or organizational units also eliminates the need to accept an AWS Resource Access Manager (AWS RAM) resource share invitation for the grant. For more information, see [Accessing and viewing shared Data Catalog tables and databases](viewing-shared-resources.md).
+ Instead of granting permissions on many individual tables in a database, use the special **All tables** wildcard to grant permissions on all tables in the database. Granting on **All tables** counts as a single grant. For more information, see [Granting permissions on Data Catalog resources](granting-catalog-permissions.md).
**Note**
For more information about requesting a higher limit for the number of resource shares in AWS RAM, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in the *AWS General Reference*.
+ You must create a resource link to a shared database for that database to appear in the Amazon Athena and Amazon Redshift Spectrum query editors. Similarly, to be able to query shared tables using Athena and Redshift Spectrum, you must create resource links to the tables. The resource links then appear in the tables list of the query editors.
Instead of creating resource links for many individual tables for querying, you can use the **All tables** wildcard to grant permissions on all tables in a database. Then, when you create a resource link for that database and select that database resource link in the query editor, you'll have access to all tables in that database for your query. For more information, see [Creating resource links](creating-resource-links.md).
+ When you share resources directly with principals in another account, the IAM principal in the recipient account may not have permission to create resource links to be able to query the shared tables using Athena and Amazon Redshift Spectrum. Instead of creating a resource link for each table that is shared, the data lake administrator can create a placeholder database and grant `CREATE_TABLE` permission to the `ALLIAMPrincipal` group. Then, all IAM principals in the recipient account can create resource links in the placeholder database and start querying the shared tables.
See the example CLI command for granting permissions to `ALLIAMPrincipals` in [Granting database permissions using the named resource method](granting-database-permissions.md).
+ When cross-account permissions are granted directly to a principal, only the recipient of the grant can view these permissions. The data lake administrator in the recipient's AWS account cannot view these direct grants.
+ Athena and Redshift Spectrum support column-level access control, but only for inclusion, not exclusion. Column-level access control is not supported in AWS Glue ETL jobs.
+ When a resource is shared with your AWS account, you can grant permissions on the resource only to users in your account. You can't grant permissions on the resource to other AWS accounts, to organizations (not even your own organization), or to the `IAMAllowedPrincipals` group.
+ You can't grant `DROP` or `Super` on a database to an external account.
+ Revoke cross-account permissions before you delete a database or table. Otherwise, you must delete orphaned resource shares in AWS Resource Access Manager.
**See also**
[Lake Formation tag-based access control best practices and considerations](lf-tag-considerations.md)
[`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table) in the [Lake Formation permissions reference](lf-permissions-reference.md) for more cross-account access rules and limitations.
# Service-linked role limitations
A service-linked role is a special type of IAM role that's linked directly to AWS Lake Formation. This role has pre-defined permissions that allow Lake Formation to perform actions on your behalf across AWS services.
The following limitations apply when using a service-linked role (SLR) to register data locations with Lake Formation.
+ You can't modify service-linked role policies once created.
+ A service linked role doesn't support encrypted catalog resources sharing across accounts. Encrypted resources require specific AWS KMS key permissions. Service-linked roles have pre-defined permissions that don't include the ability to work with encrypted catalog resources across accounts.
+ When registering multiple Amazon S3 locations, using service-linked role may cause you to exceed your IAM policy limits quickly. This happens because with service-linked roles, AWS writes the policy for you, and it increments as one large block that includes all your registrations. You can write customer-managed policies more efficiently, distribute permissions across multiple policies, or use different roles for different Regions.
+ Amazon EMR on EC2 can't access data you register data locations with service-linked roles.
+ Service-linked role operations bypass your AWS service control policies.
+ When you register data locations with a service-linked role, it updates IAM policies with eventual consistency. For more information, see the the [Troubleshoot IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency) documentation in the IAM User Guide.
+ You can't set `SET_CONTEXT = TRUE` in Lake Formation data lake settings when using service-linked roles, and you are using IAM Identity Center. The reason is that service-linked roles have immutable trust policies that are incompatible with the trusted identity propagation needed for `SetContext` auditing with IAM Identity Center principals.
# Cross-Region data access limitations
Lake Formation supports querying Data Catalog tables across AWS Regions. You can access data in a Region from other Regions using Amazon Athena, Amazon EMR, and AWS Glue ETL by creating resource links in other Regions pointing to the source databases and tables. With cross-Region table access, you can access data across Regions without copying the underlying data or the metadata into the Data Catalog.
The following limitations apply to cross-Region table access.
+ Lake Formation doesn't support querying Data Catalog tables from another Region using Amazon Redshift Spectrum.
+ In the Lake Formation console, the database and table views don't show the source Region database/table names.
+ To view the list of tables under a shared database from another Region, you need to first create a resource link to the shared database, then select the resource link, and choose **View tables**.
+ Lake Formation doesn't support cross-Region resource link calls made by SAML users.
+ Lake Formation's cross-Region feature doesn't involve additional charges for data transfers.
# Data Catalog views considerations and limitations
The following considerations and limitations apply to Data Catalog views.
+ You cannot create a Data Catalog view from the Lake Formation console. You can create views using the AWS CLI or SDK.
+ You can create Data Catalog views from 10 tables. It is a hard limit. Underlying reference tables for a view can belong to the same database or different databases within the same AWS account.
+ For additional considerations and limitations specific to creating Data Catalog views using Redshift, see the [Data Catalog views considerations and limitations](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations) section in the Amazon Redshift Database Developer Guide. For Athena, see the [Data Catalog views considerations and limitations](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations) section in the Amazon Athena User Guide.
+ You can create Data Catalog views on tables registered with Lake Formation in both hybrid access mode and Lake Formation mode.
When using Data Catalog views with Lake Formation hybrid access mode, it is recommended to ensure that the view consuming principals are opted in to Lake Formation permissions for the base tables referenced in the view without granting access. This ensures that the base tables will not be revealed to consumers through AWS Glue IAM permissions.
+ There are no restrictions on the cross-account sharing version to share views.
+ Views get versioned just like Data Catalog tables, when you use the `ALTER VIEW` statement for an already created view dialect. You cannot roll back to a previous view because the view version changes with the underlying data changes. You can delete a view version and it will default to the next available latest version. When you change the view version, make sure your data is in sync with the selected view version schema.
+ No new Data Catalog APIs are introduced. The existing `CreateTable`, `UpdateTable`, `DeleteTable` and `GetTable` APIs are updated.
+ Amazon Redshift always creates views with varchar columns from tables with strings. You must cast string columns to varchar with an explicit length when adding dialects from other engines.
+ Granting data lake permissions to `All tables` within a database will result in the grantee having permissions on all tables and views within the database.
+ You can't create views:
+ That reference other views.
+ When the reference table is a resource link.
+ When the reference table is in another account.
+ From external Hive metastores.
+ Cross-account definer roles are not supported for Redshift Spectrum Dialect views.
+ Resource links for the Athena dialect in the Athena query editor is not supported. To use cross-account definer roles for the Athena dialect, add the account that hosts the base tables as a Data Source in Athena.
# Data filtering limitations
When you grant Lake Formation permissions on a Data Catalog table, you can include data filtering specifications to restrict access to certain data in query results and engines integrated with Lake Formation. Lake Formation uses data filtering to achieve column-level security, row-level security, and cell-level security. You can define and apply data filters on nested columns if your source data contains nested structures.
## Notes and restrictions for column-level filtering
There are three ways to specify column filtering:
+ By using data filters
+ By using simple column filtering or nested column filtering.
+ By using TAGs.
Simple column filtering just specifies a list of columns to include or exclude. Both the Lake Formation console, the API, and the AWS CLI support simple column filtering. For an example, see [Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example).
The following notes and restrictions apply to column filtering:
+ AWS Glue 5.0 or higher supports fine-grained access control via Lake Formation only for Apache Hive and Apache Iceberg tables.
+ To grant `SELECT` with the grant option and column filtering, you must use an include list, not an exclude list. Without the grant option, you can use either include or exclude lists.
+ To grant `SELECT` on a table with column filtering, you must have been granted `SELECT` on the table with the grant option and without any row restrictions. You must have access to all rows.
+ If you grant `SELECT` with the grant option and column filtering to a principal in your account, that principal must specify column filtering for the same columns or a subset of the granted columns when granting to another principal. If you grant `SELECT` with the grant option and column filtering to an external account, the data lake administrator in the external account can grant `SELECT` on all columns to another principal in their account. However, even with `SELECT` on all columns, that principal will have visibility only on the columns granted to the external account.
+ You can't apply column filtering on partition keys.
+ A principal with the `SELECT` permission on a subset of columns in a table can't be granted the `ALTER`, `DROP`, `DELETE`, or `INSERT` permission on that table. For a principal with the `ALTER`, `DROP`, `DELETE`, or `INSERT` permission on a table, if you grant the `SELECT` permission with column filtering, it has no effect.
The following notes and restrictions apply to nested column filtering:
+ You can include or exclude five-levels of nested fields in a data filter.
**Example**
Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11
+ You can't apply column filtering on nested fields within partition columns.
+ If your table schema contains a top-level column name ("customer"."address") that has the same pattern of a nested field representation within a data filter (a nested column with a top level column name `customer` and a nested field name `address` is specified as `"customer"."address"` in a data filter), you can't explicitly specify access to either top level column or nested field because both are represented using the same pattern in the inclusion/exclusion lists. This is ambiguous, and Lake Formation can't resolve if you're specifying the top level column or the nested field.
+ If a top level column or nested field contains a double quote within the name, you must include a second double quote when you specify access to a nested field within a data cells filter's include and exclude list.
**Example**
Example nested column name with double quotes – `a.b.double"quote`
**Example**
Example nested column representation within a data filter – ` "a"."b"."double""quote"`
## Cell-level filtering limitations
Keep in mind the following notes and restrictions for row-level and cell-level filtering.
+ Cell-level security is not supported on nested columns, views, and resource links.
+ All expressions that are supported on top level columns are also supported on nested columns. However, nested fields under partition columns should **NOT** be referenced when defining nested row-level expressions.
+ Cell-level security is available in all regions when using Athena engine version 3 or Amazon Redshift Spectrum. For other services, cell-level security is only available in the regions mentioned on the [Supported Regions](supported-regions.md).
+ `SELECT INTO` statements are not supported.
+ The `array`, and `map` data types aren't supported in row filter expressions. The `struct` data type is supported.
+ There is no limit to the number of data filters that can be defined on a table, but there is a limit of 100 data filter for a single principal on a table.
+ To apply a data filter with a row filter expression, you must have `SELECT` with the grant option on all table columns. This restriction doesn't apply to administrators in external accounts when the grant was made to the external account.
+ If a principal is a member of a group and both the principal and the group are granted permissions on a subset of rows, the principal's effective row permissions are the union of the principal's permissions and the group's permissions.
+ The following column names are restricted in a table for row-level and cell-level filtering:
+ ctid
+ oid
+ xmin
+ cmin
+ xmax
+ cmax
+ tableoid
+ insertxid
+ deletexid
+ importoid
+ redcatuniqueid
+ If you apply the all-rows filter expression on a table concurrently with other filter expressions with predicates, the all-rows expression will prevail over all other filter expressions.
+ When permissions on a subset of rows are granted to an external AWS account and the data lake administrator of the external account grants those permissions to a principal in that account, the principal's effective filter predicate is the intersection of the account's predicate and any predicate that was directly granted to the principal.
For example, if the account has row permissions with the predicate `dept='hr'` and the principal was separately granted permission for `country='us'`, the principal has access only to rows with `dept='hr'` and `country='us'`.
For more information about cell-level filtering, see [Data filtering and cell-level security in Lake Formation](data-filtering.md).
For consideration and limitations when querying tables using Amazon Redshift Spectrum with row-level security policies, see [Considerations and limitations using RLS policies](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html) in the Amazon Redshift Database Developer Guide.
# Hybrid access mode considerations and limitations
Hybrid access mode provides the flexibility to selectively enable Lake Formation permissions for databases and tables in your AWS Glue Data Catalog.
With the Hybrid access mode, you now have an incremental path that allows you to set Lake Formation permissions for a specific set of users without interrupting the permission policies of other existing users or workloads.
The following considerations and limitations apply to hybrid access mode.
**Limitations**
+ **Update Amazon S3 location registration** – You can't edit parameters of a location that is registered with Lake Formation using a service linked role.
+ **Opt in option when using LF-Tags** – When you can grant Lake Formation permissions using LF-Tags, you can opt in principals to enforce Lake Formation permissions as a consecutive step by choosing databases and tables that has LF-Tags attached.
+ **Hybrid access mode access** – Access to hybrid access mode in Lake Formation is limited to users with data lake administrator or read-only administrator permissions.
+ **Opt in principals** – Currently, only a data lake administrator role can opt in principals to resources.
+ **Opt in all tables in a database** – In cross-account grants, when you grant permissions, and opt in all tables in a database, you need to opt in the database also for the permissions to work.
**Considerations**
+ **Updating Amazon S3 location registered with Lake Formation to hybrid access mode** – We do not recommend converting a Amazon S3 data location that is already registered with Lake Formation to hybrid access mode though it can be done.
+ **API behaviors when a data location is registered in hybrid access mode**
+ CreateTable – The location is considered as registered with Lake Formation regardless of the hybrid access mode flag and opt in status. Thus, the user requires the data location permission to create a table.
+ CreatePartition/BatchCreatePartitions/UpdatePartitions (when partition location is updated to point to the location registered with hybrid) – The Amazon S3 location is considered as registered with Lake Formation regardless of the hybrid access mode flag and opt in status. Thus, the user requires the data location permission to create or update a database.
+ CreateDatabase/UpdateDatabase (when database location is updated to point to the location registered in hybrid access mode) – The location is considered as registered with Lake Formation regardless of the hybrid access mode flag and opt in status. Thus, the user requires the data location permission to create or update a database.
+ UpdateTable (when a table location is updated to point to the location registered in hybrid access mode) – The location is considered as registered with Lake Formation regardless of the hybrid access mode flag and opt in status. Thus, the user requires data location permission to update the table. If the table location is not updated or it is pointing to a location that is not registered with Lake Formation, the user doesn't require data location permission to update the table.
# Limitations for bringing Amazon Redshift data warehouse data into the AWS Glue Data Catalog
You can catalog, and manage access to analytic data in Amazon Redshift data warehouses using the AWS Glue Data Catalog. The following limitations apply:
+ Cross-account sharing is not supported at the federated catalog level. However, you can share individual databases and tables from within a federated catalog across AWS accounts.
+ You must have **Cross account version settings** version 4 or higher for sharing databases or tables in the federated catalog across AWS accounts.
+ The Data Catalog supports the creation of only top-level catalogs.
+ You can only update the description of catalogs in the Redshift Managed Storage (RMS).
+ Setting up permissions on federated catalogs as well as databases and tables in the federated catalog to `IAMAllowedPrincipals` group is not supported.
+ Data Definition Language (DDL) operations on the catalog from engines like Athena, Amazon EMR Spark, or others, including setting catalog configurations, are not supported.
+ Performing DDL operations on RMS tables using Athena is not supported.
+ Creating materialized views is not supported, whether it is through Athena, Apache Spark, the AWS Glue Data Catalog, or the Amazon Redshift consumer.
+ Athena doesn't support a multi-catalog experience. It can only connect to a single, specific catalog at a time. Athena can't access or query across multiple catalogs simultaneously.
+ Tagging and branching operations on Iceberg tables through Athena and Amazon Redshift are not supported.
+ Time Travel on RMS tables is not supported.
+ Multi-level catalogs with data lake tables are not supported. All data stored in Amazon S3 for use with data lake tables must reside in the default AWS Glue Data Catalog, and can't be organized into multi-level catalogs.
+ In Amazon Redshift, datashares are not added to the registered namespace. Clusters and namespaces are synonymous, once you publish a cluster to the AWS Glue Data Catalog, you can't add new data.
+ Amazon EMR on EC2 doesn't support joining across RMS tables and Amazon S3 tables. Only EMR Serverless supports this capability.
+ External schemas and tables are not supported.
+ RMS tables are accessible only from the extension endpoint in AWS Glue Iceberg REST Catalog.
+ Hive tables are not accessible from third-party engines connected to the AWS Glue Iceberg REST Catalog.
+ The read\$1committed isolation level on RMS tables through Spark will be supported.
+ Redshift database names are treated as case-insensitive in the AWS Glue Data Catalog, restricted to 128 characters, and can be alphanumeric with dashes (-) and underscores (\$1).
+ The catalog names are case-insensitive, restricted to 50 characters, and can be alphanumeric with dashes (-) and underscores (\$1).
+ Amazon Redshift doesn't support using Lake Formation SQL-style GRANT and REVOKE commands to manage access permissions on tables published to the AWS Glue Data Catalog.
+ Row-level security and dynamic data masking policies that are attached to the producer (source) Amazon Redshift cluster will not be enforced. Instead, access permissions defined in Lake Formation will be enforced on the shared data.
+ Performing Data Definition Language (DDL) and Data Manipulation Language (DML) operations on table links are not supported.
+ If reserved keywords are not properly escaped, it will result in failures or errors.
+ Encryption of data in multi-catalog scenarios is not supported.
# S3 Tables catalog integration limitations
Amazon S3 Tables integrates with AWS Glue Data Catalog (Data Catalog) and registers the catalog as a Lake Formation data location. You can set up this registration from the Lake Formation console or by using the service APIs.
**Note**
If you have an IAM or S3 Tables resource-based policy that restricts IAM users and IAM roles based on principal tags, you must attach the same principal tags to the IAM role that Lake Formation uses to access your S3 data (for example, LakeFormationDataAccessRole) and grant this role the necessary permissions. This is required for your tag-based access control policy to work correctly with your S3 Tables analytics integration.
The following limitations apply to integrating S3 Tables catalog with Data Catalog and Lake Formation:
+ AWS Glue and Lake Formation don't support mixed-case column names, and convert all column names to lowercase. You must verify that table column names are unique when converted to lowercase. Use `customer_id` instead of `customerId`. The use of mixed-case column names was supported only during the preview release.
+ The CreateCatalog API cannot create table buckets in Amazon S3.
+ The SearchTables API cannot search S3 Tables.
# Hive metadata store data sharing considerations and limitations
With AWS Glue Data Catalog metadata federation (Data Catalog federation), you can connect the Data Catalog to external metastores that store metadata for your Amazon S3 data, and securely manage data access permissions using AWS Lake Formation.
The following considerations and limitations apply to federated databases that are created from Hive databases:
**Considerations**
+ **AWS SAM application support** – You're responsible for the availability of application resources that AWS SAM deploys (Amazon API Gateway and Lambda function). Make sure that the connection between the AWS Glue Data Catalog and the Hive metastore is working when users run queries.
+ **Hive metastore version requirement** – You can create federated databases only using Apache Hive version 3 and above.
+ **Mapped database requirement** – Every Hive database must be mapped to a new database in Lake Formation.
+ **Database-level federation support** – You can connect to Hive metastore only at the database level.
+ **Permissions on federated databases** – The permissions applied on a federated database or tables under a federated database persist even when a source table or a database is deleted. When the source database or table is recreated, you don't need to regrant the permissions. When a federated table with Lake Formation permissions is deleted at source, Lake Formation permissions are still visible, and you can revoke them if needed.
If a user deletes a federated database, all of its corresponding permissions are lost. Recreating the same database with the same name, will not recover Lake Formation permissions. Users will have to setup new permissions again.
+ **IAMAllowedPrincipal group permissions** on federated databases – Based on the `DataLakeSettings`, Lake Formation might set permissions to all databases and tables to a virtual group named `IAMAllowedPrincipal`. The `IAMAllowedPrincipal` refers to all IAM principals who have access to Data Catalog resources through IAM principal policies and AWS Glue resource policies. If these permissions exist on a database or a table, all principals are granted access to the database or table.
However, Lake Formation doesn't allow `IAMAllowedPrincipal` permissions on tables under federated databases. When you create federated databases, make sure that you pass the `CreateTableDefaultPermissions` parameter as an empty list.
For more information, see [Changing the default settings for your data lake](change-settings.md).
+ **Joining tables in queries** – You can join Hive metastore tables with Data Catalog native tables to run queries.
**Limitations**
+ **Limitation on syncing metadata between the AWS Glue Data Catalog and the Hive metastore** – After establishing the Hive metastore connection, you need to create a federated database to sync metadata in the Hive metastore with the AWS Glue Data Catalog. The tables under the federated database are synced at runtime when users run queries.
+ **Limitation on creating new tables under a federated database** – You will not be able to create new tables under federated databases.
+ **Data permission limitation** – Support for permissions on Hive metastore table views is not available.
# Amazon Redshift data sharing limitations
AWS Lake Formation allows you to securely manage data in a datashare from Amazon Redshift. Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the AWS Cloud. Using the data sharing capability, Amazon Redshift helps you to share data across AWS accounts. For more information about Amazon Redshift data sharing, see [Overview of data sharing in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html).
The following notes and restrictions apply to federated databases that are created from Amazon Redshift datashares:
+ **Mapped database requirement** – Every Amazon Redshift datashare must be mapped to a new database in Lake Formation. This is required to maintain unique table names when the datashare objects representation is flattened in the Data Catalog database.
+ **Limitation on creating new tables under a federated database** – You will not be able to create new tables under federated databases.
+ **Permissions on the federated databases** – The permissions applied on a federated database or tables under a federated database persist even when a source table or a database is deleted. When the source database or table is recreated, you do not need to regrant the permissions. When a federated table with Lake Formation permissions is deleted at source, Lake Formation permissions will still be visible and you can revoke them if needed.
If a user deletes a federated database, all its corresponding permissions are lost. Recreating the same database with the same name, will not recover Lake Formation permissions. Users will have to setup new permissions again.
+ **IAMAllowedPrincipal group permissions on federated databases** – Based on the `DataLakeSettings`, Lake Formation might set permissions to all databases and tables to a virtual group named `IAMAllowedPrincipal`. The `IAMAllowedPrincipal` refers to all IAM principals who have access to Data Catalog resources through IAM principal policies and AWS Glue resource policies. If these permissions exist on a database or a table, all principals are granted access to the database or table.
However, Lake Formation doesn't allow `IAMAllowedPrincipal` permissions on tables under federated databases. When you create federated databases, make sure that you pass the `CreateTableDefaultPermissions` parameter as an empty list.
For more information, see [Changing the default settings for your data lake](change-settings.md).
+ **Data filtering** – In Lake Formation, you can grant permissions on a table under a federated database with column-level and row-level filtering. However, you can't combine column-level and row-level filtering to restrict access at cell-level granularity on tables under federated databases.
+ **Case sensitivity identifier** – Amazon Redshift datashare objects managed by Lake Formation, will support table names and column names only in lowercase. Don't turn on case sensitivity identifier for databases, tables, and columns in Amazon Redshift datashares, if they will be shared and managed using Lake Formation.
+ **Query support** – You can query Amazon Redshift datashares managed by Lake Formation with Amazon Redshift. Athena doesn't support querying Amazon Redshift datashares managed by Lake Formation.
For more information on limitations when working with datashares in Amazon Redshift, see [Limitations for data sharing](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare) in the Amazon Redshift Database Developer Guide.
# IAM Identity Center integration limitations
With AWS IAM Identity Center, you can connect to identity providers (IdPs) and centrally manage access for users and groups across AWS analytics services. You can configure AWS Lake Formation as an enabled application in IAM Identity Center, and data lake administrators can grant fine-grained permissions to authorized users and groups on AWS Glue Data Catalog resources.
The following limitations apply to Lake Formation integration with IAM Identity Center:
+ You can't assign IAM Identity Center users and groups as data lake administrators or read-only administrators in Lake Formation.
IAM Identity Center users and groups can query encrypted Data Catalog resources if you are using an IAM role that AWS Glue can assume on your behalf for encrypting and decrypting the Data Catalog. AWS managed keys don't support trusted identity propagation.
+ IAM Identity Center users and groups can only invoke API operations listed in the `AWSIAMIdentityCenterAllowListForIdentityContext` policy provided by IAM Identity Center.
+ Lake Formation permits IAM roles from external accounts to act as carrier roles on behalf of IAM Identity Center users and groups for accessing Data Catalog resources, but permissions can only be granted on Data Catalog resources within the owning account. If you try to grant permissions to IAM Identity Centerusers and groups on Data Catalog resources in an external account, Lake Formation throws the following error - "Cross-account grants are not supported for the principal."
+ When using Lake Formation with IAM Identity Center, the application assignment configuration is set to `false` by default. If you modify this configuration directly through the [IAM Identity Center API](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html), you must then manage all application assignments manually using the API. Lake Formation does not automatically synchronize or manage assignment changes made outside of its standard workflows, which may impact access patterns and authorization flows within your data lake environment.
# Lake Formation tag-based access control best practices and considerations
You can create, maintain, and assign LF-Tags to control access to Data Catalog databases, tables, and columns.
Consider the following best practices when using Lake Formation tag-based access control:
+ All LF-Tags must be predefined before they can be assigned to Data Catalog resources or granted to principals.
The data lake administrator can delegate tag management tasks by creating *LF-Tag creators* with the required IAM permissions. Data engineers and analysts decide on the characteristics and relationships for LF-Tags. The LF-Tag creators then creates and maintains the LF-Tags in Lake Formation.
+ You can assign multiple LF-Tags to Data Catalog resources. Only one value for a particular key can be assigned to a particular resource.
For example, you can assign `module=Orders`, `region=West`, `division=Consumer`, and so on to a database, table, or column. You can't assign `module=Orders,Customers`.
+ You can't assign LF-Tags to resources when you create the resource. You can only add LF-Tags to existing resources.
+ You can grant LF-Tag expressions, not just single LF-Tags, to a principal.
A LF-Tag expression looks something like the following (in pseudo-code).
```
module=sales AND division=(consumer OR commercial)
```
A principal that is granted this LF-Tag expression can access only Data Catalog resources (databases, tables, and columns) that are assigned `module=sales` *and* either `division=consumer` or `division=commercial`. If you want the principal to be able to access resources that have `module=sales` *or* `division=commercial`, don't include both in the same grant. Make two grants, one for `module=sales` and one for `division=commercial`.
The simplest LF-Tag expression consists of just one LF-Tag, such as `module=sales`.
+ A principal that is granted permissions on a LF-Tag with multiple values can access Data Catalog resources with either of those values. For example, if a user is granted a LF-Tag with key=`module` and values=`orders,customers`, the user has access to resources that are assigned either `module=orders` or `module=customers`.
+ You need to have `Grant with LF-Tag expressions` permission to grant data permissions on Data Catalog resources by using the LF-TBAC method. The data lake administrator and the LF-Tag creator implicitly receive this permission. A principal that has the `Grant with LFTag expressions` permission can grant data permissions on the resources using:
+ the named resource method
+ the LF-TBAC method, but only using the same LF-Tag expression
For example, assume that the data lake administrator makes the following grant (in pseudo-code).
```
GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION
```
In this case, `user1` can grant `SELECT` on tables to other principals by using the LF-TBAC method, but only with the complete LF-Tag expression `module=customers, region=west,south`.
+ If a principal is granted permissions on a resource with both the LF-TBAC method and the named resource method, the permissions that the principal has on the resource is the union of the permissions granted by both methods.
+ Lake Formation supports granting `DESCRIBE` and `ASSOCIATE` on LF-Tags across accounts, and granting permissions on Data Catalog resources across accounts using the LF-TBAC method. In both cases, the principal is an AWS account ID.
**Note**
Lake Formation supports cross-account grants to organizations and organizational units using LF-TBAC method. To use this capability, you need to update **Cross account version settings** to **Version 3**.
For more information, see [Cross-account data sharing in Lake Formation](cross-account-permissions.md).
+ Data Catalog resources created in one account can only be tagged using LF-Tags created in the same account. LF-Tags created in one account can't be associated with shared resources from another account.
+ Using Lake Formation tag-based access control (LF-TBAC) to grant cross-account access to Data Catalog resources requires additions to the Data Catalog resource policy for your AWS account. For more information, see [Prerequisites](cross-account-prereqs.md).
+ LF-Tag keys and LF-Tag values can't exceed 50 characters in length.
+ The maximum number of LF-Tags that can be assigned to a Data Catalog resource is 50.
+ The following limits are soft limits:
+ The maximum number of LF-Tags that can be created is 1000.
+ The maximum number of values that can be defined for a LF-Tag is 1000.
+ Tags keys and values are converted to all lower case when they are stored.
+ Only one value for a LF-Tag can be assigned to a particular resource.
+ If multiple LF-Tags are granted to a principal with a single grant, the principal can access only Data Catalog resources that have all of the LF-Tags.
+ If a LF-Tag expression evaluation results in access to only a subset of table columns, but the Lake Formation permission granted when there is a match is one of the permissions that required full column access, namely `Alter`, `Drop`, `Insert`, or `Delete`, then none of those permissions is granted. Instead, only `Describe` is granted. If the granted permission is `All` (`Super`), then only `Select` and `Describe` are granted.
+ Wildcards are not used with LF-Tags. To assign a LF-Tag to all columns of a table, you assign the LF-Tag to the table, and all columns in the table inherit the LF-Tag. To assign a LF-Tag to all tables in a database, you assign the LF-Tag to the database, and all tables in the database inherit that LF-Tag.
+ You can create up to 1000 LF-Tag expressions in an account.
+ You can use up to 50 LF-Tag expressions to grant permissions to a principal on the Data Catalog resources.
+ When granting or revoking permissions on an inline LF-Tag expression, the size of the LF-Tag expression can not exceed 900 bytes. To grant permissions on larger LF-Tag expressions, use the saved LF-Tag expressions. For more information, see [Creating LF-Tag expressions](TBAC-creating-tag-expressions.md).
+ To add LF-Tag to existing Redshift federated catalogs that were created before the general availability release of LF-Tag support for federated catalogs, you need to contact the AWS support team for assistance.
# Attribute-based access control considerations, limitations, and supported regions
The following considerations and limitations apply to Attribute based access control (ABAC).
+ ABAC doesn’t support granting access using LF-Tag policies.
+ Grantable permissions are not available with ABAC.
+ ABAC doesn’t support granting permissions to IAM Identity Center users.
+ When using ABAC grants on a table in Lake Formation, Lake Formation doesn't grant `DESCRIBE` permissions to the parent database or catalog. This differs from non-ABAC scenarios, where Lake Formation provides implicit `DESCRIBE` permissions to parent resources.
+ All principals with the `AmazonDataZoneProject` tag key are always treated as opted in to Lake Formation for all Data Catalog resources.
+ ABAC supports only string attributes.