AWS Lake Formation と Trusted Identity Propagation でクロスリージョンのきめ細かなデータアクセスを実現する

本記事は 2026 年 10 月 23 日に公開された「Enable cross-Region fine-grained data access with AWS Lake Formation and Trusted Identity Propagation」を翻訳したものです。

AWS に分析データを保存している組織では、2 つの要件を同時に満たす必要があることが少なくありません。1 つ目は、各ユーザーが閲覧を許可されたデータだけにアクセスを限定する、きめ細かなアクセス制御です。2 つ目はユーザー単位での監査で、すべてのクエリを、共有の AWS Identity and Access Management (IAM) ロールではなく、実際にクエリを実行した本人までたどれる必要があります。

AWS IAM Identity Center の Trusted Identity Propagation (信頼できる ID の伝播、TIP) は、どちらの要件も満たします。一度サインインすれば、ユーザーの ID がクライアントアプリケーションからクエリエンジンを経て Lake Formation とストレージレイヤーまで伝播するため、すべてのリクエストが実際のユーザーとして認可され、すべてのクエリが AWS CloudTrail に記録されます。

今回、TIP がリージョンをまたいで使えるようになりました。IAM Identity Center は、ユーザー、グループ、セッション情報といった ID オブジェクトを、選択したすべての AWS リージョンにレプリケートします。そのため、スタック内のサービスが異なるリージョンにまたがっていても、同じユーザー ID を認識できます。

本記事は 3 回シリーズの第 1 回で、基盤の構築と、Amazon SageMaker Unified Studio (Amazon Athena と Amazon Redshift) からのクエリを扱います。第 2 回では Amazon Quick を、第 3 回では Amazon EMR を取り上げます。

概要

本記事では、プロデューサーがアジアパシフィック (シドニー) リージョン (ap-southeast-2) からデータを共有し、コンシューマーが南米 (サンパウロ) リージョン (sa-east-1) から本人の ID でクエリします。同じパターンに沿った 2 つのケースを紹介します。ケース 1 では、Lake Formation で管理する Amazon Simple Storage Service (Amazon S3) のデータを共有し、Amazon SageMaker Unified Studio (Athena) からクエリします。ケース 2 では、AWS Glue Data Catalog に登録したデータ共有で Amazon Redshift のデータを共有し、Amazon Redshift Serverless からクエリします。

Cross-Region, cross-account architecture: a Sydney producer governs data with Lake Formation and a São Paulo consumer queries it

図 1: クロスリージョンかつクロスアカウントのアーキテクチャ

図の左側では、ID プロバイダーが System for Cross-domain Identity Management (SCIM) プロトコルでユーザーとグループを AWS IAM Identity Center に同期します。IAM Identity Center は管理アカウントの組織インスタンスとして動作し、同期された ID を利用中のすべてのリージョンにレプリケートします。中央では、シドニーのプロデューサーアカウントが AWS Lake Formation で Amazon S3 と Amazon Redshift の両方のデータを一元管理します。プロデューサーがテーブルやデータベースを共有すると、その共有は右側に示したサンパウロのコンシューマーアカウントに届きます。コンシューマーアカウントでは、リソースリンクを使って共有データをローカルのデータと同じようにクエリできます。右側では、データアナリストが企業の認証情報で Amazon SageMaker Unified Studio にサインインします。Trusted Identity Propagation を有効にしていれば、アナリストの ID は Lake Formation へのすべてのリクエストに引き継がれます。Lake Formation は、ユーザーが引き受けた IAM ロールではなく、ユーザーが誰であるかに基づいて各クエリを認可します。

本記事の例では、3 つのリージョンにまたがる 3 つのアカウントを使います。プロデューサーアカウントは、ap-southeast-2 (シドニー) で Amazon S3、AWS Glue Data Catalog、Lake Formation、Amazon Redshift Serverless を運用します。コンシューマーアカウントは、SageMaker Unified Studio または Amazon Redshift を使って sa-east-1 (サンパウロ) からクエリします。IAM Identity Center は、管理アカウントの us-east-1 (バージニア) で動作します。

Lake Formation によるクロスアカウント共有は AWS Organizations の組織をまたいでも行えますが、TIP との統合ではさらに厳しい要件が加わります。ユーザーの ID を伝播させるには、プロデューサーアカウントとコンシューマーアカウントが同じ組織に属し、IAM Identity Center の同じ組織インスタンスを共有している必要があります。アカウントやリージョンを追加するときは、コンシューマー側の手順を繰り返します。今回のリリースにより、Lake Formation がすべてのリクエストを実際のユーザーとして認可したまま、共有データを別のリージョンからクエリできるようになりました。

