Depuis le 20 avril 2026, BigLake s'appelle désormais Lakehouse. BigLake Metastore s'appelle désormais le catalogue d'environnements d'exécution Lakehouse. Les noms des API Lakehouse, des bibliothèques clientes, des commandes CLI et d'IAM restent inchangés et font toujours référence à BigLake.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Configurer une connexion multicloud pour AWS Glue

Une connexion cross-cloud à un catalogue de données AWS Glue vous permet d'interroger les données de ce catalogue directement dans Google Cloud. Cette fonctionnalité unifie votre analyse de données en intégrant vos sources de données externes à votre environnementGoogle Cloud existant.

Une fois la connexion configurée, vous pouvez interroger et gérer vos tables Apache Iceberg fédérées dans Lakehouse sans déplacer de fichiers.

Avant de commencer

Consultez la présentation de Lakehouse pour comprendre comment Lakehouse gère l'accès aux données.
Découvrez comment accéder aux données cross-cloud.
Consultez les catalogues compatibles pour vérifier les configurations compatibles.
Facultatif : Si vous prévoyez d'acheminer les lectures de requêtes ou l'actualisation des métadonnées en arrière-plan via une interconnexion privée entre votre réseau cloud privé virtuel (VPC) Google Cloudet votre VPC AWS, vérifiez que vous disposez d'un compte AWS actif, provisionnez un Cross-Cloud Interconnect dédié ou un Cross-Cloud Interconnect partenaire, établissez des sessions BGP avec votre routeur Cloud Router et vérifiez que vous disposez des autorisations IAM (Identity and Access Management) requises dans les deux environnements cloud.

Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is not already enabled.

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, if it is not already enabled.

Roles required to enable APIs

Enable the API

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer Lakehouse pour l'accès aux données cross-cloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Gérer les catalogues Lakehouse : Administrateur BigLake (roles/biglake.admin)
Acheminer le trafic via une interconnexion privée (utilisateur) : Administrateur de réseaux Compute (roles/compute.networkAdmin)
Acheminer le trafic via une interconnexion privée (compte de service du catalogue) :
- Lecteur de l'Annuaire des services (roles/servicedirectory.viewer)
- Service autorisé PSC de l'Annuaire des services (roles/servicedirectory.pscAuthorizedService)

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Limites et points à noter

Cette section liste les limites et les points à prendre en compte pour accéder aux données cross-cloud.

VPC Service Controls : si le projet qui contient le point de terminaison de votre catalogue fédéré ou le bucket Cloud Storage sous-jacent se trouve dans un périmètre de service VPC Service Controls, vous devez configurer des règles d'entrée ou de sortie. Pour en savoir plus, consultez Utiliser VPC Service Controls avec des points de terminaison de catalogue fédéré.
Fournisseurs de services cloud interconnexion cross-cloud Interconnect : l'utilisation d'une interconnexion privée pour acheminer le transport des requêtes, l'actualisation des métadonnées en arrière-plan ou les deux est compatible avec AWS. Vous pouvez utiliser Dedicated Cross-Cloud Interconnect ou Partner Cross-Cloud Interconnect (pour AWS).
Routage réseau : si vous ne configurez pas d'interconnexion privée pour le transport des requêtes ou l'actualisation des métadonnées en arrière-plan, le trafic correspondant est acheminé via l'Internet public à l'aide de TLS. Le routage des lectures de requêtes sur l'Internet public peut entraîner des frais de sortie plus élevés de la part de votre fournisseur de services cloud distant et des performances moins prévisibles.
Lecture seule : les catalogues fédérés dans Lakehouse sont des vues en lecture seule du catalogue distant. La manipulation des ressources (par exemple, la création, la mise à jour ou la suppression de ressources) n'est pas possible et doit être effectuée directement dans le catalogue distant.
Fraîcheur des données : l'option --refresh-interval d'un catalogue fédéré détermine la fréquence de synchronisation des métadonnées. La valeur doit être 0s (désactivé) ou au moins 300s (5 minutes). L'actualisation des métadonnées en arrière-plan d'un catalogue peut prendre plus de temps si le nombre de ressources d'espace de noms et de table est élevé. Si l'actualisation précédente dépasse le délai, l'actualisation actuelle est ignorée et l'actualisation suivante est planifiée à l'intervalle suivant. Les requêtes utilisent les métadonnées du catalogue synchronisées le plus récemment. Par conséquent, les modifications apportées au catalogue distant, telles que les nouvelles tables, les mises à jour de schéma ou les données récemment validées, ne sont pas visibles dans Lakehouse tant que l'actualisation des métadonnées en arrière-plan n'est pas terminée.
Mise en cache Lakehouse : la mise en cache cross-cloud est désactivée par défaut (--cross-cloud-cache=disabled). Vous pouvez activer ou désactiver la mise en cache au niveau du catalogue fédéré ou de la connexion. Les clés de chiffrement gérées par le client (CMEK) ne sont pas compatibles avec la mise en cache. Les fichiers mis en cache sont chiffrés à l'aide de Google-owned and Google-managed encryption keys. Si la contrainte de règle d'administration constraints/gcp.restrictNonCmekServices est appliquée à une table de la requête, la mise en cache est automatiquement désactivée pour cette requête. Pour en savoir plus, consultez Mise en cache intelligente.
Résidence des données et conformité : lorsque vous activez la mise en cache cross-cloud sur un catalogue ou une connexion fédérés, Lakehouse stocke temporairement les fichiers mis en cache au repos dans la région Google Cloud où la requête est exécutée. Si vos fichiers cloud distants résident dans une autre juridiction, vérifiez que la mise en cache interrégionale répond aux exigences de résidence des données et de conformité de votre organisation avant de l'activer.

