2026 年 4 月 20 日より、BigLake は Lakehouse for Apache Iceberg に名称変更されました。BigLake metastore は、Lakehouse ランタイムカタログと呼ばれるようになりました。Lakehouse API、クライアントライブラリ、CLI コマンド、IAM 名は変更されず、引き続き BigLake を参照します。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

AWS Glue 用のボーダレス Lakehouse を設定する

このドキュメントでは、 Google Cloud内で AWS Glue カタログから直接データをクエリするようにボーダーレスな Lakehouse を設定する方法について説明します。この機能は、外部データソースを既存の Google Cloud 環境と統合することで、データ分析を統合します。

その後、Lakehouse for Apache Iceberg を使用して、フェデレーションデータへのアクセスを管理できます。

始める前に

Lakehouse の概要を確認して、Lakehouse がデータへのアクセスを管理する方法を理解します。
仕組みについては、ボーダーレス Lakehouse についてをご覧ください。
サポートされているカタログを確認して、テーブル形式の要件とサポートされている構成を確認します。
AWS 管理者に Identity and Access Management（IAM）ロールを作成し、権限ポリシーを構成する権限があることを確認します。
省略可: Google Cloud VPC とリモートクラウドプロバイダの VPC（AWS など）間のプライベート相互接続を介してクエリをルーティングする場合は、リモートプロバイダのアカウントが有効になっていること、Dedicated Cross-Cloud InterconnectまたはPartner Cross-Cloud Interconnectをプロビジョニングしていること、Cloud Router との BGP セッションを確立していること、両方のクラウド環境で必要な IAM 権限があることを確認します。

Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

Enable the API

必要なロール

ボーダレス Lakehouse の設定に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

Lakehouse カタログを管理する: BigLake 管理者（roles/biglake.admin）
プライベート相互接続経由でトラフィックを転送する（ユーザー）: Compute ネットワーク管理者（roles/compute.networkAdmin）
プライベート相互接続を介してトラフィックを転送する（カタログサービスアカウント）:
- Service Directory 閲覧者（roles/servicedirectory.viewer）
- Service Directory PSC 承認済みサービス（roles/servicedirectory.pscAuthorizedService）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

制限事項と考慮事項

このセクションでは、ボーダーレス Lakehouse の使用に関する制限事項と考慮事項について説明します。

サポートされているクラウドプロバイダ: ボーダーレス Lakehouse でプライベート相互接続を使用することは、次のリモートクラウドプロバイダでサポートされています。Amazon Web Services（AWS）。専用の Cross-Cloud Interconnect またはパートナーの Cross-Cloud Interconnect を使用できます。
ネットワークルーティング: プライベートインターコネクト（Dedicated CCI や Partner CCI など）が構成されていない場合、クエリは公共のインターネット経由でルーティングされます。これにより、リモートクラウドプロバイダからの下り（外向き）料金が増加し、パフォーマンスの予測可能性が低下する可能性があります。
データの更新速度: フェデレーションカタログの --refresh-interval フラグは、メタデータの同期頻度を決定します。間隔を短くすると、より新しいデータが提供されますが、リモートカタログプロバイダから追加の API 費用が発生する可能性があります。
Iceberg 指標レポート: Iceberg 指標レポートは、フェデレーションカタログでは使用できません。連携カタログにアクセスするときに、Iceberg クライアントで rest-metrics-reporting-enabled プロパティを false に設定します。

全般的なワークフロー

ボーダレスレイクハウスを設定して使用する一般的な手順は次のとおりです。

Cross-Cloud Interconnect を設定する（省略可）: Google Cloud VPC とリモートクラウドプロバイダの間にプライベート接続を構成します。
連携を設定する: リモートプロバイダのプレースホルダ信頼ポリシーを使用して IAM ロールを作成し、認証を構成します。次に、Lakehouse に連携カタログを作成し、信頼ポリシーを更新します。
接続を確認する: Lakehouse がリモートカタログに正常に接続できることを確認します。
データをクエリする: BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。詳細については、ボーダレス Lakehouse を使用するをご覧ください。
権限を構成する: IAM を使用して、統合データを表示してクエリできるユーザーを管理します。

