翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Lake Formation 許可へのオンボーディング AWS Lake Formation は AWS Glue Data Catalog (データカタログ) を使用して、Amazon S3 データレイクのメタデータと、Amazon Redshift などの外部データソースをカタログ、データベース、テーブルの形式で保存します。データカタログ内のメタデータは、カタログ、データベース、テーブルで構成される 3 レベルのデータ階層に分類されます。さまざまなソースからのデータをカタログと呼ばれる論理コンテナにまとめます。データベースはテーブルのコレクションです。Data Catalog には、リソースリンクも含まれています。これは、外部アカウントの共有データベースとテーブルへのリンクで、データレイク内のデータへのクロスアカウントアクセスに使用されます。各 AWS アカウントには、 AWS リージョンごとに 1 つのデータカタログがあります。 Lake Formation には、Amazon S3 内の基盤となるデータを含むデータカタログのカタログ、データベース、テーブル、列へのアクセスを許可または取り消すためのリレーショナルデータベース管理システム (RDBMS) のアクセス許可モデルが用意されています。 Lake Formation 許可モデルの詳細について学ぶ前に、以下の背景情報を確認しておくことが役に立ちます。 + Lake Formation によって管理されるデータレイクは、Amazon Simple Storage Service (Amazon S3) 内の指定されたロケーションに置かれます。データカタログにはカタログオブジェクトも含まれています。各カタログは、Amazon Redshift データウェアハウス、 Amazon DynamoDB データベース、および Snowflake、MySQL の他 30 を超える外部データソースを含むサードパーティーデータソースソースなどのソースからのデータを表し、これらはフェデレーティッドコネクタを介して統合されています。 + Lake Formation は、データレイクにインポートされるログやリレーショナルデータベース内のデータなどのソースデータ、および Amazon S3 内のデータレイクにあるデータに関するメタデータが含まれた Data Catalog を維持します。データカタログには、Amazon S3 以外の外部データソースからのデータに関するメタデータも含まれています。メタデータは、カタログ、データベース、テーブルとして編成されます。メタデータテーブルには、スキーマ、ロケーション、パーティショニング、およびそれらが表すデータに関するその他の情報が含まれています。メタデータデータベースは、テーブルのコレクションです。 + Lake Formation Data Catalog は、AWS Glue が使用する Data Catalog と同じです。AWS Glue クローラを使用して Data Catalog テーブルを作成し、AWS Glue 抽出、変換、ロード (ETL) ジョブを使用してデータレイク内の基盤となるデータを投入することができます。 + データカタログ内のカタログ、データベース、テーブルは、*データカタログリソース*と呼ばれます。データカタログ内のテーブルは、Amazon S3 のデータソースまたは表形式データ内のテーブルと区別するために、*メタデータテーブル*と呼ばれます。メタデータテーブルがポイントする Amazon S3 またはデータソース内のデータは、*基盤となるデータ*と呼ばれます。 + *プリンシパル*は、ユーザーまたはロール、Amazon Quick ユーザーまたはグループ、SAML プロバイダーを介して Lake Formation で認証するユーザーまたはグループ、またはクロスアカウントアクセスコントロール、 AWS アカウント ID、組織 ID、または組織単位 ID です。 + AWS Glue クローラはメタデータテーブルを作成しますが、Lake Formation コンソール、API、または AWS Command Line Interface () を使用してメタデータテーブルを手動で作成することもできますAWS CLI。メタデータテーブルを作成するときは、ロケーションを指定する必要があります。データベースを作成するときは、ロケーションはオプションです。テーブルロケーションは、Amazon S3 ロケーション、または Amazon Relational Database Service (Amazon RDS) データベースなどのデータソースロケーションにすることができます。データベースロケーションは、常に Amazon S3 ロケーションです。 + Amazon Athena および Amazon Redshift などの Lake Formation と統合するサービスは、メタデータの取得、またはクエリを実行するための認可の確認を実行するために Data Catalog にアクセスできます。統合されたサービスの完全なリストについては、「[AWS Lake Formation との サービス統合](service-integrations.md)」を参照してください。 **Topics** + [Lake Formation 許可の概要](lf-permissions-overview.md) + [Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md) + [データレイクのデフォルト設定の変更](change-settings.md) + [黙示的な Lake Formation 許可](implicit-permissions.md) + [Lake Formation 許可のリファレンス](lf-permissions-reference.md) + [IAM アイデンティティセンターの統合](identity-center-integration.md) + [データレイクへの Amazon S3 ロケーションの追加](register-data-lake.md) + [ハイブリッドアクセスモード](hybrid-access-mode.md) + [でのオブジェクトの作成 AWS Glue Data Catalog](populating-catalog.md) + [Lake Formation でのワークフローを使用したデータのインポート](workflows.md) # Lake Formation 許可の概要 AWS Lake Formationには、2 つの主な許可タイプがあります。 + メタデータアクセス – データカタログリソースに対する許可 (*データカタログ許可*)。 これらの許可は、プリンシパルが Data Catalog 内のメタデータデータベースとテーブルの作成、読み取り、更新、および削除を実行できるようにします。 + 基盤となるデータアクセス – Amazon Simple Storage Service (Amazon S3) 内のロケーションに対するアクセス許可 (*データアクセス許可*と*データロケーション許可*)。 + データレイクのアクセス許可により、プリンシパルが*基盤*となる Amazon S3 ロケーション (データカタログリソースがポイントするデータ) に対するデータの読み取りと書き込みが実行できるようになります。 + データロケーション許可は、プリンシパルが特定の Amazon S3 ロケーションをポイントするメタデータデータベースとテーブルの作成と変更を実行できるようにします。 どちらの領域でも、Lake Formation は Lake Formation アクセス許可と AWS Identity and Access Management (IAM) アクセス許可の組み合わせを使用します。IAM 許可モデルは、IAM ポリシーで構成されます。Lake Formation 許可モデルは、`Grant SELECT on tableName to userName` のような、DBMS 形式の GRANT/REVOKE コマンドとして実装されます。 プリンシパルが Data Catalog リソース、または基盤となるデータへのアクセスをリクエストするときにリクエストが成功するには、そのリクエストが IAM と Lake Formation の両方による許可チェックに合格する必要があります。 ![\[リクエスト元からのリクエストは、リソースに到達するために Lake Formation 許可と IAM 許可の 2 つの「ドア」を通過する必要があります。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/permissions_doors.png) Lake Formation 許可は Data Catalog リソース、Amazon S3 ロケーション、およびこれらのロケーションにある基盤となるデータへのアクセスを制御します。IAM 許可は、Lake Formation、および AWS Glue の API とリソースへのアクセスを制御します。このため、Data Catalog にメタデータテーブルを作成するための Lake Formation 許可 (`CREATE_TABLE`) を持っていても、`glue:CreateTable` API に対する IAM の許可を持っていなければ、操作が失敗します。(`glue:` 許可である理由は、Lake Formation が AWS Glue Data Catalog を使用するからです。) **注記** Lake Formation 許可は、それらが付与されたリージョンのみで適用されます。 AWS Lake Formation では、各プリンシパル (ユーザーまたはロール) に Lake Formation が管理するリソースでアクションを実行する権限が必要です。プリンシパルは、データレイク管理者、または Lake Formation 許可を付与する許可を持つ別のプリンシパルから必要な認可を付与されます。 Lake Formation 許可をプリンシパルに付与するときは、その許可を別のプリンシパルに渡す能力をオプションで付与できます。 Lake Formation API、 AWS Command Line Interface (AWS CLI)、または Lake Formation コンソール**のデータアクセス許可**と**データロケーション**ページを使用して、Lake Formation アクセス許可を付与および取り消すことができます。 # 細粒度のアクセスコントロールのための方式 データレイクでは、データに対する細粒度のアクセスコントロールを持つことが目標になります。これは、Lake Formation では Data Catalog リソースと Amazon S3 ロケーションに対する細粒度のアクセスコントロールを意味します。細粒度のアクセスコントロールは、以下の方式のいずれかを使用して達成することができます。 | 方式 | Lake Formation 許可 | IAM 許可 | コメント | | --- | --- | --- | --- | | 方式 1 | オープン | 細粒度 | AWS Glue との後方互換性のための**デフォルト方式**です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/access-control-fine-grained.html) Lake Formation コンソールでは、この方式が **[Use only IAM access control]** (IAM アクセスコントロールのみを使用する) として表示されます。 | | 方式 2 | 細粒度 | 粗粒度 | **これは、推奨される方法です。** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/access-control-fine-grained.html) | **重要** 以下の点に注意してください。 Lake Formation では、既存の AWS Glue Data Catalog 動作との互換性のために、**[Use only IAM access control]** (IAM アクセスコントロールのみを使用する) がデフォルトで有効になっています。これらの設定は、Lake Formation 許可の使用への移行後に無効化することをお勧めします。詳細については、「[データレイクのデフォルト設定の変更](change-settings.md)」を参照してください。 データレイク管理者とデータベース作成者には、理解しておく必要がある黙示的な Lake Formation 許可があります。詳細については、「[黙示的な Lake Formation 許可](implicit-permissions.md)」を参照してください。 # メタデータのアクセスコントロール Data Catalog リソースのアクセスコントロールに関する以下の説明は、Lake Formation 許可を使用した細粒度のアクセスコントロールと、IAM ポリシーを使用した粗粒度のアクセスコントロールを前提としています。 Data Catalog リソースに対する Lake Formation 許可を付与するには、以下の 2 つの異なる方式があります。 + **名前付きリソースでのアクセスコントロール** – この方式では、データベース名またはテーブル名を指定することで、特定のデータベースまたはテーブルに対する許可を付与します。付与はこのような形式になります。 Grant *(アクセス許可)* to *(プリンシパル)* on *(リソース)* [with grant option] grant オプションは、付与対象者が他のプリンシパルに許可を付与することを可能にします。 + **タグベースのアクセスコントロール** – この方式では、Data Catalog のデータベース、テーブル、および列に 1 つまたは複数の LF タグを割り当てて、1 つまたは複数の LF タグに対するアクセス許可をプリンシパルに付与します。各 LF タグは、`department=sales` のようなキーと値のペアです。Data Catalog リソースの LF タグと一致する LF タグを持つプリンシパルが、そのリソースにアクセスできます。この方式は、多数のデータベースとテーブルを持つデータレイクに推奨されます。これは、「[Lake Formation のタグベースのアクセス制御](tag-based-access-control.md)」で詳しく説明されています。 プリンシパルがリソースに対して持っている許可は、両方の方式によって付与された許可を結合したものです。 以下の表は、Data Catalog リソースに対して利用できる Lake Formation 許可の要約です。列の見出しは、許可が付与されるリソースを示しています。 | カタログ | データベース | テーブル | | --- | --- | --- | | CREATE\$1DATABASE | CREATE\$1TABLE | ALTER | | | ALTER | DROP | | | DROP | DESCRIBE | | | DESCRIBE | SELECT\$1 | | | | INSERT\$1 | | | | DELETE\$1 | 例えば、データベースに対する `CREATE_TABLE` 許可が付与されるとします。これは、プリンシパルがそのデータベース内にテーブルを作成できることを意味します。 アスタリスク (\$1) が付いた許可は Data Catalog リソースについて付与されますが、基盤となるデータに適用されます。例えば、メタデータテーブルに対する `DROP` 許可は、Data Catalog からテーブルをドロップできるようにします。一方で、同じテーブルについて付与された `DELETE` 許可は、Amazon S3 内にあるテーブルの基盤となるデータを、SQL `DELETE` 文などを使用して削除できるようにします。これらの許可があれば、Lake Formation コンソールでテーブルを表示したり、AWS Glue API を使用してテーブルに関する情報を取得したりすることもできます。したがって、`SELECT`、`INSERT`、および `DELETE` は、Data Catalog 許可とデータアクセス許可の両方になります。 テーブルに対する `SELECT` を付与するときは、1 つ、または複数の列を包含する、または除外するフィルターを追加できます。これは、メタデータテーブル列に対する細粒度のアクセスコントロールを可能にして、統合されたサービスのユーザーがクエリを実行するときに表示される列を制限します。この機能は、IAM ポリシーのみを使用して利用することはできません。 `Super` という名前の特別な許可もあります。この `Super` 許可は、プリンシパルが、許可の対象であるデータベースまたはテーブルで、サポートされているすべての Lake Formation 操作を実行できるようにします。この許可は、他の Lake Formation 許可と共存できます。例えば、メタデータテーブルに対する `Super`、`SELECT`、および `INSERT` を付与することができます。プリンシパルは、サポートされているすべてのアクションをテーブルで実行でき、`Super` 許可を取り消しても、`SELECT` と `INSERT` 許可は残ります。 各許可の詳細については、「[Lake Formation 許可のリファレンス](lf-permissions-reference.md)」を参照してください。 **重要** 別のユーザーが作成した Data Catalog テーブルを表示するには、そのテーブルに対する Lake Formation 許可が、少なくとも 1 つ付与されている必要があります。テーブルに対する許可が少なくとも 1 つ付与されている場合は、テーブルが含まれているデータベースも表示することができます。 Data Catalog 許可は、Lake Formation コンソール、API、または AWS Command Line Interface (AWS CLI) を使用して付与または取り消すことができます。以下は、`retail`データベースにテーブルを作成するアクセス`datalake_user1`許可をユーザーに付与する AWS CLI コマンドの例です。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}' ``` 以下は、Lake Formation 許可による細粒度のアクセスコントロールを補完する粗粒度のアクセスコントロール IAM ポリシーの例です。これは、任意のメタデータデータベースまたはテーブルに対するすべての操作を許可します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:*Database*", "glue:*Table*", "glue:*Partition*" ], "Resource": "*" } ] } ``` ------ 次の例も粗粒度ですが、制限が多少厳しくなります。これは、指定されたアカウントとリージョン内の Data Catalog にある、すべてのメタデータデータベースおよびテーブルに対する読み取り専用操作を許可します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": "arn:aws:glue:us-east-1:111122223333:*" } ] } ``` ------ これらのポリシーを、IAM ベースの細粒度のアクセスコントロールを実装する以下のポリシーと比較してください。これは、指定されたアカウントとリージョン内の顧客関係管理 (CRM) メタデータデータベースにあるテーブルのサブセットのみに対する許可を付与します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:catalog", "arn:aws:glue:us-east-1:111122223333:database/CRM", "arn:aws:glue:us-east-1:111122223333:table/CRM/P*" ] } ] } ``` ------ 粗粒度のアクセスコントロールポリシーの追加例については、「[Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md)」を参照してください。 # 基盤となるデータのアクセスコントロール 統合された AWS サービスが、アクセスが制御されている Amazon S3 ロケーションのデータへのアクセスをリクエストすると AWS Lake Formation、Lake Formation はデータにアクセスするための一時的な認証情報を提供します。 Amazon S3 の場所にある基盤となるデータへのアクセスを Lake Formation が制御できるようにするには、Lake Formation にその場所を*登録*します。 Amazon S3 ロケーションを登録したら、以下の Lake Formation 許可の付与を開始できます。 + そのロケーションをポイントする Data Catalog テーブルに対するデータアクセス許可 (`SELECT`、`INSERT`、および `DELETE)`)。 + そのロケーションに対するデータロケーション許可。 Lake Formation のデータロケーション許可は、特定の Amazon S3 ロケーションをポイントする Data Catalog リソースを作成する機能を制御します。データロケーション許可は、データレイク内のロケーションのセキュリティをさらに強化します。プリンシパルに `CREATE_TABLE` または `ALTER` 許可を付与するときは、プリンシパルがメタデータテーブルの作成または変更を実行できるロケーションを制限するためのデータロケーション許可も付与します。 Amazon S3 ロケーションは、バケット、またはバケット下のプレフィックスで、個々の Amazon S3 オブジェクトではありません。 データロケーション許可は、Lake Formation コンソール、API、または AWS CLIを使用してプリンシパルに付与することができます。付与の一般的な形式は以下のとおりです。 ``` grant DATA_LOCATION_ACCESS to principal on S3 location [with grant option] ``` `with grant option` を含めると、付与対象者は他のプリンシパルに許可を付与することができます。 Lake Formation のアクセス許可は常に、きめ細かなアクセスコントロールのための AWS Identity and Access Management (IAM) アクセス許可と組み合わせて機能することを覚えておいてください。基盤となる Amazon S3 データに対する読み取り/書き込み許可では、IAM 許可が以下のように付与されます。 ロケーションを登録するときは、そのロケーションに対する読み取り/書き込み許可を付与する IAM ロールを指定します。Lake Formation は、統合 AWS サービスに一時的な認証情報を提供するときに、そのロールを引き受けます。典型的なロールには、以下のようなポリシーがアタッチされている場合があります。このポリシーの登録済みロケーションはバケット `awsexamplebucket` です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] } ] } ``` ------ Lake Formation は、このようなポリシーを自動的に作成するために登録時に使用できる、サービスリンクロールを提供します。詳細については、「[Lake Formation のサービスリンクロールの使用](service-linked-roles.md)」を参照してください。 このため、Amazon S3 ロケーションの登録によって、そのロケーションに対する必要な IAM `s3:` 許可が付与され、この許可は、ロケーションの登録に使用されたロールによって指定されます。 **重要** **[Requester pays]** (リクエスタ支払い) が有効になっている Amazon S3 バケットの登録は避けてください。Lake Formation に登録されたバケットの場合、バケットの登録に使用されるロールは常にリクエスト元であると見なされます。バケットが別の AWS アカウントからアクセスされた場合、ロールがバケット所有者と同じアカウントに属している場合、バケット所有者はデータアクセスに対して課金されます。 基盤となるデータへの読み取り/書き込みアクセスの場合、プリンシパルには、Lake Formation アクセス許可に加えて以下の `lakeformation:GetDataAccess` IAM アクセス許可も必要になります。この許可があると、Lake Formation がデータにアクセスするための一時的な認証情報のリクエストを承諾します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": "*" } ] } ``` ------ 上記のポリシーでは、リソースパラメータを「\$1」(すべて) に設定する必要があります。このアクセス許可に他のリソースを指定することはサポートされていません。この設定により、Lake Formation はデータレイク環境全体のデータアクセスを効率的に管理できます。 **注記** Amazon Athena では、ユーザーに `lakeformation:GetDataAccess` アクセス許可が必要です。他の統合サービスでは、基盤となる実行ロールに `lakeformation:GetDataAccess` アクセス許可が必要です。 この許可は、「[Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md)」で提案されているポリシーに含まれています。 要約すると、Lake Formation プリンシパルが Lake Formation 許可でアクセス制御されている基盤となるデータに対する読み取りと書き込みを実行できるようにするには、以下が必要になります。 + データが含まれる Amazon S3 ロケーションを Lake Formation に登録します。 + 基盤となるデータのロケーションをポイントする Data Catalog テーブルを作成するプリンシパルにデータロケーション許可があること。 + 基盤となるデータに対する読み取りと書き込みを実行するプリンシパルに、基盤となるデータのロケーションをポイントする Data Catalog テーブルに対する Lake Formation データアクセス許可があること。 + 基礎となるデータロケーションが Lake Formation に登録されているとき、基礎となるデータを読み書きするプリンシパルには `lakeformation:GetDataAccess` IAM アクセス許可が必要です。 **注記** ユーザーが IAM または Amazon S3 ポリシーを通して Amazon S3 ロケーションへのアクセス権を得ている場合、Lake Formation 許可モデルは、Amazon S3 API またはコンソール経由でのそれらのロケーションへのアクセスを阻止しません。IAM ポリシーをプリンシパルにアタッチして、このアクセスをブロックすることができます。 **データロケーションアクセス許可の詳細** データロケーション許可は、Data Catalog データベースとテーブルに対する作成および更新操作の結果を制御します。ルールは以下のとおりです。 + プリンシパルが Amazon S3 ロケーションを指定するデータベースまたはテーブルを作成または更新するには、そのロケーションに対する明示的または黙示的なデータロケーション許可を持っている必要があります。 + 明示的なアクセス許可`DATA_LOCATION_ACCESS`は、 コンソール、API、または を使用して付与されます AWS CLI。 + 黙示的な許可は、登録されたロケーションをポイントするロケーションプロパティがデータベースにあり、プリンシパルがそのデータベースに対する `CREATE_TABLE` 許可を持っていて、プリンシパルがそのロケーションまたは子ロケーションでテーブルを作成しようとするときに付与されます。 + そのロケーションに対するデータロケーション許可がプリンシパルに付与されている場合、プリンシパルはすべての子ロケーションに対するデータロケーション許可を持っています。 + プリンシパルに、基盤となるデータに対する読み取り/書き込み操作を実行するためのデータロケーション許可は必要ありません。`SELECT` または `INSERT` データアクセス許可があれば十分です。データロケーション許可は、そのロケーションをポイントする Data Catalog リソースの作成のみに適用されます。 以下の図にあるシナリオを考えてみましょう。 ![\[フォルダ階層と、データベース A と B の 2 つのデータベースがあり、データベース B が Customer service (カスタマーサービス) フォルダをポイントしています。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/location-permissions-example.png) この図では、以下のようになっています。 + Amazon S3 バケット `Products`、`Finance`、および `Customer Service` が Lake Formation に登録されている。 + `Database A` にはロケーションプロパティがなく、`Database B` には `Customer Service` バケットをポイントするロケーションプロパティがある。 + ユーザー `datalake_user` が両方のデータベースに対する `CREATE_TABLE` を持っている。 + ユーザー `datalake_user` には、`Products` バケットのみに対するデータロケーション許可が付与されている。 以下は、ユーザー `datalake_user` が特定のロケーションで特定のデータベース内にカタログテーブルを作成しようとする場合の結果です。 **`datalake_user` がテーブルを作成しようとするロケーション** | データベースとロケーション | 成功または失敗 | 理由 | | --- | --- | --- | | Finance/Sales でのデータベース A | 失敗 | データロケーション許可がない | | Products でのデータベース A | 成功 | データロケーション許可がある | | HR/Plans でのデータベース A | 成功 | ロケーションが登録されていない | | Customer Service/Incidents でのデータベース B | 成功 | データベースに Customer Service のロケーションプロパティがある | 詳細については、次を参照してください。 + [データレイクへの Amazon S3 ロケーションの追加](register-data-lake.md) + [Lake Formation 許可のリファレンス](lf-permissions-reference.md) + [Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md) # Lake Formation のペルソナと IAM 許可のリファレンス このセクションでは、Lake Formation の推奨されるペルソナと、これらのペルソナに推奨される  AWS Identity and Access Management  (IAM) 許可を一覧表示します。Lake Formation 許可については、「[Lake Formation 許可のリファレンス](lf-permissions-reference.md)」を参照してください。 ## AWS Lake Formation ペルソナ 次の表に、推奨される AWS Lake Formation ペルソナを示します。 **Lake Formation のペルソナ** | ペルソナ | 説明 | | --- | --- | | IAM 管理者 (スーパーユーザー) | (必須) IAM ユーザーとロールを作成できるユーザーです。AdministratorAccess AWS 管理ポリシーがあります。すべての Lake Formation リソースに対するすべての許可を持っています。データレイク管理者を追加できます。データレイク管理者としても指定されている場合を除き、Lake Formation 許可を付与することはできません。 | | データレイク管理者 | (必須) Amazon S3 ロケーションの登録、データカタログへのアクセス、データベースの作成、ワークフローの作成と実行、他のユーザーへの Lake Formation アクセス許可の付与、 AWS CloudTrail ログの表示を行うことができるユーザー。IAM 許可の数は IAM 管理者よりも少ないですが、データレイクを管理するには十分な許可を持っています。他のデータレイク管理者を追加することはできません。 | | 読み取り専用管理者 | (オプション) プリンシパル、データカタログリソース、アクセス許可、および  AWS CloudTrail  ログを表示できますが、更新するアクセス許可を持たないユーザー。 | | データエンジニア | (オプション) データベースの作成、クローラとワークフローの作成と実行、およびクローラとワークフローが作成する Data Catalog テーブルに対する Lake Formation 許可の付与を実行できるユーザーです。すべてのデータエンジニアをデータベース作成者にすることが推奨されます。詳細については、「[データベースを作成する](creating-database.md)」を参照してください。 | | データアナリスト | (オプション) Amazon Athenaなどを使用して、データレイクに対するクエリを実行できるユーザーです。クエリを実行するために十分な許可のみを持っています。 | | ワークフローロール | (必須) ユーザーに代わってワークフローを実行するロールです。このロールは、ブループリントからワークフローを作成するときに指定します。 | **注記** Lake Formation では、データベースの作成後に追加されたデータレイク管理者はアクセス許可を付与できますが、SELECT や DESCRIBE などのデータアクセス許可が自動的に付与されるわけではありません。データベースを作成する管理者は、それらのデータベースに対する `SUPER` アクセス許可を受け取ります。この動作は意図したものであり、すべての管理者が自身に必要なアクセス許可を付与できますが、これらのアクセス許可が既存のリソースに自動的に適用されることはありません。したがって、管理者は管理者権限が割り当てられる前に存在していたデータベースへのアクセスを自分自身に明示的に付与する必要があります。 ## AWS Lake Formation の マネージドポリシー AWS 管理ポリシーとインラインポリシー AWS Lake Formation を使用して、 の操作に必要な AWS Identity and Access Management (IAM) アクセス許可を付与できます。Lake Formation では、次の AWS 管理ポリシーを使用できます。 ### AWS マネージドポリシー:AWSLakeFormationDataAdmin [AWSLakeFormationDataAdmin](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) ポリシーは、データレイクを管理する AWS Glue ための AWS Lake Formation や などの関連サービスへの管理アクセスを許可します。 ユーザー、グループおよびロールに `AWSLakeFormationDataAdmin` をアタッチできます。 **アクセス許可の詳細** + `CloudTrail` – プリンシパルに AWS CloudTrail ログの表示を許可します。これは、データレイクの設定エラーを確認するために必要です。 + `Glue` — プリンシパルに対して、Data Catalog 内のメタデータテーブルおよびデータベースの表示、作成、更新を許可します。これには、`Get`、`List`、`Create`、`Update`、`Delete`、`Search` で始まる API オペレーションが含まれます。これはデータレイクテーブルのメタデータを管理するために必要です。 + `IAM` — プリンシパルに対して、IAM ユーザー、ロール、およびロールにアタッチされたポリシーに関する情報の取得を許可します。これは、データ管理者が IAM ユーザーおよびロールを確認して表示し、Lake Formation のアクセス許可を付与するために必要です。 + `Lake Formation` — データレイク管理者に対して、データレイクを管理するために必要な Lake Formation のアクセス許可を付与します。 + `S3` — プリンシパルに対して、Amazon S3 バケットとその場所に関する情報を取得し、データレイクのデータロケーションを設定することを許可します。 ``` "Statement": [ { "Sid": "AWSLakeFormationDataAdminAllow", "Effect": "Allow", "Action": [ "lakeformation:*", "cloudtrail:DescribeTrails", "cloudtrail:LookupEvents", "glue:CreateCatalog", "glue:UpdateCatalog", "glue:DeleteCatalog", "glue:GetCatalog", "glue:GetCatalogs", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetConnections", "glue:SearchTables", "glue:GetTable", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTableVersions", "glue:GetPartitions", "glue:GetTables", "glue:ListWorkflows", "glue:BatchGetWorkflows", "glue:DeleteWorkflow", "glue:GetWorkflowRuns", "glue:StartWorkflowRun", "glue:GetWorkflow", "s3:ListBucket", "s3:GetBucketLocation", "s3:ListAllMyBuckets", "s3:GetBucketAcl", "iam:ListUsers", "iam:ListRoles", "iam:GetRole", "iam:GetRolePolicy" ], "Resource": "*" }, { "Sid": "AWSLakeFormationDataAdminDeny", "Effect": "Deny", "Action": [ "lakeformation:PutDataLakeSettings" ], "Resource": "*" } ] } ``` **注記** `AWSLakeFormationDataAdmin` ポリシーは、データレイク管理者に必要なすべての許可を付与しません。ワークフローの作成と実行、およびサービスリンクロール `AWSServiceRoleForLakeFormationDataAccess` を使用したロケーションの登録には、追加の許可が必要です。詳細については、「[データレイク管理者を作成する](initial-lf-config.md#create-data-lake-admin)」および「[Lake Formation のサービスリンクロールの使用](service-linked-roles.md)」を参照してください。 ### AWS マネージドポリシー:AWSLakeFormationCrossAccountManager [AWSLakeFormationCrossAccountManager](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) ポリシーは、Lake Formation を介して AWS Glue リソースへのクロスアカウントアクセスを提供し、 AWS Organizations や などの他の必要なサービスへの読み取りアクセスを許可します AWS RAM。 ユーザー、グループおよびロールに `AWSLakeFormationCrossAccountManager` をアタッチできます。 **アクセス許可の詳細** このポリシーには、以下のアクセス許可が含まれています。 + `Glue` — プリンシパルに対して、アクセス制御用の Data Catalog リソースポリシーの設定または削除を許可します。 + `Organizations` — プリンシパルに対して、組織のアカウントおよび組織単位 (OU) 情報の取得を許可します。 + `ram:CreateResourceShare` — プリンシパルに対して、リソース共有の作成を許可します。 + `ram:UpdateResourceShare` —プリンシパルに対して、指定したリソース共有の一部のプロパティの変更を許可します。 + `ram:DeleteResourceShare` — プリンシパルに対して、指定したリソース共有の削除を許可します。 + `ram:AssociateResourceShare` — プリンシパルに対して、指定したプリンシパルのリストとリソースのリストをリソース共有に追加することを許可します。 + `ram:DisassociateResourceShare` — プリンシパルに対して、指定したプリンシパルまたはリソースを、指定したリソース共有への参加から除外することを許可します。 + `ram:GetResourceShares` — プリンシパルに対して、ユーザー自身が所有しているか、ユーザー自身と共有しているリソース共有に関する詳細を取得することを許可します。 + `ram:RequestedResourceType` — プリンシパルに対して、リソースタイプ (データベース、テーブル、またはカタログ) の取得を許可します。 + `AssociateResourceSharePermission` – プリンシパルがリソース共有に含まれるリソースタイプの AWS RAM アクセス許可を追加または置換できるようにします。リソース共有内のリソースタイプごとに、1 つのアクセス許可のみを関連付けることができます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "AllowCreateResourceShare", "Effect": "Allow", "Action": [ "ram:CreateResourceShare" ], "Resource": "*", "Condition": { "StringLikeIfExists": { "ram:RequestedResourceType": [ "glue:Table", "glue:Database", "glue:Catalog" ] } } }, { "Sid": "AllowManageResourceShare", "Effect": "Allow", "Action": [ "ram:UpdateResourceShare", "ram:DeleteResourceShare", "ram:AssociateResourceShare", "ram:DisassociateResourceShare", "ram:GetResourceShares" ], "Resource": "*", "Condition": { "StringLike": { "ram:ResourceShareName": [ "LakeFormation*" ] } } }, { "Sid": "AllowManageResourceSharePermissions", "Effect": "Allow", "Action": [ "ram:AssociateResourceSharePermission" ], "Resource": "*", "Condition": { "ArnLike": { "ram:PermissionArn": [ "arn:aws:ram::aws:permission/AWSRAMLFEnabled*" ] } } }, { "Sid": "AllowXAcctManagerPermissions", "Effect": "Allow", "Action": [ "glue:PutResourcePolicy", "glue:DeleteResourcePolicy", "organizations:DescribeOrganization", "organizations:DescribeAccount", "ram:Get*", "ram:List*" ], "Resource": "*" }, { "Sid": "AllowOrganizationsPermissions", "Effect": "Allow", "Action": [ "organizations:ListRoots", "organizations:ListAccountsForParent", "organizations:ListOrganizationalUnitsForParent" ], "Resource": "*" } ] } ``` ------ ### AWS マネージドポリシー:AWSGlueConsoleFullAccess [AWSGlueConsoleFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueConsoleFullAccess) ポリシーは、ポリシーがアタッチされている ID が を使用する場合、 AWS Glue リソースへのフルアクセスを許可します AWS マネジメントコンソール。このポリシーで指定されたリソースの命名規則に従った場合、ユーザーは完全なコンソール機能を使用できます。このポリシーは通常、 AWS Glue コンソールのユーザーにアタッチされます。 さらに、AWS Glue と Lake Formation は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、および Amazon CloudWatch などの関連サービスへのアクセスを許可するために、サービスロール `AWSGlueServiceRole` を引き受けます。 ### AWS managed policy:LakeFormationDataAccessServiceRolePolicy このポリシーは、ユーザーのリクエストに応じてサービスがリソースに対してアクションを実行することを許可する、`ServiceRoleForLakeFormationDataAccess` というサービスリンクロールにアタッチされます。このポリシーを IAM ID にアタッチすることはできません。 このポリシーにより、 Amazon Athena や Amazon Redshift などの Lake Formation 統合 AWS サービスが、サービスにリンクされたロールを使用して Amazon S3 リソースを検出できるようになります。 詳細については、[Lake Formation のサービスリンクロールの使用](service-linked-roles.md) を参照してください。 **アクセス許可の詳細** このポリシーには、次の許可が含まれています。 + `s3:ListAllMyBuckets` - 認証されたリクエスト送信者が所有するすべてのバケットのリストを返します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccessServiceRolePolicy", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "arn:aws:s3:::*" ] } ] } ``` ------ **AWS 管理ポリシーに対する Lake Formation の更新** このサービスがこれらの変更の追跡を開始してからの Lake Formation の AWS マネージドポリシーの更新に関する詳細を表示します。 | 変更 | 説明 | 日付 | | --- | --- | --- | | Lake Formation が AWSLakeFormationCrossAccountManager ポリシーを更新しました。 | Lake Formation は、StringLike 条件演算子を、IAM による ARN 形式チェックの実行を可能にする ArnLike 演算子に置き換えて、[AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) ポリシーを強化しました。 | 2025 年 1 月 | | Lake Formation が AWSLakeFormationDataAdmin ポリシーを更新しました。 | Lake Formation は、マルチカタログ機能の一部として次の AWS Glue Data Catalog CRUD API を追加して、[AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) ポリシーを強化しました。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html)この管理ポリシーの変更は、Lake Formation 管理者ペルソナにこれらの新しいオペレーションに対する IAM アクセス許可がデフォルトで付与されるようにするためです。 | 2024 年 12 月 | | Lake Formation が AWSLakeFormationCrossAccountManager ポリシーを更新しました。 | Lake Formation で [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) ポリシーが強化され、ポリシーステートメントに Sid 要素が追加されました。 | 2024 年 3 月 | | Lake Formation が AWSLakeFormationDataAdmin ポリシーを更新しました。 | Lake Formation で [AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) ポリシーが強化され、ポリシーステートメントに Sid 要素が追加され、余分なアクションが削除されました。 | 2024 年 3 月 | | Lake Formation が LakeFormationDataAccessServiceRolePolicy ポリシーを更新しました。 | Lake Formation で [LakeFormationDataAccessServiceRolePolicy](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/LakeFormationDataAccessServiceRolePolicy) ポリシーが強化され、ポリシーステートメントに Sid 要素が追加されました。 | 2024 年 2 月 | | Lake Formation が AWSLakeFormationCrossAccountManager ポリシーを更新しました。 | Lake Formation では、ハイブリッドアクセスモードでのクロスアカウントデータ共有を可能にする新しいアクセス許可を追加し、[AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) ポリシーを強化しました。 | 2023 年 10 月 | | Lake Formation が AWSLakeFormationCrossAccountManager ポリシーを更新しました。 | Lake Formation は [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) ポリシーを強化し、リソースの最初の共有時に、受信者アカウントごとに 1 つのリソース共有のみを作成するようになりました。以降に同じアカウントで共有されるすべてのリソースは、同じリソース共有にアタッチされます。 | 2022 年 5 月 6 日 | | Lake Formation が変更の追跡を開始しました。 | Lake Formation は AWS 、管理ポリシーの変更の追跡を開始しました。 | 2022 年 5 月 6 日 | ## ペルソナに推奨される許可 以下は、各ペルソナに推奨される許可です。IAM 管理者であるユーザーは、すべてのリソースに対するすべての許可を持っているため、ここのは含まれていません。 **Topics** + [データレイク管理者の許可](#persona-dl-admin) + [読み取り専用管理者のアクセス許可](#persona-read-only-admin) + [データエンジニアの許可](#persona-engineer) + [データアナリストの許可](#persona-user) + [ワークフローロールの許可](#persona-workflow-role) ### データレイク管理者の許可 **重要** 次のポリシーでは、** を有効な AWS アカウント番号に置き換え、** を、「」で定義されているように、ワークフローを実行するアクセス許可を持つロールの名前に置き換えます[ワークフローロールの許可](#persona-workflow-role)。 | ポリシータイプ | ポリシー | | --- | --- | | AWS マネージドポリシー | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) オプションの AWS 管理ポリシーの詳細については、「」を参照してください[データレイク管理者を作成する](initial-lf-config.md#create-data-lake-admin)。 | | インラインポリシー (Lake Formation サービスリンクロールの作成用) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": "lakeformation.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam:::role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess"
        }
    ]
}
| | (オプション) インラインポリシー (ワークフローロールのための PassRole ポリシー)。これは、データレイク管理者がワークフローを作成して実行する場合にのみ必要になります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | | (オプション) インラインポリシー (アカウントがクロスアカウント Lake Formation 許可を付与または受けている場合)。このポリシーは、 AWS RAM リソース共有の招待を承諾または拒否し、組織へのクロスアカウントアクセス許可の付与を有効にするためのものです。 ram:EnableSharingWithAwsOrganizationは、管理アカウントのデータレイク管理者 AWS Organizations にのみ必要です。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | ### 読み取り専用管理者のアクセス許可 | ポリシータイプ | ポリシー | | --- | --- | | インラインポリシー (ベーシック) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | ### データエンジニアの許可 **重要** 次のポリシーでは、** を有効な AWS アカウント番号に置き換え、** をワークフローロールの名前に置き換えます。 | ポリシータイプ | ポリシー | | --- | --- | | AWS マネージドポリシー | AWSGlueConsoleFullAccess | | インラインポリシー (ベーシック) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | | インラインポリシー (トランザクション内での操作を含む、管理対象テーブルでの操作用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | | インラインポリシー (Lake Formation のタグベースのアクセス制御 (LF-TBAC) 方式を使用したメタデータアクセス制御用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | | インラインポリシー (ワークフローロールのための PassRole ポリシー) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | ### データアナリストの許可 | ポリシータイプ | ポリシー | | --- | --- | | AWS マネージドポリシー | AmazonAthenaFullAccess | | インラインポリシー (ベーシック) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lakeformation:GetDataAccess",
                "glue:GetTable",
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:GetPartitions",
                "lakeformation:GetResourceLFTags",
                "lakeformation:ListLFTags",
                "lakeformation:GetLFTag",
                "lakeformation:SearchTablesByLFTags",
                "lakeformation:SearchDatabasesByLFTags"                
           ],
            "Resource": "*"
        }
    ]
}
| | (オプション) インラインポリシー (トランザクション内での操作を含む、管理対象テーブルでの操作用) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | ### ワークフローロールの許可 このロールには、ワークフローを実行するために必要な許可があります。これらの許可を持つロールは、ワークフローを作成するときに指定します。 **重要** 次のポリシーでは、** を有効な AWS リージョン識別子 (例: `us-east-1`)、** を有効な AWS アカウント番号、** をワークフローロールの名前、** を AWS CloudTrail ログへの Amazon S3 パスに置き換えます。 | ポリシータイプ | ポリシー | | --- | --- | | AWS マネージドポリシー | AWSGlueServiceRole | | インラインポリシー (データアクセス) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Lakeformation",
            "Effect": "Allow",
            "Action": [
                 "lakeformation:GetDataAccess",
                 "lakeformation:GrantPermissions"
             ],
            "Resource": "*"
        }
    ]
}
| | インラインポリシー (ワークフローロールのための PassRole ポリシー) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | | インラインポリシー ( AWS CloudTrail ログなど、データレイクの外部にデータを取り込む場合) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/permissions-reference.html) | # データレイクのデフォルト設定の変更 との下位互換性を維持するためにAWS Glue、 AWS Lake Formation には以下の初期セキュリティ設定があります。 + 既存の AWS Glue Data Catalog リソースのすべてに対する `Super` 許可がグループ `IAMAllowedPrincipals` に付与されます。 + 新しい Data Catalog リソースには「Use only IAM access control」(IAM アクセス制御のみを使用する) 設定が有効になっています。 これらの設定により、データカタログリソースと Amazon S3 ロケーションへのアクセスは、 AWS Identity and Access Management (IAM) ポリシーによってのみ制御されます。個々の Lake Formation 許可は適用されません。 `IAMAllowedPrincipals` グループには、IAM ポリシーによって Data Catalog リソースへのアクセスを許可される IAM ユーザーとロールが含まれます。この `Super` 許可は、プリンシパルが、許可の対象であるデータベースまたはテーブルで、サポートされているすべての Lake Formation 操作を実行できるようにします。 Data Catalog リソース (データベースおよびテーブル) へのアクセスが Lake Formation 許可によって管理されるようにセキュリティ設定を変更するには、以下を実行します。 1. 新しいリソースに対するデフォルトのセキュリティ設定を変更する。手順については、「[デフォルトのアクセス許可モデルを変更する、またはハイブリッドアクセスモードを使用する](initial-lf-config.md#setup-change-cat-settings)」を参照してください。 1. 既存の Data Catalog リソースに対する設定を変更する。手順については、「[AWS Lake Formation モデルへのAWS Glueデータアクセス許可のアップグレード](upgrade-glue-lake-formation.md)」を参照してください。 **Lake Formation の `PutDataLakeSettings` API 操作を使用したデフォルトセキュリティ設定の変更** デフォルトのセキュリティ設定は、Lake Formation の [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html) API オペレーションを使用して変更することもできます。このアクションは、オプションのカタログ ID と [DataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DataLakeSettings.html) 構造を引数として使用します。 Lake Formation によるメタデータと基盤となるデータのアクセス制御を新しいデータベースとテーブルに適用するには、`DataLakeSettings` 構造を以下のようにコード化します。 **注記** ** を有効な AWS アカウント ID に、** を有効な IAM ユーザー名に置き換えます。複数のユーザーをデータレイク管理者として指定できます。 ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [] } } ``` この構造は、以下のようにコード化することもできます。`CreateDatabaseDefaultPermissions` または `CreateTableDefaultPermissions` パラメータを省略することは、空のリストを渡すことに相当します。 ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ] } } ``` このアクションは実質的に、`IAMAllowedPrincipals` グループから新しいデータベースとテーブルに対するすべての Lake Formation 許可を取り消します。この設定は、データベースを作成するときに上書きすることができます。 IAM のみによるメタデータと基盤となるデータのアクセス制御を新しいデータベースとテーブルに適用するには、`DataLakeSettings` 構造を以下のようにコード化します。 ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ], "CreateDatabaseDefaultPermissions": [ { "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": [ "ALL" ] } ], "CreateTableDefaultPermissions": [ { "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": [ "ALL" ] } ] } } ``` これは、新しいデータベースとテーブルに対する `Super` Lake Formation 許可を `IAMAllowedPrincipals` グループに付与します。この設定は、データベースを作成するときに上書きすることができます。 **注記** 前述の `DataLakeSettings` 構造では、`DataLakePrincipalIdentifier` に許可される値は `IAM_ALLOWED_PRINCIPALS` のみで、`Permissions` に許可される値は `ALL` のみです。 # 黙示的な Lake Formation 許可 AWS Lake Formation は、データレイク管理者、データベース作成者、およびテーブル作成者に次の暗黙的なアクセス許可を付与します。 **データレイク管理者** + 別のアカウントから別のプリンシパルに直接共有されているリソースを除き、データカタログ内のすべての `Describe` リソースにアクセスできます。管理者からこのアクセス権を取り消すことはできません。 + データレイク全体に対するデータロケーション許可があります。 + Data Catalog 内の任意のリソースへのアクセス権を任意のプリンシパル (自分自身を含む) に付与する、またはそれらをまたは取り消すことができます。管理者からこのアクセス権を取り消すことはできません。 + Data Catalog にデータベースを作成できます。 + データベースを作成する許可を別のユーザーに付与できます。 データレイク管理者が Amazon S3 ロケーションを登録できるのは、それを実行するための IAM 許可を持っている場合に限定されます。本ガイドで推奨されているデータレイク管理者ポリシーは、これらの許可を付与します。また、データレイク管理者には、データベースをドロップする、または他のユーザーが作成したテーブルを変更/ドロップするための黙示的な許可はありませんが、それらを実行する許可を自分自身に付与することが可能です。 データレイク管理者の詳細については、「[データレイク管理者を作成する](initial-lf-config.md#create-data-lake-admin)」を参照してください。 **カタログ作成者** + 作成するカタログに対するすべてのカタログアクセス許可を持ち、カタログ内に作成するデータベースとテーブルに対するアクセス許可を持ち、カタログ内にデータベースとテーブルを作成するアクセス許可を同じ AWS アカウントの他のプリンシパルに付与できます。`AWSLakeFormationCrossAccountManager` AWS 管理ポリシーも持つカタログ作成者は、カタログに対するアクセス許可を他の AWS アカウントまたは組織に付与できます。 データレイク管理者は、Lake Formation コンソールまたは API を使用してカタログ作成者を指定することができます。 **注記** カタログ作成者には、他のユーザーによってカタログ内に作成されるデータベースとテーブルに対する黙示的なアクセス許可はありません。 カタログの作成の詳細については、「[へのデータの取り込み AWS Glue Data Catalog](bring-your-data-overview.md)」を参照してください。 **データベース作成者** + 作成するデータベースに対するすべてのデータベースアクセス許可を持ち、データベースに作成するテーブルに対するアクセス許可を持ち、同じ AWS アカウントの他のプリンシパルにデータベースにテーブルを作成するアクセス許可を付与できます。`AWSLakeFormationCrossAccountManager` AWS マネージドポリシーも持つデータベース作成者は、データベースに対するアクセス許可を他の AWS アカウントまたは組織に付与できます。 データレイク管理者は、Lake Formation コンソールまたは API を使用してデータベース作成者を指定することができます。 **注記** データベース作成者に、他のユーザーがデータベース内に作成するテーブルに対する黙示的な許可はありません。 詳細については、「[データベースを作成する](creating-database.md)」を参照してください。 **テーブル作成者** + 作成するテーブルに対するすべての許可があります。 + 作成するすべてのテーブルに対する許可を同じ AWS アカウント内のプリンシパルに付与できます。 + `AWSLakeFormationCrossAccountManager` AWS 管理ポリシーがある場合は、作成したすべてのテーブルに対するアクセス許可を他の AWS アカウントまたは組織に付与できます。 + 作成するテーブルが含まれるデータベースを表示できます。 # Lake Formation 許可のリファレンス AWS Lake Formation オペレーションを実行するには、プリンシパルに Lake Formation アクセス許可と AWS Identity and Access Management (IAM) アクセス許可の両方が必要です。IAM 許可は通常、「[Lake Formation 許可の概要](lf-permissions-overview.md)」で説明したように、粗粒度のアクセス制御ポリシーを使用して付与します。Lake Formation のアクセス許可は、 コンソール、 API、または AWS Command Line Interface () を使用して付与できますAWS CLI。 Lake Formation 許可を付与または取り消す方法を学ぶには、「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」および「[データロケーション許可の付与](granting-location-permissions.md)」を参照してください。 **注記** このセクションの例は、同じ AWS アカウント内のプリンシパルに許可を付与するを説明するものです。クロスアカウント付与の例については、「[Lake Formation でのクロスアカウントデータ共有](cross-account-permissions.md)」を参照してください。 ## リソースタイプ別の Lake Formation 許可 各リソースで利用できる有効な Lake Formation 許可は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/lf-permissions-reference.html) **Topics** + [リソースタイプ別の Lake Formation 許可](#lf-resource-permissions-summary) + [Lake Formation の許可と取り消し AWS CLI コマンド](#perm-command-format) + [Lake Formation 許可](#lf-permissions) ## Lake Formation の許可と取り消し AWS CLI コマンド このセクションの各アクセス許可の説明には、 AWS CLI コマンドを使用してアクセス許可を付与する例が含まれています。Lake Formation コマンド**grant-permissions**と **revoke-permissions** AWS CLI コマンドの概要を次に示します。 ``` grant-permissions [--catalog-id ] --principal --resource --permissions [--permissions-with-grant-option ] [--cli-input-json ] [--generate-cli-skeleton ] ``` ``` revoke-permissions [--catalog-id ] --principal --resource --permissions [--permissions-with-grant-option ] [--cli-input-json ] [--generate-cli-skeleton ] ``` これらのコマンドの詳しい説明については、「AWS CLI コマンドリファレンス」の「[grant-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/grant-permissions.html)」および「[revoke-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/revoke-permissions.html)」を参照してください。このセクションは、`--principal` オプションに関する追加の情報を提供します。 `--principal` オプションの値は、以下のいずれかになります。 + (IAM) ユーザーまたはロールの Amazon リソースネーム AWS Identity and Access Management (ARN) + Microsoft アクティブディレクトリフェデレーションサービス (AD FS) などの SAML プロバイダー経由で認証するユーザーまたはグループの ARN + Amazon Quick ユーザーまたはグループの ARN + クロスアカウントアクセス許可、 AWS アカウント ID、組織 ID、または組織単位 ID の場合 + IAM アイデンティティセンターユーザーまたはグループの場合、IAM アイデンティティセンターユーザーユーザーまたはグループの ARN。 以下は、すべての `--principal` タイプの構文と例です。 **プリンシパルが IAM ユーザー** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::user/ ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 ``` **プリンシパルが IAM ロール** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::role/ ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/workflowrole ``` **プリンシパルが SAML プロバイダー経由で認証するユーザー** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:user/ ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:user/datalake_user1 ``` ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:user/athena-user@example.com ``` **プリンシパルが SAML プロバイダー経由で認証するグループ** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:group/ ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:group/data-scientists ``` ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:group/my-group ``` **プリンシパルは Amazon Quick Enterprise Edition ユーザーです** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:::user// ``` ** には `default` を指定する必要があります。 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:user/default/bi_user1 ``` **プリンシパルは Amazon Quick Enterprise Edition グループです** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:::group// ``` ** には `default` を指定する必要があります。 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:group/default/data_scientists ``` **プリンシパルは AWS アカウントです** 構文: ``` --principal DataLakePrincipalIdentifier= ``` 例: ``` --principal DataLakePrincipalIdentifier=111122223333 ``` **プリンシパルが組織** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations:::organization/ ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:organization/o-abcdefghijkl ``` **プリンシパルが組織単位** 構文: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations:::ou// ``` 例: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:ou/o-abcdefghijkl/ou-ab00-cdefghij ``` **プリンシパルが IAM アイデンティティセンターの ID ユーザーまたはグループ** 例: ユーザー ``` --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ ``` 例: グループ ``` --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::group/ ``` **プリンシパルが IAM グループ - `IAMAllowedPrincipals`** Lake Formation は、データカタログ内のすべてのデータベースとテーブルに対する `Super` アクセス許可を、デフォルトで `IAMAllowedPrincipals` というグループに設定します。このグループアクセス許可がデータベースまたはテーブルに存在する場合、アカウント内のすべてのプリンシパルが、 AWS Glueの IAM プリンシパルポリシーを介してリソースにアクセスできるようになります。これにより、以前に AWS Glueの IAM ポリシーで保護されていたデータカタログリソースを Lake Formation アクセス許可で保護し始めるときに、下位互換性が提供されます。 Lake Formation を使用してデータカタログリソースのアクセス許可を管理する場合、Lake Formation アクセス許可を機能させるには、まずリソースに設定されている `IAMAllowedPrincipals` アクセス許可を取り消すか、プリンシパルとリソースをハイブリッドアクセスモードにオプトインする必要があります。 例: ``` --principal DataLakePrincipalIdentifier=IAM_Allowed_Principals ``` **プリンシパルが IAM グループ - `ALLIAMPrincipals`** データカタログリソースへのアクセス許可を `ALLIAMPrincipals` グループに付与すると、アカウント内のすべてのプリンシパルが、Lake Formation アクセス許可と IAM アクセス許可を使用してデータカタログリソースにアクセスできるようになります。 例: ``` --principal DataLakePrincipalIdentifier=123456789012:IAMPrincipals ``` ## Lake Formation 許可 このセクションでは、プリンシパルに付与できる Lake Formation 許可を一覧表示します。 ### `ALTER` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | ALTER | DATABASE | glue:UpdateDatabase | | ALTER | TABLE | glue:UpdateTable | | ALTER | LF-Tag | lakeformation:UpdateLFTag | この許可を持つプリンシパルは、Data Catalog 内のデータベースまたはテーブルのメタデータを変更できます。テーブルの場合は、列スキーマを変更し、列パラメータを追加することができます。メタデータテーブルがポイントする基盤となるデータの列を変更することはできません。 変更されるプロパティが登録済みの Amazon Simple Storage Service (Amazon S3) ロケーションである場合は、プリンシパルが新しいロケーションに対するデータロケーション許可を持っている必要があります。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`datalake_user1`のユーザーに アクセス`ALTER`許可を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Database": {"Name":"retail"}}' ``` **Example** 以下の例は、データベース `retail` にあるテーブル `inventory` に対する `ALTER` をユーザー `datalake_user1` に付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` ### `CREATE_DATABASE` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | CREATE\$1DATABASE | Data Catalog | glue:CreateDatabase | この許可を持つプリンシパルは、Data Catalog にメタデータデータベースまたはリソースリンクを作成できます。プリンシパルは、データベースにテーブルを作成することもできます。 **Example** 次の例では`CREATE_DATABASE`、 AWS アカウント 1111-2222-3333 `datalake_user1`の ユーザーに を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_DATABASE" --resource '{ "Catalog": {}}' ``` プリンシパルが Data Catalog にデータベースを作成するときに、基盤となるデータに対する許可は付与されません。以下の追加のメタデータ許可が、これらの許可を他のユーザーに付与する能力と共に付与されます。 + データベース内での `CREATE_TABLE` + データベースの `ALTER` + データベースの `DROP` プリンシパルは、データベースを作成するときにオプションで Amazon S3 ロケーションを指定できます。プリンシパルがデータロケーション許可を持っているかどうかに応じて、`CREATE_DATABASE` 許可ではデータベースを作成できない場合があります。以下の 3 つのユースケースを念頭に置いておくことが重要です。 | データベースの作成ユースケース | 必要となる許可 | | --- | --- | | ロケーションプロパティが指定されていない。 | CREATE\$1DATABASE で十分です。 | | ロケーションプロパティが指定されており、ロケーションが Lake Formation によって管理されていない (登録されていない)。 | CREATE\$1DATABASE で十分です。 | | ロケーションプロパティが指定されており、ロケーションが Lake Formation によって管理されている (登録されている)。 | CREATE\$1DATABASE に加えて、指定されたロケーションに対するデータロケーション許可が必要です。 | ### `CREATE_TABLE` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | CREATE\$1TABLE | DATABASE | glue:CreateTable | この許可を持つプリンシパルは、指定したデータベース内の Data Catalog にメタデータテーブルまたはリソースリンクを作成できます。 **Example** 次の例では、 AWS アカウント 1111-2222-3333 の`retail`データベースにテーブルを作成する`datalake_user1`アクセス許可をユーザーに付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}' ``` プリンシパルが Data Catalog にテーブルを作成すると、そのテーブルに対するすべての Lake Formation 許可が、これらの許可を他のユーザーに付与する能力と共にプリンシパルに付与されます。 **クロスアカウント付与** データベース所有者アカウントが受領者アカウントに `CREATE_TABLE` を付与し、受領者アカウントのユーザーが所有者アカウントのデータベースにテーブルを正常に作成する場合、以下のルールが適用されます。 + 受領者アカウントのユーザーとデータレイク管理者には、このテーブルに対するすべての Lake Formation 許可があり、テーブルに対する許可をアカウント内の他のプリンシパルに付与することができます。所有者アカウントまたはその他のアカウントのプリンシパルに許可を付与することはできません。 + 所有者アカウントのデータレイク管理者は、テーブルに対する許可をアカウント内の他のプリンシパルに付与できます。 **データロケーション許可** Amazon S3 ロケーションをポイントするテーブルの作成を試みるときは、データロケーション許可を持っているかどうかに応じて、`CREATE_TABLE` 許可がテーブルの作成に不十分である場合があります。以下の 3 つのユースケースを念頭に置いておくことが重要です。 | テーブルの作成ユースケース | 必要となる許可 | | --- | --- | | 指定されたロケーションが Lake Formation によって管理されていない (登録されていない)。 | CREATE\$1TABLE で十分です。 | | 指定されたロケーションが Lake Formation によって管理されて (登録されて) おり、それが含まれるデータベースにロケーションプロパティがないか、テーブルロケーションの Amazon S3 プレフィックスではないロケーションプロパティがある。 | CREATE\$1TABLE に加えて、指定されたロケーションに対するデータロケーション許可が必要です。 | | 指定されたロケーションが Lake Formation によって管理されて (登録されて) おり、それが含まれるデータベースに、登録済みで、かつテーブルロケーションの Amazon S3 プレフィックスであるロケーションをポイントするロケーションプロパティがある。 | CREATE\$1TABLE で十分です。 | ### `DATA_LOCATION_ACCESS` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | DATA\$1LOCATION\$1ACCESS | Amazon S3 ロケーション | (このロケーションに対する Amazon S3 許可。これは、ロケーションの登録に使用されたロールによって指定されている必要があります。) | これが唯一のデータロケーション許可です。この許可を持つプリンシパルは、指定された Amazon S3 ロケーションをポイントするメタデータデータベースまたはテーブルを作成できます。このロケーションは登録される必要があります。ロケーションに対するデータロケーション許可を持つプリンシパルは、子ロケーションに対するロケーション許可も持っています。 **Example** 以下の例は、 AWS アカウント 1111-2222-3333 のユーザー `datalake_user1` に `s3://products/retail` に対するデータロケーション許可を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DATA_LOCATION_ACCESS" --resource '{ "DataLocation": {"ResourceArn":"arn:aws:s3:::products/retail"}}' ``` 基盤となるデータのクエリや更新に `DATA_LOCATION_ACCESS` は必要ありません。この許可は、Data Catalog リソースの作成のみに適用されます。 データロケーション許可については、「[Underlying data access control](access-control-underlying-data.md#data-location-permissions)」を参照してください。 ### `DELETE` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | DELETE | TABLE | (ロケーションが登録されている場合、追加の IAM 許可は必要ありません。) | この許可を持つプリンシパルは、テーブルが指定する Amazon S3 ロケーションにある基盤となるデータの挿入、更新、および読み取りを実行できます。プリンシパルは、Lake Formation コンソールでテーブルを表示し、AWS Glue API を使用してテーブルに関する情報を取得することもできます。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`inventory`の テーブル`datalake_user1`に対する アクセス`DELETE`許可をユーザーに付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DELETE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` この許可は、Amazon S3 内のデータにのみ適用され、Amazon Relational Database Service (Amazon RDS) などの他のデータストア内のデータには適用されません。 ### `DESCRIBE` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | DESCRIBE | テーブルリソースリンク データベースリソースリンク | `glue:GetTable` `glue:GetDatabase` | | DESCRIBE | DATABASE | glue:GetDatabase | | DESCRIBE | TABLE | glue:GetTable | | DESCRIBE | LF-Tag | `glue:GetTable` `glue:GetDatabase` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` | この許可を持つプリンシパルは、指定されたデータベース、テーブル、またはリソースリンクを表示できます。これ以外の Data Catalog 許可が黙示的に付与されることはなく、データアクセス許可が黙示的に付与されることもありません。統合サービスのクエリエディタにはデータベースとテーブルが表示されますが、他の Lake Formation 許可 (`SELECT` など) が付与されていない限り、それらに対するクエリを実行することはできません。 例えば、データベースに対する `DESCRIBE` を持つユーザーは、そのデータベースとすべてのデータベースメタデータ (説明、ロケーションなど) を確認できますが、データベースにどのテーブルが含まれているかは判断できず、データベースでテーブルの削除、変更、または作成を行うことはできません。同様に、テーブルに対する `DESCRIBE` を持つユーザーは、テーブルとテーブルメタデータ (説明、スキーマ、ロケーションなど) を確認できますが、テーブルに対してドロップ、変更、またはクエリを実行することはできません。 以下は、`DESCRIBE` に関する追加のルールです。 + ユーザーがデータベース、テーブル、またはリソースリンクに対する他の Lake Formation 許可を持っている場合、`DESCRIBE` が黙示的に付与されます。 + ユーザーがテーブルについて列のサブセットのみに対する `SELECT` (partial `SELECT`) を持っている場合、ユーザーはこれらの列のみの表示に制限されます。 + テーブルに対する partial SELECT を持つユーザーに `DESCRIBE` を付与することはできません。これとは逆に、`DESCRIBE` が付与されているテーブルに、列の包含リストや除外リストを指定することはできません。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`inventory-link`のテーブルリソースリンク`datalake_user1`に対する アクセス`DESCRIBE`許可をユーザーに付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}' ``` ### `DROP` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | DROP | DATABASE | glue:DeleteDatabase | | DROP | TABLE | glue:DeleteTable | | DROP | LF-Tag | lakeformation:DeleteLFTag | | DROP | データベースリソースリンク テーブルリソースリンク | `glue:DeleteDatabase` `glue:DeleteTable` | この許可を持つプリンシパルは、Data Catalog 内のデータベース、テーブル、またはリソースリンクをドロップできます。データベースに対する DROP を、外部のアカウントまたは組織に付与することはできません。 **警告** データベースをドロップすると、データベース内のすべてのテーブルがドロップされます。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`datalake_user1`のユーザーに アクセス`DROP`許可を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Database": {"Name":"retail"}}' ``` **Example** 以下の例は、データベース `retail` にあるテーブル `inventory` に対する `DROP` をユーザー `datalake_user1` に付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` **Example** 以下の例は、データベース `retail` にあるテーブルリソースリンク `inventory-link` に対する `DROP` をユーザー `datalake_user1` に付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}' ``` ### `INSERT` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | INSERT | TABLE | (ロケーションが登録されている場合、追加の IAM 許可は必要ありません。) | この許可を持つプリンシパルは、テーブルが指定する Amazon S3 ロケーションにある基盤となるデータの挿入、更新、および読み取りを実行できます。プリンシパルは、Lake Formation コンソールでテーブルを表示し、AWS Glue API を使用してテーブルに関する情報を取得することもできます。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`inventory`の テーブル`datalake_user1`に対する アクセス`INSERT`許可をユーザーに付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "INSERT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` この許可は、Amazon S3 内のデータにのみ適用され、Amazon RDS などの他のデータストア内のデータには適用されません。 ### `SELECT` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | SELECT | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/lf-permissions-reference.html) | (ロケーションが登録されている場合、追加の IAM 許可は必要ありません。) | この許可を持つプリンシパルは、Data Catalog 内のテーブルを表示し、テーブルが指定するロケーションにある Amazon S3 内の基盤となるデータをクエリすることができます。プリンシパルは、Lake Formation コンソールでテーブルを表示し、AWS Glue API を使用してテーブルに関する情報を取得することができます。この許可の付与時に列フィルタリングが適用された場合、プリンシパルは、包含されている列のメタデータのみを表示でき、包含されている列からのデータのみをクエリできます。 **注記** クエリの処理時に列フィルタリングを適用するのは、統合された分析サービスの責任です。 **Example** 次の例では、`retail` AWS アカウント 1111-2222-3333 のデータベース`inventory`の テーブル`datalake_user1`に対する アクセス`SELECT`許可をユーザーに付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` この許可は、Amazon S3 内のデータにのみ適用され、Amazon RDS などの他のデータストア内のデータには適用されません。 オプションの包含リストまたは除外リストを使用して、特定の列をフィルタリング (それらへのアクセスを制限) できます。包含リストは、アクセスできる列を指定します。除外リストは、アクセスできない列を指定します。包含リストまたは除外リストがない場合は、すべてのテーブル列にアクセスできます。 `glue:GetTable` の結果は、呼び出し元が表示許可を持っている列のみを返します。Amazon Athena および Amazon Redshift などの統合サービスは、包含リストと除外リストに従います。 **Example** 以下の例は、包含リストを使用して、テーブル `inventory` に対する `SELECT` をユーザー `datalake_user1` に付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnNames": ["prodcode","location","period","withdrawals"]}}' ``` **Example** 次の例は、除外リストを使用して、`inventory` テーブルに対する `SELECT` を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnWildcard": {"ExcludedColumnNames": ["intkey", "prodcode"]}}}' ``` `SELECT` 許可には以下の制限が適用されます。 + 列フィルタリングが適用されている場合、`SELECT` を付与するときに grant オプションを含めることはできません。 + パーティションキーである列に対するアクセス制御を制限することはできません。 + テーブル内の列のサブセットに対する `SELECT` 許可を持つプリンシパルに、そのテーブルに対する `ALTER`、`DROP`、`DELETE` または `INSERT` 許可を付与することはできません。同様に、テーブルに対する `ALTER`、`DROP`、`DELETE` または `INSERT` 許可を持つプリンシパルに、列フィルタリングを伴う `SELECT` 許可を付与することはできません。 `SELECT` 許可は常に、Lake Formation コンソールの **[Data permissions]** (データの許可) ページに個別の行として表示されます。以下の画像は、`inventory` テーブル内のすべての列に対する `SELECT` が、ユーザー `datalake_user2` と `datalake_user3` に付与されていることを示しています。 ![\[データアクセス許可ページには 4 行が表示されます。最初の行と 3 行目には Delete (削除) と Insert (挿入) のアクセス許可とともにリソースタイプ Table (テーブル) がリストされており、2 行目と 4 行目には Select (選択)アクセス許可と Column (列) リソースタイプがリストされ、リソースとして retail.inventory.* が表示されています。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/data-permissions-dialog-select-cross.png) ### `Super` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | Super | DATABASE | glue:\$1Database\$1 | | Super | TABLE | glue:\$1Table\$1, glue:\$1Partition\$1 | この許可は、プリンシパルが、データベースまたはテーブルでサポートされているすべての Lake Formation 操作を実行できるようにします。データベースに対する `Super` を、外部アカウントに付与することはできません。 この許可は、他の Lake Formation 許可と共存できます。例えば、メタデータテーブルに対する `Super`、`SELECT`、および `INSERT` 許可を付与することができます。そうすることで、プリンシパルはテーブルに対してサポートされているすべての操作を実行できるようになります。`Super` を取り消すときは、`SELECT` と `INSERT` 許可が残り、プリンシパルは選択操作と挿入操作のみを実行できます。 `Super` は、個々のプリンシパルに付与する代わりに、グループ `IAMAllowedPrincipals` に付与することができます。`IAMAllowedPrincipals` グループは自動的に作成され、IAM ポリシーによって Data Catalog リソースへのアクセスを許可されるすべての IAM ユーザーとロールが含まれます。Data Catalog リソースに対する `Super` が `IAMAllowedPrincipals` に付与される場合、リソースへのアクセスは、実質的に IAM ポリシーのみで制御されることになります。 Lake Formation コンソールの **[設定]** ページにあるオプションを活用すると、新しいカタログリソースへの `Super` アクセス許可が自動的に `IAMAllowedPrincipals` に付与されるようにすることができます。 ![\[[Data catalog settings] (Data Catalog 設定) ダイアログボックスには、「Default permissions for newly created databases and tables」(新しく作成されたデータベースとテーブルのデフォルト許可) というサブタイトルが付いており、テキストで説明されている 2 つのチェックボックスがあります。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/settings-page.png) + すべての新しいデータベースに対する `Super` を `IAMAllowedPrincipals` に付与するには、**[Use only IAM access control for new databases]** (新しいデータベースに IAM アクセス制御のみを使用) を選択します。 + 新しいデータベース内のすべての新しいテーブルに対する `Super` を `IAMAllowedPrincipals` に付与するには、**[Use only IAM access control for new databases]** (新しいデータベースに IAM アクセス制御のみを使用) を選択します。 **注記** このオプションを選択すると、**[Create database]** (データベースの作成) ダイアログボックスの **[Use only IAM access control for new tables in this database]** (このデータベース内の新しいテーブルには IAM アクセス制御のみを使用する) チェックボックスがデフォルトでオンになります。それ以上は何も行われません。`IAMAllowedPrincipals` への `Super` の付与を有効にするのは、**[Create database]** (データベースの作成) ダイアログボックスにあるチェックボックスです。 これらの **[Settings]** (設定) ページオプションは、デフォルトで有効になっています。詳細については次を参照してください: + [データレイクのデフォルト設定の変更](change-settings.md) + [AWS Lake Formation モデルへのAWS Glueデータアクセス許可のアップグレード](upgrade-glue-lake-formation.md) ### `SUPER_USER` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | Super user | Catalog | glue:GetCatalog | `Super user` アクセス許可は、デフォルトのデータカタログ内のカタログの特定のプリンシパルにのみ付与できます。デフォルトのカタログ、データベースやテーブルなどの他のリソースタイプ、または外部アカウントのプリンシパルに `Super user` アクセス許可を付与することはできません。`Super user` アクセス許可により、プリンシパルは、付与されたカタログ内のデータベースとテーブルに対して、サポートされているすべての Lake Formation オペレーションを実行できます。 `Super user` アクセス許可を使用すると、プリンシパル (被付与者) はカタログ内のリソース (カタログ、データベース、テーブル) に対して次のアクションを実行できます。 + `CREATE_DATABASE`、カタログに対する `DESCRIBE` アクセス許可。 + カタログ内のすべてのデータベースに対する `DROP`、`ALTER`、`CREATE_TABLE`、`DESCRIBE` (実質的に `SUPER`) アクセス許可。 + カタログ内のすべてのデータベース内のすべてのテーブルに対する `DROP`、`ALTER`、`DESCRIBE`、`SELECT`、`INSERT`、`DELETE` (実質的に `SUPER`) アクセス許可。 + カタログ内のカタログに対する `All` (実質的に SUPER) アクセス許可。 + カタログ内のすべてのカタログ、データベース、テーブルに対するアクセス許可を付与可能 (これらのアクセス許可を他のプリンシパルに付与する機能）。 カタログリソースに対する `Super user` アクセス許可では、被付与者はカタログに対して `ALTER` アクションと `DROP` アクションを実行または委任することはできません。 ### `ASSOCIATE` | 許可 | 付与対象リソース | 付与対象に必要な追加の許可 | | --- | --- | --- | | ASSOCIATE | LF-Tag | `glue:GetDatabase` `glue:GetTable` `lakeformation:AddLFTagsToResource"` `lakeformation:RemoveLFTagsFromResource"` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` | LF タグに対してこの許可を持つプリンシパルは、LF タグを Data Catalog リソースに割り当てることができます。`ASSOCIATE` の付与は、`DESCRIBE` を黙示的に付与します。 **Example** この例は、`module` キーを持つ LF タグに対する `ASSOCIATE` アクセス許可をユーザー `datalake_user1` に付与します。これは、そのキーのすべての値 (アスタリスク (\$1) で指定) を表示して割り当てる許可を付与します。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ASSOCIATE" --resource '{ "LFTag": {"CatalogId":"111122223333","TagKey":"module","TagValues":["*"]}}' ``` # IAM アイデンティティセンターの統合 を使用すると AWS IAM アイデンティティセンター、ID プロバイダー (IdPs) に接続し、 AWS 分析サービス全体でユーザーとグループのアクセスを一元管理できます。Okta、Ping、Microsoft Entra ID (以前は Azure Active Directory と呼ばれていました) などの ID プロバイダーを IAM アイデンティティセンターと統合すると、組織内のユーザーは、シングルサインオンエクスペリエンスを使用してデータにアクセスできるようになります。IAM アイデンティティセンターは、追加のサードパーティ ID プロバイダーとの接続もサポートしています。 詳細については、「 AWS IAM アイデンティティセンター ユーザーガイド[」の「サポートされている ID プロバイダー](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)」を参照してください。 IAM Identity Center では、 を有効なアプリケーション AWS Lake Formation として設定でき、データレイク管理者は AWS Glue Data Catalog リソースの承認されたユーザーとグループにきめ細かなアクセス許可を付与できます。 組織のユーザーは、組織の ID プロバイダーを使用してアイデンティティセンター対応アプリケーションにサインインし、Lake Formation 許可を適用してデータセットにクエリを実行できます。この統合により、複数の IAM ロールを作成することなく、 AWS サービスへのアクセスを管理できます。 [信頼できる ID 伝達](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html)は、接続された の管理者がサービスデータへのアクセスを許可および監査するために AWS のサービス 使用できる AWS IAM アイデンティティセンター 機能です。このデータへのアクセスは、グループの関連付けなどのユーザー属性に基づいています。信頼できる ID 伝達を設定するには、接続されている の管理者 AWS のサービス と IAM Identity Center の管理者間のコラボレーションが必要です。詳細については、「[Prerequisites and considerations](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html)」を参照してください。 制限事項については、「[IAM アイデンティティセンター 統合の制限事項](identity-center-lf-notes.md)」を参照してください。 **Topics** + [IAM アイデンティティセンターを Lake Formation と統合するための前提条件](prerequisites-identity-center.md) + [Lake Formation と IAM アイデンティティセンターとの接続](connect-lf-identity-center.md) + [IAM アイデンティティセンター統合の更新](update-lf-identity-center-connection.md) + [IAM アイデンティティセンターとの Lake Formation 統合の削除](delete-lf-identity-center-connection.md) + [ユーザーおよびグループへのアクセス許可の付与](grant-permissions-sso.md) + [CloudTrail ログへの IAM アイデンティティセンターのユーザーコンテキストの追加](identity-center-ct-logs.md) # IAM アイデンティティセンターを Lake Formation と統合するための前提条件 IAM アイデンティティセンターを Lake Formation と統合するための前提条件は次のとおりです。 1. IAM アイデンティティセンターを有効にする — IAM アイデンティティセンターを有効にすることは、認証と ID の伝播をサポートするための前提条件です。 1. ID ソースを選択する — IAM アイデンティティセンターを有効にしたら、ユーザーとグループを管理する ID プロバイダーが必要になります。組み込まれているアイデンティティセンターディレクトリをアイデンティティソースとして使用することも、Microsoft Entra ID や Okta などの外部 IdP を使用することもできます。 詳細については、「 AWS IAM アイデンティティセンター ユーザーガイド」の[「ID ソースの管理](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)」および[「外部 ID プロバイダーへの接続](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)」を参照してください。 1. IAM ロールを作成する — IAM アイデンティティセンター接続を作成するロールには、以下のインラインポリシーのように、Lake Formation と IAM アイデンティティセンターでアプリケーション設定を作成および変更するアクセス許可が必要です。 IAM のベストプラクティスに従ってアクセス許可を追加する必要があります。特定のアクセス許可については、以降の手順で詳しく説明します。詳細については、「[IAM アイデンティティセンターの開始方法](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html)」を参照してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:CreateLakeFormationIdentityCenterConfiguration", "sso:CreateApplication", "sso:PutApplicationAssignmentConfiguration", "sso:PutApplicationAuthenticationMethod", "sso:PutApplicationGrant", "sso:PutApplicationAccessScope" ], "Resource": [ "*" ] } ] } ``` ------ Data Catalog リソースを外部 AWS アカウント または組織と共有する場合は、リソース共有を作成するための AWS Resource Access Manager (AWS RAM) アクセス許可が必要です。リソースの共有に必要なアクセス許可の詳細については、「[クロスアカウントデータ共有の一般的な要件](cross-account-prereqs.md)」を参照してください。 以下のインラインポリシーには、Lake Formation と IAM アイデンティティセンターの統合のプロパティを表示、更新、削除するために必要な特定の権限が含まれています。 + 以下のインラインポリシーを使用して、IAM ロールで Lake Formation と IAM アイデンティティセンターの統合を表示できるようにします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:DescribeLakeFormationIdentityCenterConfiguration", "sso:DescribeApplication" ], "Resource": [ "*" ] } ] } ``` ------ + 以下のインラインポリシーを使用して、IAM ロールで Lake Formation と IAM アイデンティティセンターの統合を更新できるようにします。このポリシーには、外部アカウントとリソースを共有するために必要なオプションのアクセス許可も含まれています。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:UpdateLakeFormationIdentityCenterConfiguration", "lakeformation:DescribeLakeFormationIdentityCenterConfiguration", "sso:DescribeApplication", "sso:UpdateApplication" ], "Resource": [ "*" ] } ] } ``` ------ + 以下のインラインポリシーを使用して、IAM ロールで Lake Formation と IAM アイデンティティセンターの統合を削除できるようにします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:DeleteLakeFormationIdentityCenterConfiguration", "sso:DeleteApplication" ], "Resource": [ "*" ] } ] } ``` ------ + IAM アイデンティティセンターのユーザーとグループにデータレイクのアクセス許可を付与または取り消すために必要な IAM アクセス許可については、「[Lake Formation 許可の付与と取り消しに必要な IAM 許可](required-permissions-for-grant.md)」を参照してください。 *アクセス許可の説明* + `lakeformation:CreateLakeFormationIdentityCenterConfiguration` – Lake Formation IdC 設定を作成します。 + `lakeformation:DescribeLakeFormationIdentityCenterConfiguration` – 既存の IdC 設定について説明します。 + `lakeformation:DeleteLakeFormationIdentityCenterConfiguration` – 既存のLake Formation IdC 設定を削除できます。 + `lakeformation:UpdateLakeFormationIdentityCenterConfiguration` – 既存のLake Formation 設定を変更するために使用されます。 + `sso:CreateApplication` – IAM アイデンティティセンターのアプリケーションを作成するために使用されます。 + `sso:DeleteApplication` – IAM アイデンティティセンターのアプリケーションを削除するために使用されます。 + `sso:UpdateApplication` – IAM アイデンティティセンターのアプリケーションの更新に使用されます。 + `sso:PutApplicationGrant` – 信頼できるトークン発行者の情報を変更するために使用されます。 + `sso:PutApplicationAuthenticationMethod` – Lake Formation 認証アクセスを許可します。 + `sso:GetApplicationGrant` – 信頼できるトークン発行者の情報を一覧表示するために使用されます。 + `sso:DeleteApplicationGrant` – 信頼できるトークン発行者の情報を削除します。 + `sso:PutApplicationAccessScope` – アプリケーションの IAM アイデンティティセンターアクセススコープの承認済みターゲットのリストを追加または更新します。 + `sso:PutApplicationAssignmentConfiguration` – ユーザーがアプリケーションにアクセスする方法を設定するために使用されます。 # Lake Formation と IAM アイデンティティセンターとの接続 IAM アイデンティティセンターを使用して ID を管理し、Lake Formation を使用してデータカタログリソースへのアクセスを許可する前に、次の手順を完了する必要があります。Lake Formation コンソールまたは AWS CLIを使用して IAM アイデンティティセンター統合を作成できます。 ------ #### [ AWS マネジメントコンソール ] **Lake Formation を IAM アイデンティティセンターと接続するには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. 左側のナビゲーションペインで、**[IAM アイデンティティセンターの統合]** を選択します。 ![\[IAM アイデンティティセンターの統合画面とアイデンティティセンター ARN\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/identity-center-integ.png) 1. (オプション) 1 つ以上の AWS アカウント IDs、組織 IDs、組織単位 IDs を入力して、外部アカウントが Data Catalog リソースにアクセスできるようにします。IAM アイデンティティセンターのユーザーまたはグループが Lake Formation で管理されているデータカタログリソースにアクセスしようとすると、Lake Formation は IAM ロールを引き受けてメタデータアクセスを認可します。IAM ロールがリソースポリシーと AWS Glue リソース AWS RAM 共有を持たない外部アカウントに属している場合、IAM アイデンティティセンターのユーザーとグループは、Lake Formation アクセス許可があってもリソースにアクセスできません。 Lake Formation は AWS Resource Access Manager 、 (AWS RAM) サービスを使用して外部アカウントおよび組織とリソースを共有します。 は、リソース共有を承認または拒否するための招待を被付与者アカウント AWS RAM に送信します。 詳細については、「[からのリソース共有の招待の承諾 AWS RAM](accepting-ram-invite.md)」を参照してください。 **注記** Lake Formation は、データカタログリソースへのアクセスのために、外部アカウントの IAM ロールが IAM アイデンティティセンターのユーザーとグループに代わってキャリアロールとして動作することを許可しますが、アクセス許可を付与できるのは、所有アカウント内のデータカタログリソースに対してだけです。外部アカウント内のデータカタログリソースに対するアクセス許可を IAM アイデンティティセンターのユーザーとグループに付与しようとすると、Lake Formation から「Cross-account grants are not supported for the principal」というエラーがスローされます。 1. (オプション) **[Lake Formation 統合の作成]** 画面で、Lake Formation に登録された Amazon S3 ロケーションにあるデータにアクセスできるサードパーティアプリケーションの ARN を指定します。Lake Formation は、有効なアクセス許可に基づいて、スコープダウンされた一時的な認証情報を AWS STS トークンの形式で登録された Amazon S3 ロケーションに提供し、承認されたアプリケーションがユーザーに代わってデータにアクセスできるようにします。 1. (オプション) **Lake Formation 統合の作成**画面で、Trusted Identity Propagation の Amazon Redshift Connect チェックボックスをオンにして、IDC を介した Amazon Redshift フェデレーティッドアクセス許可の検出を有効にします。Lake Formation は、有効なアクセス許可に基づいて ID をダウンストリームに伝播するため、承認されたアプリケーションはユーザーに代わってデータにアクセスできます。 1. **[送信]** を選択します。 Lake Formation 管理者が手順を完了して統合を作成すると、IAM アイデンティティセンターのプロパティが Lake Formation コンソールに表示されます。上記のタスクを完了すると、Lake Formation は IAM アイデンティティセンター対応アプリケーションになります。コンソールのプロパティには統合ステータスが含まれます。統合が完了すると、統合ステータスに `Success` と表示されます。このステータスは IAM アイデンティティセンターの設定が完了したかどうかを示します。 ------ #### [ AWS CLI ] + 次の例は、IAM アイデンティティセンターとの Lake Formation 統合を作成する方法を示しています。アプリケーションの `Status` (`ENABLED`、`DISABLED`) を指定することもできます。 ``` aws lakeformation create-lake-formation-identity-center-configuration \ --catalog-id <123456789012> \ --instance-arn \ --share-recipients '[{"DataLakePrincipalIdentifier": "<123456789012>"}, {"DataLakePrincipalIdentifier": "<555555555555>"}]' \ --external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}' ``` + 次の例は、IAM アイデンティティセンターとの Lake Formation 統合を表示する方法を示しています。 ``` aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012> ``` + 次の例は、`Redshift:Connect`認可を有効にする方法を示しています。認可は ENABLED または DISABLED にすることができます。 ``` aws lakeformation create-lake-formation-identity-center-configuration \ --instance-arn \ --service-integrations '[{ "Redshift": [{ "RedshiftConnect": { "Authorization": "ENABLED" } }] }]' ``` + `describe-lake-formation-identity-center-configuration` コマンドを使用して、レイクフォーメーションアイデンティティセンターアプリケーションを記述します。`Redshift:Connect`サービス統合は、クロスサービスおよびクラスター間の IdC ID の伝播に不可欠です。 ``` aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012> ``` レスポンス: ``` { "CatalogId": "CATALOG ID", "InstanceArn": "INSTANCE ARN", "ApplicationArn": "APPLICATION ARN", "ShareRecipients": [], "ServiceIntegrations": [ { "Redshift": [ { "RedshiftConnect": { "Authorization": "ENABLED" } } ] } ] } ``` ------ ## 複数の で IAM Identity Center を使用する AWS リージョン Lake Formation は、複数の で IAM Identity Center をサポートしています AWS リージョン。IAM アイデンティティセンターをプライマリリージョンから追加のリージョン AWS リージョン に拡張して、ユーザーと信頼性に近接することでパフォーマンスを向上させることができます。IAM アイデンティティセンターに新しいリージョンが追加されると、プライマリリージョンの ID をレプリケートすることなく、新しいリージョンに Lake Formation アイデンティティセンターアプリケーションを作成できます。複数のリージョンで IAM アイデンティティセンターの使用を開始する方法の詳細については、[IAM アイデンティティセンターユーザーガイドの「マルチリージョン](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html) *IAM アイデンティティセンター*」を参照してください。 # IAM アイデンティティセンター統合の更新 接続を作成したら、IAM アイデンティティセンター統合のサードパーティのアプリケーションを追加して Lake Formation と統合し、ユーザーに代わって Amazon S3 データにアクセスできるようになります。既存のアプリケーションを IAM アイデンティティセンター統合から削除することもできます。Lake Formation コンソール、および [UpdateLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_UpdateLakeFormationIdentityCenterConfiguration.html) オペレーションを使用して AWS CLI、アプリケーションを追加または削除できます。 **注記** IAM アイデンティティセンター統合を作成した後は、インスタンスの `ARN` を更新することはできません。 ------ #### [ AWS マネジメントコンソール ] **Lake Formation との既存の IAM アイデンティティセンターの接続を更新するには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. 左側のナビゲーションペインで、**[IAM アイデンティティセンターの統合]** を選択します。 1. **[IAM アイデンティティセンターの統合]** ページで **[追加]** を選択します。 1. 1 つ以上の AWS アカウント IDs、組織 IDs、組織単位 IDs を入力して、外部アカウントが Data Catalog リソースにアクセスできるようにします。 1. **[アプリケーションの追加]** 画面で、Lake Formation と統合するサードパーティアプリケーションのアプリケーション ID を入力します。 1. **[追加]** を選択します。 1. (Optioanlly) **IAM Identity Center 統合**ページで、Amazon Redshift 接続の信頼できる ID 伝達を有効にするか、無効にすることができます。Lake Formation は、有効なアクセス許可に基づいて ID をダウンストリームに伝播するため、承認されたアプリケーションはユーザーに代わってデータにアクセスできます。 ------ #### [ AWS CLI ] 次の AWS CLI コマンドを実行して、IAM Identity Center 統合用のサードパーティーアプリケーションを追加または削除できます。外部フィルタリングステータスを `ENABLED` に設定すると、IAM アイデンティティセンターで、Lake Formation によって管理されるデータにアクセスするためのサードパーティのアプリケーションの ID 管理を提供できるようになります。また、アプリケーションステータスを設定することで、IAM アイデンティティセンター統合を有効または無効にすることもできます。 ``` aws lakeformation update-lake-formation-identity-center-configuration \ --external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'\ --share-recipients '[{"DataLakePrincipalIdentifier": "<444455556666>"} {"DataLakePrincipalIdentifier": "<777788889999>"}]' \ --application-status ENABLED ``` 既存の LF IDC アプリケーションがあり、`Redshift:Connect`認可を追加する場合は、以下を使用して Lake Formation IDC アプリケーションを更新できます。認可は ENABLED または DISABLED にすることができます。 ``` aws lakeformation update-lake-formation-identity-center-configuration \ --service-integrations '[{ "Redshift": [{ "RedshiftConnect": { "Authorization": "ENABLED" } }] }]' ``` ------ # IAM アイデンティティセンターとの Lake Formation 統合の削除 既存の IAM Identity Center 統合を削除する場合は、Lake Formation コンソール AWS CLI、または [DeleteLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DeleteLakeFormationIdentityCenterConfiguration.html) オペレーションを使用して削除できます。 ------ #### [ AWS マネジメントコンソール ] **Lake Formation との既存の IAM アイデンティティセンターの接続を削除するには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. 左側のナビゲーションペインで、**[IAM アイデンティティセンターの統合]** を選択します。 1. **[IAM アイデンティティセンターの統合]** ページで **[削除]** を選択します。 1. **[統合の確認]** 画面でアクションを確認し、**[削除]** を選択します。 ------ #### [ AWS CLI ] IAM Identity Center の統合を削除するには、次の AWS CLI コマンドを実行します。 ``` aws lakeformation delete-lake-formation-identity-center-configuration \ --catalog-id <123456789012> ``` ------ # ユーザーおよびグループへのアクセス許可の付与 データレイク管理者は、データカタログリソース (データベース、テーブル、ビュー) について IAM アイデンティティセンターのユーザーとグループにアクセス許可を付与できます。これにより、データに簡単にアクセスできるようになります。データレイクのアクセス許可を付与または取り消すには、付与者に次の IAM アイデンティティセンターアクションに対するアクセス許可が必要です。 + [DescribeUser](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeUser.html) + [DescribeGroup](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeGroup.html) + [DescribeInstance](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_DescribeInstance.html) 許可は、Lake Formation コンソール、API、または AWS CLIを使用して付与することができます。 許可の付与の詳細については、「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」を参照してください。 **注記** アクセス許可は、アカウント内のリソースに対してのみ付与できます。共有されているリソースのユーザーとグループに許可をカスケードするには、 AWS RAM リソース共有を使用する必要があります。 ------ #### [ AWS マネジメントコンソール ] **ユーザーおよびグループにアクセス許可を付与するには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. Lake Formation コンソールの **[許可]** で **[データレイクのアクセス許可]** を選択します。 1. **[付与]** を選択します。 1. **[データレイクのアクセス許可の付与]** ページで、**[IAM アイデンティティセンター]** のユーザーとグループを選択します。 1. **[追加]** を選択して、許可を付与するユーザーとグループを選択します。 ![\[IAM アイデンティティセンターセンターのユーザーとグループが選択された [データレイクのアクセス許可の付与] 画面。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/identity-center-grant-perm.png) 1. **[ユーザーとグループの割り当て]** 画面で、許可を付与するユーザーやグループを選択します。 **[割り当て]** を選択します。 ![\[IAM アイデンティティセンターセンターのユーザーとグループが選択された [データレイクのアクセス許可の付与] 画面。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/identity-center-assign-users-groups.png) 1. 次に、許可を付与する方法を選択します。 名前付きリソース方式を使用して許可を付与する手順については、「[名前付きリソース方式を使用したデータアクセス許可の付与](granting-cat-perms-named-resource.md)」を参照してください。 LF タグを使用して許可を付与する手順については、「[LF-TBAC 方式を使用したデータレイク許可の付与](granting-catalog-perms-TBAC.md)」を参照してください。 1. 許可を付与するデータカタログリソースを選択します。 1. 付与するデータカタログのアクセス許可を選択します。 1. **[付与]** を選択します。 ------ #### [ AWS CLI ] 次の例は、テーブルに対する `SELECT` 許可を IAM アイデンティティセンターユーザーに付与する方法を示しています。 ``` aws lakeformation grant-permissions \ --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ \ --permissions "SELECT" \ --resource '{ "Table": { "DatabaseName": "retail", "TableWildcard": {} } }' ``` IAM アイデンティティセンターから `UserId` を取得するには、「IAM アイデンティティセンター API リファレンス」で [GetUserId](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html) オペレーションを参照してください。 ------ # CloudTrail ログへの IAM アイデンティティセンターのユーザーコンテキストの追加 Lake Formation では、[認証情報の供給](using-cred-vending.md)を使用して Amazon S3 データへの一時的なアクセスを提供します。統合された分析サービスに IAM アイデンティティセンターユーザーがクエリを送信した場合、デフォルトで CloudTrail ログには、サービスが短期間のアクセスを提供するために引き受けた IAM ロールのみが記録されます。ユーザー定義ロールを使用して Amazon S3 データロケーションを Lake Formation に登録すると、CloudTrail イベントに IAM アイデンティティセンターユーザーのコンテキストを含めるようにオプトインし、リソースにアクセスするユーザーを追跡できます。 **重要** オブジェクトレベルの Amazon S3 API リクエストを CloudTrail に含めるには、Amazon S3 バケットとオブジェクトの CloudTrail イベントログを有効にする必要があります。詳細については、「Amazon S3 ユーザーガイド」の「[S3 バケットとオブジェクトの CloudTrail イベントログ記録の有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)」を参照してください。 **ユーザー定義ロールを使用して登録されたデータレイクロケーションで認証情報供給の監査を有効にするには** 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) にサインインします。 1. 左側のナビゲーションで、**[管理]** を展開し、**[データカタログの設定]** を選択します。 1. **[拡張監査]** で、**[提供されたコンテキストを伝播]** を選択します。 1. **[保存]** を選択します。 拡張監査オプションは、[PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html) オペレーションで `Parameters` 属性を設定することでも有効にできます。デフォルトでは、`SET_CONTEXT"` パラメータの値は「true」に設定されます。 ``` { "DataLakeSettings": { "Parameters": {"SET_CONTEXT": "true"}, } } ``` 以下は、拡張監査オプションを有効にした場合の CloudTrail イベントからの抜粋です。このログには、IAM アイデンティティセンターユーザーのセッションコンテキストと、Amazon S3 データロケーションにアクセスするために Lake Formation によって引き受けられたユーザー定義の IAM ロールの両方が含まれています。以下の抜粋の `onBehalfOf` パラメーターを参照してください。 ``` { "eventVersion":"1.09", "userIdentity":{ "type":"AssumedRole", "principalId":"AROAW7F7MOX4OYE6FLIFN:access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab", "arn":"arn:aws:sts::123456789012:assumed-role/accessGrantsTestRole/access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab", "accountId":"123456789012", "accessKeyId":"ASIAW7F7MOX4CQLD4JIZN", "sessionContext":{ "sessionIssuer":{ "type":"Role", "principalId":"AROAW7F7MOX4OYE6FLIFN", "arn":"arn:aws:iam::123456789012:role/accessGrantsTestRole", "accountId":"123456789012", "userName":"accessGrantsTestRole" }, "attributes":{ "creationDate":"2023-08-09T17:24:02Z", "mfaAuthenticated":"false" } }, "onBehalfOf":{ "userId": "", "identityStoreArn": "arn:aws:identitystore::" } }, "eventTime":"2023-08-09T17:25:43Z", "eventSource":"s3.amazonaws.com", "eventName":"GetObject", .... ``` # データレイクへの Amazon S3 ロケーションの追加 データロケーションをデータレイクのストレージとして追加するには、そのロケーション (**データレイクの場所) ***を登録*します AWS Lake Formation。その後、Lake Formation アクセス許可を使用して、この場所を指す AWS Glue Data Catalog オブジェクトと、その場所の基盤となるデータへのきめ細かなアクセスコントロールを行うことができます。 また、Lake Formation では、ハイブリッドアクセスモードでデータロケーションを登録でき、Data Catalog 内のデータベースとテーブルに対して Lake Formation 許可を選択的に有効にできる柔軟性があります。ハイブリッドアクセスモードでは、増分パスにより、他の既存のユーザーやワークロードのアクセス許可ポリシーを中断することなく、特定のユーザーのセットに Lake Formation アクセス許可を設定できます。 ハイブリッドアクセスモードアクセスの詳細については、「[ハイブリッドアクセスモード](hybrid-access-mode.md)」を参照してください。 ロケーションを登録すると、その Amazon S3 パスと、そのパスの下にあるすべてのフォルダが登録されます。 例えば、以下のような Amazon S3 パス組織があるとします。 `/mybucket/accounting/sales/` `S3://mybucket/accounting` を登録すると、`sales` フォルダも登録され、Lake Formation の管理下に置かれます。 ロケーションの登録に関する詳細については、「[Underlying data access control](access-control-underlying-data.md#underlying-data-access-control)」を参照してください。 **注記** Lake Formation 許可は、構造化データ (行と列がある表にまとめられたデータ) が推奨されます。データにオブジェクトベースの非構造化データが含まれている場合は、Amazon S3 Access Grants を使用してデータアクセスを管理することを検討してください。 **Topics** + [ロケーションの登録に使用されるロールの要件](registration-role.md) + [Amazon S3 ロケーションの登録](register-location.md) + [暗号化された Amazon S3 ロケーションの登録](register-encrypted.md) + [別の AWS アカウントでの Amazon S3 ロケーションの登録](register-cross-account.md) + [AWS アカウント間で暗号化された Amazon S3 の場所を登録する](register-cross-encrypted.md) + [Amazon S3 ロケーションの登録解除](unregister-location.md) # ロケーションの登録に使用されるロールの要件 Amazon Simple Storage Service AWS Identity and Access Management (Amazon S3) の場所を登録するときは、 (IAM) ロールを指定する必要があります。 はその場所のデータにアクセスするときにそのロールを AWS Lake Formation 引き受けます。 ロケーションは、以下のロールタイプのいずれかを使用して登録できます。 + Lake Formation サービスリンクロール。このロールは、ロケーションに対する必要な許可を付与します。このロールの使用は、ロケーションを登録する最もシンプルな方法です。詳細については、「[Lake Formation のサービスリンクロールの使用](service-linked-roles.md)」および「[サービスにリンクされたロールの制限](service-linked-role-limitations.md)」を参照してください。 + ユーザー定義のロール。ユーザー定義のロールは、サービスリンクロールが提供する許可よりも多くの許可を付与する必要があるときに使用します。 以下の状況では、ユーザー定義のロールを使用する必要があります。 + 別のアカウントにあるロケーションを登録する場合。 詳細については、「[別の AWS アカウントでの Amazon S3 ロケーションの登録](register-cross-account.md)」および「[AWS アカウント間で暗号化された Amazon S3 の場所を登録する](register-cross-encrypted.md)」を参照してください。 + AWS マネージド CMK (`aws/s3`) を使用して Amazon S3 の場所を暗号化した場合。 詳細については、「[暗号化された Amazon S3 ロケーションの登録](register-encrypted.md)」を参照してください。 + Amazon EMR を使用してロケーションにアクセスする予定の場合。 サービスリンクロールを使用してロケーションをすでに登録しており、Amazon EMR を使用したロケーションへのアクセスを開始したいという場合は、ロケーションの登録を解除してから、ユーザー定義のロールを使用して再度登録する必要があります。詳細については、「[Amazon S3 ロケーションの登録解除](unregister-location.md)」を参照してください。 # Lake Formation のサービスリンクロールの使用 AWS Lake Formation は AWS Identity and Access Management (IAM) *サービスにリンクされたロール*を使用します。サービスリンクロールは、Lake Formation に直接リンクされた特殊なタイプの IAM ロールです。サービスにリンクされたロールは Lake Formation によって事前定義されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。 ロールを作成して必要な許可を手動で追加する必要がないため、サービスリンクロールは Lake Formation のセットアップを容易にします。サービスリンクロールの許可は Lake Formation が定義し、別途定義されている場合を除いて、Lake Formation のみがそのロールを引き受けることができます。定義された許可には信頼ポリシーと許可ポリシーが含まれ、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。 このサービスリンクロールは、ロールの引き受けについて以下のサービスを信頼します。 + `lakeformation.amazonaws.com` アカウント A のサービスリンクロールを使用して、アカウント B が所有する Amazon S3 ロケーションを登録する場合は、アカウント B の Amazon S3 バケットポリシー (リソースベースのポリシー) で、アカウント A のサービスリンクロールにアクセス許可を付与する必要があります。 サービスリンクロールを使用してデータの場所を登録する方法については、「[サービスにリンクされたロールの制限](service-linked-role-limitations.md)」を参照してください。 **注記** サービスリンクロールは、サービスコントロールポリシー (SCP) の影響を受けません。 詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。 ## Lake Formation のサービスリンクロールの許可 Lake Formation は、`AWSServiceRoleForLakeFormationDataAccess` という名前のサービスリンクロールを使用します。このロールは、Lake Formation 統合サービス ( など) が登録済みロケーションにアクセスできるようにする Amazon Simple Storage Service (Amazon S3 Amazon Athena) アクセス許可のセットを提供します。データレイクロケーションを登録するときは、そのロケーションに対する必要な Amazon S3 読み取り/書き込み許可を持つロールを指定する必要があります。ユーザーは、必要な Amazon S3 許可を持つロールを作成する代わりに、このサービスリンクロールを使用することができます。 パスを登録するためのロールとしてサービスリンクロールを初めて指定すると、ユーザーに代わってサービスリンクロールと新しい IAM ポリシーが作成されます。Lake Formation がインラインポリシーにそのパスを追加し、ポリシーをサービスリンクロールにアタッチします。サービスリンクロールに後続のパスを登録すると、Lake Formation がそのパスを既存のポリシーに追加します。 データレイク管理者としてサインインしているときに、データレイクロケーションを登録します。次に、IAM コンソールで `AWSServiceRoleForLakeFormationDataAccess` ロールを検索し、アタッチされたポリシーを確認します。 例えば、`s3://my-kinesis-test/logs` のロケーションを登録すると、Lake Formation が以下のインラインポリシーを作成し、`AWSServiceRoleForLakeFormationDataAccess` にアタッチします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccessPermissionsForS3", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::my-kinesis-test/logs/*" ] }, { "Sid": "LakeFormationDataAccessPermissionsForS3ListBucket", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::my-kinesis-test" ] } ] } ``` ------ ## Lake Formation のサービスリンクロールの作成 サービスリンクロールを手動で作成する必要はありません。Amazon S3 ロケーションを AWS マネジメントコンソール、、 AWS CLIまたは AWS API で Lake Formation に登録すると、Lake Formation によってサービスにリンクされたロールが作成されます。 **重要** このサービスリンクロールは、このロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。詳細については、[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)を参照してください。 このサービスリンクロールを削除した後で再度作成する必要が生じた場合は、同じ手順でアカウントにロールを再作成できます。Amazon S3 ロケーションを Lake Formation に登録すると、Lake Formation によってサービスリンクロールが再度作成されます。 IAM コンソールを使用して、**Lake Formation** ユースケースでサービスリンクロールを作成することもできます。 AWS CLI または AWS API で、サービス名を使用して`lakeformation.amazonaws.com`サービスにリンクされたロールを作成します。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。 ## Lake Formation のサービスリンクロールの編集 Lake Formation では、`AWSServiceRoleForLakeFormationDataAccess` サービスリンクロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。 ## Lake Formation のサービスリンクロールの削除 サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、積極的にモニタリングまたは保守されていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンクロールのリソースをクリーンアップする必要があります。 **注記** リソースを削除しようとしたときに Lake Formation サービスでロールが使用されていると、削除に失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。 **Lake Formation で使用されている Lake Formation リソースを削除するには** + サービスリンクロールを使用して Amazon S3 ロケーションを Lake Formation に登録した場合は、サービスリンクロールを削除する前に、そのロケーションを登録解除し、カスタムロールを使用して再登録する必要があります。 **サービスリンクロールを IAM で手動削除するには** IAM コンソール、 AWS CLI、または AWS API を使用して、`AWSServiceRoleForLakeFormationDataAccess`サービスにリンクされたロールを削除します。詳細については、*IAM ユーザーガイド*の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。 以下は、ユーザー定義のロールの要件です。 + 新しいロールを作成するときは、IAM コンソールの **[ロールの作成]** ページで **[AWS のサービス]** を選択してから、**[ユースケースの選択]** で **[Lake Formation]** を選択します。 別のパスを使用してロールを作成する場合は、そのロールに `lakeformation.amazonaws.com` との信頼関係があることを確認します。詳細については、「[ロール信頼ポリシーの更新 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)」を参照してください。 + ロールには、ロケーションに対する Amazon S3 の読み取り/書き込み許可を付与するインラインポリシーが必要です。以下は典型的なポリシーです。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::awsexamplebucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::awsexamplebucket" ] } ] } ``` ------ + Lake Formation サービスでロールを引き受け、統合された分析エンジンに一時的な認証情報を提供できるようにするには、IAM ロールに次の信頼ポリシーを追加します。 CloudTrail ログに IAM アイデンティティセンターのユーザーコンテキストを含めるには、信頼ポリシーに `sts:SetContext` アクションのアクセス許可が必要です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerAssumeRole1", "Effect": "Allow", "Principal": { "Service": [ "lakeformation.amazonaws.com" ] }, "Action": [ "sts:AssumeRole", "sts:SetContext" ] } ] } ``` ------ + ロケーションを登録するデータレイク管理者は、ロールに対する `iam:PassRole` 許可を持っている必要があります。 以下は、この許可を付与するインラインポリシーです。** を有効な AWS アカウント番号に置き換え、** をロールの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PassRolePermissions", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/" ] } ] } ``` ------ + Lake Formation が CloudWatch Logs にログを追加し、メトリクスを発行できるようにするには、以下のインラインポリシーを追加します。 **注記** CloudWatch Logs への書き込みには料金が発生します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Sid1", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*:log-stream:*" ] } ] } ``` ------ # Amazon S3 ロケーションの登録 Amazon Simple Storage Service AWS Identity and Access Management (Amazon S3) ロケーションを登録するときは、(IAM) ロールを指定する必要があります。Lake Formation は、その場所のデータにアクセスする統合 AWS サービスに一時的な認証情報を付与するときに、そのロールを引き受けます。 **重要** **[Requester pays]** (リクエスタ支払い) が有効になっている Amazon S3 バケットの登録は避けてください。Lake Formation に登録されたバケットの場合、バケットの登録に使用されるロールは常にリクエスト元であると見なされます。バケットが別の AWS アカウントからアクセスされた場合、ロールがバケット所有者と同じアカウントに属している場合、バケット所有者はデータアクセスに対して課金されます。 AWS Lake Formation コンソール、Lake Formation API、または AWS Command Line Interface (AWS CLI) を使用して Amazon S3 の場所を登録できます。 **[開始する前に]** 「[ロケーションの登録に使用されるロールの要件](registration-role.md)」を確認してください。 **ロケーションを登録する (コンソール)** **重要** 次の手順では、Amazon S3 の場所がデータカタログと同じ AWS アカウントにあり、その場所のデータが暗号化されていないことを前提としています。クロスアカウント登録と暗号化されたロケーションの登録については、本章の他のセクションで説明されています。 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者、または `lakeformation:RegisterResource` IAM 許可を持つユーザーとしてサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. **[Register location]** (ロケーションを登録) を選択してから、**[Browse]**(参照) を選択して Amazon Simple Storage Service (Amazon S3) パスを選択します。 1. (強く推奨されるオプション) **[ロケーションのアクセス許可のレビュー]** を選択して、選択した Amazon S3 ロケーションにあるすべての既存のリソースおよびアクセス許可のリストを確認します。 選択されたロケーションの登録により、Lake Formation ユーザーがそのロケーションにすでに存在するデータにアクセスできるようになる可能性があります。このリストの確認は、既存のデータのセキュリティが確保されていることを確実にするために役立ちます。 1. **[IAM role]** (IAMロール) には、`AWSServiceRoleForLakeFormationDataAccess` サービスリンクロール (デフォルト)、または「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たすカスタム IAM ロールを選択します。 登録したロケーションやその他の詳細を更新できるのは、カスタム IAM ロールを使用して登録した場合のみです。サービスにリンクされたロールを使用して登録したロケーションを編集するには、ロケーションの登録を解除して再度登録する必要があります。 1. **データカタログフェデレーションを有効にする**オプションを選択して、Lake Formation がロールを引き受け、統合 AWS サービスに一時的な認証情報を提供してフェデレーションデータベースのテーブルにアクセスできるようにします。ロケーションが Lake Formation に登録されていて、フェデレーションデータベースのテーブルにも同じロケーションを使用する場合は、同じロケーションを **[Data Catalog フェデレーションを有効にする]** オプションで登録する必要があります。 1. Lake Formation 許可をデフォルトで有効にしない場合は、**[ハイブリッドアクセスモード]** を選択します。Amazon S3 ロケーションをハイブリッドアクセスモードで登録すると、そのロケーションにあるデータベースとテーブルのプリンシパルをオプトインすることで、Lake Formation 許可を有効にできます。
 ハイブリッドアクセスモードアクセスの設定の詳細については、「[ハイブリッドアクセスモード](hybrid-access-mode.md)」を参照してください。 1. **[ロケーションを登録]** を選択します。 **ロケーションを登録するには (AWS CLI)** 1. **新しいロケーションを Lake Formation に登録します。** この例では、サービスにリンクされたロールを使用してロケーションを登録します。その代わりに `--role-arn` 引数を使用して、独自のロールを提供することができます。 ** を有効な Amazon S3 パスに、アカウント番号を有効な AWS アカウントに置き換え、** をデータロケーションを登録する権限を持つ IAM ロールに置き換えます。 **注記** ロケーションの登録にサービスにリンクされたロールを使用した場合、登録したロケーションのプロパティは編集できません。 ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --use-service-linked-role ``` 次の例では、カスタムロールを使用してロケーションを登録します。 ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ ``` 1. **Lake Formation に登録したロケーションを更新するには** 登録したロケーションは、カスタム IAM ロールを使用して登録している場合にのみ編集できます。サービスにリンクされたロールに登録されているロケーションについては、ロケーションの登録を解除してから再度登録する必要があります。詳細については、「[Amazon S3 ロケーションの登録解除](unregister-location.md)」を参照してください。 ``` aws lakeformation update-resource \ --role-arn arn:aws:iam::<123456789012>:role/\ --resource-arn arn:aws:s3::: ``` ``` aws lakeformation update-resource \ --resource-arn arn:aws:s3::: \ --use-service-linked-role ``` 1. **ハイブリッドアクセスモードでデータロケーションをフェデレーションに登録します。** ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --hybrid-access-enabled ``` ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --with-federation ``` ``` aws lakeformation update-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --hybrid-access-enabled ``` 詳細については、「[RegisterResource](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_RegisterResource.html)」を参照してください。 **注記** Amazon S3 ロケーションを登録すると、そのロケーション (またはその子ロケーション) を指す AWS Glue テーブルは、`GetTable`呼び出し`true`のように `IsRegisteredWithLakeFormation`パラメータの値を返します。`GetTables` および `SearchTables` などの Data Catalog API 操作が `IsRegisteredWithLakeFormation` パラメータの値を更新せず、デフォルト値の false を返すという既知の制限があります。`IsRegisteredWithLakeFormation` パラメータの正しい値を表示するには、`GetTable` API を使用することが推奨されます。 # 暗号化された Amazon S3 ロケーションの登録 Lake Formation は [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS) と統合して、Amazon Simple Storage Service (Amazon S3) ロケーションにあるデータの暗号化と復号化を行うために、他の統合サービスをより簡単にセットアップできるようにします。 カスタマー管理 AWS KMS keys と の両方 AWS マネージドキー がサポートされています。現在、クライアント側の暗号化/復号は Athena でのみサポートされています。 Amazon S3 ロケーションを登録するときは、 AWS Identity and Access Management (IAM) ロールを指定する必要があります。 Amazon S3 暗号化された Amazon S3 の場所の場合、ロールには を使用してデータを暗号化および復号するアクセス許可が必要です。または AWS KMS key、KMS キーポリシーはキーに対するアクセス許可をロールに付与する必要があります。 **重要** **[Requester pays]** (リクエスタ支払い) が有効になっている Amazon S3 バケットの登録は避けてください。Lake Formation に登録されたバケットの場合、バケットの登録に使用されるロールは常にリクエスト元であると見なされます。バケットが別の AWS アカウントからアクセスされた場合、ロールがバケット所有者と同じアカウントに属している場合、バケット所有者はデータアクセスに対して課金されます。 Lake Formation は、サービスにリンクされたロールを使用してデータの場所を登録します。ただし、このロールにはいくつかの[制約](service-linked-role-limitations.md)があります。こうした制約があるため、柔軟性と制御性を高めるために、代わりにカスタム IAM ロールを作成して使用することをお勧めします。場所を登録するために作成するカスタムロールは、[ロケーションの登録に使用されるロールの要件](registration-role.md) で指定された要件を満たしている必要があります。 **重要** を使用して Amazon S3 の場所を AWS マネージドキー 暗号化した場合、Lake Formation サービスにリンクされたロールを使用することはできません。カスタムロールを使用して、キーに対する IAM 許可をロールに追加する必要があります。詳細については、このセクションで後ほど説明します。 以下の手順では、カスタマーマネージドキー、または AWS マネージドキーで暗号化された Amazon S3 ロケーションを登録する方法を説明します。 + [カスタマーマネージドキーで暗号化されたロケーションの登録](#proc-register-cust-cmk) + [で暗号化された場所の登録 AWS マネージドキー](#proc-register-aws-cmk) **開始する前に** 「[ロケーションの登録に使用されるロールの要件](registration-role.md)」を確認してください。 **カスタマーマネージドキーで暗号化された Amazon S3 ロケーションを登録する** **注記** KMS キーまたは Amazon S3 の場所がデータカタログと同じ AWS アカウントにない場合は、[AWS アカウント間で暗号化された Amazon S3 の場所を登録する](register-cross-encrypted.md)代わりに「」の手順に従います。 1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) で AWS KMS コンソールを開き、 AWS Identity and Access Management (IAM) 管理ユーザーとして、または場所の暗号化に使用される KMS キーのキーポリシーを変更できるユーザーとしてログインします。 1. ナビゲーションペインで **[カスタマーマネージドキー]** を選択してから、目的の KMS キーの名前を選択します。 1. KMS キーの詳細ページで **[キーポリシー]** タブを選択してから、以下のいずれかを行って、カスタムロールまたは Lake Formation サービスリンクロールを KMS キーユーザーとして追加します。 + **デフォルトビューが表示されている場合** (**キー管理者**、**キー削除**、**キーユーザー**、**その他の AWS アカウント**セクションを使用) – **キーユーザー**セクションで、カスタムロール または Lake Formation サービスにリンクされたロール を追加します`AWSServiceRoleForLakeFormationDataAccess`。 + **キーポリシー (JSON) が表示されている場合** – 以下の例にあるように、ポリシーを編集して、「Allow use of the key」オブジェクトにカスタムロールまたは Lake Formation サービスリンクロール (`AWSServiceRoleForLakeFormationDataAccess`) を追加します。 **注記** そのオブジェクトが欠落している場合は、例にある許可と共に追加してください。この例は、サービスリンクロールを使用しています。 ``` ... { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess", "arn:aws:iam::111122223333:user/keyuser" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, ... ``` 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者、または `lakeformation:RegisterResource` IAM 許可を持つユーザーとしてサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. **[Register location]** (ロケーションを登録) を選択してから、**[Browse]**(参照) を選択して Amazon Simple Storage Service (Amazon S3) パスを選択します。 1. (強く推奨されるオプション) **[Review location permissions]** (ロケーションの許可のレビュー) を選択して、選択された Amazon S3 ロケーションにあるすべての既存のリソースとそれらの許可のリストを確認します。 選択されたロケーションの登録により、Lake Formation ユーザーがそのロケーションにすでに存在するデータにアクセスできるようになる可能性があります。このリストの確認は、既存のデータのセキュリティが確保されていることを確実にするために役立ちます。 1. **[IAM role]** (IAMロール) には、`AWSServiceRoleForLakeFormationDataAccess` サービスリンクロール (デフォルト)、または「[ロケーションの登録に使用されるロールの要件](registration-role.md)」に適合するカスタム IAM ロールを選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 サービスリンクロールの詳細については、「[Lake Formation のサービスリンクロールの許可](service-linked-roles.md#service-linked-role-permissions)」を参照してください。 **で暗号化された Amazon S3 の場所を登録するには AWS マネージドキー** **重要** Amazon S3 の場所がデータカタログと同じ AWS アカウントにない場合は、[AWS アカウント間で暗号化された Amazon S3 の場所を登録する](register-cross-encrypted.md)代わりに「」の手順に従います。 1. ロケーションの登録に使用する IAM ロールを作成します。ロールが「[ロケーションの登録に使用されるロールの要件](registration-role.md)」に記載されている条件を満たすことを確認してください。 1. 以下のインラインポリシーをロールに追加します。これは、キーに対する許可をロールに付与します。`Resource` の仕様は、 AWS マネージドキーの Amazon リソースネーム (ARN) を指定する必要があります。ARN は AWS KMS コンソールから取得できます。正しい ARN を取得するには、場所の暗号化に AWS マネージドキー 使用された と同じ AWS アカウントとリージョンで AWS KMS コンソールにログインしてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } ] } ``` ------ キー ID の代わりに KMS キーエイリアスを使用できます - `arn:aws:kms:region:account-id:key/alias/your-key-alias` 詳細については、「 AWS Key Management Service デベロッパーガイド[」の「 セクションのエイリア AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html)ス」を参照してください。 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者、または `lakeformation:RegisterResource` IAM 許可を持つユーザーとしてサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. **[Register location]** (ロケーションを登録) を選択してから、**[Browse]**(参照) を選択して Amazon S3 パスを選択します。 1. (強く推奨されるオプション) **[Review location permissions]** (ロケーションの許可のレビュー) を選択して、選択された Amazon S3 ロケーションにあるすべての既存のリソースとそれらの許可のリストを確認します。 選択されたロケーションの登録により、Lake Formation ユーザーがそのロケーションにすでに存在するデータにアクセスできるようになる可能性があります。このリストの確認は、既存のデータのセキュリティが確保されていることを確実にするために役立ちます。 1. **[IAM role]** (IAM ロール) には、ステップ 1 で作成したロールを選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 # 別の AWS アカウントでの Amazon S3 ロケーションの登録 AWS Lake Formation では、 AWS アカウント間で Amazon Simple Storage Service (Amazon S3) ロケーションを登録できます。たとえば、 AWS Glue Data Catalog がアカウント A にある場合、アカウント A のユーザーはアカウント B に Amazon S3 バケットを登録できます。 AWS アカウント A の AWS Identity and Access Management (IAM) ロールを使用してアカウント B に AWS Amazon S3 バケットを登録するには、次のアクセス許可が必要です。 + アカウント A のロールが、アカウント B のバケットに対する許可を付与する必要があります。 + アカウント B のバケットポリシーが、アカウント A のロールにアクセス許可を付与する必要があります。 **重要** **[Requester pays]** (リクエスタ支払い) が有効になっている Amazon S3 バケットの登録は避けてください。Lake Formation に登録されたバケットの場合、バケットの登録に使用されるロールは常にリクエスト元であると見なされます。バケットが別の AWS アカウントからアクセスされた場合、ロールがバケット所有者と同じアカウントに属している場合、バケット所有者はデータアクセスに対して課金されます。 Lake Formation サービスリンクロールを使用して、別のアカウントにあるロケーションを登録することはできません。その代わりに、ユーザー定義のロールを使用する必要があります。このロールは、「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たす必要があります。サービスリンクロールの詳細については、「[Lake Formation のサービスリンクロールの許可](service-linked-roles.md#service-linked-role-permissions)」を参照してください。 **[開始する前に]** 「[ロケーションの登録に使用されるロールの要件](registration-role.md)」を確認してください。 **別の AWS アカウントでロケーションを登録するには** **注記** ロケーションが暗号化されている場合は、代わりに「[AWS アカウント間で暗号化された Amazon S3 の場所を登録する](register-cross-encrypted.md)」の手順を実行してください。 以下の手順は、Data Catalog が含まれるアカウント 1111-2222-3333 のプリンシパルが、アカウント 1234-5678-9012 にある Amazon S3 バケット `awsexamplebucket1` を登録したいという状況を前提としています。 1. アカウント 1111-2222-3333 で、 にサインイン AWS マネジメントコンソール し、 で IAM コンソールを開きます[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。 1. 新しいロールを作成するか、「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たす既存のロールを表示します。ロールが `awsexamplebucket1` に対する Amazon S3 許可を付与することを確認します。 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。アカウント 1234-5678-9012 でサインインします。 1. **[Bucket name]** (バケット名) リストで、`awsexamplebucket1` というバケット名を選択します。 1. **[Permissions]** (アクセス許可) を選択します。 1. **[Permissions]** (アクセス許可) ページで、**[Bucket Policy]** (バケットポリシー) を選択します。 1. **[Bucket policy editor]** (バケットポリシーエディタ) に、以下のポリシーを貼り付けます。** をロールの名前に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action":"s3:ListBucket", "Resource":"arn:aws:s3:::awsexamplebucket1" }, { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Resource":"arn:aws:s3:::awsexamplebucket1/*" } ] } ``` ------ 1. **[保存]** を選択します。 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者として、またはロケーションを登録するために十分な許可を持つユーザーとして、アカウント 1111-2222-3333 にサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. **[データレイクのロケーション]** ページで、**[ロケーションを登録]** を選択します。 1. **[Register location]** (ロケーションの登録) ページで、**[Amazon S3 path]** (Amazon S3 パス) にバケット名 `s3://awsexamplebucket1` を入力します。 **注記** クロスアカウントバケットは **[Browse]** (参照) を選択してもリストに表示されないため、バケット名を入力する必要があります。 1. **[IAM role]** (IAM ロール) でロールを選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 # AWS アカウント間で暗号化された Amazon S3 の場所を登録する AWS Lake Formation は [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS) と統合されているため、Amazon Simple Storage Service (Amazon S3) ロケーションでデータを暗号化および復号するための他の統合サービスをより簡単にセットアップできます。 カスタマーマネージドキーと の両方 AWS マネージドキー がサポートされています。クライアント側の暗号化/復号化はサポートされていません。 **重要** **[Requester pays]** (リクエスタ支払い) が有効になっている Amazon S3 バケットの登録は避けてください。Lake Formation に登録されたバケットの場合、バケットの登録に使用されるロールは常にリクエスト元であると見なされます。バケットが別の AWS アカウントからアクセスされた場合、ロールがバケット所有者と同じアカウントに属している場合、バケット所有者はデータアクセスに対して課金されます。 このセクションでは、以下の状況で Amazon S3 ロケーションを登録する方法について説明します。 + Amazon S3 内ロケーション内のデータが、 AWS KMSで作成された KMS キーで暗号化されている。 + Amazon S3 の場所が と同じ AWS アカウント内にありません AWS Glue Data Catalog。 + KMS キーは、 データカタログと同じ AWS アカウントにあるか、または存在しないかのいずれかです。 AWS アカウント A の (IAM) ロールを使用して AWS アカウント B に AWS KMS暗号化された Amazon S3 バケットを登録するには、 AWS Identity and Access Management 次のアクセス許可が必要です。 + アカウント A のロールが、アカウント B のバケットに対する許可を付与する必要があります。 + アカウント B のバケットポリシーが、アカウント A のロールにアクセス許可を付与する必要があります。 + KMS キーがアカウント B にある場合は、キーポリシーがアカウント A のロールにアクセス権を付与し、アカウント A のロールが KMS キーに対する許可を付与する必要があります。 次の手順では、データカタログを含む AWS アカウントにロールを作成します (前の説明のアカウント A)。次に、このロールを使用してロケーションを登録します。Lake Formation は、Amazon S3 内の基盤となるデータにアクセスするときに、このロールを引き受けます。引き受けたロールには、KMS キーに対する必要な許可があります。その結果、ETL ジョブや Amazon Athenaなどの統合サービスで基盤となるデータにアクセスするプリンシパルに、KMS キーに対する許可を付与する必要がなくなります。 **重要** Lake Formation サービスリンクロールを使用して、別のアカウントにあるロケーションを登録することはできません。その代わりに、ユーザー定義のロールを使用する必要があります。このロールは、「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たす必要があります。サービスリンクロールの詳細については、「[Lake Formation のサービスリンクロールの許可](service-linked-roles.md#service-linked-role-permissions)」を参照してください。 **開始する前に** 「[ロケーションの登録に使用されるロールの要件](registration-role.md)」を確認してください。 **AWS アカウント間で暗号化された Amazon S3 の場所を登録するには** 1. データカタログと同じ AWS アカウントで、 にサインイン AWS マネジメントコンソール し、 で IAM コンソールを開きます[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。 1. 新しいロールを作成するか、「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たす既存のロールを表示します。そのロールに、ロケーションに対する Amazon S3 許可を付与するポリシーが含まれていることを確認します。 1. KMS キーが Data Catalog と同じアカウントにないという場合は、KMS キーに対する必要な許可を付与するインラインポリシーをロールに追加します。以下は、ポリシーの例です。リージョンとアカウント ID を、KMS キーのリージョンとアカウント番号に置き換えます。** は、キー ID に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/" } ] } ``` ------ 1. Amazon S3 コンソールで、必要な Amazon S3 の許可をロールに付与するバケットポリシーを追加します。以下は、バケットポリシーの例です。アカウント ID をデータカタログの AWS アカウント番号に、** をロール名に、** をバケットの名前に置き換えてください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action":"s3:ListBucket", "Resource":"arn:aws:s3:::" }, { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Resource":"arn:aws:s3:::/*" } ] } ``` ------ 1. で AWS KMS、KMS キーのユーザーとしてロールを追加します。 1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) で AWS KMS コンソールを開きます。次に、管理者ユーザーとして、またはロケーションの暗号化に使用された KMS キーのキーポリシーを変更できるユーザーとしてサインインします。 1. ナビゲーションペインで **[Customer managed keys]** (カスタマー管理型のキー) を選択してから、KMS キーの名前を選択します。 1. KMS キーの詳細ページの **[Key policy]** (キーポリシー) タブにキーポリシーの JSON ビューが表示されていない場合は、**[Switch to policy view]** (ポリシービューへの切り替え) を選択します。 1. **[Key policy]** (キーポリシー) セクションで **[Edit]** (編集) を選択し、以下の例にあるように、ロールの Amazon リソースネーム (ARN) を `Allow use of the key` オブジェクトに追加します。 **注記** そのオブジェクトが欠落している場合は、例にある許可と共に追加してください。 ``` ... { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::role/" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, ... ``` 詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.amazonaws.cn/en_us/kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者として Data Catalog AWS アカウントにサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 1. **[Register location]** (ロケーションの登録) ページの **[Amazon S3 path]** (Amazon S3 パス) に、ロケーションのパスを **s3://**/**** として入力します。** はバケット名、** はロケーションのパスの残りの部分に置き換えてください。 **注記** クロスアカウントバケットは **[Browse]** (参照) を選択してもリストに表示されないため、パスを入力する必要があります。 1. **[IAM role]** (IAMロール) には、ステップ 2 からのロールを選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 # Amazon S3 ロケーションの登録解除 Amazon Simple Storage Service (Amazon S3) ロケーションを Lake Formation で管理する必要がなくなった場合は、このロケーションの登録を解除できます。ロケーションの登録を解除しても、そのロケーションに対して付与されている Lake Formation データロケーション許可には影響しません。登録を解除したロケーションは再登録でき、データロケーション許可は引き続き有効になります。ロケーションは、別のロールを使用して再登録できます。 **ロケーションの登録を解除する (コンソール)** 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開きます。データレイク管理者、または `lakeformation:RegisterResource` IAM 許可を持つユーザーとしてサインインします。 1. ナビゲーションペインの **[管理]** で、**[データレイクのロケーション]** を選択します。 1. ロケーションを選択し、**[Actions]** (アクション) メニューで **[Remove]** (削除) を選択します。 1. 確認を求めるプロンプトが表示されたら、**[Remove]** (削除) を選択します。 # ハイブリッドアクセスモード AWS Lake Formation *ハイブリッドアクセスモード*は、同じ AWS Glue Data Catalog オブジェクトへの 2 つのアクセス許可パスをサポートします。
 最初のパスでは、Lake Formation を使用して特定のプリンシパルを選択し、オプトインしてカタログ、データベース、テーブル、ビューにアクセスするための Lake Formation アクセス許可を付与できます。2 番目のパスでは、他のすべてのプリンシパルが Amazon S3 および AWS Glue アクションのデフォルトの IAM プリンシパルポリシーを通じてこれらのリソースにアクセスできます。 Amazon S3 ロケーションを Lake Formation に登録する場合、そのロケーションのすべてのリソースに Lake Formation 許可を適用するか、ハイブリッドアクセスモードを使用するかを選択できます。ハイブリッドアクセスモードは、デフォルトで、`CREATE_TABLE`、`CREATE_PARTITION`、および `UPDATE_TABLE` 許可のみが適用されます。Amazon S3 ロケーションがハイブリッドモードの場合、そのロケーションの Data Catalog オブジェクトのプリンシパルをオプトインすることで、Lake Formation アクセス許可を有効にできます。