Workflow général

Pour accéder aux données cross-cloud, procédez comme suit :

Configurer Cross-Cloud Interconnect (facultatif) : configurez une connexion privée entre votre réseau VPC Google Cloud et votre VPC AWS.
Configurer la fédération : configurez l'authentification en créant un rôle IAM avec un espace réservé pour la stratégie d'approbation dans AWS. Ensuite, créez un catalogue fédéré dans Lakehouse et mettez à jour la stratégie de confiance.
Vérifier la connexion : vérifiez que Lakehouse peut se connecter à votre catalogue distant.
Interroger des données : exécutez des requêtes sur vos données fédérées à l'aide de BigQuery ou de Managed Service pour Apache Spark en utilisant la convention d'attribution de noms PROJECT_ID.CATALOG_NAME.NAMESPACE.TABLE en quatre parties. Vous pouvez éventuellement activer la mise en cache multicloud sur le catalogue fédéré pour réduire les coûts de sortie multicloud et accélérer les requêtes ultérieures. Pour en savoir plus, consultez Interroger des données distantes.
Configurer les autorisations : utilisez IAM pour gérer les utilisateurs autorisés à afficher et à interroger les données fédérées.

Configurer interconnexion cross-cloud (facultatif)

Par défaut, les lectures de données de requête et l'actualisation des métadonnées en arrière-plan transitent par l'Internet public à l'aide de TLS. Pour améliorer l'isolation du réseau, fournir une latence prévisible et réduire les coûts de transfert de données, vous pouvez configurer une interconnexion privée entre votre réseau VPC Google Cloudet votre réseau cloud distant (AWS VPC).

Vous pouvez provisionner l'une des options d'interconnexion privée suivantes :

Cross-Cloud Interconnect dédié : connexion physique dédiée.
Cross-Cloud Interconnect partenaire : connexion à AWS via un fournisseur de services compatible.

Établissez des sessions BGP entre votre Cloud Router dans Google Cloudet votre réseau cloud distant pour permettre l'échange de routes.

Vous pouvez configurer le routage privé sur interconnexion cross-cloud pour l'un des chemins de trafic suivants, ou les deux, en fonction de vos exigences de sécurité et de coût :

Transport de requêtes (--service-directory-name) : achemine les lectures de requêtes depuis BigQuery ou des moteurs Open Source vers votre stockage d'objets distant (Amazon S3) pour réduire les frais de sortie cross-cloud et maintenir une latence de requête prévisible.
Actualisation des métadonnées en arrière-plan (--metadata-service-directory-name) : achemine les requêtes d'actualisation des métadonnées et d'authentification en arrière-plan du plan de contrôle depuis le catalogue d'exécution Lakehouse vers le point de terminaison privé de votre catalogue de données AWS Glue distant (par exemple, lorsque votre catalogue distant limite l'accès à l'Internet public).