Cross-Cloud Interconnect を設定する（省略可）

リモートカタログへのクエリは、デフォルトで公共のインターネットを経由します。セキュリティとコンプライアンスの強化、予測可能なパフォーマンスの提供、データ転送費用の削減に役立つプライベート相互接続を使用します。これにより、 Google CloudVirtual Private Cloud（VPC）とリモートクラウドプロバイダのネットワーク（AWS など）の間に専用のプライベートネットワーク接続が確立されます。

Google Cloud VPC とリモートクラウドプロバイダの VPC（AWS など）の間に、次のいずれかのプライベート相互接続オプションをプロビジョニングして構成できます。

専用の Cross-Cloud Interconnect: 専用の物理接続。
パートナークロスクラウド相互接続: サポートされているサービスプロバイダを介した接続。

Google Cloud の Cloud Router とリモートクラウドプロバイダの VPC の間に BGP セッションを確立し、ルート交換を確保します。

プライベートクエリを有効にするには、プライベート相互接続を介して Lakehouse からリモートストレージバケット（AWS Amazon S3 バケットなど）へのパスを構成する必要があります。このルーティングを構成するには、次の 2 つのアーキテクチャフローがあります。

内部リージョンプロキシネットワークロードバランサのルーティング: このフローでは、Google Cloud 内部リージョンプロキシネットワークロードバランサを使用して、複数の AWS Elastic Network Interface（ENI）を指すハイブリッド接続ネットワークエンドポイントグループ（NEG）にリクエストを分散します。このフローは、ロードバランシング、スケーラビリティ、高可用性に不可欠です。Partner CCI では必須であり、Dedicated CCI ではロードバランシング、スケーラビリティ、高可用性のために推奨されます。
直接エンドポイントルーティング: このフローは、Service Directory を単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接接続します。このフローは専用 CCI でのみ機能し、パートナー CCI では対象外です。

アーキテクチャ要件に合った構成フローを選択します。

内部リージョンプロキシネットワークロードバランサ

高可用性とロードバランシングのために、複数の AWS ENI にリクエストを分散するように内部リージョンプロキシネットワークロードバランサを構成する手順は次のとおりです。

AWS ネットワーキングを構成する

まず、Amazon S3 VPC インターフェースエンドポイント（AWS PrivateLink）を作成します。

AWS VPC コンソールで、Amazon S3 のインターフェースエンドポイントを作成します。
サービス名に「com.amazonaws.AWS_REGION.s3」と指定します。
Direct Connect を介して Google Cloud VPC に接続されている VPC とサブネットを選択します。
セキュリティグループをエンドポイントに接続して、インバウンドアクセスを制御します。
これにより、選択した各サブネットに Elastic Network Interface（ENI）がプロビジョニングされます。これらの ENI のプライベート IP アドレスをメモします。

次に、セキュリティグループを構成します。

Amazon S3 エンドポイント ENI に関連付けられているセキュリティグループで、 Google Cloud VPC からポート 443 への TCP トラフィックの受信が許可されていることを確認します。これには、ヘルスチェックと転送されたトラフィックを許可するGoogle Cloud プロキシ専用サブネットの CIDR の範囲を含める必要があります。

Google Cloud ネットワーキングを構成する

設定を簡素化するには、次のコマンドを実行して内部ロードバランサを構成します。高度な構成または詳細については、ハイブリッドエンドポイント用に内部リージョンプロキシネットワークロードバランサを設定するをご覧ください。

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

次のように置き換えます。

PROXY_SUBNET_NAME: プロキシ専用サブネットの名前。
PROXY_SUBNET_RANGE: VPC ネットワーク内の未使用の CIDR の範囲（10.129.0.0/23 など）。