これは、Lake Formation アクセス許可と IAM アクセス許可の両方が、そのデータへのアクセスを制御できることを意味します。つまり、オプトインされたプリンシパルはデータにアクセスするために Lake Formation アクセス許可と IAM アクセス許可の両方を必要とし、non-opted-inプリンシパルは引き続き IAM アクセス許可のみを使用してデータにアクセスします。 したがって、ハイブリッドアクセスモードでは、他の既存のユーザーやワークロードのアクセスを中断することなく、特定のユーザーのセットに対してデータカタログ内のカタログ、データベース、テーブルに対して Lake Formation を選択的に有効にする柔軟性が得られます。 ![\[AWS アカウント architecture showing data flow between S3, Glue, Lake Formation, Athena, and IAM roles.\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/hybrid-access-mode-concept.png) 考慮事項と制限事項については、「[ハイブリッドアクセスモードには次の考慮事項と制限事項が適用されます。](notes-hybrid.md)」を参照してください。用語と定義 アクセス許可の設定方法に基づく Data Catalog リソースの定義は次のとおりです。 Lake Formation のリソース Lake Formation に登録されているリソース。ユーザーがリソースにアクセスするには、Lake Formation 許可が必要です。 AWS Glue リソース Lake Formation に登録されていないリソース。リソースに `IAMAllowedPrincipals` グループのアクセス許可があるため、リソースにアクセスするには IAM 許可のみが必要です。Lake Formation 許可は適用されません。 `IAMAllowedPrincipals` グループのアクセス許可の詳細については、「[メタデータアクセス許可](metadata-permissions.md)」を参照してください。 ハイブリッドリソース ハイブリッドアクセスモードで登録されたリソース。リソースにアクセスするユーザーに基づいて、リソースは Lake Formation リソースと AWS Glue リソースの間で動的に切り替わります。 ## 一般的なハイブリッドアクセスモードのユースケース ハイブリッドアクセスモードを使用すると、単一アカウントおよびクロスアカウントのデータ共有シナリオでアクセスを許可できます。 **単一アカウントのシナリオ** + ** AWS Glue リソースをハイブリッドリソースに変換**する – このシナリオでは、現在 Lake Formation を使用していませんが、Data Catalog オブジェクトに Lake Formation アクセス許可を採用したいと考えています。Amazon S3 ロケーションをハイブリッドアクセスモードで登録すると、そのロケーションを指す特定のデータベースとテーブルをオプトインするユーザーに、Lake Formation 許可を付与できます。 + **Lake Formation リソースをハイブリッドリソースに変換する** - 現在、Lake Formation アクセス許可を使用してデータカタログデータベースへのアクセスを制御していますが、既存の Lake Formation アクセス許可を中断せずに、Amazon S3 と AWS Glue の IAM アクセス許可を使用して新しいプリンシパルにアクセスを許可したいと考えています。 データロケーション登録をハイブリッドアクセスモードに更新すると、新しいプリンシパルは、既存のユーザーの Lake Formation 許可を中断することなく、IAM 許可ポリシーを使用して Amazon S3 ロケーションを指す Data Catalog データベースにアクセスできます。 データロケーション登録を更新してハイブリッドアクセスモードを有効にする前に、まず、現在 Lake Formation 許可でリソースにアクセスしているプリンシパルをオプトインする必要があります。
 これは、現在のワークフローが中断される可能性を防ぐためです。
 また、データベース内のテーブルに対する `Super` 許可を `IAMAllowedPrincipal` グループに付与する必要があります。 **クロスアカウントデータ共有のシナリオ** + **ハイブリッドアクセスモードを使用して AWS Glue リソースを共有する** – このシナリオでは、プロデューサーアカウントには、Amazon S3 および AWS Glue アクションの IAM アクセス許可ポリシーを使用して、コンシューマーアカウントと現在共有されているデータベースにテーブルがあります。データベースのデータロケーションは、Lake Formation に登録されていません。 ハイブリッドアクセスモードでデータロケーションを登録する前に、**[クロスアカウントバージョン設定]** をバージョン 4 に更新する必要があります。バージョン 4 では、`IAMAllowedPrincipal`グループがリソースに対する AWS RAM アクセス許可を持っている場合に、クロスアカウント共有に必要な新しい`Super`アクセス許可ポリシーが提供されます。`IAMAllowedPrincipal` グループアクセス許可のあるリソースについては、外部アカウントに Lake Formation 許可を付与し、そのアカウントが Lake Formation 許可を使用するようにオプトインできます。受信者アカウントのデータレイク管理者は、アカウント内のプリンシパルに Lake Formation 許可を付与し、プリンシパルをオプトインして Lake Formation 許可を適用できます。 + **ハイブリッドアクセスモードを使用して Lake Formation リソースを共有する** – 現在、プロデューサーアカウントのデータベース内のテーブルは、Lake Formation 許可を適用するコンシューマーアカウントと共有されています。データベースのデータロケーションは、Lake Formation に登録されています。 この場合、Amazon S3 ロケーションの登録をハイブリッドアクセスモードに更新し、Amazon S3 バケットポリシーと Data Catalog リソースポリシーを使用して Amazon S3 のデータと Data Catalog のメタデータをコンシューマーアカウントのプリンシパルと共有できます。Amazon S3 ロケーションの登録を更新する前に、既存の Lake Formation 許可を再度付与し、プリンシパルをオプトインする必要があります。また、データベース内のテーブルに対する `Super` 許可を `IAMAllowedPrincipals` グループに付与する必要があります。 **Topics** + [一般的なハイブリッドアクセスモードのユースケース](#hybrid-access-mode-use-cases) + [ハイブリッドアクセスモードの仕組み](hybrid-access-workflow.md) + [ハイブリッドアクセスモードの設定 - 一般的なシナリオ](hybrid-access-setup.md) + [ハイブリッドアクセスモードからプリンシパルとリソースを削除する](delete-hybrid-access.md) + [ハイブリッドアクセスモードでプリンシパルとリソースを表示する](view-hybrid-access.md) + [その他のリソース](additional-resources-hybrid.md) # ハイブリッドアクセスモードの仕組み 次の図は、ハイブリッドアクセスモードで Data Catalog リソースにクエリを実行するときに Lake Formation 認可がどのように機能するかを示しています。 ![\[AWS Lake Formation authorization process flowchart for hybrid access mode queries.\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/hybrid-workflow.png) データレイク内のデータにアクセスする前に、データレイク管理者または管理権限を持つユーザーが、Data Catalog テーブルへのアクセスを許可または拒否する個々の Data Catalog テーブルのユーザーポリシーを設定します。次に、`RegisterResource` オペレーションを実行するアクセス許可を持つプリンシパルが、ハイブリッドアクセスモードで Lake Formation にテーブルの Amazon S3 ロケーションを登録します。データロケーションが Lake Formation に登録されていない場合、管理者は Data Catalog データベースとテーブルの特定のユーザーに Lake Formation アクセス許可を付与し、ハイブリッドアクセスモードでそれらのデータベースとテーブルに Lake Formation アクセス許可を使用するようにオプトインします。 1. **クエリを送信する** - プリンシパルは、Amazon Athena、Amazon EMR AWS Glue、Amazon Redshift Spectrum などの統合サービスを使用してクエリまたは ETL スクリプトを送信します。 1. **データのリクエスト** – 統合分析エンジンは、要求されているテーブルを識別し、メタデータのリクエストを Data Catalog (`GetTable`、`GetDatabase`) に送信します。 1. **アクセス許可を確認** – Data Catalog は、クエリ元プリンシパルのアクセス許可を Lake Formation で検証します。 1. テーブルに `IAMAllowedPrincipals` グループアクセス許可がアタッチされていない場合は、Lake Formation 許可が適用されます。 1. プリンシパルがハイブリッドアクセスモードで Lake Formation 許可を使用することをオプトインしていて、テーブルに `IAMAllowedPrincipals` グループアクセス許可がアタッチされている場合、Lake Formation 許可が適用されます。クエリエンジンは、Lake Formation から受け取ったフィルターを適用し、データをユーザーに返します。 1. テーブルロケーションが Lake Formation に登録されておらず、プリンシパルがハイブリッドアクセスモードで Lake Formation 許可を使用することをオプトインしていない場合、Data Catalog はテーブルに `IAMAllowedPrincipals` グループアクセス許可がアタッチされているかどうかを確認します。このアクセス許可がテーブルに存在する場合、アカウント内のすべてのプリンシパルはテーブルに対する `Super` または `All` 許可が付与されます。 データの場所が Lake Formation に登録されていない限り、オプトインしても Lake Formation の認証情報供給は使用できません。 1. **認証情報の取得** – Data Catalog は、テーブルのロケーションが Lake Formation に登録されているかどうかを確認し、エンジンに知らせます。基盤となるデータが Lake Formation に登録されている場合、分析エンジンは、Amazon S3 バケットのデータにアクセスするための一時的な認証情報を Lake Formation に要求します。 1. **データの取得** – プリンシパルがテーブルデータへのアクセスを許可されている場合、Lake Formation は統合分析エンジンへの一時的なアクセスを提供します。一時的なアクセスを使用して、分析エンジンは Amazon S3 からデータを取得し、列、行、またはセルのフィルタリングなど、必要なフィルタリングを実行します。エンジンはジョブの実行を終了すると、結果をユーザーに返します。このプロセスは、認証情報の供給と呼ばれます。詳細については、「[サードパーティーサービスと Lake Formation との統合](Integrating-with-LakeFormation.md)」を参照してください。 1. 
テーブルのデータロケーションが Lake Formation に登録されていない場合、分析エンジンからの 2 回目の呼び出しは Amazon S3 に対して直接行われます。関係する Amazon S3 バケットポリシーと IAM ユーザーポリシーのデータアクセスが評価されます。IAM ポリシーを使用するときは、常に IAM のベストプラクティスに従うようにしてください。詳細については、「IAM ユーザーガイド」の「[IAM でのセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。 # ハイブリッドアクセスモードの設定 - 一般的なシナリオ Lake Formation のアクセス許可と同様に、ハイブリッドアクセスモードを使用してデータアクセスを管理できるシナリオには、通常、1 つの 内のプリンシパルへのアクセス AWS アカウント を提供し、外部 AWS アカウント またはプリンシパルへのアクセスを提供するという 2 種類があります。 このセクションでは、以下のシナリオでハイブリッドアクセスモードを設定する方法について説明します。 **ハイブリッドアクセスモードで 1 つの 内でアクセス許可を管理する AWS アカウント** + [AWS Glue リソースをハイブリッドリソースに変換する](hybrid-access-mode-new.md) – 現在、Amazon S3 の IAM アクセス許可を使用して、アカウント内のすべてのプリンシパルにデータベース内のテーブルへのアクセスを提供していますが、アクセス許可を段階的に管理するために Lake Formation を採用したいと考えています。 AWS Glue + [Lake Formation リソースをハイブリッドリソースに変換する](hybrid-access-mode-update.md) - 現在、アカウント内のすべてのプリンシパルについて、Lake Formation を使用してデータベース内のテーブルへのアクセスを管理しているが、特定のプリンシパルにのみ Lake Formation を使用したいと考えている。同じデータベースとテーブルで AWS Glue と Amazon S3 の IAM アクセス許可を使用して、新しいプリンシパルへのアクセスを提供する必要があります。 **間のハイブリッドアクセスモードでアクセス許可を管理する AWS アカウント** + [ハイブリッドアクセスモードを使用した AWS Glue リソースの共有](hybrid-access-mode-cross-account.md) - 現在、テーブルのアクセス許可管理に Lake Formation を使用していないが、Lake Formation アクセス許可を適用して別のアカウント内のプリンシパルにアクセスを許可したいと考えている。 + [ハイブリッドアクセスモードを使用して Lake Formation リソースを共有する](hybrid-access-mode-cross-account-IAM.md) – Lake Formation を使用してテーブルのアクセスを管理しているが、同じデータベースとテーブルで AWS Glue と Amazon S3 の IAM アクセス許可を使用して、別のアカウントのプリンシパルにアクセスを許可したい。 **ハイブリッドアクセスモードの設定 – 概要ステップ** 1. **[ハイブリッドアクセスモード]** を選択して、Amazon S3 データロケーションを Lake Formation に登録します。 1. プリンシパルは、Data Catalog のテーブルまたはデータベースのポイント先となるデータレイクのロケーションに対する `DATA_LOCATION` 許可を持っている必要があります。 1. **[クロスアカウントバージョン設定]** をバージョン 4 に設定します。 1. データベースやテーブル上の特定の IAM ユーザーまたはロールにきめ細かいアクセス許可を付与します。同時に、データベース上の `IAMAllowedPrincipals` グループとデータベース内のすべてまたは選択したテーブルに、必ず `Super` または `All` 許可を設定します。 1. プリンシパルとリソースをオプトインします。アカウントの他のプリンシパルは、 および Amazon S3 アクションの IAM アクセス許可ポリシーを使用して、データベース AWS Glue とテーブルに引き続きアクセスできます。 1. オプションで、Lake Formation 許可を使用するようオプトインしているプリンシパルの Amazon S3 の IAM 許可ポリシーをクリーンアップします。 # ハイブリッドアクセスモードの設定の前提条件 ハイブリッドアクセスモードを設定するための前提条件は次のとおりです。 **注記** Lake Formation 管理者が Amazon S3 ロケーションをハイブリッドアクセスモードで登録し、プリンシパルとリソースをオプトインすることをお勧めします。 1. データロケーション許可 (`DATA_LOCATION_ACCESS`) は、Amazon S3 ロケーションをポイントする Data Catalog リソースを作成する場合に付与します。データロケーションのアクセス許可は、特定の Amazon S3 ロケーションを指す Data Catalog カタログ、データベース、テーブルを作成する機能を制御します。 1. Data Catalog リソースをハイブリッドアクセスモードの別のアカウントと共有するには (リソースから`IAMAllowedPrincipals`グループアクセス許可を削除せずに）、**クロスアカウントバージョン設定**をバージョン 4 以降に更新する必要があります。Lake Formation コンソールを使用してバージョンを更新するには、**データカタログ****設定ページのクロスアカウントバージョン**設定で**バージョン 4** または**バージョン 5** を選択します。 `put-data-lake-settings` AWS CLI コマンドを使用して、 `CROSS_ACCOUNT_VERSION`パラメータをバージョン 4 または 5 に設定することもできます。 ``` aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam::<111122223333>:user/" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [], "Parameters": { "CROSS_ACCOUNT_VERSION": "5" } } ``` 1. 
ハイブリッドアクセスモードでクロスアカウントアクセス許可を付与するには、付与者に AWS Glue および AWS RAM サービスに必要な IAM アクセス許可が必要です。 AWS 管理ポリシーは、必要なアクセス許可`AWSLakeFormationCrossAccountManager`を付与します。
 ハイブリッドアクセスモードでクロスアカウントデータ共有を有効にするために、次の 2 つの新しい IAM アクセス許可を追加して `AWSLakeFormationCrossAccountManager` 管理ポリシーを更新しました。 + ram:ListResourceSharePermissions + ram:AssociateResourceSharePermission **注記** 付与者ロールに AWS 管理ポリシーを使用していない場合は、カスタムポリシーに上記のポリシーを追加します。 ## Amazon S3 バケットの場所とユーザーアクセス でカタログ、データベース、またはテーブルを作成するときに AWS Glue Data Catalog、基盤となるデータの Amazon S3 バケットの場所を指定し、Lake Formation に登録できます。次の表は、テーブルまたはデータベースの Amazon S3 データの場所に基づいて、 AWS Glue および Lake Formation ユーザー (プリンシパル) に対するアクセス許可の仕組みを示しています。 **Lake Formation に登録された Amazon S3 ロケーション** | データベースの Amazon S3 ロケーション | AWS Glue ユーザー | Lake Formation ユーザー | | --- | --- | --- | | Lake Formation に登録 (ハイブリッドアクセスモードまたは Lake Formation モード) | IAMAllowedPrincipals グループ (スーパーアクセス) のアクセス許可を継承し、Amazon S3 データロケーションへの読み取り/書き込みアクセス権を持ちます。 | 付与された CREATE TABLE アクセス許可から、テーブルを作成するアクセス許可を継承します。 | | 関連付けられた Amazon S3 ロケーションなし | CREATE TABLE および INSERT TABLE ステートメントを実行するには、明示的な DATA LOCATION アクセス許可が必要です。 | CREATE TABLE および INSERT TABLE ステートメントを実行するには、明示的な DATA LOCATION アクセス許可が必要です。 | ****IsRegisteredWithLakeFormation** テーブルプロパティ** テーブルの `IsRegisteredWithLakeFormation` プロパティは、テーブルのデータロケーションがリクエスタの Lake Formation に登録されているかどうかを示します。ロケーションのアクセス許可モードが Lake Formation として登録されている場合は、すべてのユーザーがそのテーブルにオプトインされていると見なされるため、データロケーションにアクセスするすべてのユーザーに対して `IsRegisteredWithLakeFormation` プロパティが `true` になります。ロケーションがハイブリッドアクセスモードで登録されている場合は、そのテーブルにオプトインしたユーザーに対してのみ値が `true` に設定されます。 **`IsRegisteredWithLakeFormation` の仕組み** | アクセス許可モード | ユーザー/ロール | `IsRegisteredWithLakeFormation` | 説明 | | --- | --- | --- | --- | | Lake Formation | すべて | 正 | ロケーションが Lake Formation で登録されている場合、`IsRegisteredWithLakeFormation` プロパティはすべてのユーザーに対して true に設定されます。つまり、Lake Formation で定義されたアクセス許可が、登録されたロケーションに適用されます。認証情報供給は Lake Formation によって行われます。 | | ハイブリッドアクセスモード | オプトイン済み | 正 | テーブルのデータアクセスとガバナンスに Lake Formation を使用するようにオプトインしたユーザーでは、そのテーブルの `IsRegisteredWithLakeFormation` プロパティが `true` に設定されます。これらのユーザーには、登録されているロケーションに対して Lake Formation で定義されたアクセス許可ポリシーが適用されます。 | | ハイブリッドアクセスモード | オプトインなし | 誤 | Lake Formation アクセス許可の使用にオプトインしていないユーザーの場合、`IsRegisteredWithLakeFormation` プロパティは `false` に設定されます。これらのユーザーには、登録されている場所に対して Lake Formation で定義されているアクセス許可ポリシーは適用されません。代わりに、ユーザーは Amazon S3 アクセス許可ポリシーに従います。 | # AWS Glue リソースをハイブリッドリソースに変換する 以下のステップに従って Amazon S3 ロケーションをハイブリッドアクセスモードで登録し、既存の Data Catalog ユーザーのデータアクセスを中断することなく、新しい Lake Formation ユーザーをオンボーディングします。 シナリオの説明 – データロケーションは、Lake Formation に登録されていません。Data Catalog データベースとテーブルへのユーザーのアクセスは、Amazon S3 および AWS Glue アクションの IAM アクセス許可ポリシーによって決定されます。
 デフォルトでは、この `IAMAllowedPrincipals` グループにはデータベース内のすべてのテーブルに対する `Super` 許可があります。 **Lake Formation に登録されていないデータロケーションのハイブリッドアクセスモードを有効にするには** 1. **Amazon S3 ロケーションを登録して、ハイブリッドアクセスモードを有効にします。** ------ #### [ Console ] 1. [Lake Formation コンソール](https://console.aws.amazon.com/lakeformation/)にデータレイク管理者としてサインインします。 1. ナビゲーションペインで、**[管理]** の **[データレイクのロケーション]** を選択します。 1. **[Register location]** (ロケーションを登録) を選択します。 ![\[Register location form for Amazon S3 data lake with path input, IAM role selection, and permission mode options.\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/hybrid-access-register-s3.png) 1. **[ロケーションを登録]** ウィンドウで、Lake Formation に登録する **[Amazon S3]** パスを選択します。 1. **[IAM ロール]** で、`AWSServiceRoleForLakeFormationDataAccess` サービスリンクロール (デフォルト)、または「[ロケーションの登録に使用されるロールの要件](registration-role.md)」の要件を満たすカスタム IAM ロールを選択します。 1. **[ハイブリッドアクセスモード]** を選択すると、登録されたロケーションを指すオプトインプリンシパルと Data Catalog データベースおよびテーブルに、きめ細かい Lake Formation アクセスコントロールポリシーが適用されます。
 Lake Formation を選択すると、Lake Formation は登録されたロケーションへのアクセスリクエストを承認できるようになります。
 1. **[Register location]** (ロケーションを登録) を選択します。 ------ #### [ AWS CLI ] 次の例では、HybridAccessEnabled:true/false と設定して、Lake Formation にデータロケーションを登録しています。`HybridAccessEnabled` パラメータのデフォルト値は false です。Amazon S3 パス、ロール名、 AWS アカウント ID を有効な値に置き換えます。 ``` aws lakeformation register-resource --cli-input-json file:file path json: { "ResourceArn": "arn:aws:s3:::s3-path", "UseServiceLinkedRole": false, "RoleArn": "arn:aws:iam::<123456789012>:role/", "HybridAccessEnabled": true } ``` ------ 1. **ハイブリッドアクセスモードでリソースに Lake Formation 許可を使用するようにアクセス許可を付与し、プリンシパルをオプトインする** ハイブリッドアクセスモードでプリンシパルとリソースをオプトインする前に、ハイブリッドアクセスモードで Lake Formation に登録された場所があるデータベースとテーブルに`IAMAllowedPrincipals`、 `Super`または グループの`All`アクセス許可が存在することを確認します。 **注記** データベース内の `All tables` に `IAMAllowedPrincipals` グループアクセス許可を付与することはできません。ドロップダウンメニューから各テーブルを個別に選択し、アクセス許可を付与する必要があります。また、データベースに新しいテーブルを作成するときは、**[データカタログの設定]** で [`Use only IAM access control for new tables in new databases`] を選択できます。このオプションでは、データベース内に新しいテーブルを作成すると、自動的に `IAMAllowedPrincipals` グループに `Super` 許可が付与されます。 ------ #### [ Console ] 1. Lake Formation コンソール**のデータカタログ**で、**カタログ**、**データベース**、または**テーブル**を選択します。 1. リストからカタログ、データベース、またはテーブルを選択し、**アクション**メニューから**付与**を選択します。 1. プリンシパルを選択し、名前付きリソース方式または LF タグを使用して、データベース、テーブル、および列に対するアクセス許可を付与します。 または、**データアクセス許可**を選択し、リストからアクセス許可を付与するプリンシパルを選択し、**付与**を選択します。 データアクセス許可の付与に関する詳細については、「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」を参照してください。 **注記** プリンシパルにテーブル作成のアクセス許可を付与する場合は、プリンシパルにデータロケーション許可 (`DATA_LOCATION_ACCESS`) を付与する必要もあります。このアクセス許可はテーブルの更新には必要ありません。 詳細については、「[データロケーション許可の付与](granting-location-permissions.md)」を参照してください。 1. **[名前付きリソース方式]** を使用してアクセス許可を付与する場合、プリンシパルとリソースをオプトインするオプションが **[データ許可の付与]** ページの下部に表示されます。 プリンシパルとリソースの Lake Formation 許可を有効にするには、**[Lake Formation 許可をすぐに有効にする]** を選択します。 ![\[Data Catalog リソースのハイブリッドアクセスモードを選択するオプション。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/hybrid-access-grant-option.png) 1. **[付与]** を選択します。 データロケーションを指しているテーブル A のプリンシパル A をオプトインした場合、データロケーションがハイブリッドモードで登録されていれば、プリンシパル A は Lake Formation 許可を使用してこのテーブルのロケーションにアクセスできます。 ------ #### [ AWS CLI ] 以下の例では、ハイブリッドアクセスモードでプリンシパルとテーブルをオプトインしています。ロール名、 AWS アカウント ID、データベース名、およびテーブル名を有効な値に置き換えます。 ``` aws lakeformation create-lake-formation-opt-in --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/" }, "Resource": { "Table": { "CatalogId": "<123456789012>", "DatabaseName": "", "Name": "" } } } ``` ------ 1. アクセス許可を付与するために LF タグを選択した場合は、別のステップで Lake Formation 許可を使用するようにプリンシパルをオプトインできます。これを行うには、左側のナビゲーションバーの **[アクセス許可]** で **[ハイブリッドアクセスモード]** を選択します。 1. **[ハイブリッドアクセスモード]** ページの下部にある **[追加]** を選択して、リソースとプリンシパルをハイブリッドアクセスモードに追加します。 1. **リソースとプリンシパルの追加**ページで、ハイブリッドアクセスモードで登録されているカタログ、データベース、テーブルを選択します。 アクセスを許可するデータベースで、`All tables` を選択できます。 ![\[ハイブリッドアクセスモードでカタログ、データベース、テーブルを追加するインターフェイス。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/hybrid-access-opt-in.png) 1. ハイブリッドアクセスモードで Lake Formation アクセス許可を使用するようにオプトインするプリンシパルを選択します。 + **プリンシパル** – IAM ユーザーとロールは、同じアカウントまたは別のアカウントで選択できます。SAML ユーザーとグループを選択することもできます。 + **属性** – 属性を選択して、属性に基づいてアクセス許可を付与します。 ![\[属性式を使用してプリンシパルとリソースを追加するインターフェイス。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/abac-hybrid-access.png) + キーと値のペアを入力して、属性に基づいて権限を作成します。コンソールで Cedar ポリシー式を確認します。Cedar の詳細については、「[Cedar とは」を参照してください。\$1 Cedar Policy Language Reference GuideLink](https://docs.cedarpolicy.com/) を参照してください。 + **[Add]** (追加) を選択します。 属性が一致するすべての IAM ロール/ユーザーにアクセス権が付与されます。 1. **[Add]** (追加) を選択します。 # Lake Formation リソースをハイブリッドリソースに変換する 現在 Data Catalog データベースとテーブルに Lake Formation 許可を使用している場合は、ロケーションの登録プロパティを編集してハイブリッドアクセスモードを有効にできます。これにより、既存の Lake Formation アクセス許可を中断することなく、Amazon S3 の IAM アクセス許可ポリシーと AWS Glue アクションを使用して、新しいプリンシパルに同じリソースへのアクセスを提供できます。 シナリオの説明 – 以下のステップは、Lake Formation にデータロケーションを登録していて、そのロケーションを指すデータベース、テーブル、または列に対するプリンシパルのアクセス許可を設定していることを前提としています。そのロケーションが、サービスにリンクされたロールに登録されている場合、ロケーションパラメータを更新してハイブリッドアクセスモードを有効にすることはできません。`IAMAllowedPrincipals` グループには、データベースとそのすべてのテーブルの Super 許可がデフォルトで与えられます。 **重要** そのロケーションのデータにアクセスするプリンシパルをオプトインすることなく、ロケーションの登録をハイブリッドアクセスモードに更新しないでください。 **Lake Formation に登録されたデータロケーションのハイブリッドアクセスモードを有効にする** 1. **警告** 他の既存のユーザーやワークロードのアクセス許可ポリシーを中断しないようにするため、Lake Formation が管理するデータロケーションをハイブリッドアクセスモードに変換することはお勧めしません。 Lake Formation 許可を持つ既存のプリンシパルをオプトインします。 1. カタログ、データベース、テーブルのプリンシパルに付与したアクセス許可を一覧表示して確認します。詳細については、「[Lake Formation でのデータベースとテーブル許可の表示](viewing-permissions.md)」を参照してください。 1. 左側のナビゲーションバーの **[アクセス許可]** で **[ハイブリッドアクセスモード]** を選択し、**[追加]** を選択します。 1. **プリンシパルとリソースの追加**ページで、ハイブリッドアクセスモードで使用する Amazon S3 データの場所からカタログ、データベース、テーブルを選択します。既に Lake Formation 許可を持っているプリンシパルを選択します。 1. ハイブリッドアクセスモードで Lake Formation 許可を使用するようにプリンシパルをオプトインするには、**[追加]** を選択します。 1. **[ハイブリッドアクセスモード]** オプションを選択して Amazon S3 バケット/プレフィックス登録を更新します。 ------ #### [ Console ] 1. Lake Formation コンソールにデータレイク管理者としてサインインします。 1. ナビゲーションペインの **[Register and ingest]** (登録および取り込み) で **[Data lake locations]** (データレイクのロケーション) を選択します。 1. ロケーションを選択し、**[アクション]** メニューの **[削除]** を選択します。 1. **[ハイブリッドアクセスモード]** を選択します。 1. **[保存]** を選択します。 1. Data Catalog で、データベースまたはテーブルを選択し、`IAMAllowedPrincipals` という仮想グループに `Super` または `All` 許可を付与します。 1. ロケーションの登録プロパティを更新したときに、既存の Lake Formation ユーザーのアクセスが中断されていないことを検証します。Lake Formation プリンシパルとして Athena コンソールにサインインし、更新されたロケーションを指すテーブルに対してサンプルクエリを実行します。 同様に、IAM アクセス許可ポリシーを使用してデータベースとテーブルにアクセスしている AWS Glue ユーザーのアクセスを確認します。 ------ #### [ AWS CLI ] 次の例では、HybridAccessEnabled:true/false と設定して、Lake Formation にデータロケーションを登録しています。`HybridAccessEnabled` パラメータのデフォルト値は false です。Amazon S3 パス、ロール名、 AWS アカウント ID を有効な値に置き換えます。 ``` aws lakeformation update-resource --cli-input-json file://file path json: { "ResourceArn": "arn:aws:s3:::", "RoleArn": "arn:aws:iam::<123456789012>:role/", "HybridAccessEnabled": true } ``` ------ # ハイブリッドアクセスモードを使用した AWS Glue リソースの共有 既存の Data Catalog ユーザーの IAM AWS アカウント ベースのアクセスを中断することなく、別の AWS アカウント または別の のプリンシパルとデータを共有します。 シナリオの説明 - プロデューサーアカウントには、Amazon S3 の IAM プリンシパルポリシーと AWS Glue アクションを使用してアクセスが制御された Data Catalog データベースがあります。データベースのデータロケーションは、Lake Formation に登録されていません。`IAMAllowedPrincipals` グループには、デフォルトで、データベースとそのすべてのテーブルに対する `Super` アクセス許可があります。 **ハイブリッドアクセスモードでクロスアカウントの Lake Formation 許可を付与する** 1. **プロデューサーアカウントの設定** 1. `lakeformation:PutDataLakeSettings` IAM アクセス許可を持つロールを使用して Lake Formation コンソールにサインインします。 1. **[データカタログの設定]** ページに移動し、**[クロスアカウントバージョン設定]** で [`Version 4`] を選択します。 現在バージョン 1 または 2 を使用している場合は、バージョン 3 への更新について、「[クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md)」の手順を参照してください。 バージョン 3 から 4 にアップグレードする場合、アクセス許可ポリシーを変更する必要はありません。 1. ハイブリッドアクセスモードで共有する予定のデータベースまたはテーブルの Amazon S3 ロケーションを登録します。 1. 上記のステップにおいて、ハイブリッドアクセスモードでデータロケーションを登録したデータベースとテーブルに、`IAMAllowedPrincipals` グループに対する `Super` 許可があることを確認します。 1. Lake Formation のアクセス許可を AWS 組織、組織単位 (OUs) に付与するか、別のアカウントの IAM プリンシパルに直接付与します。 1. IAM プリンシパルに直接許可を付与する場合は、コンシューマーアカウントからプリンシパルにオプトインし、**[Lake Formation 許可をすぐに有効にする]** オプションを有効にして、ハイブリッドアクセスモードで Lake Formation 許可を適用します。 別の AWS アカウントにクロスアカウントアクセス許可を付与する場合、アカウントをオプトインすると、Lake Formation アクセス許可はそのアカウントの管理者にのみ適用されます。受信者アカウントのデータレイク管理者は、アクセス許可をカスケードし、アカウントのプリンシパルをオプトインして、ハイブリッドアクセスモードの共有リソースに Lake Formation 許可を適用する必要があります。 **[LF タグに一致するリソース]** オプションを選択してクロスアカウントアクセス許可を付与する場合は、まずアクセス許可の付与ステップを完了する必要があります。Lake Formation コンソールの左側のナビゲーションバーにある [アクセス許可] で **[ハイブリッドアクセスモード]** を選択することで、プリンシパルとリソースをハイブリッドアクセスモードに別のステップとしてオプトインできます。次に、**[追加]** を選択して、Lake Formation 許可を適用するリソースとプリンシパルを追加します。 1. **コンシューマーアカウントの設定** 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) にデータレイク管理者としてサインインします。 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) に移動し、リソース共有の招待を受け入れます。 AWS RAM コンソールの共有**タブ**には、アカウントと共有されているデータベースとテーブルが表示されます。 1. Lake Formation の共有データベースまたはテーブルへのリソースリンクを作成します。 1. リソースリンクの `Describe` 許可と (元の共有リソースの) `Grant on target` 許可を (コンシューマー) アカウントの IAM プリンシパルに付与します。 1. 共有されているデータベースまたはテーブルの Lake Formation 許可を、アカウントのプリンシパルに付与します。**[Lake Formation 許可をすぐに有効にする]** オプションを有効することで、プリンシパルとリソースをオプトインし、ハイブリッドアクセスモードで Lake Formation 許可を適用します。 1. Athena のサンプルクエリを実行して、プリンシパルの Lake Formation 許可をテストします。Amazon S3 および AWS Glue アクションの IAM プリンシパルポリシーを使用して、 AWS Glue ユーザーの既存のアクセスをテストします。 (オプション) データアクセス用の Amazon S3 バケットポリシーと、Lake Formation 許可を使用するように設定したプリンシパルの AWS Glue と Amazon S3 データアクセス用の IAM プリンシパルポリシーを削除します。 # ハイブリッドアクセスモードを使用して Lake Formation リソースを共有する 外部アカウントの新しい Data Catalog ユーザーが、既存の Lake Formation のクロスアカウント共有アクセス許可を中断することなく、IAM ベースのポリシーを使用して Data Catalog データベースとテーブルにアクセスできるようにします。 シナリオの説明 – プロデューサーアカウントには、アカウントレベルまたは IAM プリンシパルレベルで外部 (コンシューマー) アカウントと共有される Lake Formation 管理データベースとテーブルがあります。データベースのデータロケーションは、Lake Formation に登録されています。`IAMAllowedPrincipals` グループには、データベースとそのテーブルに対する `Super` 許可はありません。 **既存の Lake Formation 許可を中断することなく、IAM ベースのポリシーを介して新しい Data Catalog ユーザーにクロスアカウントアクセスを許可する** 1. **プロデューサーアカウントの設定** 1. `lakeformation:PutDataLakeSettings` を持つロールを使用して Lake Formation コンソールにサインインします。 1. **[データカタログの設定]** ページの **[クロスアカウントバージョン設定]** で、[`Version 4`] を選択します。 現在バージョン 1 または 2 を使用している場合は、バージョン 3 への更新について、「[クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md)」の手順を参照してください。 バージョン 3 から 4 へのアップグレードには、アクセス許可ポリシーの変更は必要ありません。 1. データベースとテーブルでプリンシパルに付与したアクセス許可を一覧表示します。詳細については、「[Lake Formation でのデータベースとテーブル許可の表示](viewing-permissions.md)」を参照してください。 1. プリンシパルとリソースをオプトインすることで、既存の Lake Formation のクロスアカウントアクセス許可を再付与します。 **注記** データロケーション登録をハイブリッドアクセスモードに更新してクロスアカウントアクセス許可を付与する前に、アカウントごとに少なくとも 1 つのクロスアカウントデータ共有を再付与する必要があります。このステップは、 AWS RAM リソース共有にアタッチされた AWS RAM 管理アクセス許可を更新するために必要です。 2023 年 7 月、Lake Formation はデータベースとテーブルの共有に使用される AWS RAM マネージドアクセス許可を更新しました。 `arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueAllTablesReadWriteForDatabase` (データベースレベルの共有ポリシー) `arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueTableReadWrite` (テーブルレベルの共有ポリシー) 2023 年 7 月より前に行われたクロスアカウントアクセス許可の付与には、これらの更新された AWS RAM アクセス許可はありません。 クロスアカウントアクセス許可をプリンシパルに直接付与した場合は、それらのアクセス許可を個別にプリンシパルに再付与する必要があります。このステップをスキップすると、共有リソースにアクセスするプリンシパルに不正な組み合わせエラーが発生する可能性があります。 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) に移動します。 1. AWS RAM コンソールの **Shared by me** タブには、外部アカウントまたはプリンシパルと共有したデータベースとテーブル名が表示されます。 共有リソースにアタッチされたアクセス許可に、正しい ARN があることを確認します。 1. AWS RAM 共有内のリソースのステータスが であることを確認します`Associated`。ステータスが `Associating` と表示される場合は、`Associated` 状態になるまで待ちます。ステータスが `Failed` になった場合は、停止して Lake Formation サービスチームにご連絡ください。 1. 左側のナビゲーションバーの **[アクセス許可]** で **[ハイブリッドアクセスモード]** を選択し、**[追加]** を選択します。 1. **[プリンシパルとリソースの追加]** ページには、アクセス権のあるデータベース、テーブル、またはその両方とプリンシパルが表示されます。プリンシパルとリソースを追加または削除することで、必要な更新を行うことができます。 1. ハイブリッドアクセスモードに変更するデータベースとテーブルの Lake Formation 許可を持つプリンシパルを選択します。データベースとテーブルを選択します。 1. ハイブリッドアクセスモードで Lake Formation 許可を適用するようにプリンシパルをオプトインするには、**[追加]** を選択します。 1. データベースと選択したテーブルの仮想グループ `IAMAllowedPrincipals` に `Super` 許可を付与します。 1. Amazon S3 ロケーションの Lake Formation 登録をハイブリッドアクセスモードに編集します。 1. Amazon S3 AWS Glue actions の IAM アクセス許可ポリシーを使用して、外部 (コンシューマー) アカウントの AWS Glue ユーザーにアクセス許可を付与します。 1. **コンシューマーアカウントの設定** 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) にデータレイク管理者としてサインインします。 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) に移動し、リソース共有の招待を受け入れます。 AWS RAM ページの**リソース共有**タブには、アカウントと共有されているデータベース名とテーブル名が表示されます。 AWS RAM 共有の場合は、アタッチされたアクセス許可に共有 AWS RAM 招待の正しい ARN があることを確認します。 AWS RAM 共有内のリソースが `Associated`ステータスになっているかどうかを確認します。ステータスが `Associating` と表示される場合は、`Associated` 状態になるまで待ちます。ステータスが `Failed` になった場合は、停止して Lake Formation サービスチームにご連絡ください。 1. Lake Formation の共有データベースまたはテーブルへのリソースリンクを作成します。 1. リソースリンクの `Describe` 許可と (元の共有リソースの) `Grant on target` 許可を (コンシューマー) アカウントの IAM プリンシパルに付与します。 1. 次に、共有データベースまたはテーブルのアカウントのプリンシパルに Lake Formation 許可を設定します。 左側のナビゲーションバーの **[アクセス許可]** で、**[ハイブリッドアクセスモード]** を選択します。 1. **[ハイブリッドアクセスモード]** ページの下部にある **[追加]** を選択して、プリンシパルと、プロデューサーアカウントから共有されているデータベースまたはテーブルをオプトインします。 1. Amazon S3 AWS Glue actions の IAM アクセス許可ポリシーを使用して、アカウントの AWS Glue ユーザーにアクセス許可を付与します。 1. Athena を使用してテーブルで個別のサンプルクエリを実行して、ユーザーの Lake Formation のアクセス許可と AWS Glue アクセス許可をテストする (オプション) ハイブリッドアクセスモードになっているプリンシパルに対する Amazon S3 の IAM 許可ポリシーをクリーンアップします。 # ハイブリッドアクセスモードからプリンシパルとリソースを削除する 以下のステップに従って、ハイブリッドアクセスモードからデータベース、テーブル、およびプリンシパルを削除します。 ------ #### [ Console ] 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) にサインインします。 1. **[アクセス許可]** で **[ハイブリッドアクセスモード]** を選択します。 1. **[ハイブリッドアクセスモード]** ページで、データベース名またはテーブル名の横にあるチェックボックスを選択し、[`Remove`] を選択します。 1. 警告メッセージが表示され、アクションの確認を求められます。**[**を削除] を選択します。 Lake Formation はこれらのリソースにアクセス許可を強制しなくなり、このリソースへのアクセスは IAM と アクセス AWS Glue 許可を使用して制御されます。これにより、ユーザーが適切な IAM アクセス許可を持っていないと、このリソースにアクセスできなくなる可能性があります。 ------ #### [ AWS CLI ] 次の例は、ハイブリッドアクセスモードからリソースを削除する方法を示しています。 ``` aws lakeformation delete-lake-formation-opt-in --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/role name" }, "Resource": { "Table": { "CatalogId": "<123456789012>", "DatabaseName": "", "Name": "" } } } ``` ------ # ハイブリッドアクセスモードでプリンシパルとリソースを表示する 以下のステップに従って、ハイブリッドアクセスモードでデータベース、テーブル、プリンシパルを表示します。 ------ #### [ Console ] 1. Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) にサインインします。 1. **[アクセス許可]** で **[ハイブリッドアクセスモード]** を選択します。 1. **[ハイブリッドアクセスモード]** ページには、現在ハイブリッドアクセスモードになっているリソースとプリンシパルが表示されます。 ------ #### [ AWS CLI ] 次の例は、ハイブリッドアクセスモードのすべてのオプトインプリンシパルとリソースを一覧表示する方法を示しています。 ``` aws lakeformation list-lake-formation-opt-ins ``` 次の例は、特定のプリンシパルリソースペアのオプトインを一覧表示する方法を示しています。 ``` aws lakeformation list-lake-formation-opt-ins --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam:::role/" }, "Resource": { "Table": { "CatalogId": "", "DatabaseName": "", "Name": "
" } } } ``` ------ # その他のリソース 次のブログ記事では、IAM および Amazon S3 のアクセス許可を通じて他のユーザーが既にデータベースにアクセスできる場合に、選択したユーザーのために Lake Formation のアクセス許可をハイブリッドアクセスモードでオンボーディングする手順について説明します。アカウント内および 2 つの AWS アカウント間でハイブリッドアクセスモードを設定する手順を確認します。 + [ Lake Formation と IAM および Amazon S3 ポリシーを使用してアクセス AWS Glue Data Catalog を保護するための のハイブリッドアクセスモードを導入しました。 Amazon S3 ](https://aws.amazon.com/blogs/big-data/introducing-hybrid-access-mode-for-aws-glue-data-catalog-to-secure-access-using-aws-lake-formation-and-iam-and-amazon-s3-policies/) # でのオブジェクトの作成 AWS Glue Data Catalog AWS Lake Formation は AWS Glue Data Catalog (データカタログ) を使用して、データレイク、データソース、変換、ターゲットに関するメタデータを保存します。メタデータは、データセット内の基になるデータに関するデータです。各 AWS アカウントには、 AWS リージョンごとに 1 つのデータカタログがあります。 データカタログ内のメタデータは、カタログ、データベース、テーブルで構成される 3 レベルのデータ階層に分類されます。さまざまなソースからのデータをカタログと呼ばれる論理コンテナにまとめます。各カタログは、Amazon Redshift データウェアハウス、 Amazon DynamoDB データベース、および Snowflake、MySQL の他 30 を超える外部データソースを含むサードパーティーデータソースソースなどのソースからのデータを表し、これらはフェデレーティッドコネクタを介して統合されています。データカタログに新しいカタログを作成して、S3 テーブルバケットまたは Redshift マネージドストレージ (RMS) にデータを保存することもできます。 テーブルには、スキーマ情報、パーティション情報、およびデータロケーションなどの基盤となるデータに関する情報が保存されます。データベースはテーブルのコレクションです。データカタログには、リソースリンクも含まれています。これは、外部アカウントで共有されるカタログ、データベース、テーブルへのリンクで、データレイク内のデータへのクロスアカウントアクセスに使用されます。 データカタログは、カタログ、データベース、テーブルを含むネストされたカタログオブジェクトです。これは AWS アカウント ID によって参照され、アカウントと のデフォルトカタログです AWS リージョン。データカタログは、3 レベルの階層 (catalog.database.table) を使用してテーブルを整理します。 + カタログ – データカタログの 3 つのレベルのメタデータ階層の最上位レベル。フェデレーションを利用して、データカタログに複数のカタログを追加できます。 + データベース – テーブルとビューで構成されるメタデータ階層の 2 番目のレベル。データベースは、Amazon Redshift や Trino などの多くのデータシステムではスキーマとも呼ばれます。 + テーブルとビュー – データカタログの 3 レベルデータ階層の 3 番目のレベル。 Amazon S3 内のすべての Iceberg テーブルは、カタログ ID = AWS アカウント ID を持つデフォルトのデータカタログに保存されます。フェデレーションを通じて、Amazon Redshift、Amazon S3 Table ストレージ、またはその他のサードパーティーデータソースにテーブルの定義 AWS Glue Data Catalog を保存するフェデレーションカタログを に作成できます。 **Topics** + [カタログの作成](creating-catalog.md) + [データベースを作成する](creating-database.md) + [テーブルの作成](creating-tables.md) + [AWS Glue Data Catalog ビューの構築](working-with-views.md) # カタログの作成 カタログは、 AWS Glue Data Catalogの 3 レベルのメタデータ階層の最上位レベルを表します。複数の方式を使用して、データをデータカタログに取り込み、マルチレベルカタログを作成できます。 外部データソースからカタログを作成する方法の詳細については、「[へのデータの取り込み AWS Glue Data Catalog](bring-your-data-overview.md)」を参照してください。 Lake Formation コンソールを使用してカタログを作成するには、データレイク管理者、または*カタログ作成者*としてサインインしている必要があります。カタログ作成者は、Lake Formation の `CREATE_CATALOG` アクセス許可を付与されているプリンシパルです。カタログ作成者のリストは、Lake Formation コンソールの **[管理ロールとタスク]** ページで確認することができます。このリストを表示するには、`lakeformation:ListPermissions` IAM 許可があり、データレイク管理者、または `CREATE_CATALOG` アクセス許可に対する付与オプションを持つカタログ作成者としてサインインしている必要があります。 # データベースを作成する Data Catalog のメタデータテーブルは、データベース内に保存されます。データベースは必要な数だけ作成でき、データベースごとに異なる Lake Formation 許可を付与できます。 データベースは、オプションのロケーションプロパティを持つことができます。通常、このロケーションは Lake Formation に登録されている Amazon Simple Storage Service (Amazon S3) ロケーション内にあります。ロケーションを指定するときは、プリンシパルに、データベースロケーション内のロケーションをポイントする Data Catalog テーブルを作成するためのデータロケーション許可は必要ありません。詳細については、「[Underlying data access control](access-control-underlying-data.md#data-location-permissions)」を参照してください。 Lake Formation コンソールを使用してデータベースを作成するには、データレイク管理者、または*データベース作成者*としてサインインしている必要があります。データベース作成者は、Lake Formation の `CREATE_DATABASE` 許可を付与されたプリンシパルです。データベース作成者のリストは、Lake Formation コンソールの **[Administrative roles and tasks]** (管理ロールとタスク) ページで確認することができます。このリストを表示するには、`lakeformation:ListPermissions` IAM 許可を持っており、データレイク管理者、または `CREATE_DATABASE` 許可に対する grant オプションを持つデータベース作成者としてサインインしている必要があります。 **データベースを作成する** 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で AWS Lake Formation コンソールを開き、データレイク管理者またはデータベース作成者としてサインインします。 1. ナビゲーションペインの **[Data catalog]** で **[Databases]** (データベース) を選択します。 1. **[Create database]** (データベースを作成) を選択します。 1. **[Create database]** (データベースの作成) ダイアログボックスで、データベース名、オプションのロケーション、およびオプションの説明を入力します。 1. オプションで、**[Use only IAM access control for new tables in this database]** (このデータベース内の新しいテーブルには IAM アクセス制御のみを使用する) を選択します。 このオプションについては、「[データレイクのデフォルト設定の変更](change-settings.md)」を参照してください。 1. **[Create database]** (データベースを作成) を選択します。 # テーブルの作成 AWS Lake Formation メタデータテーブルには、スキーマ情報、パーティション情報、データの場所など、データレイク内のデータに関する情報が含まれています。これらのテーブルは、AWS Glue Data Catalog に保存されます。これらは、データレイクにある基盤となるデータにアクセスし、Lake Formation 許可でそのデータを管理するために使用します。テーブルは、Data Catalog 内のデータベースに保存されます。 Data Catalog テーブルを作成するには、いくつかの方法があります。 + AWS Glue でクローラを実行する。「*AWS Glue デベロッパーガイド*」の「[クローラの定義](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html)」を参照してください。 + ワークフローを作成して実行する。「[Lake Formation でのワークフローを使用したデータのインポート](workflows.md)」を参照してください。 + Lake Formation コンソール、AWS Glue API、または AWS Command Line Interface (AWS CLI) を使用して、テーブルを手動で作成する。 + を使用してテーブルを作成します Amazon Athena。 + 外部アカウント内のテーブルへのリソースリンクを作成する。「[リソースリンクの作成](creating-resource-links.md)」を参照してください。 # Apache Iceberg テーブルの作成 AWS Lake Formation は、Amazon S3 に AWS Glue Data Catalog データが存在する で Apache Parquet データ形式を使用する Apache Iceberg テーブルの作成をサポートしています。Data Catalog のテーブルは、データストア内のデータを表すメタデータ定義です。デフォルトでは、Lake Formation は Iceberg v2 テーブルを作成します。v1 テーブルと v2 テーブルの違いについては、Apache Iceberg ドキュメントの「[形式バージョンの変更](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)」を参照してください。 [Apache Iceberg](https://iceberg.apache.org/) は、非常に大規模な分析データセット用のオープンテーブル形式です。Iceberg では、スキーマの変更 (スキーマ進化とも呼ばれます) を簡単に行うことができます。つまり、基になるデータを中断することなく、データテーブルの列を追加、名前変更、または削除できます。Iceberg はデータのバージョニングもサポートしているため、データの変更を経時的に追跡できます。これにより、タイムトラベル機能が有効になるため、過去のバージョンのデータにアクセスしてクエリを実行し、更新と削除の間に行われたデータの変更を分析できます。 Lake Formation コンソールまたは AWS Glue API の `CreateTable`オペレーションを使用して、データカタログに Iceberg テーブルを作成できます。詳細については、「[CreateTable アクション (Python: create\$1table)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)」を参照してください。 Data Catalog に Iceberg テーブルを作成する場合、読み取りと書き込みを実行できるように、Amazon S3 でテーブル形式とメタデータファイルのパスを指定する必要があります。 Lake Formation を使用して、Amazon S3 データロケーションの登録時にきめ細かなアクセスコントロール許可を使用して Iceberg テーブルを保護できます AWS Lake Formation。Amazon S3 のソースデータおよび Lake Formation に登録されていないメタデータの場合、アクセスは Amazon S3 および AWS Glue アクションの IAM アクセス許可ポリシーによって決まります。詳細については、「[Lake Formation 許可の管理](managing-permissions.md)」を参照してください。 **注記** Data Catalog は、パーティションの作成と Iceberg テーブルプロパティの追加をサポートしていません。 **Topics** + [前提条件](#iceberg-prerequisites) + [Iceberg テーブルの作成](#create-iceberg-table) ## 前提条件 Data Catalog に Iceberg テーブルを作成し、Lake Formation のデータアクセス許可を設定するには、次の要件を満たす必要があります。 1. **Lake Formation にデータが登録されていない状態で Iceberg テーブルを作成するために必要なアクセス許可。** Data Catalog にテーブルを作成するために必要なアクセス許可に加えて、テーブル作成者には次のアクセス許可が必要です。 + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:PutObject` + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:GetObject` + リソース arn:aws:s3:::\$1bucketName\$1 での `s3:DeleteObject` 1. **Lake Formation にデータが登録されている状態で Iceberg テーブルを作成するために必要なアクセス許可:** Lake Formation を使用してデータレイク内のデータを管理および保護するには、テーブルのデータを含む Amazon S3 ロケーションを Lake Formation に登録します。これは、Lake Formation が Athena、Redshift Spectrum、Amazon EMR などの AWS 分析サービスに認証情報を提供してデータにアクセスできるようにするためです。Amazon S3 ロケーションの登録の詳細については「[データレイクへの Amazon S3 ロケーションの追加](register-data-lake.md)」を参照してください。 Lake Formation に登録されている、基盤となるデータを読み書きするプリンシパルには、次のアクセス許可が必要です。 + `lakeformation:GetDataAccess` + `DATA_LOCATION_ACCESS` ロケーションに対するデータロケーション許可を持つプリンシパルは、すべての子ロケーションに対するロケーション許可も持っています。 データロケーション許可の詳細については、「[基盤となるデータのアクセスコントロール](access-control-underlying-data.md)」を参照してください。 圧縮を有効にするには、Data Catalog 内のテーブルを更新するアクセス許可を持つ IAM ロールを、サービスが引き受ける必要があります。詳細については、「[テーブル最適化の前提条件](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)」を参照してください。 ## Iceberg テーブルの作成 このページに記載されている AWS Command Line Interface ように、Lake Formation コンソールまたは を使用して Iceberg v1 および v2 テーブルを作成できます。 AWS Glue コンソールまたは を使用して Iceberg テーブルを作成することもできます AWS Glue クローラー。詳細については、「 AWS Glue デベロッパーガイド」の「[Data Catalog とクローラー](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)」を参照してください。 **Iceberg テーブルを作成するには** ------ #### [ Console ] 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. Data Catalog で **[テーブル]** を選択し、**[テーブルの作成]** ボタンを使用して次の属性を指定します。 + **テーブル名**: テーブルの名前を入力します。Athena を使用してテーブルにアクセスする場合は、「Amazon Athena ユーザーガイド」の[命名に関するヒント](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html)を使用します。 + **データベース**: 既存のデータベースを選択するか、新しいデータベースを作成します。 + **説明**: テーブルの説明。テーブルの内容を理解しやすくするために説明を記入できます。 + **テーブル形式**: **[テーブル形式]** として、[Apache Iceberg] を選択します。 ![\[Apache Iceberg テーブルオプションの選択とテーブル最適化オプション。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/table-optimization.png) + **テーブル最適化** + **圧縮** - データファイルをマージして書き換えて、古くなったデータを削除し、断片化されたデータをより大きい効率的なファイルに統合します。 + **スナップショット保持** - スナップショットは、Iceberg テーブルのタイムスタンプ付きバージョンです。スナップショット保持設定を使用すると、スナップショットを保持する期間と保持するスナップショットの数を強制できます。スナップショット保持オプティマイザーを設定すると、古い不要なスナップショットと、その基になる関連付けられたファイルを削除して、ストレージのオーバーヘッドを管理できます。 + **孤立ファイルの削除** — 孤立ファイルは、Iceberg テーブルメタデータによって参照されなくなったファイルです。これらのファイルは、特にテーブルの削除や ETL ジョブの失敗などのオペレーションの後、時間の経過と共に蓄積される可能性があります。孤立ファイルの削除を有効にすると AWS Glue 、 はこれらの不要なファイルを定期的に識別して削除し、ストレージを解放できます。 詳細については、「[Iceberg テーブルの最適化](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)」を参照してください。 + **IAM ロール**: 圧縮を実行する場合、サービスはユーザーに代わって IAM ロールを引き受けます。IAM ロールは、ドロップダウンを使用して選択できます。圧縮を有効にするために必要なアクセス許可がロールにあることを確認します。 必要なアクセス許可の詳細については、「[テーブル最適化の前提条件](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)」を参照してください。 + **ロケーション**: メタデータテーブルを保存する Amazon S3 内のフォルダへのパスを指定します。Iceberg が読み取りと書き込みを実行するには、メタデータファイルと Data Catalog 内のロケーションが必要です。 + **スキーマ**: **[列を追加]** を選択して、列と、列のデータ型を追加します。空のテーブルを作成して、後でスキーマを更新することもできます。Data Catalog は Hive データ型をサポートしています。詳細については、「[Hive データ型](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462)」を参照してください。 Iceberg では、テーブルを作成した後でスキーマとパーティションを進化させることができます。[[Athena クエリ]](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html) を使用してテーブルスキーマを更新し、[[Spark クエリ]](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions) を使用してパーティションを更新できます。 ------ #### [ AWS CLI ] ``` aws glue create-table \ --database-name iceberg-db \ --region us-west-2 \ --open-table-format-input '{ "IcebergInput": { "MetadataOperation": "CREATE", "Version": "2" } }' \ --table-input '{"Name":"test-iceberg-input-demo", "TableType": "EXTERNAL_TABLE", "StorageDescriptor":{ "Columns":[ {"Name":"col1", "Type":"int"}, {"Name":"col2", "Type":"int"}, {"Name":"col3", "Type":"string"} ], "Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/" } }' ``` ------ # Iceberg テーブルの最適化 Lake Formation は、 AWS 分析エンジンと ETL ジョブで使用される Apache Iceberg テーブルの管理とパフォーマンスを向上させるために、複数のテーブル最適化オプションをサポートしています。これらのオプティマイザーは、効率的なストレージの使用量、クエリパフォーマンスの向上、効果的なデータ管理を実現します。Lake Formation では、次の 3 種類のテーブルオプティマイザーを使用できます。 + **圧縮** - データ圧縮では、小さいデータファイルを圧縮してストレージの使用量を減らし、読み取りパフォーマンスを向上させます。古いデータを削除して、フラグメント化されたデータをより大規模で効率的なファイルに統合するために、データファイルはマージされ、書き換えられます。圧縮は、必要に応じて自動または手動でトリガーするように設定できます。 + **スナップショット保持** - スナップショットは、Iceberg テーブルのタイムスタンプ付きバージョンです。スナップショット保持設定を使用すると、スナップショットを保持する期間と保持するスナップショットの数を強制できます。スナップショット保持オプティマイザーを設定すると、古い不要なスナップショットと、その基になる関連付けられたファイルを削除して、ストレージのオーバーヘッドを管理できます。 + **孤立ファイルの削除** — 孤立ファイルは、Iceberg テーブルメタデータによって参照されなくなったファイルです。これらのファイルは、特にテーブルの削除や ETL ジョブの失敗などのオペレーションの後、時間の経過と共に蓄積される可能性があります。孤立ファイルの削除を有効にすると AWS Glue 、 はこれらの不要なファイルを定期的に識別して削除し、ストレージを解放できます。 AWS Glue コンソール、または AWS Glue API オペレーションを使用して、データカタログ内の個々の Iceberg テーブルの圧縮 AWS CLI、スナップショット保持、孤立ファイル削除オプティマイザを有効または無効にできます。 詳細については、「 AWS Glue デベロッパーガイド」の[「Iceberg テーブルの最適化](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)」を参照してください。 # テーブルの検索 AWS Lake Formation コンソールを使用して、名前、場所、データベースを含むデータカタログテーブルなどでデータカタログテーブルを検索できます。検索結果には、Lake Formation 許可を持つテーブルのみが表示されます。 **テーブルを検索する (コンソール)** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) で Lake Formation コンソールを開きます。 1. ナビゲーションペインで **[Table]** (テーブル) を選択します。 1. ページの上部にある検索フィールドにカーソルを置きます。このフィールドには、*[プロパティでテーブルを検索]* というプレースホルダテキストが表示されています。 検索に使用できるさまざまなテーブルプロパティを示す **[Properties]** (プロパティ) メニューが表示されます。 ![\[検索フィールドから [Properties] (プロパティ) メニューがドロップダウンされます。これには、[Name] (名前)、[Classification] (分類)、[Database] (データベース)、[Location] (ロケーション)、[Catalog ID] (カタログ ID) のエントリが含まれています。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/search-for-tables.png) 1. 以下のいずれかを実行します。 + テーブルが含まれるデータベースで検索します。 1. **[Properties]** (プロパティ) メニューから **[Databases]** (データベース) を選択し、表示される **[Databases]** (データベース) メニューからデータベースを選択するか、データベース名を入力して **[Enter]** キーを押します。 データベースにある、許可を持っているテーブルがリストされます。 1. (オプション) このリストをデータベース内の単一のテーブルに絞り込むには、もう 1 度検索フィールドにカーソルを置き、**[Properties]** (プロパティ) メニューから **[Name]** (名前) を選択して、表示される **[Tables]** (テーブル) メニューからテーブル名を選択するか、テーブル名を入力して **[Enter]** キーを押します。 単一のテーブルがリストされ、検索フィールドの下にデータベース名とテーブル名の両方がタイルとして表示されます。 ![\[検索フィールドの下に、[Database] (データベース) とラベル付けされた、選択したデータベース名が含まれるタイルと、[Table] (テーブル) とラベル付けされた、選択したテーブル名が含まれるタイルの 2 つのタイルがあります。タイルの右側には、[Clear filter] (フィルターをクリア) ボタンがあります。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/search-for-tables-with-filter.png) フィルターを調整するには、どちらかのタイルを閉じるか、**[Clear filter]** (フィルターをクリア) を選択します。 + 他のプロパティで検索します。 1. **[Properties]** (プロパティ) メニューから検索プロパティを選択します。 AWS アカウント ID で検索するには、**プロパティ**メニューから**カタログ ID** を選択し、有効な AWS アカウント ID (111122223333 など) を入力して **Enter **キーを押します。 ロケーションで検索するには、**[Properties]** (プロパティ) メニューから **[Location]** (ロケーション) を選択し、表示される **[Location]** (ロケーション) メニューからロケーションを選択します。選択したロケーション (Amazon S3 など) のルートロケーションにあるすべてのテーブルが返されます。 **を使用したテーブルの検索 AWS CLI** + 次の例は、部分検索を実行する方法を示しています。`--search-text` パラメータを使用すると、指定されたテキストがメタデータに含まれるテーブルを検索できます。この場合、名前、説明、またはその他のメタデータフィールドに「顧客」が含まれるすべてのテーブルが返されます。 ``` aws glue search-tables --search-text "customer" --region AWS リージョン --max-results 10 --sort-criteria "FieldName=Name,Sort=ASC" ``` # AWS アカウント間でのデータカタログテーブルとデータベースの共有 リソースに対する Lake Formation アクセス許可を外部 AWS アカウントに付与することで、Data Catalog リソース (データベースとテーブル) を外部アカウントと共有できます。ユーザーはその後、複数のアカウントにまたがるテーブルを結合してクエリするクエリとジョブを実行できるようになります。制限はいくつかありますが、Data Catalog リソースを別のアカウントと共有する場合、そのアカウント内のプリンシパルは、そのリソースをプリンシパルの Data Catalog 内にあるかのように操作することができます。 リソースは外部 AWS アカウントの特定のプリンシパルと共有しません。リソースは AWS アカウントまたは組織と共有します。 AWS 組織とリソースを共有する場合は、その組織にあるすべてのレベルのすべてのアカウントとリソースを共有することになります。共有後、各外部アカウントのデータレイク管理者が、そのアカウント内のプリンシパルに共有リソースに対する許可を付与する必要があります。 詳細については、「[Lake Formation でのクロスアカウントデータ共有](cross-account-permissions.md)」および「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」を参照してください。 **以下も参照してください。** [共有 Data Catalog テーブルとデータベースへのアクセスと表示](viewing-shared-resources.md) [前提条件](cross-account-prereqs.md) # AWS Glue Data Catalog ビューの構築 では AWS Glue Data Catalog、*ビュー*は、1 つ以上のテーブルを参照する SQL クエリによってコンテンツが定義される仮想テーブルです。Amazon Athena、Amazon Redshift、または Apache Spark の SQL エディタを使用して、EMR Serverless または AWS Glue バージョン 5.0 を使用して、最大 10 個のテーブルを参照するデータカタログビューを作成できます。ビューの基盤となる参照テーブルは、同じデータベースに属することも、同じデータカタログ内の異なるデータベースに属する AWS アカウントこともできます。 [Apache Hudi、Linux Foundation Delta Lake](https://hudi.incubator.apache.org/)[https://delta.io/](https://delta.io/)、[Apache Iceberg](https://iceberg.apache.org/) などのオープンテーブル形式 (OTF) の標準 AWS Glue テーブルとテーブルを参照できます。基盤となるデータは、Amazon S3 ロケーションに登録されています AWS Lake Formation。また、Lake Formation と共有された Amazon Redshift データ共有のフェデレーションテーブルからビューを作成することもできます。 ## データカタログビューと他のビュータイプとの区別 データカタログビューは、Apache Hive、Apache Spark、Amazon Athena のビューとは異なります。データカタログビューは のネイティブ機能であり AWS Glue Data Catalog、マルチダイアレクト定義によって作成されたビューです。Athena や Amazon Redshift Spectrum など、サポートされている分析サービスのいずれかを使用してデータカタログビューを作成し、サポートされている他の分析サービスを使用して同じビューにアクセスできます。一方、Apache Hive、Apache Spark、Athena のビューは、Athena や Amazon Redshift などの各分析サービスで個別に作成され、そのサービス内でのみ表示およびアクセスできます。 ## 定義者ビューとは 定義者ビューとは、そのビューを作成したプリンシパルのアクセス許可に基づいて動作する SQL ビューです。定義者ロールは、参照されるテーブルへのアクセスに必要なアクセス許可を持ち、ビューを定義する SQL ステートメントを実行します。定義者はビューを作成し、 AWS Lake Formationのきめ細かなアクセスコントロールを通じて他のユーザーと共有します。 ユーザーが定義者ビューにクエリを実行すると、クエリエンジンは、定義者ロールのアクセス許可を使用して基盤の参照テーブルにアクセスします。このアプローチにより、ユーザーはソーステーブルへの直接アクセスを必要とせずにビューを操作できるため、セキュリティが強化され、データのアクセス管理が簡素化されます。 定義者ビューを設定するには、定義者 IAM ロールをベーステーブルと同じ AWS アカウント内、またはクロスアカウント定義者ロールを使用する別のアカウント内に配置できます。定義者ロールに必要なアクセス許可の詳細については、「[ビュー作成の前提条件](views-prereqs.md)」を参照してください。 ## マルチダイアレクトビューのフレームワーク データカタログは、複数の構造化クエリ言語 (SQL) ダイアレクトを使用したビューの作成をサポートしています。SQL は、リレーショナルデータベースに情報を保存および処理するために使用される言語であり、各 AWS 分析エンジンは独自のバリエーションの SQL または SQL ダイアレクトを使用します。 サポートされている分析クエリエンジンのいずれかを使用して、1 つの SQL ダイアレクトでデータカタログビューを作成します。その後、サポートされている他の分析エンジン内の別の SQL ダイアレクトで、`ALTER VIEW` ステートメントを使用してビューを更新できます。ただし、各ダイアレクトは同じテーブル、列、データ型のセットを参照する必要があります。 `GetTable` API AWS CLI と AWS コンソールを使用して、ビューで使用できる複数のダイアレクトにアクセスできます。このように、データカタログビューには、サポートされているさまざまな分析エンジンから参照やクエリを行うことができます。 データカタログビューでは、複数のエンジンからクエリできる共通のビュースキーマとメタデータオブジェクトを定義することで、データレイク全体で統一されたビューを使用できます。 各ダイアレクトでスキーマがどのように解決されるかの詳細については、[API リファレンスへのリンク]()を参照してください。さまざまなタイプのマッチングルールの詳細については、[API ドキュメントの関連するセクションへのリンク]()を参照してください。 ## Lake Formation アクセス許可との統合 を使用して AWS Lake Formation 、ユーザーの AWS Glue Data Catalog ビューに対するアクセス許可管理を一元化できます。名前付きリソースメソッドまたは LF タグを使用して、Data Catalog ビューにきめ細かなアクセス許可を付与し、組織 AWS アカウント、 AWS 組織単位間で共有できます。リソースリンク AWS リージョン を使用して、 間でデータカタログビューを共有してアクセスすることもできます。これにより、ユーザーはデータソースを複製せずにデータアクセスを提供し、基になるテーブルを共有できます。 データカタログビューの `CREATE VIEW`DDL ステートメントは、Hudi、Delta Lake、Iceberg などのオープンテーブル形式 (OTF) の標準 AWS Glue テーブルとテーブルを、Lake Formation に登録されている Amazon S3 ロケーションに保存されている基盤となるデータとともに、Lake Formation と共有されている Amazon Redshift データ共有のフェデレーティッドテーブルで参照できます。テーブルのファイル形式は、ビューのクエリに使用されるエンジンがサポートしている形式であれば、任意の形式にすることができます。また、実行されているエンジンの組み込み関数を参照することもできますが、他のエンジン固有のリソースは許可されない場合があります。詳細については、「[データカタログビューの考慮事項と制限](views-notes.md)」を参照してください。 ## ユースケース データカタログビューの重要なユースケースを以下に示します。 + 1 つのビュースキーマでアクセス許可を作成および管理します。これにより、複数のエンジンで作成された重複したビューに対するアクセス許可に整合性がなくなるリスクを回避できます。 + 基になる参照テーブルに直接アクセス許可を付与しなくても、複数のテーブルを参照するビューに対するアクセス許可をユーザーに付与できます。 + LF タグを使用してテーブルの行レベルのフィルタリングを実現します (LF タグのカスケードは列レベルまでに限られます)。これは、ビューに LF タグを適用し、LF タグベースのアクセス許可をユーザーに付与することで行います。 ## ビューでサポートされている AWS 分析サービス 次の AWS 分析サービスは、データカタログビューの作成をサポートしています。 + Amazon Redshift + Amazon Athena バージョン 3 + EMR Serverless 上の Apache Spark + AWS Glue バージョン 5.0 の Apache Spark ## その他のリソース データカタログの詳細については、このガイドおよび以下のリソースを参照してください。 次のビデオでは、Athena と Amazon Redshift からビューを作成してクエリを実行する方法を説明しています。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL) **Topics** + [データカタログビューと他のビュータイプとの区別](#diff-views) + [定義者ビューとは](#definer-view) + [マルチダイアレクトビューのフレームワーク](#multi-dialect) + [Lake Formation アクセス許可との統合](#lf-view-integ) + [ユースケース](#views-use-cases) + [ビューでサポートされている AWS 分析サービス](#views-supported-engines) + [その他のリソース](#views-addtional-resources) + [ビュー作成の前提条件](views-prereqs.md) + [DDL ステートメントを使用したデータカタログビューの作成](create-views.md) + [AWS Glue APIs を使用したデータカタログビューの作成](views-api-usage.md) + [データカタログビューに対する許可の付与](grant-perms-views.md) + [マテリアライズドビュー](materialized-views.md) # ビュー作成の前提条件 + データカタログでビューを作成するには、参照テーブルの基礎となる Amazon S3 データの場所を Lake Formation に登録する必要があります。Lake Formation へのデータの登録の詳細については、「[データレイクへの Amazon S3 ロケーションの追加](register-data-lake.md)」を参照してください。 + データカタログビューを作成できるのは IAM ロールだけです。他の IAM ID はデータカタログビューを作成できません。 + ビューを定義する IAM ロールには、次のアクセス許可が必要です。 + すべての列を含む、すべての参照テーブルに対する `Grantable` オプション付きの Lake Formation `SELECT` アクセス許可。 + ビューが作成されるターゲットデータベースに対する Lake Formation `CREATE_TABLE` アクセス許可。 + Lake Formation と AWS Glue のサービスがロールを引き受ける信頼ポリシー。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerAssumeRole1", "Effect": "Allow", "Principal": { "Service": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ + AWS Glue および Lake Formation の iam:PassRole アクセス許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerPassRole1", "Action": [ "iam:PassRole" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] } } } ] } ``` ------ + AWS Glue および Lake Formation のアクセス許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "Glue:GetDatabase", "Glue:GetDatabases", "Glue:CreateTable", "Glue:GetTable", "Glue:GetTables", "Glue:BatchGetPartition", "Glue:GetPartitions", "Glue:GetPartition", "Glue:GetTableVersion", "Glue:GetTableVersions", "Glue:PassConnection", "lakeFormation:GetDataAccess" ], "Resource": "*" } ] } ``` ------ + `IAMAllowedPrincipals` グループに `Super` または `ALL` アクセス許可が付与されているデータベースにビューを作成することはできません。データベースに設定されている `IAMAllowedPrincipals` グループの `Super` アクセス許可を取り消すか、「[ステップ 4: データストアを Lake Formation 許可モデルに切り替える](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4)」を参照するか、または **[新しく作成されたテーブルのデフォルトのアクセス許可]** の **[このデータベースの新しいテーブルに IAM アクセスコントロールのみを使用]** ボックスをオフにして新しいデータベースを作成できます。 # DDL ステートメントを使用したデータカタログビューの作成 Athena、Amazon Redshift の SQL エディタと AWS Glue APIs/ を使用して AWS Glue Data Catalog ビューを作成できますAWS CLI。 SQL エディタを使用してデータカタログビューを作成するには、Athena または Redshift Spectrum を選択し、`CREATE VIEW` データ定義言語 (DDL) ステートメントを使用してビューを作成します。最初のエンジンのダイアレクトでビューを作成した後、2 番目のエンジンの `ALTER VIEW` DDL ステートメントを使用してダイアレクトを追加できます。 ビューを定義するときは、次の点を考慮することが重要です。 + **マルチダイアレクトビューの定義** - 複数のダイアレクトでビューを定義する場合、異なるダイアレクトのスキーマが一致している必要があります。各 SQL ダイアレクトは構文の仕様が若干異なります。データカタログビューを定義するクエリ構文は、どのダアレクトでもまったく同じ列リストに解決され、各列のタイプと名前も一致する必要があります。この情報はビューの `StorageDescriptor` に格納されます。各ダイアレクトでは、データカタログから、基になる同じテーブルオブジェクトを参照する必要もあります。 DDL を使用してビューに別のダイアレクトを追加するには、`ALTER VIEW` ステートメントを使用できます。`ALTER VIEW` ステートメントでビュー定義を更新しようとすると (ストレージ記述子やビューの基になるテーブルを変更しようとした場合など)、ステートメントから「Input and existing storage descriptor mismatch」というエラーが出力されます。ビューの列タイプを確実に一致させるには、SQL のキャスト操作を使用できます。 + **ビューの更新** - ビューを更新するには、`UpdateTable` API を使用できます。ストレージ記述子や参照テーブルを一致させずにビューを更新する場合は、`FORCE` フラグを指定できます (構文についてはエンジン SQL ドキュメントを参照してください)。強制更新後、ビューには強制された `StorageDescriptor` と参照テーブルが反映されます。それ以降の `ALTER VIEW` DDL は、変更された値と一致する必要があります。更新の結果として互換性のないダイアレクトが含まれるビューは、「Stale」ステータスになります。ビューのステータスは、Lake Formation コンソールおよび `GetTable` オペレーションを使用して確認できます。 + **varchar 列タイプの文字列としての参照** - Redshift Spectrum の varchar 列タイプを文字列にキャストすることはできません。Redshift Spectrum で varchar 列タイプを持つビューが作成され、後続のダイアレクトがそのフィールドを文字列として参照しようとすると、データカタログは `FORCE` フラグがなくてもそのフィールドを文字列として扱います。 + **複合タイプのフィールドの処理** - Amazon Redshift ではすべての複合タイプが [SUPER タイプ](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html)として扱われますが、Athena では複合タイプが指定されます。ビューに `SUPER` タイプのフィールドがあり、別のエンジンがその列を構造体 (`>`) などの特定の複合タイプとして参照する場合、データカタログはフィールドが特定の複合タイプであると想定し、`Force` フラグがなくてもそのタイプをストレージ記述子で使用します。 データカタログビューを作成および管理するための構文の詳細については、以下を参照してください。 + Amazon Athena ユーザーガイドの「[AWS Glue Data Catalog ビューの使用](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html)」。 + 「Amazon Athena ユーザーガイド」の「[Glue データカタログビューのクエリ構文](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html)」。 + Amazon Redshift データベース開発者ガイドの「[AWS Glue Data Catalogでのビューの作成](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html)」。 データカタログ内のビューに関連する SQL コマンドの詳細については、「[外部ビューの作成](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html)」、「[外部ビューの変更](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html)」、および「[外部ビューの削除](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html)」を参照してください。 データカタログビューを作成すると、ビューの詳細が Lake Formation コンソールに表示されます。 1. Lake Formation コンソールの [データカタログ] で **[ビュー]** を選択します。 1. 使用可能なビューのリストがビューページに表示されます。 1. リストからビューを選択すると、詳細ページにビューの属性が表示されます。 ![\[下側のセクションには 5 つのタブが水平に配置されており、各タブには対応する情報が含まれています。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/view-definition.png) Schema `Column` 行を選択し、**[LF タグの編集]** を選択して、タグ値の更新や新しい LF タグの割り当てを行います。 SQL 定義 使用可能な SQL 定義のリストが表示されます。**[SQL 定義を追加]** を選択し、クエリエンジンを選択して SQL 定義を追加します。`Edit definition` 列の下にあるクエリエンジン (Athena または Amazon Redshift) を選択して、SQL 定義を更新します。 LF タグ **[LF タグを編集**] を選択して、タグの値を編集したり、新しいタグを割り当てたりします。LF タグを使用すると、ビューに許可を付与できます。 クロスアカウントアクセス データカタログビューを共有した AWS アカウント組織と組織単位 (OUs) のリストを表示できます。 基礎となるテーブル ビューの作成に使用された SQL 定義で参照される基礎となるテーブルがこのタブに表示されます。 # AWS Glue APIs を使用したデータカタログビューの作成 AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html) API と [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs を使用して、データカタログでビューを作成および更新できます。`CreateTable` および `UpdateTable` オペレーションには、`ViewDefinition` を含む新しい `TableInput` 構造が用意されています。`SearchTables`、`GetTable`、`GetTables`、`GetTableVersion`、`GetTableVersions` オペレーションでは、ビューの出力構文に `ViewDefinition` が含められます。さらに、`GetTable` API の出力には新しい `Status` フィールドがあります。 サポートされている各クエリエンジンと Amazon Athena Amazon Redshift の SQL ダイアレクトを検証するために、2 つの新しい AWS Glue 接続を使用できます。 `CreateTable` および `UpdateTable` API は、ビューで使用する場合は非同期です。これらの API が複数の SQL ダイアレクトで呼び出されると、各エンジンで呼び出しが検証され、そのエンジンでダイアレクトを実行できるかどうか、および各ダイアレクトから返される結果のビューのスキーマが一致するかどうかが判定されます。この AWS Glue サービスは、これらの接続を使用して、分析エンジンへの内部呼び出しを行います。これらの呼び出しは、`CREATE VIEW` または `ALTER VIEW` SQL DDL がエンジンで実行されたとした場合にそのエンジンで行われる検証をシミュレートします。 指定された SQL が有効で、各ビューダイアレクトのスキーマが一致すれば、 AWS Glue API は結果を不可分的にコミットします。この不可分性により、複数のダイアレクトを持つビューをダウンタイムなしで作成または変更できます。 **Topics** + [ステータスを検証するための AWS Glue 接続の作成](views-api-usage-connection.md) + [ビューの生成ステータスの検証](views-api-usage-get-table.md) + [非同期状態とオペレーション](views-api-usage-async-states.md) + [非同期オペレーションでの作成失敗シナリオの例](views-api-usage-errors.md) # ステータスを検証するための AWS Glue 接続の作成 `CreateTable` または `UpdateTable`オペレーションを使用して AWS Glue Data Catalog ビューを作成または更新するには、検証用の新しいタイプの AWS Glue 接続を作成し、サポートされている分析エンジンに提供する必要があります。この接続は、Athena または Amazon Redshift でデータカタログビューを使用するために必要です。これらの接続は AWS CLI、、 AWS SDKs、または AWS Glue APIs を使用してのみ作成できます。を使用して AWS Glue 接続 AWS マネジメントコンソール を作成することはできません。 **注記** ビュー定義者のロールと `CreateTable` または `UpdateTable` を呼び出すロールが異なる場合は、両方の IAM ポリシーステートメントに `glue:PassConnection` アクセス許可が必要です。 詳細については、[「create-connection](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI ドキュメント」を参照してください。 **AWS CLI 接続を作成するための コマンド** 接続を作成するための AWS CLI コマンドを次に示します。 ``` aws glue create-connection --region us-east-1 --endpoint-url https://glue.us-east-1.amazonaws.com --cli-input-json file:///root/path/to/create-connection.json ``` **AWS CLI 入力 JSON** Amazon Redshift の場合: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_REDSHIFT", "Name": "views-preview-cluster-connection-2", "Description": "My first Amazon Redshift validation connection", "ConnectionProperties": { "DATABASE": "dev", "CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster" } } } ``` Amazon Athena の場合: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_ATHENA", "Name": "views-preview-cluster-connection-3", "Description": "My first Amazon Athena validation connection", "ConnectionProperties": { "WORKGROUP_NAME": "workgroup-name" } } } ``` # ビューの生成ステータスの検証 `CreateTable` または `UpdateTable` オペレーションを実行すると、`GetTable` API 出力の `Status` フィールドに、ビューの作成ステータスの詳細が示されます。テーブルがまだ存在しない`create`リクエストの場合、 は非同期プロセス中に空のテーブル AWS Glue を作成します。`GetTable` の呼び出し時には、オプションでブール値の `IncludeStatusDetails` フラグを渡すことができます。このフラグは、リクエストに関する診断情報を出力するように指定します。エラーが発生すると、このフラグは、各ダイアレクトの個々のステータスを含むエラーメッセージを提供します。 ビューの作成、読み取り、更新、削除 (CRUD) オペレーション中のエラーは、 AWS Glue/Lake Formation サービスでの処理中、または Amazon Redshift または Athena でのビュー SQL 検証中に発生する可能性があります。エンジンの検証中にエラーが発生した場合、 AWS Glue サービスは、エンジンから返されたエラーメッセージを提供します。 **ステータスフィールド** 以下はステータスフィールドです。 + Status - さまざまなジョブのタイプに依存しない汎用のステータスです。 + QUEUED + IN\$1PROGRESS + SUCCESS + FAILED + Action - テーブルで呼び出されたアクションを示します。現時点では、`CREATE` または `UPDATE` オペレーションのみが利用可能です。 ビューを操作するときは、`UPDATE` オペレーションと `CREATE` オペレーションを区別することが重要です。オペレーションタイプによって、テーブルのクエリをどのように進めるかべきが決まります。 `UPDATE` オペレーションは、テーブルがデータカタログに既に存在することを意味します。この場合、以前に作成されたテーブルへのクエリを問題なく続行できます。一方、`CREATE ` オペレーションは、これまでテーブルが正常に作成されたことはないことを示します。テーブルが `CREATE` としてマークされている場合、そのテーブルはまだシステムに存在しないため、クエリを試みても失敗します。したがって、テーブルのクエリを試みる前にオペレーションタイプ (UPDATE または CREATE) を特定する必要があります。 + RequestedBy - 非同期の変更をリクエストしたユーザーの ARN。 + UpdatedBy - キャンセルや変更のリクエストなど、非同期変更プロセスを最後に手動で変更したユーザーの ARN。 + Error - このフィールドは状態が **FAILED** の場合にのみ存在します。これは親レベルの例外メッセージです。ダイアレクトごとに異なるエラーが発生する場合があります。 + ErrorCode - 例外のタイプ。 + ErrorMessage - 例外の簡単な説明。 + RequestTime - 変更が開始された時刻を示す ISO 8601 形式の日付文字列。 + UpdateTime - 状態が最後に更新された時刻を示す ISO 8601 形式の日付文字列。 # 非同期状態とオペレーション `glue:CreateTable` リクエストを実行すると、データカタログビューの非同期作成が開始されます。以下のセクションでは、このドキュメントで、`glue:GetTable`レスポンスで使用できる AWS Glue ビュー`Status`の について説明します。簡潔にするために、このセクションではレスポンス全体は省略しています。 ``` { "Table": { ... "Status": { ... "Action": "CREATE", "State": "QUEUED", } } } ``` 上記の属性はどちらも重要な診断情報を表し、非同期オペレーションの状態と、このビューで実行できるアクションを示します。これらの属性が取り得る値は次のとおりです。 1. `Status.Action` 1. CREATE 1. UPDATE 1. `Status.State` 1. QUEUED 1. IN\$1PROGRESS 1. SUCCESS 1. FAILED 重要な点として、データカタログビューの更新の中には、非同期オペレーションを必要としないものがあることにも注意してください。例えば、テーブルの `Description` 属性を更新しようとしているとします。これは非同期オペレーションを必要としないため、結果のテーブルメタデータには `Status` が含まれず、属性は `NULL` になります。 ``` { "Table": { ..., "Description": "I changed this attribute!" } } ``` 次に、このトピックでは、上記のステータス情報が AWS Glue ビューで実行できるオペレーションにどのように影響するかについて説明します。 **glue:CreateTable** この API は、Glue テーブルに対する `glue:CreateTable` の動作と比べて変更はありません。`CreateTable` は、まだ存在しない任意のテーブル名に対して呼び出すことができます。 **glue:UpdateTable** このオペレーションは、以下のステータス情報を持つ AWS Glue ビューでは実行できません。 1. Action == CREATE かつ State == QUEUED 1. Action == CREATE かつ State == IN\$1PROGRESS 1. Action == CREATE かつ State == FAILED 1. Action == UPDATE かつ State == QUEUED 1. Action == UPDATE かつ State == IN\$1PROGRESS まとめると、データカタログビューは以下の要件を満たしている場合にのみ更新できます。 1. 最初に正常に作成された場合。 1. Action == CREATE かつ State == SUCCESS 1. 非同期更新オペレーションの後、最終状態に達している場合。 1. Action == UPDATE かつ State == SUCCESS 1. Action == UPDATE かつ State == FAILED 1. 同期更新の結果として State 属性が `NULL` になっている場合。 **glue:DeleteTable** このオペレーションは、 がどの AWS Glue テーブルに対してどのように`glue:DeleteTable`機能するかと比較して変更されません。データカタログビューは、その状態に関係なく削除できます。 **glue:GetTable** このオペレーションは、 がどの AWS Glue テーブルに対してどのように`glue:GetTable`機能するかと比較して変更されません。ただし、データカタログビューが最初に正常に作成されるまで (`Action == CREATE and State == SUCCESS`)、分析エンジンからデータカタログビューにクエリを実行することはできません。データカタログビューが最初に正常に作成された後は、ステータスに関係なくビューをクエリできます。 **注記** このセクションのすべての情報は、`GetTable`、`GetTables`、`SearchTables` などのすべてのテーブル読み取り API に適用されます。 # 非同期オペレーションでの作成失敗シナリオの例 ここでは、ビューに対する `CreateTable` または `UpdateTable` API コールの結果として発生する可能性のある代表的なエラータイプの例を示します。SQL クエリの失敗のエラーサーフェスは大きいため、これらはすべてを網羅するものではありません。 ## シナリオ 1: Amazon Redshift クエリの失敗 Amazon Redshift に指定されたクエリにテーブル名のスペルミスが含まれているため、検証時にテーブルがデータカタログ内に見つかりません。結果のエラーは、ビューの `GetTable` レスポンスの `Status` フィールドに示されます。 `GetTable` リクエスト: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-72", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` レスポンス: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:40:06-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "UpdateTime": "2024-07-11T11:39:37-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" } } ] } } } } ``` ## シナリオ 2: 無効な Amazon Redshift 接続 次の例の Amazon Redshift 接続は、指定されたクラスター/サーバーレスエンドポイントに存在しない Amazon Redshift データベースを参照しているため、正しくありません。Amazon Redshift はビューを検証できず、`GetTable` レスポンスの `Status` フィールドにはエラー (Amazon Redshift からの `"State": "FAILED"`) が示されます。 `GetTable` リクエスト: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-73", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection-malformed" } ] } } } ``` `GetTable` レスポンス: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:43:40-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:43:38-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" } } ] } } } } ``` ## シナリオ 3: Athena クエリの失敗 ここでの Athena の SQL は、クエリにデータベース名のスペルミスが含まれているため無効です。Athena のクエリ検証によってこれが検出され、結果のエラーが `GetTable` 呼び出しの `Status` オブジェクトを通じて表面化されます。 `GetTable` リクエスト: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-70", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` レスポンス: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10: 41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "SUCCESS" } ] } } } } ``` ## シナリオ 4: ストレージ記述子の不一致 Athena ダイアレクトに指定された SQL では `col1` と `col2` が選択されますが、Redshift の SQL では `col1` のみが選択されます。これにより、ストレージ記述子の不一致エラーが発生します。 `GetTable` リクエスト: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-71", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` レスポンス: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:23:19-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:22:49-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } } ] } } } } ``` # データカタログビューに対する許可の付与 でビューを作成したら AWS Glue Data Catalog、ビューに対するデータレイクのアクセス許可を、、組織 AWS アカウント、組織単位全体のプリンシパルに付与できます。アクセス許可は、LF タグまたは名前付きリソース方式を使用して付与できます。リソースのタグ付けの詳細については、「[Lake Formation のタグベースのアクセス制御](tag-based-access-control.md)」を参照してください。ビューに対するアクセス許可の直接付与の詳細については、「[名前付きリソース方式を使用したビューに対するアクセス権限の付与](granting-view-permissions.md)」を参照してください。 # マテリアライズドビュー **Topics** + [マテリアライズドビューを他のビュータイプと区別する](#materialized-views-differentiating) + [ユースケース](#materialized-views-use-cases) + [主要なコンセプト](#materialized-views-key-concepts) + [マテリアライズドビューのアクセス許可](#materialized-views-permissions) + [マテリアライズドビューの作成と管理](#materialized-views-creating-managing) + [ストレージとデータアクセス](#materialized-views-storage-access) + [アクセス AWS Lake Formation 許可との統合](#materialized-views-lake-formation) + [モニタリングとデバッグ](#materialized-views-monitoring-debugging) + [更新ジョブの管理](#materialized-views-managing-refresh-jobs) + [モニタリングとトラブルシューティング](#materialized-views-monitoring-troubleshooting) + [考慮事項と制限事項](#materialized-views-considerations-limitations) AWS Glue データカタログでは、マテリアライズドビューは、SQL クエリの事前計算された結果を Apache Iceberg 形式で保存するマネージドテーブルです。アクセスされるたびにクエリを実行する標準の Data Catalog ビューとは異なり、マテリアライズドビューはクエリ結果を物理的に保存し、基盤となるソーステーブルが変更されるたびに更新します。Amazon Athena、Amazon EMR、または で Apache Spark バージョン 3.5.6 以降を使用してマテリアライズドビューを作成できます AWS Glue。 マテリアライズドビューは、 AWS Glue Data Catalog に登録された Apache Iceberg テーブルを参照し、事前計算されたデータは Amazon S3 Tables バケットまたは Amazon S3 汎用バケットに Apache Iceberg テーブルとして保存されるため、Amazon Athena、Amazon Redshift、サードパーティーの Iceberg 互換エンジンなどの複数のクエリエンジンからアクセスできます。 ## マテリアライズドビューを他のビュータイプと区別する マテリアライズドビューは、 AWS Glue データカタログビュー、Apache Spark ビュー、Amazon Athena ビューと根本的に異なります。データカタログビューは、アクセスされるたびに SQL クエリ定義を実行する仮想テーブルですが、マテリアライズドビューは事前に計算されたクエリ結果を物理的に保存します。これにより、冗長な計算が不要になり、頻繁にアクセスされる複雑な変換のクエリパフォーマンスが大幅に向上します。 マテリアライズドビューは、ETL ジョブまたはカスタム Spark AWS Glue ジョブで構築された従来のデータ変換パイプラインとも異なります。変更検出、増分更新、ワークフローオーケストレーションを処理するカスタムコードを記述する代わりに、標準の SQL 構文を使用してマテリアライズドビューを定義します。Data Catalog AWS Glue は、フルマネージド型のコンピューティングインフラストラクチャを使用して、ソーステーブルを自動的にモニタリングし、変更を検出し、マテリアライズドビューを更新します。 ## ユースケース マテリアライズドビューの重要なユースケースは次のとおりです。 + **複雑な分析クエリの高速化** – 高価な結合、集計、ウィンドウ関数を事前に計算するマテリアライズドビューを作成します。Spark エンジンは、事前計算された結果を使用するように後続のクエリを自動的に書き換え、クエリのレイテンシーとコンピューティングコストを削減します。 + **データ変換パイプラインの簡素化** – 変更検出、増分更新、ワークフローオーケストレーションを処理する複雑な ETL ジョブを、シンプルな SQL ベースのマテリアライズドビュー定義に置き換えます。 AWS Glue Data Catalog は、すべての運用上の複雑さを自動的に管理します。 + **管理されたデータアクセスでセルフサービス分析を有効にする** – 未加工データをビジネス対応データセットに変換する厳選されたマテリアライズドビューを作成します。基盤となるソーステーブルを公開することなくマテリアライズドビューへのアクセス権をユーザーに付与し、セルフサービス分析を強化しながらセキュリティ管理を簡素化します。 + **機械学習の特徴量エンジニアリングを最適化する** – ML モデルの特徴量変換を実装するマテリアライズドビューを定義します。自動更新機能により、ソースデータの進化に合わせて機能ストアを最新の状態に保ち、増分更新によりコンピューティングコストを最小限に抑えます。 + **効率的なデータ共有の実装** – 特定のコンシューマーのデータをフィルタリングおよび変換するマテリアライズドビューを作成します。を使用してアカウントとリージョン間でマテリアライズドビューを共有するため AWS Lake Formation、一元化されたガバナンスを維持しながら、データの重複を排除できます。 ## 主要なコンセプト ### 自動更新 自動更新は、ソーステーブルを継続的にモニタリングし、定義したスケジュールに従ってマテリアライズドビューを更新する機能です。マテリアライズドビューを作成するときは、1 時間間隔の時間ベースのスケジューリングを使用して更新頻度を指定できます。 AWS Glue Data Catalog は、マネージド Spark コンピューティングインフラストラクチャを使用してバックグラウンドで更新オペレーションを実行し、変更検出と増分更新のすべての側面を透過的に処理します。 更新間隔の間にソースデータが変更されると、マテリアライズドビューは一時的に古くなります。マテリアライズドビューに直接アクセスするクエリは、次のスケジュールされた更新が完了するまで、古い結果を返します。最新のデータへの即時アクセスが必要なシナリオでは、`REFRESH MATERIALIZED VIEW`SQL コマンドを使用して手動更新を実行できます。 ### 増分更新 増分更新は、マテリアライズドビュー全体を再計算するのではなく、前回の更新以降にソーステーブルで変更されたデータのみを処理する最適化手法です。 AWS Glue Data Catalog は Apache Iceberg のメタデータレイヤーを活用して、ソーステーブルの変更を効率的に追跡し、マテリアライズドビューのどの部分に更新が必要かを判断します。 このアプローチは、フル更新オペレーションと比較して、コンピューティングコストと更新期間を大幅に削減します。特に、更新サイクル間でデータ変更の割合がごくわずかである大規模なデータセットの場合です。増分更新メカニズムは自動的に動作します。変更されたデータを検出または処理するためにカスタムロジックを記述する必要はありません。 ### 自動クエリ書き換え 自動クエリ書き換えは、Amazon Athena、Amazon EMR、および の Spark エンジンで使用できるクエリ最適化機能です AWS Glue。ベーステーブルに対してクエリを実行すると、Spark オプティマイザはクエリプランを分析し、使用可能なマテリアライズドビューがクエリをより効率的に満たすことができるかどうかを自動的に判断します。適切なマテリアライズドビューが存在する場合、オプティマイザはベーステーブルを処理する代わりに、事前に計算された結果を使用するようにクエリを透過的に書き換えます。 この最適化は、アプリケーションコードやクエリステートメントを変更することなく行われます。Spark オプティマイザは、自動クエリ書き換えがマテリアライズドビューが最新で、正確な結果を生成できる場合にのみ適用されるようにします。マテリアライズドビューが古くなったり、クエリ要件に完全に一致しない場合、オプティマイザはベーステーブルに対して元のクエリプランを実行し、パフォーマンスよりも正確性を優先します。 ### ビュー定義ロール マテリアライズドビューは、ビュー定義ロールと呼ばれる、マテリアライズドビューを作成した IAM ロールのアクセス許可に基づいて動作します。定義者ロールには、マテリアライズドビュー定義で参照されるすべてのベーステーブルへの読み取りアクセスと、ターゲットデータベースへのテーブルアクセス許可の作成が必要です。Data Catalog AWS Glue がマテリアライズドビューを更新すると、ソーステーブルにアクセスして更新された結果を書き込むための定義ロールを引き受けます。 このセキュリティモデルを使用すると、基になるソーステーブルに対する直接アクセス許可を付与することなく、マテリアライズドビューへのアクセス権をユーザーに付与できます。ビュー定義ロールがベーステーブルにアクセスできなくなった場合、アクセス許可が復元されるまで後続の更新オペレーションは失敗します。 ## マテリアライズドビューのアクセス許可 マテリアライズドビューを作成および管理するには、 AWS Lake Formation アクセス許可を設定する必要があります。マテリアライズドビューを作成する IAM ロール (定義ロール) には、ソーステーブルとターゲットデータベースに対する特定のアクセス許可が必要です。 ### 定義者ロールに必要なアクセス許可 定義者ロールには、次の Lake Formation アクセス許可が必要です。 + ソーステーブル – 行、列、またはセルフィルターが適用されていない SELECT または ALL アクセス許可 + ターゲットデータベース – CREATE\$1TABLE アクセス許可 + AWS Glue データカタログ – GetTable および CreateTable API アクセス許可 マテリアライズドビューを作成すると、定義ロールの ARN がビュー定義に保存されます。 AWS Glue データカタログは、自動更新オペレーションを実行するときにこのロールを引き受けます。定義者ロールがソーステーブルへのアクセスを失った場合、アクセス許可が復元されるまで更新オペレーションは失敗します。 ### AWS Glue ジョブの IAM アクセス許可 AWS Glue ジョブの IAM ロールには、次のアクセス許可が必要です。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetDatabase", "glue:GetDatabases", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:*:/aws-glue/*" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" } ] } ``` マテリアライズドビューの自動更新に使用するロールには、ロールに対する iam:PassRole アクセス許可が必要です。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Glue でマテリアライズドビューを自動的に更新するには、サービスがロールを引き受けることができる次の信頼ポリシーもロールに必要です。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` マテリアライズドビューが S3 Tables バケットに保存されている場合は、ロールに次のアクセス許可も追加する必要があります。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3tables:PutTableMaintenanceConfiguration" ], "Resource": "arn:aws:s3tables:*:123456789012:*" } ] } ``` ### マテリアライズドビューへのアクセスを付与する マテリアライズドビューをクエリするアクセス許可を他のユーザーに付与するには、 AWS Lake Formation を使用してマテリアライズドビューテーブルに対する SELECT アクセス許可を付与します。ユーザーは、マテリアライズドビューをクエリできます。基盤となるソーステーブルに直接アクセスする必要はありません。 Lake Formation アクセス許可の設定の詳細については、「 AWS Lake Formation デベロッパーガイド」の「データカタログリソースに対するアクセス許可の付与と取り消し」を参照してください。 ## マテリアライズドビューの作成と管理 Spark エンジンの `CREATE MATERIALIZED VIEW` SQL ステートメントを使用してマテリアライズドビューを作成します。ビュー定義は、変換ロジック、ターゲットデータベースとテーブル名、およびオプションの更新設定を定義する SQL クエリを指定します。集計、複数のテーブル間の結合、フィルター、ウィンドウ関数など、複雑な変換を定義できます。 ``` CREATE MATERIALIZED VIEW sales_summary AS SELECT region, product_category, SUM(sales_amount) as total_sales, COUNT(DISTINCT customer_id) as unique_customers FROM sales_transactions WHERE transaction_date >= current_date - interval '90' day GROUP BY region, product_category; ``` 自動更新を設定するには、ビュー定義に更新スケジュールを含めます。 ``` CREATE MATERIALIZED VIEW sales_summary SCHEDULE REFRESH EVERY 1 HOUR AS SELECT region, product_category, SUM(sales_amount) as total_sales FROM sales_transactions GROUP BY region, product_category; ``` マテリアライズドビューは、 `REFRESH MATERIALIZED VIEW` コマンドを使用していつでも手動で更新できます。 ``` REFRESH MATERIALIZED VIEW sales_summary; ``` 既存のマテリアライズドビューの更新スケジュールを変更するには、 `ALTER MATERIALIZED VIEW`ステートメントを使用します。 ``` ALTER MATERIALIZED VIEW sales_summary ADD SCHEDULE REFRESH EVERY 2 HOURS; ``` ### ネストされたマテリアライズドビュー 他のマテリアライズドビューをベーステーブルとして参照するマテリアライズドビューを作成し、複数ステージのデータ変換を有効にできます。ネストされたマテリアライズドビューを作成すると、 AWS Glue データカタログは依存関係を追跡し、マテリアライズドビュー階層を通じて更新を自動的に伝達します。ベースマテリアライズドビューが更新されると、それに依存するすべてのダウンストリームマテリアライズドビューがそれに応じて更新されます。 この機能を使用すると、複雑な変換を論理ステージに分解し、保守性を向上させ、データの鮮度要件に基づいて変換レイヤーを選択的に更新できます。 ## ストレージとデータアクセス マテリアライズドビューは、事前計算された結果を Apache Iceberg テーブルとして S3 Tables バケットまたは AWS アカウント内の汎用 S3 バケットに保存します。 AWS Glue Data Catalog は、S3 Tables の自動最適化機能を通じて、圧縮やスナップショットの保持など、Iceberg テーブルのメンテナンスのあらゆる側面を管理します。 マテリアライズドビューは Iceberg テーブルとして保存されるため、Amazon Athena、Amazon Redshift、サードパーティーの分析プラットフォームなど、Iceberg 互換エンジンから直接読み取ることができます。このマルチエンジンアクセシビリティにより、事前計算されたデータは、データ重複や形式変換なしで分析エコシステム全体でアクセス可能になります。 ## アクセス AWS Lake Formation 許可との統合 を使用して AWS Lake Formation 、マテリアライズドビューに対するきめ細かなアクセス許可を管理できます。ビュー作成者は自動的にマテリアライズドビューの所有者になり、 AWS Lake Formationの名前付きリソースメソッドまたは LF タグを使用して他のユーザーまたはロールにアクセス許可を付与できます。 マテリアライズドビューに対する`SELECT`アクセス許可をユーザーに付与すると、ユーザーは基盤となるソーステーブルにアクセスすることなく、事前に計算された結果をクエリできます。このセキュリティモデルは、データアクセス管理を簡素化し、最小特権の原則を実装して、ユーザーが必要とする特定のデータ変換にのみアクセスできるようにします。 AWS Lake Formationのクロスアカウント共有機能を使用して、 AWS アカウント、 AWS 組織、組織単位間でマテリアライズドビューを共有できます。リソースリンクを使用して AWS リージョン間でマテリアライズドビューにアクセスすることもできます。これにより、分散データアクセスによる一元化されたデータガバナンスが可能になります。 ## モニタリングとデバッグ AWS Glue Data Catalog は、すべてのマテリアライズドビューの更新オペレーションと関連するメトリクスを Amazon CloudWatch に発行します。CloudWatch メトリクスを使用して、更新の開始時刻、終了時刻、期間、処理されたデータボリューム、更新ステータスをモニタリングできます。更新オペレーションが失敗すると、エラーメッセージと診断情報が CloudWatch Logs にキャプチャされます。 更新ジョブが予想期間を超えたとき、または繰り返し失敗したときに通知を受信するように CloudWatch アラームを設定できます。 AWS Glue データカタログは、更新実行の成功と失敗の両方について変更イベントを に発行するため、マテリアライズドビューオペレーションをより広範なワークフローオートメーションに統合できます。 マテリアライズドビューの現在のステータスを確認するには、`DESCRIBE MATERIALIZED VIEW`SQL コマンドを使用します。このコマンドは、古いステータス、最終更新タイムスタンプ、更新スケジュール設定などのメタデータを返します。 ## 更新ジョブの管理 ### 手動更新の開始 スケジュールされた間隔外に即時更新をトリガーします。 必要なアクセス許可: API コールを行うために使用される AWS 認証情報には、マテリアライズドビューに対する`glue:GetTable`アクセス許可が必要です。 S3 Tables Catalog の場合: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id :s3tablescatalog/ \ --database-name \ --table-name ``` ルートカタログの場合: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ### 更新ステータスの確認 特定の更新ジョブのステータスを取得します。 ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id ``` ### 更新履歴の一覧表示 マテリアライズドビューのすべての更新ジョブを表示します。 ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name ``` **注記** S3 テーブル`:s3tablescatalog/`の場合は 、ルートカタログ``の場合は を使用します。 ### 実行中の更新の停止 進行中の更新ジョブをキャンセルします。 ``` aws glue stop-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ## モニタリングとトラブルシューティング マテリアライズドビューの更新ジョブをモニタリングするには、次の 3 つの方法があります。 ### CloudWatch メトリクス CloudWatch のすべてのマテリアライズドビュー更新ジョブの集計メトリクスを表示します。 使用可能なメトリクス: + AWSディメンションを含む /Glue 名前空間: + CatalogId: カタログ識別子 + DatabaseName: マテリアライズドビューを含むデータベース + TableName: マテリアライズドビュー名 + TaskType: をMaterializedViewRefresh」に設定する コンソールでの表示: 1. CloudWatch コンソール → メトリクスに移動する 1. Select AWS/Glue 名前空間 1. ディメンションでフィルタリング: CatalogId、DatabaseName、TableName、TaskType 1. ジョブの成功、失敗、期間に関するメトリクスを表示する CloudWatch メトリクスクエリの例: ``` {AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh ``` の使用 AWS CLI: ``` aws cloudwatch get-metric-statistics \ --namespace AWS/Glue \ --metric-name \ --dimensions Name=CatalogId,Value= \ Name=DatabaseName,Value= \ Name=TableName,Value= \ Name=TaskType,Value=MaterializedViewRefresh \ --start-time \ --end-time \ --period 3600 \ --statistics Sum \ --region ``` ### CloudWatch Logs 個々の更新タスク実行の詳細な実行ログを表示します。 ロググループ: `/aws-glue/materialized-views/` `` は UUID (abc12345-def6-7890-ghij-klmnopqrstuv など) です。 ログの表示: ``` # List log streams for a task run aws logs describe-log-streams \ --log-group-name /aws-glue/materialized-views/ \ --region # Get log events aws logs get-log-events \ --log-group-name /aws-glue/materialized-views/ \ --log-stream-name \ --region ``` CloudWatch コンソールの場合: 1. CloudWatch → ロググループに移動する 1. /aws-glue/materialized-views/ の検索 1. タスク実行 ID を持つロググループを選択する 1. 詳細な実行ログ、エラー、Spark ジョブ出力を表示する ### 通知 更新ジョブの状態の変更に関するリアルタイム通知のイベントをサブスクライブします。 使用可能なイベントタイプ: + Glue マテリアライズドビューの更新タスクが開始されました + Glue マテリアライズドビューの更新タスクが正常に完了しました + Glue マテリアライズドビューの更新タスクに失敗しました + Glue マテリアライズドビューの自動更新呼び出しの失敗 ルールの作成: ``` aws events put-rule \ --name materialized-view-refresh-notifications \ --event-pattern '{ "source": ["aws.glue"], "detail-type": [ "Glue Materialized View Refresh Task Started", "Glue Materialized View Refresh Task Succeeded", "Glue Materialized View Refresh Task Failed", "Glue Materialized View Auto-Refresh Invocation Failure" ] }' \ --region ``` ターゲットの追加 (SNS トピックなど) ``` aws events put-targets \ --rule materialized-view-refresh-notifications \ --targets "Id"="1","Arn"="arn:aws:sns:::" \ --region ``` ### 更新ステータスの表示 AWS Glue API を使用してマテリアライズドビューの更新ジョブのステータスを確認します。 ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id \ --region ``` または、最近のすべての更新実行を一覧表示します。 ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name \ --region ``` これは以下を示しています。 + 最終更新時間 + 更新ステータス (成功、失敗、実行中、停止) + タスク実行 ID + エラーメッセージ (失敗した場合) 一般的な更新状態: + RUNNING: 更新ジョブは現在実行中です + 成功: 更新が正常に完了しました + 失敗: 更新でエラーが発生しました + STOPPED: 更新が手動でキャンセルされました 更新失敗のトラブルシューティング: 更新が失敗した場合は、以下を確認してください。 1. IAM アクセス許可: 定義ロールがすべてのベーステーブルとマテリアライズドビューの場所にアクセスできることを確認します。 1. ベーステーブルの可用性: 参照されるすべてのテーブルが存在し、アクセス可能であることを確認する 1. クエリの有効性: SQL クエリが Spark SQL ダイアレクトに対して有効であることを確認する 1. リソース制限: アカウントの同時更新制限に達したかどうかを確認します。 GetMaterializedViewRefreshTaskRun API を使用して、詳細なエラーメッセージを取得します。 ## 考慮事項と制限事項 + マテリアライズドビューは、 AWS Glue データカタログに登録された Apache Iceberg テーブルをベーステーブルとしてのみ参照できます。 + ビューの作成と自動クエリの書き換えは、Amazon Athena、Amazon EMR、および AWS Glue (バージョン 5.1) 全体で Apache Spark バージョン 3.5.6 以降の Spark エンジンでのみ使用できます。 + マテリアライズドビューは、最終的にベーステーブルと一致します。更新ウィンドウ中に、マテリアライズドビューに直接アクセスするクエリが古いデータを返す場合があります。現在のデータにすぐにアクセスするには、手動更新を実行します。 + 自動更新の最小間隔は 1 時間です。より頻繁な更新を必要とするユースケースでは、 `REFRESH MATERIALIZED VIEW` コマンドを使用してプログラムで手動更新を実行します。 + クエリの書き換えでは、パフォーマンスよりも正確性が優先されます。マテリアライズドビューが古くなった場合、またはクエリ要件を正確に満たすことができない場合、Spark エンジンはベーステーブルに対して元のクエリを実行します。 # Lake Formation でのワークフローを使用したデータのインポート AWS Lake Formation では、*ワークフロー*を使用してデータをインポートできます。ワークフローは、データレイクにデータをインポートするためのデータソースとスケジュールを定義します。これは、データレイクのロードとアップデートのプロセスをオーケストレートするために使用される、AWS Glue クローラー、ジョブ、およびトリガーのコンテナです。 **Topics** + [Lake Formation のブループリントとワークフロー](workflows-about.md) + [ワークフローの作成](workflows-creating.md) + [ワークフローの実行](workflows-running.md) # Lake Formation のブループリントとワークフロー ワークフローは、複雑なマルチジョブの抽出、変換、ロード (ETL) アクティビティをカプセル化します。ワークフローは、データのロードと更新をオーケストレートするために、AWS Glue クローラー、ジョブ、およびトリガーを生成します。Lake Formation は、ワークフローを単一のエンティティとして実行し、追跡します。ワークフローは、オンデマンドで、またはスケジュールに従って実行されるように設定できます。 **注記** Spark Parquet ライターは、列名での特殊文字をサポートしていません。これはライター自体の技術的な制限であり、設定の問題ではありません。 Lake Formation で作成するワークフローは、AWS Glue コンソールに DAG (Directed Acyclic Graph) として表示されます。各 DAG ノードは、ジョブ、クローラ、またはトリガーです。進捗状況のモニタリングとトラブルシューティングを行うために、ワークフロー内の各ノードのステータスを追跡することができます。 Lake Formation ワークフローが完了すると、ワークフローを実行したユーザーには、ワークフローが作成する Data Catalog テーブルに対する Lake Formation の `SELECT` 許可が付与されます。 ワークフローは AWS Glue で作成することもできますが、Lake Formation ではブループリントからワークフローを作成できるため、Lake Formation でのワークフローの作成は、よりシンプルで、自動的です。Lake Formation は、以下のタイプのブループリントを提供します。 + **[Database snapshot]** (データベーススナップショット) – すべてのテーブルからのデータを、JDBC ソースからデータレイクにロードまたは再ロードします。除外パターンに基づいて、一部のデータをソースから除外することができます。 + **[Incremental database]** (増分データベース) – 以前に設定されたブックマークに基づいて、新しいデータだけを JDBC ソースからデータレイクにロードします。これに含める JDBC ソースデータベース内の個々のテーブルは、ユーザーが指定します。ブックマーク列とブックマークのソート順をテーブルごとに選択して、以前にロードされたデータを把握しておきます。一連のテーブルに対して増分データベースブループリントを初めて実行すると、ワークフローがそれらのテーブルからすべてのデータをロードして、次回の増分データベースブループリントの実行のためにブックマークを設定します。このため、データソース内の各テーブルをパラメータとして指定しておけば、データベーススナップショットブループリントではなく、増分データベースブループリントを使用して、すべてのデータをロードすることができます。 + [**Log file**] (ログファイル) – AWS CloudTrail、Elastic Load Balancing ログ、Application Load Balancer ログなどのログファイルソースからのデータを一括でロードします。 以下の表を使用して、データベーススナップショットと増分データベースブループリントのどちらを使用するかを決定してください。 | データベーススナップショットを使用する状況 | 増分データベースを使用する状況 | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/workflows-about.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/workflows-about.html) | **注記** Lake Formation によって作成されたブループリントとワークフローを編集することはできません。 # ワークフローの作成 開始する前に、`LakeFormationWorkflowRole` ロールに必要なデータ許可とデータロケーション許可が付与されていることを確認してください。これは、ワークフローが Data Catalog にメタデータテーブルを作成し、Amazon S3 内のターゲットロケーションにデータを書き込むことができるようにするためです。詳細については、「[(オプション) ワークフロー用の IAM ロールを作成する](initial-lf-config.md#iam-create-blueprint-role)」および「[Lake Formation 許可の概要](lf-permissions-overview.md)」を参照してください。 **注記** Lake Formation は、`GetTemplateInstance`、`GetTemplateInstances`、および `InstantiateTemplate` オペレーションを使用して、ブループリントからワークフローを作成します。これらのオペレーションは一般には公開されておらず、ユーザーに代わってリソースを作成するために内部でのみ使用されます。ユーザーは、ワークフローを作成するための CloudTrail イベントを受け取ります。 **ブループリントからワークフローを作成する** 1. AWS Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) を開きます。データレイク管理者として、またはデータエンジニア許可を持つユーザーとしてサインインします。詳細については、「[Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md)」を参照してください。 1. ナビゲーションペインで **[Blueprints]** (ブループリント) を選択してから、**[Use blueprint]** (ブループリントを使用) を選択します。 1. **[Use a blueprint]** (ブループリントの使用) ページで、ブループリントタイプを選択するタイルを選択します。 1. **[Import source]** (インポートソース) で、データソースを指定します。 JDBC ソースからインポートしている場合は、以下を指定します。 + ****[Database connection]**** (データベース接続) – リストから接続を選択します。AWS Glue コンソールを使用して、追加の接続を作成します。接続の JDBC ユーザー名とパスワードによって、ワークフローがアクセスできるデータベースオブジェクトが決まります。 + ****[Source data path]**** (ソースデータパス) – データベース製品に応じて、**/**/*
*、または **/*
* を入力します。Oracle データベース と MySQL は、パス内のスキーマをサポートしません。** または *
* は、パーセント (%) 文字に置き換えることができます。例えば、システム識別子 (SID) が `orcl` の Oracle データベースの場合は、`orcl/%` を入力して、接続で指定されているユーザーがアクセスできるすべてのテーブルをインポートします。 **重要** このフィールドでは、大文字と小文字が区別されます。いずれかのコンポーネントで大文字と小文字の不一致がある場合は、ワークフローが失敗します。 MySQL データベースを指定する場合、AWS Glue ETL はデフォルトで Mysql5 JDBC ドライバーを使用するため、MySQL8 はネイティブでサポートされていません。「*AWS Glue デベロッパーガイド*」の「[JDBC connectionType の値](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-jdbc)」で説明されているように、`customJdbcDriverS3Path` パラメータを使用するように ETL ジョブスクリプトを編集して、MySQL8 をサポートする別の JDBC ドライバーを使用することができます。 ログファイルからインポートしている場合は、ワークフローに指定するロール (「ワークフローロール」) に、データソースへのアクセスに必要な IAM 許可があることを確認してください。例えば、AWS CloudTrail ログをインポートするには、ユーザーが、ワークフローの作成中に CloudTrail ログのリストを確認するための `cloudtrail:DescribeTrails` と `cloudtrail:LookupEvents` 許可を持っており、ワークフローロールが Amazon S3 内の CloudTrail ロケーションに対する許可を持っている必要があります。 1. 以下のいずれかを実行します。 + **[Database snapshot]** (データベーススナップショット) のブループリントタイプの場合は、オプションで、1 つ、または複数の除外パターンを指定することによってインポートするデータのサブセットを特定します。これらの除外パターンは、Unix スタイルの `glob` パターンです。これらは、ワークフローによって作成されるテーブルのプロパティとして保存されます。 利用可能な除外パターンの詳細については、「*AWS Glue デベロッパーガイド*」の「[包含パターンと除外パターン](https://docs.aws.amazon.com/glue/latest/dg/define-crawler.html#crawler-data-stores-exclude)」を参照してください。 + **[Incremental database]** (増分データベース) のブループリントタイプの場合は、以下のフィールドを指定します。インポートするテーブルごとに行を追加してください。 **[Table name] (テーブル名)** インポートするテーブル。すべて小文字にする必要があります。 **[Bookmark keys] (ブックマークキー)** ブックマークキーを定義する列名のカンマ区切りのリスト。空白になっている場合は、新しいデータの判別にプライマリキーが使用されます。各列の大文字と小文字は、データソースで定義されている大文字と小文字と一致する必要があります。 プライマリキーがデフォルトのブックマークキーとして認められるのは、それがギャップを生じることなく連続的に増加または減少している場合のみです。プライマリキーをブックマークキーとして使用したいが、ギャップがあるという場合は、プライマリキー列をブックマークキーとして指定する必要があります。 **[Bookmark order] (ブックマークの順序)** **[Ascending]** (昇順) を選択すると、ブックマークされた値よりも大きい値を持つ行が新しい行として識別されます。**[Descending]** (降順) を選択すると、ブックマークされた値より小さい値を持つ行が新しい行として識別されます。 **[Partitioning scheme] (パーティショニングスキーム)** (オプション) スラッシュ (/) で区切られた、パーティショニングキー列のリスト。例えば、` year/month/day` などです。 ![\[コンソールの [Incremental data] (増分データ) セクションには、[Table name] (テーブル名)、[Bookmark keys] (ブックマークキー)、[Bookmark order] (ブックマークの順序)、および [Partitioning scheme] (パーティショニングスキーム)のフィールドがあります。行は追加または削除 (それぞれの行が異なるテーブル用のもの) することができます。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/incremental-data.png) 詳細については、「*AWS Glueデベロッパーガイド*」の「[ジョブのブックマークを使用した処理済みデータの追跡](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html)」を参照してください。 1. **[Import target]** (インポートターゲット) で、ターゲットデータベース、ターゲット Amazon S3 ロケーション、およびデータ形式を指定します。 ワークフローロールに、データベースと Amazon S3 ターゲットロケーションに対する必要な Lake Formation 許可があることを確認してください。 **注記** 現在、ブループリントはターゲットでのデータの暗号化をサポートしていません。 1. インポートの頻度 を選択します。 **[Custom]** (カスタム) オプションでは、`cron` 式を指定することができます。 1. **[Import options]** (インポートオプション) で以下を実行します。 1. ワークフロー名を入力します。 1. ロールには、「[(オプション) ワークフロー用の IAM ロールを作成する](initial-lf-config.md#iam-create-blueprint-role)」で作成したロール `LakeFormationWorkflowRole` を選択します。 1. オプションで、テーブルプレフィックスを指定します。プレフィックスは、ワークフローが作成する Data Catalog テーブルの名前の前に付加されます。 1. **[Create]** (作成) を選択し、ワークフローが正常に作成されたことコンソールが報告するまで待機します。 **ヒント** 以下のエラーメッセージが表示されましたか? `User: arn:aws:iam:::user/ is not authorized to perform: iam:PassRole on resource:arn:aws:iam:::role/...` 表示された場合は、すべてのポリシーの ** が有効な AWS アカウント番号に置き換えられていることを確認してください。 **以下も参照してください。** [Lake Formation のブループリントとワークフロー](workflows-about.md) # ワークフローの実行 ワークフローは、Lake Formation コンソール、AWS Glue コンソール、AWS Glue コマンドラインインターフェイス (AWS CLI)、または API を使用して実行することができます。 **ワークフローを実行する (Lake Formation コンソール)** 1. AWS Lake Formation コンソール ([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)) を開きます。データレイク管理者として、またはデータエンジニア許可を持つユーザーとしてサインインします。詳細については、「[Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md)」を参照してください。 1. ナビゲーションペインで **[Blueprints]** (ブループリント) を選択します。 1. **[Blueprints]** (ブループリント) ページで、ワークフローを選択します。次に、**[Actions]** (アクション) メニューで **[Start]** (開始) を選択します。 1. ワークフローの実行に伴って、その進捗状況を **[Last run status]** (最終実行ステータス) 列で確認します。更新ボタンを随時選択します。 ステータスは、**[RUNNING]** (実行中) から、**[Discovering]** (検出中)、**[Importing]** (インポート中)、**[COMPLETED]** (完了) と移行します。 ワークフローが完了すると、以下のようになります。 + Data Catalog に新しいメタデータテーブルがある。 + データがデータレイクに取り込まれる。 ワークフローが失敗する場合は、以下を実行します。 1. ワークフローを選択します。**[Actions]** (アクション) を選択してから、**[View graph]** (グラフを表示) を選択します。 AWS Glue コンソールでワークフローが開きます。 1. そのワークフローが選択されていることを確認し、**[History]** (履歴) タブを選択します。 1. **[History]** (履歴) で、最新の実行を選択し、**[View run details]** (実行の詳細を表示) を選択します。 1. 動的 (ランタイム) グラフで失敗したジョブまたはクローラを選択し、エラーメッセージを確認します。障害が発生したノードは赤色または黄色のいずれかになっています。 **以下も参照してください。** [Lake Formation のブループリントとワークフロー](workflows-about.md)