Si vous acheminez à la fois le transport des requêtes et l'actualisation des métadonnées en arrière-plan via interconnexion cross-cloud, suivez les étapes de configuration du point de terminaison privé, du routage et de l'Annuaire des services une fois pour votre point de terminaison de stockage distant et une fois pour votre point de terminaison de catalogue distant. Les deux services de l'Annuaire des services doivent se trouver dans la même région Google Cloud que votre catalogue fédéré et peuvent partager le même sous-réseau proxy réservé et le même espace de noms de l'Annuaire des services.

Vous pouvez utiliser l'un des deux flux architecturaux pour acheminer le trafic de l'Annuaire des services vers vos points de terminaison privés distants :

Routage de l'équilibreur de charge réseau proxy régional interne : utilise un équilibreur de charge réseau proxy régional interne Google Cloudpour répartir les requêtes entre les groupes de points de terminaison du réseau (NEG) de connectivité hybride qui pointent vers les adresses IP de vos points de terminaison privés distants (interfaces réseau élastiques AWS (ENI)). Ce flux est requis pour interconnexion cross-cloud partenaire et recommandé pour interconnexion cross-cloud dédié pour l'équilibrage de charge, l'évolutivité et la haute disponibilité.
Routage direct des points de terminaison : connecte l'Annuaire des services directement à une seule adresse IP de point de terminaison privé distant. Ce flux ne fonctionne qu'avec interconnexion cross-cloud dédié et n'est pas compatible avec interconnexion cross-cloud partenaire.

Sélectionnez le flux de configuration qui correspond à vos exigences d'architecture :

Équilibreur de charge réseau proxy interne régional

Pour configurer un équilibreur de charge réseau proxy interne régional qui distribue les requêtes entre les adresses IP de vos points de terminaison privés distants, procédez comme suit :

Configurer des points de terminaison privés cloud distants

Créez des points de terminaison privés dans le réseau et les sous-réseaux distants qui se connectent à votre réseau VPC Google Cloud via interconnexion cross-cloud, et notez les adresses IP privées attribuées à chaque point de terminaison :