リージョンヘルスチェックを作成します。
```
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443
```
次のように置き換えます。
- HEALTH_CHECK_NAME: ヘルスチェックの名前。
- REGION: Google Cloud リージョン（例: us-east4）。
ハイブリッド接続ネットワークエンドポイントグループ（NEG）を作成してエンドポイントを追加します。

各ゾーンにハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT）を作成します。
```
gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK
```
AWS ENI のプライベート IP アドレスを対応するハイブリッド NEG に追加します。
```
gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=AWS_S3_IP,port=443"
```
次のように置き換えます。
- NEG_NAME: ハイブリッド NEG の名前。
- ZONE: Google Cloud ゾーン（例: us-east4-a）。このゾーンは、Cross-Cloud Interconnect VLAN アタッチメントのリージョン内に存在する必要があります。
- VPC_NETWORK: VPC ネットワークの名前。
- AWS_S3_IP: そのゾーンの AWS Amazon S3 VPC エンドポイント（ENI）のプライベート IP アドレス。
AWS ENI が複数のゾーンに分散している場合は、これらのコマンドを繰り返して NEG を作成し、他のゾーンのエンドポイントを追加します。
バックエンドサービスを作成して構成します。

内部マネージドロードバランシングを使用してリージョンバックエンドサービスを作成します。
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
ハイブリッド NEG をバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --region=REGION \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=ZONE \
    --balancing-mode=CONNECTION \
    --max-connections=MAX_CONNECTIONS
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- NEG_NAME: 前の手順で作成したハイブリッド NEG の名前。
- ZONE: Google Cloud ゾーン（例: us-east4-a）。
- MAX_CONNECTIONS: バックエンドが処理する最大同時接続数（例: 100）。
作成したハイブリッド NEG ごとに add-backend コマンドを繰り返します。

ロードバランサのフロントエンドを構成します。

ターゲット TCP プロキシを作成します。

gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --region=REGION

ターゲットプロキシにトラフィックをルーティングする転送ルールを作成します。

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=VPC_NETWORK \
    --subnet=VPC_SUBNET \
    --ports=443 \
    --region=REGION \
    --target-tcp-proxy=TARGET_PROXY_NAME \
    --target-tcp-proxy-region=REGION \
    --allow-global-access

次のように置き換えます。

TARGET_PROXY_NAME: ターゲットプロキシの名前。
FORWARDING_RULE_NAME: 転送ルールの名前。
VPC_SUBNET: VPC サブネットワークの名前。

ロードバランサの転送ルールを作成したら、割り当てられた内部 IP アドレスをメモします。これが ILB_IP_ADDRESS です。

Service Directory を構成する

Lakehouse が検出できるように、ILB の IP アドレスを Service Directory に登録します。

リモートクラウドの Namespace を作成します。
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
次のように置き換えます。
- NAMESPACE: 名前空間の一意の識別子。
- PROJECT_ID: 実際の Google Cloud プロジェクト ID。
- REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーションカタログと同じリージョンにする必要があります。

Service Directory 名前空間にサービスを作成します。

gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

次のように置き換えます。

SERVICE_NAME: サービスの一意の識別子。

サービスで ILB のエンドポイントを作成します。
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --project=PROJECT_ID \
    --namespace=NAMESPACE \
    --service=SERVICE_NAME \
    --location=REGION \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
    --address=ILB_IP_ADDRESS \
    --port=443