構成要素の連携

本アーキテクチャは 4 つの機能で成り立っています。IAM Identity Center はリージョンをまたいだ単一の ID 基盤を提供するため、すべてのアカウントで同じユーザーとグループを利用できます。スタック内の各サービスが Trusted Identity Propagation に対応しているため、ユーザーの ID は IAM ロールに置き換わることなく、クライアントアプリケーションから Lake Formation まで伝わります。IAM Identity Center 経由で企業の認証情報を使ってサインインすると、ユーザーの ID を組織内のリージョンとアカウント全体で利用できます。最後に、AWS Resource Access Manager (AWS RAM) の共有とリソースリンクがリージョン間の隔たりを埋めるため、コンシューマーはプロデューサーのリージョンでカタログ化されたデータをクエリできます。

前提条件

始める前に、以下を準備してください。

プロデューサーアカウントとコンシューマーアカウントが同じ組織に属していること。
IAM Identity Center の組織インスタンスがあり、ユーザーとグループがプロビジョニングされていること。
運用するすべてのリージョンに IAM Identity Center がレプリケートされていること。詳しくは「Deploy AWS applications and access AWS accounts across multiple Regions with IAM Identity Center」を参照してください。
対象のアカウントで、AWS Lake Formation、AWS Glue、AWS RAM、Amazon Simple Storage Service (Amazon S3)、Amazon SageMaker Unified Studio、Amazon Redshift を管理する権限があること。
プロデューサーの Lake Formation の Data catalog settings で、Use only IAM access control のオプションのチェックを外しておくこと。
本記事で使う AWS のサービスが、本ウォークスルーで使うリージョンのプロデューサーアカウントとコンシューマーアカウントの両方で、AWS IAM Identity Center と統合されていること。詳しくは「信頼できる ID の伝播のユースケース」を参照してください。

ケース 1 では、S3 のデータとそのカタログは終始プロデューサーのアカウントとリージョンにとどまり、シドニー (ap-southeast-2) の Lake Formation で管理されます。リージョンをまたぐのはクエリそのものです。別のアカウントにいるコンシューマーは、サンパウロ (sa-east-1) から接続し、SageMaker Unified Studio で Amazon Athena を使って同じデータをクエリします。ケース 1 はフェデレーテッドクエリのパターンで、データはその場にとどまり、クエリだけがリージョンをまたぎます。カタログとデータを一方のリージョンに、クライアントとクエリをもう一方のリージョンに分けて置くからこそ、単なるクロスアカウントではなく、本当の意味でのクロスリージョン構成になります。

パート 1: プロデューサーアカウント (シドニー、ap-southeast-2)

リージョンに関する注意: 本ウォークスルーでは ap-southeast-2 (プロデューサー) と sa-east-1 (コンシューマーとクエリ) を使います。プレースホルダーの箇所は、ご自身のリージョンとアカウント ID に置き換えてください。Lake Formation のクロスアカウントの権限付与は、すべてプロデューサーのリージョンで行う必要があります。唯一の例外はリソースリンクとその Describe 権限の付与で、どちらもコンシューマーのクエリ用リージョンで行います。

ステップ 1.1: サンプルデータファイルを作成する

次の内容で customers.csv という名前のファイルを作成します。

customer_id,first_name,last_name,email,city,state,signup_date
1,Martha,Rivera,martha.rivera@example.com,Seattle,WA,2024-01-15
2,Jane,Doe,jane.doe@example.com,Portland,OR,2024-02-20
3,Mateo,Jackson,mateo.j@example.com,Denver,CO,2024-03-10
4,Saanvi,Sarkar,saanvi.s@example.com,Austin,TX,2024-04-05
5,Mary,Major,mary.m@example.com,Chicago,IL,2024-05-12

ステップ 1.2: S3 バケットを作成してデータをアップロードする

プロデューサーアカウント (ap-southeast-2) で Amazon S3 コンソールを開きます。
Create bucket を選択し、一意の名前 (例: amzn-s3-demo-sydney-lakehouse-bucket) を入力して、Create bucket を選択します。
バケットを開いて customers という名前のフォルダを作成し、そこに customers.csv をアップロードします。

