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

# クロスアカウントデータ共有のベストプラクティスと考慮事項
<a name="cross-account-notes"></a>

 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)」を参照してください。