Pour le transport de requêtes privées (stockage d'objets distant) : créez un point de terminaison de VPC d'interface pour Amazon S3 (com.amazonaws.AWS_REGION.s3) dans votre VPC AWS, puis notez les adresses IP privées des ENI provisionnées.
Pour l'actualisation privée des métadonnées en arrière-plan (catalogue distant) : créez un point de terminaison de VPC d'interface pour AWS Glue (com.amazonaws.AWS_REGION.glue) dans votre VPC AWS, puis notez les adresses IP privées des ENI provisionnées.
Règles de sécurité entrantes : vérifiez que les groupes de sécurité AWS associés à vos points de terminaison privés autorisent le trafic TCP entrant sur le port 443 à partir de vos plages CIDR de VPC Google Cloud . Incluez la plage CIDR de votre sous-réseau proxy réservé Google Cloud pour autoriser les vérifications d'état et le trafic transféré.

Configurer la mise en réseau Google Cloud

Exécutez les commandes suivantes pour configurer l'équilibreur de charge interne. Si vous acheminez à la fois le transport des requêtes et l'actualisation des métadonnées en arrière-plan via interconnexion cross-cloud, configurez un service de backend, un proxy TCP cible et une règle de transfert distincts pour votre point de terminaison de stockage et votre point de terminaison de catalogue. Pour les configurations avancées, consultez Configurer un équilibreur de charge réseau proxy régional interne pour les points de terminaison hybrides.

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

Remplacez les éléments suivants :

PROXY_SUBNET_NAME : nom du sous-réseau proxy réservé.
PROXY_SUBNET_RANGE : plage CIDR inutilisée dans votre réseau VPC (par exemple, 10.129.0.0/23).

Créez une vérification de l'état TCP régionale :
```
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443
```
Remplacez les éléments suivants :
- HEALTH_CHECK_NAME : nom de la vérification d'état.
- REGION : région Google Cloud (par exemple, us-east4).
Créez des groupes de points de terminaison du réseau (NEG) de connectivité hybride et ajoutez des points de terminaison :

Créez un NEG hybride (NON_GCP_PRIVATE_IP_PORT) pour chaque zone :
```
gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK
```
Ajoutez l'adresse IP privée de l'ENI de votre point de terminaison distant au NEG hybride :
```
gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=REMOTE_ENDPOINT_IP,port=443"
```
Remplacez les éléments suivants :
- NEG_NAME : nom du NEG hybride.
- ZONE : zone Google Cloud (par exemple, us-east4-a). Cette zone doit se trouver dans la région de votre rattachement de VLAN interconnexion cross-cloud.
- VPC_NETWORK : nom de votre réseau VPC.
- REMOTE_ENDPOINT_IP : adresse IP privée de votre point de terminaison privé de stockage distant ou de catalogue distant dans cette zone.
Si votre point de terminaison distant possède plusieurs adresses IP privées réparties dans différentes zones, répétez ces commandes pour créer des NEG hybrides et ajouter des points de terminaison pour chaque zone.
Créez et configurez le service de backend :

Créez un service de backend régional avec un équilibrage de charge géré interne :
```
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
```
Ajoutez vos NEG hybrides au service de backend :
```
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
```
Remplacez les éléments suivants :
- BACKEND_SERVICE_NAME : nom du service de backend.
- NEG_NAME : nom du NEG hybride que vous avez créé à l'étape précédente.
- ZONE : zone Google Cloud (par exemple, us-east4-a).
- MAX_CONNECTIONS : nombre maximal de connexions simultanées pour le backend (par exemple, 100).
Répétez la commande add-backend pour chaque NEG hybride que vous avez créé.

Configurez l'interface de l'équilibreur de charge :

Créez un proxy TCP cible :

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

Créez une règle de transfert pour acheminer le trafic vers le proxy cible :

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

Remplacez les éléments suivants :

TARGET_PROXY_NAME : nom du proxy cible.
FORWARDING_RULE_NAME : nom de la règle de transfert.
VPC_SUBNET : nom de votre sous-réseau VPC.

Après avoir créé la règle de transfert pour l'équilibreur de charge, notez l'adresse IP interne qui lui est attribuée. C'est votre ILB_IP_ADDRESS.

Configurer l'Annuaire des services

Enregistrez l'adresse IP de l'équilibreur de charge interne dans l'Annuaire des services afin que Lakehouse puisse la découvrir et l'acheminer de manière privée. Si vous avez configuré des règles de transfert d'équilibreur de charge distinctes pour le transport des requêtes et l'actualisation des métadonnées en arrière-plan, créez un service et un point de terminaison Annuaire des services distincts pour chaque adresse IP de règle de transfert.

Créez un espace de noms pour vos points de terminaison privés distants :
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Remplacez les éléments suivants :
- NAMESPACE : identifiant unique de votre espace de noms.
- PROJECT_ID : ID de votre projet Google Cloud .
- REGION : région Google Cloud (par exemple, us-east4). Il doit s'agir de la même région que votre catalogue fédéré.
Créez un service dans l'espace de noms de l'Annuaire des services :
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Remplacez les éléments suivants :
- SERVICE_NAME : identifiant unique de votre service (créez un nom de service distinct, tel que METADATA_SERVICE_NAME, lors de l'enregistrement d'un point de terminaison d'actualisation des métadonnées en arrière-plan).
Créez un point de terminaison pour la règle de transfert de l'équilibreur de charge dans le service :
```
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
```
Remplacez les éléments suivants :
- ENDPOINT_NAME : identifiant unique de votre point de terminaison.
- PROJECT_NUMBER : numéro de votre projet Google Cloud. Utilisez votre numéro de projet dans l'option --network.
- ILB_IP_ADDRESS : adresse IP interne de la règle de transfert de votre équilibreur de charge.

Point de terminaison direct

Pour configurer l'Annuaire des services afin d'acheminer le trafic directement vers une seule adresse IP de point de terminaison privé distant via interconnexion cross-cloud dédié, procédez comme suit :

Créez le point de terminaison privé dans votre réseau cloud distant :
- Pour le transport de requêtes privées : créez un point de terminaison d'interface VPC pour Amazon S3 (com.amazonaws.AWS_REGION.s3) dans votre VPC AWS.
- Pour l'actualisation privée des métadonnées en arrière-plan : créez un point de terminaison de VPC d'interface pour AWS Glue (com.amazonaws.AWS_REGION.glue) dans votre VPC AWS.
Notez l'adresse IP privée et le port (443) de chaque point de terminaison, puis vérifiez que vos groupes de sécurité AWS autorisent le trafic TCP entrant sur le port 443 depuis votre réseau VPC Google Cloud .
Créez un espace de noms pour vos points de terminaison privés distants :
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Remplacez les éléments suivants :
- NAMESPACE : identifiant unique de votre espace de noms.
- PROJECT_ID : ID de votre projet Google Cloud .
- REGION : région Google Cloud (par exemple, us-east4). Il doit s'agir de la même région que votre catalogue fédéré.
Créez un service dans l'espace de noms de l'Annuaire des services (si vous acheminez de manière privée à la fois le transport des requêtes et l'actualisation des métadonnées en arrière-plan, créez un service distinct pour chaque point de terminaison) :
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Remplacez les éléments suivants :
- SERVICE_NAME : identifiant unique de votre service (créez un nom de service distinct, tel que METADATA_SERVICE_NAME, lors de l'enregistrement d'un point de terminaison d'actualisation des métadonnées en arrière-plan).
Créez un point de terminaison dans le service avec l'adresse IP privée et le port de votre point de terminaison privé distant :
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=REMOTE_ENDPOINT_IP \
    --port=REMOTE_ENDPOINT_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
```
Remplacez les éléments suivants :
- ENDPOINT_NAME : identifiant unique de votre point de terminaison.
- REMOTE_ENDPOINT_IP : adresse IP privée de votre point de terminaison privé de stockage distant ou de catalogue distant (par exemple, 10.0.1.45).
- REMOTE_ENDPOINT_PORT : numéro de port de votre point de terminaison privé distant (par exemple, 443).
- PROJECT_NUMBER : numéro de votre projet Google Cloud. Utilisez votre numéro de projet dans l'option --network.
- VPC_NETWORK : nom du réseau VPC Google Cloudassocié à votre interconnexion privée.

Configurer la fédération

Pour interroger vos données, vous devez configurer un catalogue fédéré Lakehouse qui se connecte à votre catalogue de données AWS Glue distant.

Créer le rôle AWS IAM avec une stratégie d'approbation d'espace réservé

Lakehouse provisionne un ID de compte de service Google après la création du catalogue. Créez le rôle AWS IAM avec une stratégie de confiance d'espace réservé.

Créez un fichier nommé 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"
          ]
        }
      }
    }
  ]
}

Exécutez la commande AWS CLI pour créer le rôle avec la stratégie d'approbation d'espace réservé. Nous vous recommandons de définir la durée maximale de la session sur 12 heures (43200 secondes) pour éviter l'expiration des identifiants lors des jobs de longue durée :
```
aws iam create-role \
  --role-name AWS_ROLE_NAME \
  --assume-role-policy-document file://trust_policy.json \
  --max-session-duration 43200
```
Remplacez les éléments suivants :
- AWS_ROLE_NAME : nom de votre rôle AWS IAM. Exemple : lakehouse_glue_federation_role.

Associer une stratégie d'autorisation

Associez une stratégie d'autorisations à votre rôle IAM qui permet à Lakehouse d'accéder au Data Catalog Glue et aux buckets S3 de la région AWS. Cette stratégie accorde également l'accès aux buckets de table S3 si vous utilisez l'intégration des tables S3 AWS Lake Formation. Si vous êtes passé des autorisations de données AWS Glue par défaut au modèle AWS Lake Formation, vous devrez peut-être accorder des autorisations supplémentaires dans Lake Formation.

Créez un fichier nommé permissions_policy.json avec la configuration de stratégie suivante.

{
  "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:*"
      ]
    }
  ]
}

Si vous utilisez des clés gérées par le client hébergées dans AWS Key Management Service (KMS) pour chiffrer des ressources AWS Glue, Amazon S3 ou Amazon S3 Tables, vous devez ajouter une instruction accordant l'accès à la clé KMS pour déchiffrer les ressources :

# ...
{
  "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"
  ]
}
# ...

Associez cette stratégie d'autorisations à votre rôle IAM :
```
aws iam put-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-name AWS_POLICY_NAME \
  --policy-document file://permissions_policy.json
```
Remplacez les éléments suivants :
- AWS_ROLE_NAME : nom de votre rôle AWS IAM. Exemple : lakehouse_glue_federation_role.
- AWS_POLICY_NAME : nom de votre stratégie d'autorisations. Exemple :lakehouse_glue_federation_policy
- AWS_REGION : région AWS dans laquelle se trouve votre catalogue Glue ou vos tables S3. Exemple :us-east-1
- AWS_ACCOUNT_ID : chaîne d'ID de compte AWS à 12 chiffres. Exemple :123456789012

Créer un catalogue fédéré

Créez le catalogue fédéré à l'aide de la console Google Cloud ou de Google Cloud CLI.

Pour éviter les échecs d'actualisation prématurée des métadonnées en arrière-plan pendant la propagation des relations de confiance AWS, initialisez le catalogue sans spécifier de calendrier d'actualisation (qui est défini par défaut sur 0s).

Console

Pour créer un catalogue fédéré :

Dans la console Google Cloud , accédez à Lakehouse.

Accéder à Lakehouse
Cliquez sur Créer un catalogue.
Cliquez sur Catalogue fédéré.

La section Configuration du catalogue s'affiche.
Pour Source du catalogue fédéré, sélectionnez AWS Glue.
Pour Emplacement des données, sélectionnez la région Lakehouse dans laquelle vous souhaitez créer le catalogue fédéré. Exemple :us-east4 Pour réduire la latence (même sur l'Internet public), sélectionnez la région Google Cloud la plus proche de votre région AWS.
Cliquez sur Continuer.

La section Détails de la connexion s'affiche.
Dans la section Détails du catalogue distant, dans le champ Entrepôt AWS, saisissez l'ID de votre compte AWS ou le catalogue de buckets de tableaux S3. Par exemple, 123456789012 ou 123456789012:s3tablescatalog/my-table-bucket.
Dans le champ Région AWS, saisissez votre région AWS. Par exemple, us-east-1.
Dans le champ ARN du rôle AWS, saisissez l'ARN de votre rôle AWS. Utilisez le format suivant : arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME.
Sous Couche transport, sélectionnez Internet public ou Interconnexion privée dédiée. Si vous sélectionnez Interconnexion privée dédiée, configurez les champs suivants :
- Dans le champ Nom de l'Annuaire des services, saisissez le chemin d'accès à votre service de transport de l'Annuaire des services au format projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME.
- Facultatif : Pour synchroniser les métadonnées du catalogue de manière privée via interconnexion cross-cloud, saisissez le chemin d'accès à votre service d'annuaire des services de métadonnées au format projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME dans le champ Nom de l'annuaire des services de métadonnées.
Cliquez sur Créer.

gcloud

Internet public (pas de CCI)

Si vous ne configurez pas interconnexion cross-cloud, les connexions transitent par l'Internet public à l'aide de TLS.

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Appartenant au client (CCI)

Si vous avez configuré une interconnexion privée (interconnexion cross-cloud dédiée ou partenaire), fournissez la référence du service de l'Annuaire des services pour le transport de requêtes privées (--service-directory-name), l'actualisation privée des métadonnées en arrière-plan (--metadata-service-directory-name) ou les deux. Vous pouvez également ajouter ou mettre à jour l'un ou l'autre de ces indicateurs sur un catalogue existant en exécutant gcloud biglake iceberg catalogs update.

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME"

Remplacez les éléments suivants :

FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré.
PROJECT_ID : ID de votre projet Google Cloud .
REGION : région Lakehouse où le catalogue fédéré est créé. Il doit s'agir de la même région que l'espace de noms de l'Annuaire des services et le secret régional.
GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE : identifiant de votre catalogue d'entrepôt cible. Pour le Data Catalog Glue d'une région AWS, saisissez la chaîne d'ID de votre compte AWS à 12 chiffres. Exemple : 123456789012. Pour utiliser un bucket de table S3 dans la région, saisissez AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. Par exemple, 123456789012:s3tablescatalog/my-table-bucket.
AWS_ACCOUNT_ID : chaîne d'ID de compte AWS à 12 chiffres. Exemple :123456789012
AWS_REGION : région AWS dans laquelle se trouve votre catalogue Glue ou votre bucket de tableaux S3. Exemple :us-east-1
AWS_ROLE_NAME : nom de votre rôle AWS IAM. Exemple : lakehouse_glue_federation_role.
NAMESPACE_FILTERS : (facultatif) liste d'espaces de noms à fédérer, séparés par une virgule. Exemple :ns1,ns2 Si cette option est omise, Lakehouse inclut tous les espaces de noms.
CROSS_CLOUD_CACHE_MODE (facultatif) : indique si la mise en cache cross-cloud doit être activée sur le catalogue fédéré (enabled ou disabled). La valeur par défaut est disabled. Lorsqu'elle est définie sur enabled, Lakehouse met en cache les fichiers distants dans la régionGoogle Cloud du catalogue. Pour en savoir plus, consultez Mise en cache intelligente.
Si vous utilisez une interconnexion privée (interconnexion cross-cloud), spécifiez l'une des références d'annuaire des services suivantes, ou les deux (omettez l'un ou l'autre des indicateurs si vous n'acheminez pas cette couche de trafic via interconnexion cross-cloud) :
- SERVICE_DIRECTORY_NAMESPACE et SERVICE_NAME : espace de noms et nom du service de l'Annuaire des services que vous avez créés pour le transport des requêtes privées vers le store d'objets distant.
- METADATA_SERVICE_DIRECTORY_NAMESPACE et METADATA_SERVICE_NAME : espace de noms et nom du service Annuaire des services que vous avez créés pour l'actualisation privée des métadonnées en arrière-plan.

Mettre à jour la stratégie de confiance

Lors de la création du catalogue, Lakehouse provisionne un compte de service unique pour celui-ci, qui est renvoyé dans le champ biglake-service-account-id de la réponse de création du catalogue. Vous utiliserez ce compte de service pour établir la relation de confiance.

Exécutez la commande suivante pour extraire la valeur biglake-service-account-id dans une variable bash active :

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

Mettez à jour la stratégie de confiance de votre rôle AWS IAM pour remplacer l'espace réservé par l'ID de votre agent de service Google validé. Le bloc de condition valide la correspondance sub et aud. Écrivez la stratégie dans un fichier nommé 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

Appliquez la stratégie finalisée à votre rôle AWS :
```
aws iam update-assume-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-document file://trust_policy_comprehensive.json
```
Remarque : La propagation des modifications apportées à AWS IAM peut prendre quelques minutes.

Activer l'actualisation des métadonnées en arrière-plan

Maintenant que des relations de confiance sécurisées ont été établies sur les deux plates-formes, mettez à jour votre catalogue pour activer l'actualisation des métadonnées en arrière-plan (toutes les cinq minutes ou 300s, ou plus).

gcloud

gcloud 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"
        }
      }
    }
  }'

Terminer la configuration de l'interconnexion privée (interconnexion cross-cloud uniquement)

Si vous acheminez le transport des requêtes, l'actualisation des métadonnées en arrière-plan ou les deux via une interconnexion privée (Dedicated ou Partner interconnexion cross-cloud), vous devez accorder au compte de service du catalogue Lakehouse les autorisations nécessaires pour découvrir et autoriser les connexions via l'Annuaire des services. Si votre service d'annuaire des services de transport et votre service d'annuaire des services de métadonnées sont hébergés dans différents projets Google Cloud , attribuez ces rôles à chaque projet qui héberge un service d'annuaire des services.

Console

Dans la console Google Cloud , accédez à la page IAM.

Accéder à IAM
Cliquez sur Accorder l'accès (ou Ajouter).
Dans le champ Nouveaux comptes principaux, saisissez l'adresse e-mail du compte de service du catalogue Lakehouse. Vous pouvez récupérer cette adresse e-mail en décrivant le catalogue (voir l'onglet gcloud).
Dans le menu Rôle, sélectionnez Lecteur de l'Annuaire des services (roles/servicedirectory.viewer).
Cliquez sur Ajouter un autre rôle, puis sélectionnez Service autorisé PSC de l'Annuaire des services (roles/servicedirectory.pscAuthorizedService).
Cliquez sur Enregistrer.

gcloud

Attribuez les rôles requis au compte de service du catalogue sur le projet hébergeant vos services de l'Annuaire des services :

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud 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 biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Vérifier la connexion

Vérifiez que le cycle d'actualisation des métadonnées en arrière-plan du catalogue s'est bien terminé et que les espaces de noms sont synchronisés.

Vérifiez que l'état de l'actualisation indique que l'opération a réussi :

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

Vérifiez que les espaces de noms sont synchronisés :

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

Configurer une connexion multicloud pour AWS Glue Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Rôles requis

Limites et points à noter

Workflow général

Configurer interconnexion cross-cloud (facultatif)

Équilibreur de charge réseau proxy interne régional

Point de terminaison direct

Configurer la fédération

Créer le rôle AWS IAM avec une stratégie d'approbation d'espace réservé

Associer une stratégie d'autorisation

Créer un catalogue fédéré

Console

gcloud

Internet public (pas de CCI)

Appartenant au client (CCI)

Mettre à jour la stratégie de confiance

Activer l'actualisation des métadonnées en arrière-plan

gcloud

REST

Terminer la configuration de l'interconnexion privée (interconnexion cross-cloud uniquement)

Console

gcloud

Vérifier la connexion

Étapes suivantes

Configurer une connexion multicloud pour AWS Glue