ステップ 1.3: Lake Formation の登録用ロールを作成する (sts:SetContext 付き)

Lake Formation が S3 バケットを読み取るときに引き受ける IAM ロールを作成します。データレイクのロケーションの登録と、TIP の場合も含めた認証情報の発行に使うロールです。Lake Formation のサービスリンクロールは使わないでください。サービスリンクロールには sts:SetContext が含まれていません。

IAM コンソールを開き、Roles、Create role の順に選択します。
Trusted entity type で Custom trust policy を選択し、以下の信頼ポリシーを貼り付けます。
Next を選択し、マネージドポリシーのアタッチは飛ばして、Next を選択します。
ロールに名前 (例: LakeFormation-DataLocation-role) を付け、Create role を選択します。
ロールを開き、Add permissions、Create inline policy の順に選択して、以下のアクセス許可ポリシーを貼り付けます。
インラインポリシーに名前 (例: LF-S3Access) を付けて保存します。

信頼ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lakeformation.amazonaws.com" },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext"
      ]
    }
  ]
}

アクセス許可ポリシー (バケット名は置き換えてください):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::<your-s3-bucket>",
        "arn:aws:s3:::<your-s3-bucket>/*"
      ]
    }
  ]
}

注: 信頼ポリシーの sts:SetContext アクションは TIP に必要です。Lake Formation のサービスリンクロールにはこのアクションが含まれていないため、ここではカスタムロールが必要になります。

ステップ 1.4: Lake Formation に S3 のロケーションを登録する