```
次のように置き換えます。
- ENDPOINT_NAME: エンドポイントの一意の識別子。
- PROJECT_NUMBER: Google Cloudプロジェクトの番号。--network フラグでプロジェクト番号を使用します。
- ILB_IP_ADDRESS: ILB 転送ルールの内部 IP アドレス。

直接エンドポイント

トラフィックを単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接転送するようにサービスディレクトリを構成する手順は次のとおりです。

AWS VPC 内に Amazon S3 のインターフェース VPC エンドポイントを作成します。このエンドポイントの IP アドレスとポートをメモします。
リモートクラウドの Namespace を作成します。
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
次のように置き換えます。
- NAMESPACE: 名前空間の一意の識別子。
- PROJECT_ID: 実際の Google Cloud プロジェクト ID。
- REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーションカタログと同じリージョンにする必要があります。

Service Directory 名前空間にサービスを作成します。

gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

次のように置き換えます。

SERVICE_NAME: サービスの一意の識別子。

Amazon S3 インターフェース VPC エンドポイントのルーティング情報を含むエンドポイントをサービスに作成します。
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=S3_VPCE_IP_ADDRESS \
    --port=S3_VPCE_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
```
次のように置き換えます。
- ENDPOINT_NAME: エンドポイントの一意の識別子。
- S3_VPCE_IP_ADDRESS: Amazon S3 インターフェース VPC エンドポイントの IP アドレス。例: 10.0.1.45
- S3_VPCE_PORT: Amazon S3 インターフェース VPC エンドポイントのポート番号。例: 443
- PROJECT_NUMBER: Google Cloudプロジェクトの番号。--network フラグでプロジェクト番号を使用します。
- VPC_NETWORK: プライベート相互接続に関連付けられている Google Cloud VPC ネットワーク名。

連携を設定する

データをクエリするには、リモート AWS カタログに接続する Lakehouse 連携カタログを設定します。

プレースホルダ信頼ポリシーを使用して AWS IAM ロールを作成する

Lakehouse は、カタログの作成後に Google サービスアカウント ID をプロビジョニングします。プレースホルダ信頼ポリシーを使用して AWS IAM ロールを作成します。

trust_policy.json という名前のファイルを作成します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": [
            "PLACEHOLDER_VALUE"
          ],
          "accounts.google.com:sub": [
            "PLACEHOLDER_VALUE"
          ]
        }
      }
    }
  ]
}

AWS CLI コマンドを実行して、プレースホルダの信頼ポリシーでロールを作成します。長時間実行されるジョブで認証情報の有効期限が切れないように、最大セッション時間を 12 時間（43200 秒）に設定することをおすすめします。
```
aws iam create-role \
  --role-name AWS_ROLE_NAME \
  --assume-role-policy-document file://trust_policy.json \
  --max-session-duration 43200
```
次のように置き換えます。
- AWS_ROLE_NAME: AWS IAM ロールの名前。例: lakehouse_glue_federation_role

権限ポリシーを適用する

Lakehouse が AWS リージョンの Glue Data Catalog と S3 バケットにアクセスできるようにする権限ポリシーを IAM ロールに適用します。このポリシーは、AWS Lake Formation S3 テーブル統合を使用する場合に、S3 テーブルバケットへのアクセス権も付与します。デフォルトの AWS Glue データ権限から AWS Lake Formation モデルにアップグレードした場合は、代わりに Lake Formation で追加の権限を付与する必要がある場合があります。

次のポリシー構成を含む permissions_policy.json という名前のファイルを作成します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueRead",
      "Effect": "Allow",
      "Action": [
        "glue:GetCatalog",
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables"
      ],
      "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
    },
    {
      "Sid": "S3Read",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Sid": "S3TablesRead",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTableBucket",
        "s3tables:ListNamespaces",
        "s3tables:GetNamespace",
        "s3tables:ListTables",
        "s3tables:GetTable",
        "s3tables:GetTableMetadataLocation",
        "s3tables:GetTableData"
      ],
      "Resource": [
        "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
      ]
    }
  ]
}

AWS Key Management Service（KMS）でホストされている顧客管理の鍵を使用して AWS Glue、Amazon S3、Amazon S3 テーブルのリソースを暗号化する場合は、リソースを復号するための KMS 鍵アクセス権を付与するステートメントを追加する必要があります。

