翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Lake Formation のベストプラクティス、考慮事項、制限事項


このセクションでは、 AWS Lake Formationのベストプラクティス、考慮事項、制限事項をすばやく見つけます。

 AWS アカウントのサービスリソースまたはオペレーションの最大数については、「[サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/lake-formation.html#limits_lake-formation)」を参照してください。

**Topics**
+ [

# クロスアカウントデータ共有のベストプラクティスと考慮事項
](cross-account-notes.md)
+ [

# サービスにリンクされたロールの制限
](service-linked-role-limitations.md)
+ [

# クロスリージョンのデータアクセスに関する制限
](x-region-considerations.md)
+ [

# データカタログビューの考慮事項と制限
](views-notes.md)
+ [

# データフィルタリングの制限事項
](data-filtering-notes.md)
+ [

# ハイブリッドアクセスモードには次の考慮事項と制限事項が適用されます。
](notes-hybrid.md)
+ [

# Amazon Redshift データウェアハウスデータを に取り込む際の制限 AWS Glue Data Catalog
](notes-ns-catalog.md)
+ [

# S3 Tables カタログ統合の制限事項
](notes-s3-catalog.md)
+ [

# Hive メタデータストアのデータ共有に関する考慮事項と制限事項
](notes-hms.md)
+ [

# Amazon Redshift データ共有の制限事項
](notes-rs-datashare.md)
+ [

# IAM アイデンティティセンター 統合の制限事項
](identity-center-lf-notes.md)
+ [

# Lake Formation のタグベースのアクセスコントロールのベストプラクティスと考慮事項
](lf-tag-considerations.md)
+ [

# 属性ベースのアクセス制御に関する考慮事項、制限、サポートされているリージョン
](abac-considerations.md)

# クロスアカウントデータ共有のベストプラクティスと考慮事項


 Lake Formation のクロスアカウント機能を使用すると、ユーザーは分散データレイクを複数の AWS 組織間で安全に共有したり AWS アカウント、別のアカウントの IAM プリンシパルと直接共有したりして、データカタログのメタデータと基盤となるデータにきめ細かなアクセスを提供したりできます。

Lake Formation のクロスアカウントデータ共有を使用するときは、以下のベストプラクティスを検討してください。
+ 自分の AWS アカウントのプリンシパルに対して実行できる Lake Formation アクセス許可の付与の数に制限はありません。ただし、Lake Formation は、アカウントが名前付きリソースメソッドで実行できるクロスアカウント許可に AWS Resource Access Manager (AWS RAM) 容量を使用します。 AWS RAM 容量を最大化するには、名前付きリソースメソッドの以下のベストプラクティスに従います。
  +  新しいクロスアカウント付与モード (クロス**アカウントバージョン設定**の **バージョン 3** 以降) を使用して、リソースを外部と共有します AWS アカウント。詳細については、「[クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md)」を参照してください。
  +  AWS アカウントを組織に整理し、組織または組織単位にアクセス許可を付与します。組織または組織単位への付与は、1 つの付与として計上されます。

    組織または組織単位に を付与すると、グラントの AWS Resource Access Manager (AWS RAM) リソース共有の招待を受け入れる必要もなくなります。詳細については、「[共有 Data Catalog テーブルとデータベースへのアクセスと表示](viewing-shared-resources.md)」を参照してください。
  + データベース内にある多数のテーブルそれぞれに対する許可を付与する代わりに、特別な **[All tables]** (すべてのテーブル) ワイルドカードを使用して、データベース内のすべてのテーブルに対する許可を付与します。**[All tables]** (すべてのテーブル) に対する付与は、単一の付与として計上されます。詳細については、「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」を参照してください。
**注記**  
のリソース共有数の上限をリクエストする方法の詳細については AWS RAM、の[AWS 「サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください*AWS 全般のリファレンス*。
+  Amazon Athena および Amazon Redshift Spectrum クエリエディタに表示するには、共有データベースへのリソースリンクを作成する必要があります。同様に、Athena と Redshift Spectrum を使用して共有テーブルをクエリできるようにするには、そのテーブルへのリソースリンクを作成する必要があります。そうすることで、リソースリンクがクエリエディタのテーブルリストに表示されます。

  クエリのために多数のテーブルそれぞれに対するリソースリンクを作成する代わりに、**[All tables]** (すべてのテーブル) ワイルドカードを使用して、データベース内のすべてのテーブルに対する許可を付与することができます。そうすることで、そのデータベースのリソースリンクを作成し、クエリエディタでそのデータベースリソースリンクを選択するときに、クエリのために、そのデータベース内のすべてのテーブルにアクセスできるようになります。詳細については、「[リソースリンクの作成](creating-resource-links.md)」を参照してください。
+ 別のアカウントのプリンシパルとリソースを直接共有する場合、受信者アカウントの IAM プリンシパルには、Athena と Amazon Redshift Spectrum を使用して共有テーブルをクエリするためのリソースリンクを作成するアクセス許可がないことがあります。データレイク管理者は、共有されているテーブルごとにリソースリンクを作成する代わりに、プレースホルダーデータベースを作成して `ALLIAMPrincipal` グループに `CREATE_TABLE` アクセス許可を付与できます。その後、受信者アカウントのすべての IAM プリンシパルがプレースホルダーデータベースにリソースリンクを作成し、共有テーブルのクエリを開始できます。

   [名前付きリソース方式を使用したデータベースのアクセス許可の付与](granting-database-permissions.md) でアクセス許可を `ALLIAMPrincipals` に付与する方法については、CLI コマンドの例を参照してください。
+ クロスアカウントアクセス許可がプリンシパルに直接付与されると、付与の受信者のみがこれらのアクセス許可を表示できます。受信者の AWS アカウントのデータレイク管理者は、これらの直接許可を表示できません。
+ Athena と Redshift Spectrum は列レベルのアクセスコントロールをサポートしますが、これは包含のみで、除外にはサポート適用されません。AWS Glue ETLジョブでは、列レベルのアクセスコントロールはサポートされません。
+ リソースが AWS アカウントと共有されている場合、リソースに対するアクセス許可はアカウントのユーザーにのみ付与できます。リソースに対するアクセス許可を他の AWS アカウント、組織 (自分の組織でもない）、または `IAMAllowedPrincipals`グループに付与することはできません。
+ データベースに対する `DROP` または `Super` を外部アカウントに付与することはできません。
+ データベースまたはテーブルを削除する前に、クロスアカウント許可を取り消します。それ以外の場合は、 で孤立したリソース共有を削除する必要があります AWS Resource Access Manager。

**関連情報**  
[Lake Formation のタグベースのアクセスコントロールのベストプラクティスと考慮事項](lf-tag-considerations.md)
クロスアカウントアクセスに関する追加のルールと制限については、「[Lake Formation 許可のリファレンス](lf-permissions-reference.md)」の「[`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table)」を参照してください。

# サービスにリンクされたロールの制限


 サービスにリンクされたロールは、直接リンクされた特殊なタイプの IAM ロールです AWS Lake Formation。このロールには、Lake Formation が AWS サービス間でユーザーに代わってアクションを実行できるようにする事前定義されたアクセス許可があります。

サービスにリンクされたロール (SLR) を使用してデータロケーションを Lake Formation に登録する場合、次の制限が適用されます。
+ 一度作成したサービスにリンクされたロールポリシーは変更できません。
+ サービスにリンクされたロールは、アカウント間での暗号化されたカタログリソースの共有をサポートしていません。暗号化されたリソースには、特定の AWS KMS キーアクセス許可が必要です。サービスにリンクされたロールには、アカウント間で暗号化されたカタログリソースを操作する機能を含まない事前定義されたアクセス許可があります。
+ 複数の Amazon S3 ロケーションを登録する場合、サービスにリンクされたロールを使用すると、IAM ポリシーの制限をすばやく超える可能性があります。これは、サービスにリンクされたロールでは、 によってポリシーが AWS 記述され、すべての登録を含む 1 つの大きなブロックとして増分されるためです。カスタマー管理ポリシーをより効率的に記述したり、複数のポリシーに権限を分散したり、リージョンごとに異なるロールを使用したりできます。
+ Amazon EMR on EC2 は、サービスにリンクされたロールでデータロケーションを登録したデータにアクセスできません。
+ サービスにリンクされたロールオペレーションは、 AWS サービスコントロールポリシーをバイパスします。
+ データロケーションをサービスにリンクされたロールに登録すると、IAM ポリシーが結果整合性で更新されます。詳細については、[「IAM ユーザーガイド」の「IAM ドキュメントのトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html#troubleshoot_general_eventual-consistency)」を参照してください。
+  サービスにリンクされたロールを使用する場合、および IAM Identity Center を使用している場合、Lake Formation データレイク設定`SET_CONTEXT = TRUE`で を設定することはできません。その理由は、サービスにリンクされたロールには、IAM Identity Center プリンシパルによる`SetContext`監査に必要な信頼できる ID 伝達と互換性のないイミュータブルな信頼ポリシーがあるからです。

# クロスリージョンのデータアクセスに関する制限


 Lake Formation では、 AWS リージョンをまたいでデータカタログのテーブルにクエリを実行できます。ソースデータベースとテーブルを指す他のリージョンにリソースリンクを作成することで Amazon Athena、、、Amazon EMR、および AWS Glue ETL を使用して、他のリージョンからリージョンのデータにアクセスできます。クロスリージョンのテーブルアクセスでは、基になるデータやメタデータをデータカタログ内にコピーしなくても、複数のリージョンをまたいでデータにアクセスできます。

クロスリージョンのテーブルアクセスには以下の制限が適用されます。
+ Lake Formation では、Amazon Redshift Spectrum を使用して別のリージョンのデータカタログのテーブルにクエリを実行することはサポートしていません。
+ Lake Formationコンソールでは、データベースビューとテーブルビューにソースリージョンのデータベース名やテーブル名は表示されません。
+ 別のリージョンにある共有データベース内のテーブルを一覧表示するには、まず共有データベースへのリソースリンクを作成し、次にそのリソースリンクを選択して、**[テーブルを表示]** を選択する必要があります。
+ Lake Formation は、SAML ユーザーによるクロスリージョンのリソースリンク呼び出しをサポートしません。
+ Lake Formation のクロスリージョン機能には、データ転送に対する追加料金はかかりません。

# データカタログビューの考慮事項と制限


 データカタログビューに適用される考慮事項と制限事項は、以下のとおりです。
+ Lake Formation コンソールからデータカタログビューを作成することはできません。ビューは、 AWS CLI または SDK を使用して作成できます。
+ 10 個のテーブルからデータカタログビューを作成できます。これはハード制限です。ビューの基盤となるリファレンステーブルは、同じデータベースに属することも、同じ AWS アカウント内の異なるデータベースに属することもできます。
+ Redshift を使用したデータカタログビューの作成に固有のその他の考慮事項と制限については、Amazon Redshift データベースデベロッパーガイドの[「データカタログビューの考慮事項と制限](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html#data-catalog-views-considerations)」セクションを参照してください。Athena については、Amazon Athenaユーザーガイド」の[「データカタログビューの考慮事項と制限](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html#views-glue-limitations)」セクションを参照してください。
+ データカタログビューは、Lake Formation に登録されているテーブルに対して、ハイブリッドアクセスモードと Lake Formation モードのどちらでも作成できます。

  Lake Formation ハイブリッドアクセスモードでデータカタログビューを使用する場合は、ビューを消費するプリンシパルにアクセスを付与するのではなく、ビューで参照されるベーステーブルの Lake Formation アクセス許可にプリンシパルをオプトインすることをお勧めします。これにより、 AWS Glue IAM アクセス許可を通じてベーステーブルがコンシューマーに公開されることはありません。
+ ビューを共有するクロスアカウント共有バージョンに制限はありません。
+ 既に作成されているビューのダイアレクトに `ALTER VIEW` ステートメントを使用すると、データカタログテーブルと同様にビューがバージョニングされます。ビューバージョンは基盤データの変更に伴って変更されるため、以前のビューにロールバックすることはできません。ビューバージョンは削除でき、その場合はデフォルトで次に利用可能な最新バージョンになります。ビューバージョンを変更するときは、選択したビューバージョンのスキーマとデータが同期していることを確認してください。
+ 新しいデータカタログ API は導入されません。既存の `CreateTable`、`UpdateTable`、`DeleteTable`、`GetTable` API が更新されます。
+ Amazon Redshift は常に、文字列を含むテーブルから varchar 列を含むビューを作成します。他のエンジンからダイアレクトを追加する場合は、文字列の列を明示的な長さで varchar にキャストする必要があります。
+ データベース内の `All tables` にデータレイクのアクセス許可を付与すると、被付与者はデータベース内のすべてのテーブルとビューに対するアクセス許可を持つことになります。
+ 以下の場合、ビューを作成することはできません。
  + 他のビューを参照する場合。
  + 参照テーブルがリソースリンクの場合。
  + リファレンステーブルが別のアカウントで所有されている場合。
  + 外部の Hive メタストアからの場合。
+ クロスアカウント定義ロールは、Redshift Spectrum Dialect ビューではサポートされていません。
+ Athena クエリエディタの Athena ダイアレクトのリソースリンクはサポートされていません。Athena ダイアレクトにクロスアカウント定義ロールを使用するには、ベーステーブルを Athena のデータソースとしてホストするアカウントを追加します。

# データフィルタリングの制限事項


Data Catalog テーブルに対する Lake Formation 許可を付与するときは、クエリ結果、および Lake Formation と統合されたエンジン内の特定のデータへのアクセスを制限するためのデータフィルタリング仕様を含めることができます。Lake Formation は、列レベルのセキュリティ、行レベルのセキュリティ、およびセルレベルのセキュリティを実現するために、データフィルタリングを使用します。ソースデータにネストされた構造が含まれている場合は、ネストされた列にデータフィルターを定義して適用できます。

## 列レベルのフィルタリングに関する注意点と制限


列フィルタリングを指定する方法は 3 つあります。
+ データフィルターの使用。
+ シンプルな列フィルタリングまたはネストされた列フィルタリングの使用。
+ タグの使用。

シンプルな列フィルタリングは、包含または除外する列のリストを指定するだけです。Lake Formation コンソール、 API、 の両方が単純な列フィルタリング AWS CLI をサポートしています。例については、「[Grant with Simple Column Filtering](granting-table-permissions.md#simple-column-filter-example)」を参照してください。

以下の注意点と制限が列フィルタリングに適用されます。
+ AWS Glue 5.0 以降では、Apache Hive および Apache Iceberg テーブルに対してのみ、Lake Formation を介したきめ細かなアクセスコントロールがサポートされています。
+ grant オプションと列フィルタリングを伴う `SELECT` を付与するには、除外リストではなく、包含リストを使用する必要があります grant オプションを使用しない場合は、包含リストまたは除外リストのどちらでも使用することができます。
+ テーブルに対する `SELECT` を列フィルタリングと共に付与するには、テーブルに対する grant オプション付きの `SELECT` を、行制限なしで付与されている必要があります。すべての行にアクセスできる必要があります。
+ grant オプションと列フィルタリングを伴う `SELECT` をアカウント内のプリンシパルに付与する場合、そのプリンシパルは、別のプリンシパルへの付与時に、同じ列、または付与列のサブセットに対する列フィルタリングを指定する必要があります。grant オプションと列フィルタリングを伴う `SELECT` を外部アカウントに付与する場合、外部アカウントのデータレイク管理者は、そのアカウント内の別のプリンシパルに、すべての列に対する `SELECT` を付与することができます。ただし、すべての列に対する `SELECT` があるとしても、そのプリンシパルに表示されるのは外部アカウントに付与された列のみになります。
+ パーティションキーに列フィルタリングを適用することはできません。
+ テーブル内の列のサブセットに対する `SELECT` 許可を持つプリンシパルに、そのテーブルに対する `ALTER`、`DROP`、`DELETE` または `INSERT` 許可を付与することはできません。テーブルに対する `ALTER`、`DROP`、`DELETE` または `INSERT` 許可を持つプリンシパルについては、列フィルタリングを伴う `SELECT` 許可を付与しても、効果はありません。

以下の注意点と制限が、ネストされた列フィルタリングに適用されます。
+  データフィルターでは 5 レベルのネストされたフィールドを含めたり除外したりできます。  
**Example**  

  Col1.Col1\$11.Col1\$11\$11.Col1\$11\$11\$11.Col1\$11\$11\$11\$11
+  パーティション列内のネストされたフィールドに列フィルタリングを適用することはできません。
+  テーブルスキーマに、データフィルター内のネストされたフィールド表現と同じパターンを持つ最上位の列名 ("customer"."address") が含まれている場合 (最上位の列名 `customer` とネストされたフィールド名 `address` を持つネストされた列は、データフィルターで `"customer"."address"` として指定されます)、最上位の列とネストされたフィールドは両方とも包含/除外リストの同じパターンを使用するため、最上位の列またはネストされたフィールドへのアクセスを明示的に指定することはできません。これはあいまいであり、最上位の列を指定しているのか、ネストされたフィールドを指定しているのか、Lake Formation は解決できません。
+ 最上位の列またはネストされたフィールドの名前に 1 つの二重引用符が含まれている場合、データセルフィルターの包含リストと除外リスト内のネストされたフィールドへのアクセスを指定するときに、2 つ目の二重引用符を含める必要があります。  
**Example**  

  二重引用符を使用したネストされた列名の例 — `a.b.double"quote`  
**Example**  

  データフィルター内のネストされた列表現の例 — ` "a"."b"."double""quote"`

## セルレベルのフィルタリングの制限


行レベルおよびセルレベルのフィルタリングに関しては、以下の注意点と制限に留意してください。
+  セルレベルのセキュリティは、ネストされた列、ビュー、リソースリンクではサポートされません。
+ 最上位の列でサポートされているすべての式は、ネストされた列でもサポートされます。ただし、ネストされた行レベルの式を定義するときは、パーティション列の下のネストされたフィールドを参照**しない**でください。
+  Athena エンジンバージョン 3 または Amazon Redshift Spectrum を使用すると、すべてのリージョンでセルレベルのセキュリティを利用できます。他のサービスでは、セルレベルのセキュリティは、[サポートされるリージョン](supported-regions.md) に記載されているリージョンでのみ利用できます。
+  `SELECT INTO` ステートメントはサポートされません。
+ `array` および `map` データ型は、行フィルター式ではサポートされていません。`struct` データ型はサポートされています。
+ テーブルに定義できるデータフィルターの数に上限はありませんが、テーブルあたり 1 つのプリンシパルに対してデータフィルター 100 個という上限があります。
+ 行フィルター式があるデータフィルターを適用するには、すべてのテーブル列に対する grant オプション付きの `SELECT` を持っている必要があります。付与が外部アカウントに行われた場合、この制限は外部アカウントの管理者には適用されません。
+ プリンシパルがグループのメンバーであり、プリンシパルとグループの両方に行のサブセットに対する許可が付与されている場合、プリンシパルの有効な行の許可は、プリンシパルの許可とグループの許可を合わせたものになります。
+ 行レベルおよびセルレベルのフィルタリングでは、テーブルの以下の列名が制限されています。
  + ctid
  + oid
  + xmin
  + cmin
  + xmax
  + cmax
  + tableoid
  + insertxid
  + deletexid
  + importoid
  + redcatuniqueid
+ 述語を持つ他のフィルター式と同時に全行フィルター式をテーブルに適用する場合は、全行フィルター式が他のすべてのフィルター式に優先します。
+ 行のサブセットに対するアクセス許可が外部 AWS アカウントに付与され、外部アカウントのデータレイク管理者がそのアカウントのプリンシパルにそれらのアクセス許可を付与する場合、プリンシパルの有効なフィルター述語は、アカウントの述語とプリンシパルに直接付与された述語の共通部分です。

  例えば、アカウントに述語 `dept='hr'` を持つ行の許可があり、プリンシパルに `country='us'` の許可を別途付与された場合、プリシパルは `dept='hr'` と `country='us'` の行にのみアクセスすることができます。

セルレベルのフィルタリングの詳細については、「[Lake Formation でのデータフィルタリングとセルレベルのセキュリティ](data-filtering.md)」を参照してください。

行レベルのセキュリティポリシーで Amazon Redshift Spectrum を使用してテーブルをクエリする際の考慮事項と制限については、「Amazon Redshift データベースデベロッパーガイド」の「[RLS ポリシーを使用する際の考慮事項](https://docs.aws.amazon.com/redshift/latest/dg/t_rls_usage.html)」を参照してください。

# ハイブリッドアクセスモードには次の考慮事項と制限事項が適用されます。


ハイブリッドアクセスモードでは、 AWS Glue Data Catalog内のデータベースとテーブルの Lake Formation 許可を柔軟かつ選択的に有効にできます。
 ハイブリッドアクセスモードでは、他の既存のユーザーやワークロードのアクセス許可ポリシーを中断することなく、特定のユーザーのセットに Lake Formation 許可を設定できる増分パスが導入されました。

ハイブリッドアクセスモードには次の考慮事項と制限事項が適用されます。

**制限事項**
+ **Amazon S3 ロケーション登録の更新** – サービスにリンクされたロールを使用して Lake Formation に登録されているロケーションのパラメータを編集することはできません。
+ **LF タグを使用する場合のオプトインオプション** – LF タグを使用して Lake Formation 許可を付与できる場合は、LF タグがアタッチされているデータベースとテーブルを選択することで、プリンシパルに Lake Formation 許可を連続したステップで適用するようにオプトインできます。
+ **ハイブリッドアクセスモードでのアクセス** – Lake Formation のハイブリッドアクセスモードでのアクセスは、データレイク管理者または読み取り専用管理者のアクセス許可を持つユーザーに限定されます。
+ **プリンシパルのオプトイン** – 現在のところ、プリンシパルをリソースにオプトインできるのはデータレイク管理者ロールだけです。
+ **データベース内のすべてのテーブルをオプトイン** – クロスアカウント付与で、アクセス許可を付与してデータベース内のすべてのテーブルをオプトインする場合、アクセス許可が機能するためにはデータベースもオプトインする必要があります。

**考慮事項**
+ **Lake Formation に登録されている Amazon S3 ロケーションをハイブリッドアクセスモードに更新** – Lake Formation に既に登録されている Amazon S3 データロケーションをハイブリッドアクセスモードに変換することは可能ですが、お勧めしません。
+  **データロケーションがハイブリッドアクセスモードで登録されている場合の API の動作** 
  + CreateTable — ハイブリッドアクセスモードのフラグとオプトインステータスに関係なく、ロケーションは Lake Formation に登録済みであると見なされます。したがって、ユーザーがテーブルを作成するには、データロケーションへのアクセス許可が必要です。
  + CreatePartition/BatchCreatePartitions/UpdatePartitions (ハイブリッドに登録されたロケーションを指すようにパーティションのロケーションが更新されている場合) – ハイブリッドアクセスモードのフラグとオプトインステータスに関係なく、Amazon S3 ロケーションは Lake Formation に登録済みであると見なされます。したがって、ユーザーがデータベースを作成または更新するには、データロケーションへのアクセス許可が必要です。
  + CreateDatabase/UpdateDatabase (ハイブリッドアクセスモードで登録されたロケーションを指すようにデータベースのロケーションが更新されている場合) – ハイブリッドアクセスモードのフラグとオプトインステータスに関係なく、ロケーションは Lake Formation に登録済みであると見なされます。したがって、ユーザーがデータベースを作成または更新するには、データロケーションへのアクセス許可が必要です。
  + UpdateTable (ハイブリッドアクセスモードで登録されたロケーションを指すようにテーブルのロケーションが更新されている場合) – ハイブリッドアクセスモードのフラグやオプトインステータスに関係なく、ロケーションは Lake Formation に登録済みであると見なされます。したがって、ユーザーがテーブルを更新するには、データロケーションへのアクセス許可が必要です。テーブルロケーションが更新されていないか、Lake Formation に登録されていないロケーションを指している場合、ユーザーはデータロケーションへのアクセス許可を必要とすることなく、テーブルを更新できます。

# Amazon Redshift データウェアハウスデータを に取り込む際の制限 AWS Glue Data Catalog


 AWS Glue Data Catalogを使用して、Amazon Redshift データウェアハウス内の分析データをカタログ化し、アクセスを管理できます。以下の制限が適用されます。
+ フェデレーティッドカタログレベルではクロスアカウント共有はサポートされていません。ただし、フェデレーションカタログ内から AWS アカウント間で個々のデータベースとテーブルを共有できます。
+  フェデレーティッドカタログ内のデータベースまたはテーブルを 間で共有するには、**クロスアカウントバージョン設定**バージョン 4 AWS アカウント以降が必要です。
+  データカタログでは、最上位レベルのカタログの作成のみがサポートされます。
+  カタログの説明は Redshift マネージドストレージ (RMS) でのみ更新できます。
+ フェデレーティッドカタログおよびフェデレーティッドカタログ内のデータベースとテーブルに対するアクセス許可を `IAMAllowedPrincipals` グループに設定することはサポートされていません。
+ Athena、Amazon EMR Spark などのエンジンからのカタログに対するデータ定義言語 (DDL) オペレーション (カタログ設定の構成を含む) はサポートされていません。
+  Athena を使用した RMS テーブルでの DDL オペレーションの実行はサポートされていません。
+ マテリアライズドビューの作成は、Athena、Apache Spark、、 AWS Glue Data Catalogまたは Amazon Redshift コンシューマー経由であってもサポートされていません。
+  Athena は複数のカタログの利用はサポートしていません。一度に 1 つの特定のカタログにのみ接続できます。Athena は、複数のカタログ間で同時にアクセスまたはクエリを実行することはできません。
+ Athena および Amazon Redshift を介した Iceberg テーブルのタグ付けおよび分岐オペレーションはサポートされていません。
+ RMS テーブルでの Time Travel はサポートされていません。
+ データレイクテーブルを含むマルチレベルカタログはサポートされていません。データレイクテーブルで使用する Amazon S3 に保存されているすべてのデータは、デフォルトに存在する必要があり AWS Glue Data Catalog、複数レベルのカタログに整理することはできません。
+ Amazon Redshift では、登録された名前空間にデータ共有は追加されません。クラスターと名前空間は同義です。クラスターを に公開すると AWS Glue Data Catalog、新しいデータを追加できなくなります。
+ Amazon EMR on EC2 は、RMS テーブルと Amazon S3 テーブル間の結合をサポートしていません。EMR Serverless のみが、この機能をサポートしています。
+ 外部スキーマとテーブルはサポートされていません。
+ RMS テーブルには、 AWS Glue Iceberg REST Catalog の拡張エンドポイントからのみアクセスできます。
+ Hive テーブルは、 AWS Glue Iceberg REST Catalog に接続されたサードパーティーエンジンからはアクセスできません。
+ Spark を介した RMS テーブルの read\$1committed 分離レベルがサポートされます。
+ Redshift データベース名は、 では大文字と小文字が区別されず AWS Glue Data Catalog、128 文字に制限され、ダッシュ (-) とアンダースコア (\$1) を含む英数字を使用できます。
+ カタログ名は大文字と小文字が区別されず、50 文字に制限され、ダッシュ (-) とアンダースコア (\$1) を含む英数字を使用できます。
+ Amazon Redshift では、Lake Formation SQL 形式の GRANT コマンドと REVOKE コマンドを使用して AWS Glue Data Catalogに公開されたテーブルに対するアクセス許可を管理することはサポートされていません。
+ プロデューサー (ソース) Amazon Redshift クラスターにアタッチされている行レベルのセキュリティポリシーと動的データマスキングポリシーは適用されません。代わりに、Lake Formation で定義されたアクセス許可が共有データに適用されます。
+ テーブルリンクでのデータ定義言語 (DDL) およびデータ操作言語 (DML) オペレーションの実行はサポートされていません。
+ 予約キーワードが適切にエスケープされない場合、失敗またはエラーが発生します。
+ 複数カタログのシナリオでのデータの暗号化はサポートされていません。

# S3 Tables カタログ統合の制限事項


 Amazon S3 Tables は AWS Glue Data Catalog (データカタログ) と統合され、カタログを Lake Formation データの場所として登録します。この登録は、Lake Formation コンソールから、またはサービス API を使用して設定できます。

**注記**  
プリンシパルタグに基づいて IAM ユーザーと IAM ロールを制限する IAM または S3 Tables リソースベースのポリシーがある場合は、Lake Formation が S3 データ (LakeFormationDataAccessRole など) にアクセスするために使用するのと同じプリンシパルタグを IAM ロールにアタッチし、このロールに必要なアクセス許可を付与する必要があります。これは、タグベースのアクセスコントロールポリシーが S3 Tables 分析統合で正しく機能するために必要です。

 S3 Tables カタログと Data Catalog および Lake Formation の統合には、次の制限が適用されます。
+ AWS Glue と Lake Formation は、大文字と小文字が混在する列名をサポートしておらず、すべての列名を小文字に変換します。そのため、小文字に変換した場合にテーブル列名が一意になることを確認する必要があります。`customerId` ではなく `customer_id` を使用します。大文字と小文字が混在する列名の使用は、プレビューリリースでのみサポートされていました。
+ CreateCatalog API は Amazon S3 でテーブルバケットを作成できません。
+ SearchTables API は S3 テーブルを検索できません。

# Hive メタデータストアのデータ共有に関する考慮事項と制限事項


 AWS Glue Data Catalog メタデータフェデレーション (データカタログフェデレーション) を使用すると、データカタログを Amazon S3 データのメタデータを保存する外部メタストアに接続し、 を使用してデータアクセス許可を安全に管理できます AWS Lake Formation。

Hive データベースから作成されたフェデレーションデータベースには、以下の考慮事項と制限事項が適用されます。

**考慮事項**
+ **AWS SAM アプリケーションサポート** – が AWS SAM デプロイするアプリケーションリソース (Amazon API Gateway および Lambda 関数) の可用性は、お客様の責任となります。ユーザーがクエリを実行するときに、 AWS Glue Data Catalog と Hive メタストア間の接続が機能していることを確認します。
+ **Hive メタストアのバージョン要件** — Apache Hive バージョン 3 以降でのみフェデレーションデータベースを作成できます。
+ **マッピングされたデータベースの要件** – Hive の各データベースは、Lake Formation の新しいデータベースにマッピングする必要があります。
+ **データベースレベルのフェデレーションサポート** – Hive メタストアにはデータベースレベルでのみ接続できます。
+ **フェデレーションデータベースのアクセス許可** – フェデレーションデータベースまたはフェデレーションデータベース内のテーブルに適用されたアクセス許可は、ソーステーブルまたはデータベースが削除された場合でも保持されます。ソースデータベースまたはテーブルを再作成するとき、アクセス許可を再付与する必要はありません。Lake Formation のアクセス許可を持つフェデレーションテーブルをソースで削除しても、Lake Formation のアクセス許可は引き続き表示され、必要に応じて取り消すことができます。

  ユーザーがフェデレーションデータベースを削除すると、対応するアクセス許可はすべて失われます。同じデータベースを同じ名前で再作成しても、Lake Formation のアクセス許可は回復しません。ユーザーは新しいアクセス許可を再度設定する必要があります。
+ フェデレーションデータベースの **IAMAllowedPrincipal グループのアクセス許可** – `DataLakeSettings` に基づいて、Lake Formation はすべてのデータベースとテーブルに対するアクセス許可を `IAMAllowedPrincipal` という名前の仮想グループに設定する場合があります。は、IAM プリンシパルポリシーとリソースポリシーを通じて Data Catalog リソースにアクセスできるすべての IAM プリンシパル`IAMAllowedPrincipal`を指します AWS Glue 。これらのアクセス許可がデータベースまたはテーブルに存在する場合、すべてのプリンシパルにデータベースまたはテーブルへのアクセス許可が付与されます。

   ただし、Lake Formation では、フェデレーションデータベース内のテーブルに対する `IAMAllowedPrincipal` アクセス許可は許可されていません。フェデレーションデータベースを作成するときは、必ず `CreateTableDefaultPermissions` パラメータを空のリストとして渡してください。

  詳細については、「[データレイクのデフォルト設定の変更](change-settings.md)」を参照してください。
+ **クエリでのテーブルの結合** – Hive メタストアテーブルをデータカタログのネイティブテーブルと結合してクエリを実行できます。

**制限事項**
+  ** AWS Glue Data Catalog と Hive メタストア間のメタデータの同期の制限** – Hive メタストア接続を確立したら、フェデレーティッドデータベースを作成して Hive メタストアのメタデータを と同期する必要があります AWS Glue Data Catalog。フェデレーションデータベースのテーブルは、ランタイム時にユーザーがクエリを実行すると同期されます。
+  **フェデレーションデータベースでの新規テーブル作成の制限** – フェデレーションデータベースでは新しいテーブルを作成できません。
+ **データのアクセス許可の制限** – Hive メタストアテーブルビューのアクセス許可のサポートはありません。

# Amazon Redshift データ共有の制限事項


AWS Lake Formation を使用すると、Amazon Redshift からデータ共有内のデータを安全に管理できます。Amazon Redshift は、 AWS クラウド内のフルマネージド型のペタバイト規模のデータウェアハウスサービスです。Amazon Redshift では、データ共有機能を使用して、 AWS アカウント間でデータを共有できます。Amazon Redshift データ共有の詳細については、「[Amazon Redshift でのデータ共有の概要](https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html)」を参照してください。

 Amazon Redshift データ共有から作成されたフェデレーションデータベースには、以下の注意事項と制限事項が適用されます。
+ **マッピングされたデータベースの要件** – Amazon Redshift の各データ共有は、Lake Formation の新しいデータベースにマッピングする必要があります。これは、データ共有オブジェクト表現がデータカタログデータベースでフラット化されるときに、一意のテーブル名を維持するために必要です。
+ **フェデレーションデータベースでの新規テーブル作成の制限** – フェデレーションデータベースでは新しいテーブルを作成できません。
+ **フェデレーションデータベースのアクセス許可** – フェデレーションデータベースまたはフェデレーションデータベース内のテーブルに適用されたアクセス許可は、ソーステーブルまたはデータベースが削除された場合でも保持されます。ソースデータベースまたはテーブルを再作成するとき、アクセス許可を再付与する必要はありません。Lake Formation のアクセス許可を持つフェデレーションテーブルをソースで削除しても、Lake Formation のアクセス許可は引き続き表示され、必要に応じて取り消すことができます。

  ユーザーがフェデレーションデータベースを削除すると、対応するアクセス許可はすべて失われます。同じデータベースを同じ名前で再作成しても、Lake Formation のアクセス許可は回復しません。ユーザーは新しいアクセス許可を再度設定する必要があります。
+ フェデレーションデータベースの **IAMAllowedPrincipal グループのアクセス許可** – `DataLakeSettings` に基づいて、Lake Formation はすべてのデータベースとテーブルに対するアクセス許可を `IAMAllowedPrincipal` という名前の仮想グループに設定する場合があります。は、IAM プリンシパルポリシーとリソースポリシーを通じて Data Catalog リソースにアクセスできるすべての IAM プリンシパル`IAMAllowedPrincipal`を指します AWS Glue 。これらのアクセス許可がデータベースまたはテーブルに存在する場合、すべてのプリンシパルにデータベースまたはテーブルへのアクセス許可が付与されます。

  ただし、Lake Formation では、フェデレーションデータベース内のテーブルに対する `IAMAllowedPrincipal` アクセス許可は許可されていません。フェデレーションデータベースを作成するときは、必ず `CreateTableDefaultPermissions` パラメータを空のリストとして渡してください。

  詳細については、「[データレイクのデフォルト設定の変更](change-settings.md)」を参照してください。
+ **データフィルタリング** – Lake Formation では、列レベルと行レベルのフィルタリングを使用して、フェデレーションデータベース内のテーブルにアクセス許可を付与できます。ただし、列レベルのフィルタリングと行レベルのフィルタリングを組み合わせて、フェデレーションデータベース内のテーブルへのアクセスをセルレベルの精度で制限することはできません。
+ **大文字と小文字の区別識別子** – Lake Formation が管理する Amazon Redshift データ共有オブジェクトでは、テーブル名と列名は小文字でのみサポートされます。Amazon Redshift データ共有のデータベース、テーブル、列が Lake Formation を使用して共有および管理される場合は、大文字と小文字の区別識別子をオンにしないでください。
+ **クエリのサポート** - Lake Formation によって管理される Amazon Redshift データ共有は Amazon Redshift でクエリできます。Athena では、Lake Formation によって管理される Amazon Redshift データ共有のクエリはサポートされていません。

 Amazon Redshift でデータ共有を操作する際の制限事項の詳細については、「Amazon Redshift データベース開発者ガイド」の「[データ共有に関する制限事項](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html#limitations-datashare)」を参照してください。

# IAM アイデンティティセンター 統合の制限事項


を使用すると AWS IAM アイデンティティセンター、ID プロバイダー (IdPs) に接続し、 AWS 分析サービス全体でユーザーとグループのアクセスを一元管理できます。を IAM アイデンティティセンターで有効なアプリケーション AWS Lake Formation として設定でき、データレイク管理者は AWS Glue Data Catalog リソースの承認されたユーザーとグループにきめ細かなアクセス許可を付与できます。

IAM アイデンティティセンターとの Lake Formation の統合には、以下の制限が適用されます。
+ Lake Formation では、IAM アイデンティティセンターのユーザーとグループをデータレイク管理者または読み取り専用管理者として割り当てることはできません。

  IAM Identity Center のユーザーとグループは、Data Catalog の暗号化と復号のために がユーザーに代わって引き受け AWS Glue ることができる IAM ロールを使用している場合、暗号化された Data Catalog リソースをクエリできます。 AWS マネージドキーは、信頼できる ID の伝播をサポートしていません。
+ IAM ID センターのユーザーとグループは、IAM アイデンティティセンターによって提供された `AWSIAMIdentityCenterAllowListForIdentityContext` ポリシーにリストされている API オペレーションのみを呼び出すことができます。
+  Lake Formation は、データカタログリソースへのアクセスのために、外部アカウントの IAM ロールが IAM アイデンティティセンターのユーザーとグループに代わってキャリアロールとして動作することを許可しますが、アクセス許可を付与できるのは、所有アカウント内のデータカタログリソースに対してだけです。外部アカウント内のデータカタログリソースに対するアクセス許可を IAM アイデンティティセンターのユーザーとグループに付与しようとすると、Lake Formation から「Cross-account grants are not supported for the principal」というエラーがスローされます。
+ IAM アイデンティティセンターで Lake Formation を使用する場合、アプリケーション割り当て設定はデフォルトで `false` に設定されます。[IAM Identity Center API](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_PutApplicationAssignmentConfiguration.html) を使用してこの設定を直接変更する場合は、API を使用してすべてのアプリケーション割り当てを手動で管理する必要があります。Lake Formation は、標準ワークフロー外で行われた割り当ての変更を自動的に同期または管理しないため、データレイク環境内のアクセスパターンと認可フローに影響を与える可能性があります。

# Lake Formation のタグベースのアクセスコントロールのベストプラクティスと考慮事項


データカタログデータベース、テーブル、および列へのアクセスを制御するための LF タグは、作成、維持、および割り当てを行うことができます。

Lake Formation のタグベースのアクセスコントロールを使用するときは、以下のベストプラクティスを検討してください。
+ すべての LF タグは、データカタログリソースに割り当てられたり、プリンシパルに付与される前に、あらかじめ定義しておく必要があります。

  データレイク管理者は、必要な IAM アクセス許可で *LF タグ作成者*を作成することによって、タグ管理タスクを委任できます。データエンジニアとアナリストは、LF タグの特性と関係を決定します。その後、LF タグ作成者は、Lake Formation で LF タグを作成して管理します。
+ 複数の LF タグをデータカタログリソースに割り当てることができます。特定のキーに対する 1 つの値だけを、特定のリソースに割り当てることができます。

  例えば、データベース、テーブル、および列には、`module=Orders`、`region=West`、および `division=Consumer` などを割り当てることができます。`module=Orders,Customers` を割り当てることはできません。
+ リソースの作成時に LF タグをリソースに割り当てることはできません。LF タグを追加できるのは、既存のリソースのみです。
+ 単一の LF タグだけではなく、LF タグ式をプリンシパルに付与できます。

  LF タグ式は、以下のようになります (擬似コードを使用)。

  ```
  module=sales AND division=(consumer OR commercial)
  ```

  この LF タグ式を付与されたプリンシパルは、`module=sales` *と*、`division=consumer` または `division=commercial` のいずれかが割り当てられたデータカタログリソース (データベース、テーブル、および列) にのみアクセスできます。`module=sales` *または* `division=commercial` を持つリソースにプリンシパルがアクセスできるようにする場合は、同じ付与に両方を含めないでください。`module=sales` と `division=commercial` それぞれに 1 回ずつ、合計で 2 回付与を行います。

  最もシンプルな LF タグ式は、`module=sales` など、1 つの LF タグだけで構成されます。
+ 複数の値を持つ LF タグに対する許可を付与されたプリンシパルは、それらの値のいずれかを持つデータカタログリソースにアクセスできます。例えば、キーが `module` で値が `orders,customers` の LF タグがユーザーに付与される場合、そのユーザーは、`module=orders` または `module=customers` が割り当てられたリソースにアクセスできます。
+ LF-TBAC 方法を使用してデータカタログリソースに対するデータアクセス許可を付与するには、`Grant with LF-Tag expressions` アクセス許可が必要です。データレイク管理者と LF タグ作成者は、このアクセス許可を暗黙的に受け取ります。`Grant with LFTag expressions` アクセス許可を持つプリンシパルは、次の方法でリソースに対するデータアクセス許可を付与できます。
  + 名前付きリソースメソッド
  + LF-TBAC 方法。ただし、同じ LF タグ式のみを使用して。

    例えば、データレイク管理者が以下の付与を行うとします (擬似コードを使用)。

    ```
    GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION
    ```

    この場合、`user1` は LF-TBAC 方法を使用して、ただし完全な LF タグ式 `module=customers, region=west,south` を使用して、テーブルに対する `SELECT` を他のプリンシパルに付与できます。
+ LF-TBAC 方式と名前付きリソース方式の両方を使用してリソースに対する許可がプリンシパルに付与される場合、そのプリンシパルがリソースに対して持っている許可は、両方の方式によって付与された許可を結合したものになります。
+ Lake Formation は、LF-TBAC 方法を使用した複数のアカウントでの LF タグに対する `DESCRIBE` および `ASSOCIATE` の付与と、複数のアカウントでのデータカタログに対するアクセス許可の付与をサポートしています。どちらの場合も、プリンシパルは AWS アカウント ID です。
**注記**  
Lake Formation は、LF-TBAC 方式を使用した組織および組織単位へのクロスアカウント付与はサポートします。この機能を使用するには、**[Cross account version settings]** (クロスアカウントのバージョン設定) を **[Version 3]** (バージョン 3) に更新する必要があります。

  詳細については、「[Lake Formation でのクロスアカウントデータ共有](cross-account-permissions.md)」を参照してください。
+ 1 つのアカウントで作成されたデータカタログリソースは、同じアカウントで作成された LF タグを使用してのみタグ付けできます。あるアカウントで作成された LF タグを別のアカウントの共有リソースに関連付けることはできません。
+ Lake Formation タグベースのアクセスコントロール (LF-TBAC) を使用して Data Catalog リソースへのクロスアカウントアクセスを許可するには、 AWS アカウントの Data Catalog リソースポリシーに追加する必要があります。詳細については、「[前提条件](cross-account-prereqs.md)」を参照してください。
+ LF タグのキーと LF タグの値の長さは 50 文字以下にする必要があります。
+ データカタログリソースに割り当てることができる LF タグの最大数は 50 個です。
+ 次の制限はソフト制限です。
  + 作成できる LF タグの最大数は 1,000 個です。
  + LF タグに定義できる値の最大数は 1,000 個です。
+ タグのキーと値はすべて、保存されるときに小文字に変換されます。
+ LF タグの 1 つの値だけを、特定のリソースに割り当てることができます。
+ 単一の付与で複数の LF タグがプリンシパルに付与される場合、このプリンシパルはすべての LF タグを持つデータカタログリソースのみにアクセスできます。
+ LF タグ式の評価結果はテーブル列のサブセットのみへのアクセスであったが、一致があるときに付与される Lake Formation アクセス許可が、列全体へのアクセスを必要とするアクセス許可 (つまり、`Alter`、`Drop`、`Insert` または `Delete`) の 1 つである場合、これらのアクセス許可のいずれも付与されません。その代わり、`Describe` のみが付与されます。付与された許可が `All` (`Super`) である場合は、`Select` と `Describe` のみが付与されます。
+ ワイルドカードは LF タグには使用できません。LF タグをテーブルのすべての列に割り当てるには、テーブルに LF タグを割り当てます。これにより、テーブルのすべての列が LF タグを継承します。LF タグをデータベースのすべてのテーブルに割り当てるには、データベースに LF タグを割り当てます。これにより、データベース内のすべてのテーブルがその LF タグを継承します。
+  アカウントに最大 1000 個の LF タグ式を作成できます。
+  最大 50 個の LF タグ式を使用して、データカタログリソースのプリンシパルにアクセス許可を付与できます。
+  インライン LF タグ式に対するアクセス許可を付与または取り消す場合、LF タグ式のサイズは 900 バイトを超えることはできません。さらに大きな LF タグ式に対するアクセス許可を付与するには、保存された LF タグ式を使用します。詳細については、「[LF タグ式の作成](TBAC-creating-tag-expressions.md)」を参照してください。
+ フェデレーティッドカタログの LF タグサポートの一般提供リリース前に作成された既存の Redshift フェデレーティッドカタログに LF タグを追加するには、 AWS サポートチームに連絡してサポートを依頼する必要があります。

# 属性ベースのアクセス制御に関する考慮事項、制限、サポートされているリージョン


属性ベースのアクセス制御 (ABAC) には、以下の考慮事項と制限が適用されます。
+ ABAC は、LF タグポリシーを使用したアクセス許可の付与をサポートしていません。
+ 付与可能なアクセス許可は ABAC では使用できません。
+ ABAC は、IAM アイデンティティセンターユーザーへのアクセス許可の付与をサポートしていません。
+ Lake Formation のテーブルで ABAC 許可を使用する場合、Lake Formation は親データベースまたはカタログに `DESCRIBE` アクセス許可を付与しません。これは、Lake Formation が親リソースに暗黙的な `DESCRIBE` アクセス許可を提供する非 ABAC シナリオとは異なります。
+ `AmazonDataZoneProject` タグキーを持つすべてのプリンシパルは、常にすべてのデータカタログリソースに対して Lake Formation にオプトインされたものとして扱われます。
+ ABAC は文字列属性のみをサポートします。