ap-southeast-2 で Lake Formation コンソールを開きます。
Administration で Data lake locations を選択し、Register location を選択します。
Amazon S3 path に、バケットのパス (例: s3://amzn-s3-demo-sydney-lakehouse-bucket) を入力します。
IAM role で、ステップ 1.3 で作成した LakeFormation-DataLocation-role を選択します。
Permission mode で Lake Formation を選択し、Register location を選択します。

ステップ 1.5: AWS Glue データベースを作成する

Lake Formation コンソールの Data catalog で Databases を選択します。
Create database を選択します。
データベース名 (本記事では sydney_lakehouse) を入力し、Create database を選択します。

ステップ 1.6: テーブルを手動で作成する

ap-southeast-2 で AWS Glue コンソールを開きます。
Data Catalog で Tables、Add table、Add table manually の順に選択します。
Table name に customers と入力します。
Database で sydney_lakehouse を選択します。
データストアに Amazon S3 を選択し、ロケーションを s3://amzn-s3-demo-sydney-lakehouse-bucket/customers/ に設定します。
データ形式に CSV を選択し、区切り文字にカンマ (,) を指定します。
次の列でスキーマを定義します。
CSV のヘッダー行をスキップするため、テーブルプロパティ skip.header.line.count を値 1 で追加します。
内容を確認し、Create を選択します。

列名	データ型
customer_id	string
first_name	string
last_name	string
email	string
city	string
state	string
signup_date	string

コンソールで CSV のテーブルを作成する場合は、すべての列を string として定義してください。このテーブルで使う CSV のシリアライザー/デシリアライザーは、date や bigint などの型付きの列を確実には解析できません。必要に応じて、クエリ内で値をキャストしてください (例: CAST(signup_date AS date))。

ステップ 1.7: 外部 (コンシューマー) アカウントに DATABASE 権限を付与する

Lake Formation コンソールで、Permissions、Data lake permissions、Grant の順に選択します。
Principals で External accounts を選択し、コンシューマーのアカウント ID (<CONSUMER_ACCOUNT_ID>) を入力します。
Named Data Catalog resources を選択します。Databases で、対象のデータベース (本記事では sydney_lakehouse) を選択します。
Database permissions で Describe を選択し、Grantable permissions でも Describe を選択します。
Grant を選択します。

ステップ 1.8: 外部 (コンシューマー) アカウントに TABLE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で External accounts を選択し、<CONSUMER_ACCOUNT_ID> を入力します。
Named Data Catalog resources を選択します。Databases で sydney_lakehouse を、Tables で customers を選択します。
Table permissions で Select と Describe を選択し、Grantable permissions でも同じものを選択します。
Grant を選択します。

ステップ 1.9: IAM Identity Center のグループ/ユーザーに DATABASE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で IAM Identity Center を選択し、グループまたはユーザー (例: admin) を選択します。
Named Data Catalog resources を選択します。Databases で、対象のデータベース (本記事では sydney_lakehouse) を選択します。
Database permissions で Describe を選択します。
Grant を選択します。

ステップ 1.10: IAM Identity Center のグループ/ユーザーに TABLE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で IAM Identity Center を選択し、グループまたはユーザー (例: admin) を選択します。
Named Data Catalog resources を選択します。Databases と Tables で、対象のデータベースとテーブル (本記事では sydney_lakehouse と customers) を選択します。
Table permissions で Select と Describe を選択します。
Grant を選択します。

注: 両アカウントが IAM Identity Center の 1 つの組織インスタンスを共有しているため、プロデューサーは基になるテーブルの権限を IAM Identity Center のグループに直接付与できます。コンシューマーが付与するのは、ローカルのリソースリンクの Describe 権限だけです (ステップ 2.3)。

以上で、プロデューサー側の設定は完了です。コンシューマーアカウントとユーザーの両方に、必要な Lake Formation の権限が付与されました。確認するには、Lake Formation コンソールで Data lake permissions を開き、データベースとテーブルの権限付与が 4 件表示されることを確かめます。

パート 2: コンシューマーアカウント

パート 2 では、コンシューマーアカウントに切り替えて AWS RAM の共有を承諾し、共有データベースを参照するリソースリンクを作成して、ユーザーにリソースリンクへのアクセス権を付与します。以上の手順を終えると、コンシューマーアカウントから別のリージョンにあるプロデューサーのデータをクエリできる状態になります。

AWS RAM コンソールを開き、ap-southeast-2 (シドニー) に切り替えます。
Shared with me で Resource shares を選択します。
プロデューサーアカウントからのリソース共有を選択し、Accept resource share を選択します。

ステップ 2.2: リソースリンクを作成する (sa-east-1 リージョン)

Lake Formation コンソールを開き、sa-east-1 に切り替えます。
Data catalog で Databases、Create resource link の順に選択します。
Resource link name に名前 (例: rl_sydney_s3_datalake) を入力します。
Shared database’s Region で Asia Pacific (Sydney) ap-southeast-2 を選択します。
Shared database で、対象のデータベースを選択します。本記事のデータベース名は sydney_lakehouse です。
Shared database’s catalog ID には、プロデューサーのアカウント ID が自動的に入力されます。
Create を選択します。

ステップ 2.3: IAM Identity Center のグループ/ユーザーにリソースリンクの Describe 権限を付与する

Lake Formation コンソール (sa-east-1) で、Permissions、Data lake permissions、Grant の順に選択します。
Principals で IAM Identity Center を選択し、グループまたはユーザー (例: admin) を選択します。
Named Data Catalog resources を選択します。Databases で rl_sydney_s3_datalake を選択します。
Resource link permissions で Describe を選択します。
Grant を選択します。

パート 3: SageMaker Unified Studio (sa-east-1)

プロデューサーアカウントとコンシューマーアカウントの設定が終わったら、クエリ用リージョンで SageMaker Unified Studio をセットアップし、クロスリージョンクエリを実行します。

ステップ 3.1: SageMaker Unified Studio ドメインを作成する

sa-east-1 で Amazon SageMaker コンソールを開き、Unified Studio、Create domain の順に選択します。クイックセットアップの手順は、SageMaker Unified Studio 管理ガイドを参照してください。IAM Identity Center との統合はすでに完了しているため、ドメインの設定で IAM Identity Center のユーザーを指定できます。

SageMaker Unified Studio domain configuration with an IAM Identity Center user added

図 2: Amazon SageMaker Unified Studio ドメインへの SSO ユーザーの追加

SageMaker Unified Studio で Trusted Identity Propagation (TIP) を有効にするには、本記事の次のセクションを参照してください。

SageMaker Unified Studio で TIP を有効にする。
SageMaker Unified Studio ドメインのユーザーアクセスを有効にする。
プロジェクトメンバーを追加する。
Unified Studio で SQL analytics プロジェクトを作成する。本記事では、プロジェクト名に my_project_idc を使います。

ステップ 3.2: TIP を有効にする

IAM Identity Center のユーザーとして Sign in with SSO を選択し、SageMaker Unified Studio ポータルにサインインします。

IAM Identity Center sign-in page for the SageMaker Unified Studio portal

図 3: Amazon SageMaker Unified Studio に SSO でサインイン

プロジェクト (my_project_idc) を開き、Query Editor に移動します。
Catalogs で AwsDataCatalog を選択します。
rl_sydney_s3_datalake、tables の順に選択し、customers を選択します。
customers テーブルの横にある三点アイコンを選択し、Preview data を選択します。

Query Editor previewing the customers table through the rl_sydney_s3_datalake resource link

図 4: Amazon SageMaker Unified Studio から Amazon S3 のデータにアクセス

次のスクリーンショットのように、Athena のコンピューティングを使ってクエリが自動的に実行されます。

SELECT * FROM "AwsDataCatalog"."rl_sydney_s3_datalake"."customers" LIMIT 10;

Query results returning customer rows from the Sydney S3 bucket through the resource link

図 5: Amazon SageMaker Unified Studio で Amazon S3 のデータをプレビュー

シドニーにあるプロデューサーの S3 バケットから顧客データが返されます。Lake Formation で管理されたデータに sa-east-1 のリソースリンク経由でアクセスしており、ユーザーの ID は TIP で伝播しています。

ケース 2 はケース 1 と同じくカタログを一元化するパターンに沿いますが、コンシューマーは Athena ではなく Amazon Redshift Serverless でデータをクエリします。アナリストは、SageMaker Unified Studio の Amazon Redshift のクエリ機能を使ってクエリを実行します。

パート 1: プロデューサーアカウント (シドニー、ap-southeast-2)

Amazon Redshift のコンシューマークラスターが、ap-southeast-2 と sa-east-1 の両方のリージョンで IAM Identity Center と連携するよう設定されていることを確認してください。設定手順は「Integrate Identity Provider (IdP) with Amazon Redshift Query Editor V2 using AWS IAM Identity Center for seamless Single Sign-On」を参照してください。

ステップ 1.1: サーバーレスの名前空間を AWS Glue Data Catalog に登録する

Amazon Redshift コンソールを開きます。
ナビゲーションメニューで Redshift Serverless を選択します。Namespaces / Workgroups セクションに、現在のリージョンの名前空間とワークグループが表示されます。
登録する名前空間の名前を選択します。
Actions から Register to AWS Glue Data Catalog を選択します。

Amazon Redshift Serverless namespace selected to register with the AWS Glue Data Catalog

図 6: AWS Glue Data Catalog に登録する Amazon Redshift Serverless の名前空間

Do not register with Amazon Redshift federated permissions を選択します。
Use AWS Lake Formation permissions を選択します。
Destination account ID に、カタログを保持するプロデューサーアカウントの ID (<PRODUCER_ACCOUNT_ID>) を入力します。
Register を選択します。AWS Lake Formation コンソールが開きます。

Registering the Amazon Redshift Serverless namespace with the AWS Glue Data Catalog

図 7: Amazon Redshift Serverless の名前空間を AWS Glue Data Catalog に登録

Lake Formation でカタログの作成手順を進めます。「Creating Amazon Redshift federated catalogs」を参照し、次の手順に従います。
1. 名前空間の招待を確認し、承諾します。
2. フェデレーテッドカタログを作成します。

ステップ 1.2: 外部 (コンシューマー) アカウントに DATABASE 権限を付与する

Lake Formation コンソール (ap-southeast-2) で、Permissions、Data lake permissions、Grant の順に選択します。
Principals で External accounts を選択し、<CONSUMER_ACCOUNT_ID> を入力します。
Named Data Catalog resources を選択します。Catalogs/Databases で、フェデレーテッドデータベース (例: ns-redshift/dev、スキーマ sales_schema) を選択します。
Database permissions で Describe を選択します (Grantable permissions でも Describe を選択します)。
Grant を選択します。

ステップ 1.3: 外部 (コンシューマー) アカウントに TABLE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で External accounts を選択し、<CONSUMER_ACCOUNT_ID> を入力します。
Named Data Catalog resources を選択し、共有するテーブル (例: store_sales) を選択します。
Table permissions で Select と Describe を選択します (Grantable permissions でも同じものを選択します)。
Grant を選択します。

ステップ 1.4: IAM Identity Center のグループ/ユーザーに DATABASE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で IAM Identity Center を選択し、グループまたはユーザーを選択します。
Named Data Catalog resources を選択し、フェデレーテッドデータベース (スキーマ) を選択します。
Database permissions で Describe を選択します。
Grant を選択します。

ステップ 1.5: IAM Identity Center のグループ/ユーザーに TABLE 権限を付与する

Permissions、Data lake permissions、Grant の順に選択します。
Principals で IAM Identity Center を選択し、グループまたはユーザーを選択します。
Named Data Catalog resources を選択し、共有するテーブル (例: store_sales) を選択します。
Table permissions で Select と Describe を選択します。
Grant を選択します。

パート 2: コンシューマーアカウント

ここまでで、ケース 2 のプロデューサー側の設定は完了です。確認するには、Lake Formation コンソールで Data lake permissions を開き、フェデレーテッドデータベースと共有テーブルの権限付与が 4 件表示されることを確かめます。

パート 2 では、コンシューマーアカウントに切り替えて AWS RAM の共有を承諾し、クロスリージョンで Amazon Redshift にアクセスするための IAM ロールを設定します。さらに、ユーザーが別のリージョンからプロデューサーの Amazon Redshift のデータをクエリできるように TIP をセットアップします。

AWS RAM コンソールを開き、ap-southeast-2 に切り替えます。
Shared with me で Resource shares を選択します。
プロデューサーアカウントからのリソース共有を選択し、Accept resource share を選択します。

ステップ 2.2: IAM ロールの信頼関係を更新する

本記事で作成した IAM ロール (IAMIDCRedshiftRole) に移動します。

次のポリシーのように、信頼ポリシーで Amazon Redshift と Amazon Redshift Serverless に sts:AssumeRole と sts:SetContext が許可されていることを確認します。

信頼ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "redshift.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:SetContext"]
    },
    {
      "Effect": "Allow",
      "Principal": { "Service": "redshift-serverless.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:SetContext"]
    }
  ]
}