# ...
{
  "Sid": "GlueS3S3TablesKmsDecrypt",
  "Effect": "Allow",
  "Action": [
      "kms:Decrypt"
  ],
  "Resource": [
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_glue",
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3",
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3_tables"
  ]
}
# ...

この権限ポリシーを IAM ロールに関連付けます。
```
aws iam put-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-name AWS_POLICY_NAME \
  --policy-document file://permissions_policy.json
```
次のように置き換えます。
- AWS_ROLE_NAME: AWS IAM ロールの名前。例: lakehouse_glue_federation_role
- AWS_POLICY_NAME: 権限ポリシーの名前。例: lakehouse_glue_federation_policy
- AWS_REGION: Glue カタログまたは S3 テーブルが存在する AWS リージョン。例: us-east-1
- AWS_ACCOUNT_ID: 12 桁の AWS アカウント ID 文字列。例: 123456789012

連携カタログを作成する

Google Cloud コンソール、gcloud CLI、または REST API を使用して、 Google Cloud にフェデレーションカタログを確立します。

AWS 信頼関係の伝播中にバックグラウンドメタデータの更新が早期に失敗するのを防ぐには、更新スケジュールを指定せずにカタログを初期化します（デフォルトは 0s）。

コンソール

連携カタログを作成するには:

Google Cloud コンソールで、[Lakehouse] に移動します。

[Lakehouse] に移動
[ カタログを作成] をクリックします。
[連携カタログ] をクリックします。

[カタログ構成] の詳細が表示されます。
[連携カタログのソース] で、[AWS Glue] を選択します。
[データのロケーション] で、フェデレーションカタログを作成する Lakehouse リージョンを選択します。例: us-east4レイテンシを最小限に抑えるには（パブリックインターネット経由でも）、AWS リージョンに最も近い Google Cloud リージョンを選択します。
[続行] をクリックします。

[接続の詳細] の詳細が表示されます。
[Remote catalog details] セクションの [AWS warehouse] フィールドに、AWS アカウント ID または S3 テーブルバケットカタログを入力します。例: 123456789012。
[AWS region] フィールドに、AWS リージョンを入力します。例: us-east-1。
[AWS role ARN] フィールドに、AWS ロール ARN を入力します。arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME 形式を使用します。
省略可: [Service Directory 名] フィールドに、Service Directory エンドポイントまたはサービスへのパスを入力します。これは、プライベート相互接続（Cross-Cloud Interconnect）を構成する場合にのみ必要です。
[作成] をクリックします。

Google Cloud CLI

公共のインターネット（CCI なし）

CCI を構成しない場合、接続はパブリックインターネット経由で安全に転送されます。

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME"

お客様所有（CCI）

プライベートインターコネクト（Dedicated CCI や Partner CCI など）を構成した場合は、Lakehouse がトラフィックをプライベートに転送するように、Service Directory サービス参照を指定します。

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

REST

curl -s -X POST \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_NAME"'"
      }
    }
  }'

次のように置き換えます。

FEDERATED_CATALOG_NAME: フェデレーションカタログの名前。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。
REGION: 連携カタログが作成される Lakehouse リージョン。例: us-east4
GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: ターゲットのウェアハウスカタログの識別子。AWS リージョンの Glue Data Catalog の場合は、12 桁の AWS アカウント ID 文字列を入力します。例: 123456789012リージョンで S3 テーブルバケットを使用するには、AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET と入力します。例: 123456789012:s3tablescatalog/my-table-bucket
AWS_ACCOUNT_ID: 12 桁の AWS アカウント ID 文字列。例: 123456789012
AWS_REGION: Glue カタログまたは S3 テーブルバケットが存在する AWS リージョン。例: us-east-1
AWS_ROLE_NAME: AWS IAM ロールの名前。例: lakehouse_glue_federation_role
NAMESPACE:（省略可）プライベート相互接続の設定時に作成した Service Directory 名前空間。
SERVICE_NAME: （省略可）プライベート相互接続の設定時に作成した Service Directory サービス名。

信頼ポリシーを更新する