ステップ 2.3: IAM ロールに新しいポリシーを追加する

本記事で作成した IAM ロール (IAMIDCRedshiftRole) に移動し、AWS Glue と Lake Formation 用の次のポリシーを追加します。

アクセス許可ポリシー 1 (AWS Glue の読み取りと Lake Formation のデータアクセス):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueGetTable",
      "Effect": "Allow",
      "Action": [
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetPartition",
        "glue:GetPartitions"
      ],
      "Resource": "*"
    },
    {
      "Sid": "LakeFormationDataAccess",
      "Effect": "Allow",
      "Action": [
        "lakeformation:GetDataAccess",
        "lakeformation:GetTemporaryGlueTableCredentials"
      ],
      "Resource": "*"
    }
  ]
}

注: 上記のアクションは、リソース単位の権限をサポートしていないカタログレベルの検出に使われるため、"Resource": "*" が必要です。基になるデータには、引き続き Lake Formation の列レベルと行レベルの権限付与によって最小権限のアクセスが適用されます。

ステップ 2.4: Amazon Redshift でクロスリージョンの Trusted Identity Propagation (TIP) アクセスを設定する

管理者ロールで Amazon Redshift コンソールにサインインします。
Query Editor V2 に移動します。
クラスターの横にあるオプションメニュー (三点アイコン) を選択し、Create connection を選択します。
管理者ユーザーとして接続し、次のコマンドを実行して、別のリージョンにある AWS Glue Data Catalog を参照する外部スキーマを作成します。

構文:

CREATE EXTERNAL SCHEMA <schema_name>
FROM DATA CATALOG
DATABASE '<glue_db_name>'
REGION '<producer region where glue Data Catalog lives>'
CATALOG_ID '<catalog_name>';

例:

CREATE EXTERNAL SCHEMA redshift_cross_region_tip
FROM DATA CATALOG
DATABASE 'sales_schema'
REGION 'ap-southeast-2'
CATALOG_ID '123456789012:ns-producer-redshift-syd/dev';

catalog_name の情報は、シドニーリージョンにあるプロデューサーアカウントの Lake Formation で確認できます。左側の Databases に移動し、ドロップダウンから該当する Amazon Redshift のカタログ ID を選択します。

Lake Formation Databases list showing the Amazon Redshift federated catalog ID

図 8: AWS Glue Data Catalog に登録した Amazon Redshift の名前空間のカタログ ID を表示した AWS Lake Formation の画面

IAM Identity Center のグループに、外部スキーマへのアクセス権を付与します。

GRANT USAGE ON schema redshift_cross_region_tip TO ROLE "AWSIDC:admin";

ステップ 2.5: Amazon Redshift Query Editor V2 からデータをクエリする

Query Editor V2 で、クラスターの横にあるオプションメニュー (三点アイコン) を選択して Edit connection を選択し、認証方式に IAM Identity Center を選択します。
ポップアップで IdP のログインページにリダイレクトされます。IdP の認証情報を入力します。
認証に成功すると、IAM Identity Center のユーザーとして Query Editor V2 にリダイレクトされます。
次のクエリを実行します。