カタログが作成されると、Lakehouse はカタログに一意のサービスアカウントをプロビジョニングし、カタログ作成レスポンスの biglake-service-account-id フィールドとして返します。このサービスアカウントを使用して、信頼関係を確立します。

次のコマンドを実行して、biglake-service-account-id 値をアクティブな bash 変数に抽出します。

LAKEHOUSE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --format="value(biglake-service-account-id)")

AWS IAM ロールの信頼ポリシーを更新して、プレースホルダを検証済みの Google サービスエージェント ID に置き換えます。条件ブロックは、sub と aud の両方の一致を検証します。ポリシーを trust_policy_comprehensive.json という名前のファイルに書き込みます。

cat > trust_policy_comprehensive.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": [
            "$LAKEHOUSE_SA_ID"
          ],
          "accounts.google.com:sub": [
            "$LAKEHOUSE_SA_ID"
          ]
        }
      }
    }
  ]
}
EOF

最終的なポリシーを AWS ロールに適用します。
```
aws iam update-assume-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-document file://trust_policy_comprehensive.json
```
注: AWS IAM の変更が反映されるまでに数分かかることがあります。

バックグラウンドでのメタデータの更新を有効にする

両方のプラットフォームで安全な信頼関係が正常に確立されたら、カタログを更新してバックグラウンドメタデータの更新（5 分ごと、300s 以上）を有効にします。

gcloud CLI

gcloud alpha biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

REST

curl -s -X PATCH \
-H "x-goog-user-project: PROJECT_ID" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
-d '{
  "federated_catalog_options": {
    "refresh_options": {
      "refresh_schedule": {
        "refresh_interval": "300s"
      }
    }
  }
}'

プライベート相互接続の設定を完了する（Cross-Cloud Interconnect のみ）

プライベート相互接続（専用またはパートナー CCI）でトラフィックをルーティングする場合は、Lakehouse カタログサービスアカウントに Service Directory を介して接続を検出して承認する権限を付与する必要があります。

コンソール

Google Cloud コンソールで、[IAM] ページに移動します。

[IAM] に移動
[アクセス権を付与]（または [追加]）をクリックします。
[新しいプリンシパル] フィールドに、Lakehouse カタログのサービスアカウントのメールアドレスを入力します。このメールは、カタログを説明することで取得できます（gcloud タブを参照）。
[ロール] プルダウンで、[Service Directory 閲覧者]（roles/servicedirectory.viewer）を選択します。
[別のロールを追加] をクリックし、[Service Directory PSC 承認済みサービス]（roles/servicedirectory.pscAuthorizedService）を選択します。
[保存] をクリックします。

gcloud CLI

カタログのサービスアカウントに必要なロールを付与します。

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

接続を確認する

カタログのバックグラウンドメタデータの更新サイクルが正常に完了し、名前空間が同期されていることを確認します。

更新ステータスが成功を示していることを確認します。

gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

リモートデータベースが同期された Namespace として表示されることを確認します。

gcloud alpha biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

AWS Glue 用のボーダレス Lakehouse を設定する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

必要なロール

制限事項と考慮事項

全般的なワークフロー

Cross-Cloud Interconnect を設定する（省略可）

内部リージョン プロキシ ネットワーク ロードバランサ

直接エンドポイント

連携を設定する

プレースホルダ信頼ポリシーを使用して AWS IAM ロールを作成する

権限ポリシーを適用する

連携カタログを作成する

コンソール

Google Cloud CLI

公共のインターネット（CCI なし）

お客様所有（CCI）

REST

信頼ポリシーを更新する

バックグラウンドでのメタデータの更新を有効にする

gcloud CLI

REST

プライベート相互接続の設定を完了する（Cross-Cloud Interconnect のみ）

コンソール

gcloud CLI

接続を確認する

次のステップ

AWS Glue 用のボーダレス Lakehouse を設定する

内部リージョンプロキシネットワークロードバランサ