SELECT * FROM "dev"."redshift_cross_region_tip"."store_sales";

Amazon Redshift Query Editor V2 returning cross-Region store_sales rows

図 9: Amazon Redshift Query Editor V2 でクロスリージョンかつクロスアカウントのデータをクエリ

ステップ 2.6: SageMaker Unified Studio からデータをクエリする

コンシューマークラスターを SageMaker Unified Studio で使うには、Amazon Redshift のクラスターまたはワークグループに、次のいずれかのオプションでタグを付ける必要があります。先に進む前に、どちらかを選んでください。

オプション 1 – 特定の SageMaker Unified Studio プロジェクトからのアクセスだけを許可するタグを追加します: AmazonDataZoneProject=<projectID>

オプション 2 – このアカウント内のすべての SageMaker Unified Studio プロジェクトからのアクセスを許可するタグを追加します: for-use-with-all-datazone-projects=true

Amazon Redshift のクラスターまたはワークグループにタグを付けたら、次の手順に進みます。

IAM Identity Center のユーザーとして Sign in with SSO を選択し、SageMaker Unified Studio ポータルにサインインします。
SageMaker Unified Studio で Query Editor に移動し、Connections を展開します。
redshift_cross_region_tip、tables の順に選択し、store_sales を選択します。
store_sales テーブルの横にある三点アイコンを選択し、Preview data を選択します。次のスクリーンショットのように、Amazon Redshift のコンピューティングを使ってクエリが自動的に実行されます。

SageMaker Unified Studio previewing store_sales using Amazon Redshift compute

図 10: Amazon SageMaker Unified Studio で Amazon Redshift のコンピューティングを使ってデータをクエリ

シドニーのプロデューサーから共有された Amazon Redshift のデータが返されます。Lake Formation が 1 つのアカウントとリージョン (ap-southeast-2) で一元管理するデータに、別のリージョン (sa-east-1) にあるコンシューマーアカウントからアクセスしており、ユーザーの ID は TIP で伝播しています。

どちらのケースも、リージョンの分担は同じです。カタログとデータはプロデューサーのリージョン (シドニー) にとどまり、コンシューマーのリージョン (サンパウロ) から実行されるのはクライアントとクエリだけです。違いはクエリエンジンだけで、ケース 1 は Amazon Athena を、ケース 2 は Amazon Redshift Serverless を使います。クロスリージョンでの動作が異なるのも、エンジンが違うためです。Athena (ケース 1) では、追加の制約なしにクロスリージョンでクエリを実行できます。一方、Amazon Redshift のデータ共有を使う場合は、Amazon Redshift のクエリエンジンが Amazon Redshift の名前空間と同じリージョンにある必要があります。

クリーンアップ

継続的な課金を避けるため、作成したリソースを削除します。

コンシューマーアカウント:

SageMaker Unified Studio のプロジェクトとドメインを削除します (ケース 1)。
Amazon Redshift Serverless のワークグループと名前空間を削除します (ケース 2)。
Lake Formation (sa-east-1) で、リソースリンク (rl_sydney_s3_datalake、rl_redshift_cross_db_tip) を削除します。
作成した Lake Formation の権限付与をすべて取り消し、該当する場合は AWS RAM の共有から離脱するか、共有を拒否します。

プロデューサーアカウント:

コンシューマーアカウントと IAM Identity Center のグループへの Lake Formation の権限付与を取り消します。
AWS RAM の共有を取り消します。
S3 にあるデータレイクのロケーションを登録解除し、customers テーブルと sydney_lakehouse データベースを削除します。
S3 バケットを空にしてから削除します。
AWS Glue Data Catalog から Amazon Redshift の名前空間の登録を解除し、フェデレーテッドカタログを削除します (ケース 2)。
作成した IAM ロール (LakeFormation-DataLocation-role、IAMIDCRedshiftRole) を削除します。

まとめ

本記事では、AWS Lake Formation の Trusted Identity Propagation を設定し、1 つのリージョン (シドニー) で管理・共有しているデータを別のリージョン (サンパウロ) からクエリできるようにしました。Lake Formation のクロスアカウントの権限付与はプロデューサーのリージョンで行い、コンシューマーはクエリ用リージョンから、エンジンごとに適した方法で共有データにアクセスします。Amazon Athena でクエリする Amazon S3 のデータ (ケース 1) では、コンシューマーがクエリ用リージョンに、共有データベースを参照するリソースリンクを作成します。データ共有と AWS Glue のフェデレーテッドカタログで共有する Amazon Redshift のデータ (ケース 2) では、代わりにコンシューマーが Amazon Redshift に外部スキーマを作成し、プロデューサーのリージョンにあるプロデューサーの Glue Data Catalog を直接参照します。リソースリンクは必要ありません。どちらのケースでも、アクセスは共有のロールではなくユーザーの IAM Identity Center の ID に基づいて認可されるため、最小権限のアクセス、AWS CloudTrail でのユーザー単位の監査、権限の一元管理を実現できます。

コンシューマーアカウントやクエリ用リージョンを追加するには、該当するケースのコンシューマー側の手順を繰り返します。プロデューサーのリージョンで AWS RAM の共有を承諾したうえで、Amazon S3 と Athena の場合はクエリ用リージョンにリソースリンクを作成して IAM Identity Center のプリンシパルにリソースリンクの Describe を付与し、Amazon Redshift の場合はプロデューサーの Glue カタログを参照する外部スキーマを作成して IAM Identity Center のプリンシパルに USAGE を付与します。

次のステップとして、Trusted Identity Propagation がサポートするアプリケーションとサービスを確認し、Lake Formation のクロスアカウント共有のドキュメントも参考にしながら、スタック内のどのサービスで TIP を有効にするかを計画してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

Amazon Web Services ブログ

AWS Lake Formation と Trusted Identity Propagation でクロスリージョンのきめ細かなデータアクセスを実現する

概要

構成要素の連携

前提条件

ケース 1: S3 のデータを共有する (Lake Formation)

パート 1: プロデューサーアカウント (シドニー、ap-southeast-2)

ステップ 1.1: サンプルデータファイルを作成する

ステップ 1.2: S3 バケットを作成してデータをアップロードする

ステップ 1.3: Lake Formation の登録用ロールを作成する (sts:SetContext 付き)

ステップ 1.4: Lake Formation に S3 のロケーションを登録する

ステップ 1.5: AWS Glue データベースを作成する

ステップ 1.6: テーブルを手動で作成する

ステップ 1.7: 外部 (コンシューマー) アカウントに DATABASE 権限を付与する

ステップ 1.8: 外部 (コンシューマー) アカウントに TABLE 権限を付与する

ステップ 1.9: IAM Identity Center のグループ/ユーザーに DATABASE 権限を付与する

ステップ 1.10: IAM Identity Center のグループ/ユーザーに TABLE 権限を付与する

パート 2: コンシューマーアカウント

ステップ 2.1: AWS RAM の共有を承諾する (シドニーリージョン)

ステップ 2.2: リソースリンクを作成する (sa-east-1 リージョン)

ステップ 2.3: IAM Identity Center のグループ/ユーザーにリソースリンクの Describe 権限を付与する

パート 3: SageMaker Unified Studio (sa-east-1)

ステップ 3.1: SageMaker Unified Studio ドメインを作成する

ステップ 3.2: TIP を有効にする

ケース 2: AWS Glue のフェデレーテッドカタログで Amazon Redshift のデータを共有する

パート 1: プロデューサーアカウント (シドニー、ap-southeast-2)

ステップ 1.1: サーバーレスの名前空間を AWS Glue Data Catalog に登録する

ステップ 1.2: 外部 (コンシューマー) アカウントに DATABASE 権限を付与する

ステップ 1.3: 外部 (コンシューマー) アカウントに TABLE 権限を付与する

ステップ 1.4: IAM Identity Center のグループ/ユーザーに DATABASE 権限を付与する

ステップ 1.5: IAM Identity Center のグループ/ユーザーに TABLE 権限を付与する

パート 2: コンシューマーアカウント

ステップ 2.1: AWS RAM の共有を承諾する (シドニーリージョン)

ステップ 2.2: IAM ロールの信頼関係を更新する

ステップ 2.3: IAM ロールに新しいポリシーを追加する

ステップ 2.4: Amazon Redshift でクロスリージョンの Trusted Identity Propagation (TIP) アクセスを設定する

ステップ 2.5: Amazon Redshift Query Editor V2 からデータをクエリする

ステップ 2.6: SageMaker Unified Studio からデータをクエリする

クリーンアップ

まとめ

著者について

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