Partage de données inter-comptes et inter-régions SageMaker Unified Studio

L'association de comptes suit la même procédure dans les deux scénarios. Même dans le cas de l'inter-régions, l'association s'effectue dans la région d'origine du domaine. En d'autres termes, un domaine SMUS n'associe pas des régions ; il associe des comptes.

Cela permet de conserver une procédure d'association simple et identique dans les deux cas de figure. Pour associer un compte, il suffit de se rendre dans l'onglet Associated accounts sur la page d'accueil du domaine SageMaker Unified Studio et d'en faire la demande. Pour les besoins de cette démonstration, je vais associer deux comptes : l'un pour une souscription dans la même région, et l'autre pour une souscription inter-régions. Vous trouverez ci-dessous un exemple de demande d'association.

Configuration des comptes :

• 174772361029 — op : compte contenant les actifs (asset account) dans us-east-1
• 060344053677 — op1 : compte externe (cross-account) dans us-east-1
• 445817184045 — op2 : compte externe inter-régions (cross-region account) dans eu-west-1

N'utilisant pas AWS Organizations, j'ai choisi un compte externe. Les options de permission diffèrent entre les comptes d'organisation et les comptes externes ; associer un compte de la même organisation est généralement plus simple.

Choisir la deuxième option, « IAM users and roles can access APIs and IAM users can log in to Amazon SageMaker Unified Studio », permet aux utilisateurs de travailler dans le même domaine depuis le compte associé. Cela leur donne également la capacité d'exécuter des appels API et des actions à l'intérieur du domaine.

Cette option déclenche un partage de ressources AWS RAM (resource share) du domaine lui-même, du compte source vers le compte associé, dans la région d'origine du domaine.

Pour une création simple de projet inter-comptes, activez les blueprints Tooling et Lakehouse Database. Il est préférable d'utiliser les rôles créés automatiquement, à moins que vous ne travailliez via l'API ou IaC, auquel cas vous créez les rôles vous-même. Les politiques sont toutes gérées par AWS, et les articles précédents ont déjà couvert ce dont chaque rôle est responsable.

Le scénario inter-régions est différent. Tout d'abord, vous devez activer la région cible dans le blueprint Tooling du domaine. Cela met en place les fondations pour la région cible.

Le domaine principal est provisionné dans us-east-1, et le projet sera créé dans eu-west-1. La configuration Tooling contiendra donc une nouvelle région : eu-west-1.

Dans le compte local, ajoutez également la nouvelle région eu-west-1 dans l'onglet Regions du blueprint Lakehouse Database.

Dans le compte associé, vous devez également activer le blueprint Tooling. N'oubliez pas que le domaine est associé dans us-east-1, de sorte que les ressources VPC et sous-réseaux doivent être présentes à la fois dans us-east-1 et eu-west-1. Cela signifie que le compte associé active Tooling dans us-east-1 (la région d'origine du domaine) et dans eu-west-1 (la région cible). Les deux doivent être présents.

Le blueprint Lakehouse Database doit également être activé, avec la même configuration de région.

Dans les deux régions du compte cible, Lake Formation doit être activé et la version de partage inter-comptes définie sur 5.

Une fois les blueprints activés, les profils de projet peuvent être créés dans le domaine SMUS. Pour les profils de projet inter-comptes et inter-régions, les paramètres peuvent être définis directement dans le profil ou reportés au moment du déploiement.

Ensuite, la création du projet devrait se dérouler sans problème une fois que tout ce qui précède est correctement configuré, comme vu dans les articles précédents. À cette étape, les paramètres sont définis et le provisionnement du projet s'exécute.

Pour rappel, un projet s'appuie sur deux piles CloudFormation. Elles sont provisionnées dans le compte et la région définis dans le profil du projet. Pour un projet inter-régions, ses piles seront dans eu-west-1.

La procédure inter-comptes est simple. Nous pouvons appliquer des filtres, mais ici, partageons l'intégralité de la table.

Une fois la demande approuvée (auto-approuvée si vous possédez les deux projets), le projet inter-comptes obtient l'accès à l'actif de données demandé. Cela se signale par le fait que l'actif devient accessible.

Dans le compte cible, nous pouvons nous connecter avec un utilisateur IAM et requêter la table directement depuis le domaine, puisque nous avons partagé l'accès lors de l'association.

Avant de poursuivre, il est important de prendre en compte certaines limites. Les requêtes Athena inter-régions entraînent des coûts de transfert de données S3 inter-régions et une latence réseau supplémentaire. Bien que SMUS rende le partage transparent, ces facteurs sont inhérents aux architectures inter-régions et doivent être évalués par rapport aux exigences de performances et de budget de votre projet.

La procédure est fondamentalement la même que pour l'inter-comptes, avec une seule différence concernant le premier actif partagé. Cela commence par la demande de souscription.

Dans le cas inter-régions, l'invitation RAM (RAM resource share invitation) n'est généralement pas approuvée automatiquement par SMUS. La première fois, nous devons l'approuver manuellement.

Le statut d'accès peut afficher un cercle de chargement qui tourne indéfiniment. Dans ce cas, vérifiez le partage de ressources RAM (RAM resource share). C'est contre-intuitif : même si la région cible de l'actif est eu-west-1 après souscription, le compte source envoie l'invitation de partage de ressources dans la région d'origine du domaine (us-east-1).

Si votre partage inter-régions reste bloqué indéfiniment, vérifiez l'invitation RAM dans le compte cible, dans la région d'origine du domaine. Dans cet exemple, il s'agit du compte de destination dans us-east-1.

Après acceptation de l'invitation, l'actif devrait être disponible immédiatement. Il s'agit d'une action unique effectuée lors de la première souscription ; les suivantes fonctionnent de manière fluide. Ces invitations peuvent également être acceptées au préalable, au niveau de l'association des comptes par exemple.

L'actif peut ensuite être interrogé depuis le compte cible également.

Vous remarquerez peut-être que us-east-1 est mentionnée comme région. Ce n'est pas une erreur : c'est la région du domaine. Le domaine SMUS gère cet actif à travers les régions, et dans Lake Formation, la localisation réelle de l'actif est claire.

En théorie, l'ajout d'un principal à la cible de souscription (subscription target) de votre environnement de blueprint Lakehouse Database octroie l'accès externe automatiquement. Cela s'applique uniquement aux nouvelles souscriptions : SMUS applique la nouvelle configuration aux nouvelles souscriptions, et les anciennes souscriptions ne reçoivent pas l'octroi (grant) sur le rôle.

En pratique, si vous avez déjà des actifs dans le projet, les rôles nouvellement accordés dans la cible de souscription n'auront pas accès. Pour accorder l'accès, actualisez la souscription (révoquez et souscrivez à nouveau) ou utilisez directement les octrois (grants) Lake Formation.

Il y a une autre limitation : une cible de souscription n'accepte que des rôles uniques. Une fois qu'un rôle a été assigné à une cible de souscription, ce même rôle ne peut pas être assigné à une autre cible de souscription.

Nous pouvons contourner cela, car en coulisses, il s'agit d'une procédure de partage Lake Formation inter-comptes ou inter-régions. Voici comment cela fonctionne :

• La souscription est demandée et approuvée.
• Les permissions Lake Formation sont octroyées depuis le compte source sur la table partagée, pour tous les principaux dans la cible de souscription du projet de destination (les cibles de souscription ont été couvertes dans les articles précédents).
• Le partage RAM est vérifié ; s'il n'est pas présent, il est approuvé automatiquement dans le compte cible (sauf pour l'inter-régions).
• Un lien de ressource Glue (Glue resource link) est créé dans le compte cible.

Le même processus peut être appliqué en dehors de SMUS. C'est fondamentalement la configuration requise pour accéder aux actifs Glue de Lake Formation en inter-comptes ou inter-régions. SMUS automatise non seulement ce processus, mais l'enveloppe également dans une gestion des opérations impressionnante à grande échelle. Dans notre cas, la plupart des étapes sont déjà effectuées, car nous essayons d'accéder à une souscription existante : le partage RAM et le lien de ressource Glue sont déjà présents. Seuls les octrois Lake Formation restent à faire.

Je n'ai jamais réussi à accorder des principaux (principals) inter-comptes via la console Lake Formation, mais il est possible de le faire via l'API.

Le propriétaire de l'actif accorde les droits DESCRIBE et SELECT sur l'actif (ou sur les actifs d'une base de données) au principal inter-comptes. C'est logique : le propriétaire de l'actif est celui qui partage l'actif.

Warning: Accorder manuellement des permissions (grants) Lake Formation en dehors de SMUS crée une dérive de gouvernance. SMUS ne suit pas ces octrois manuels, ce qui signifie qu'une actualisation de la souscription ne les révoquera pas, et aucun des filtres de données configurés via SMUS ne sera appliqué.

# validated
aws lakeformation grant-permissions \
    --principal DataLakePrincipalIdentifier="arn:aws:iam::445817184045:user/op2" \
    --resource '{ "Table": { "CatalogId": "174772361029", "DatabaseName": "glue_db_destination", "Name": "customer_orders" } }' \
    --permissions "DESCRIBE" "SELECT"

# AI generated
import boto3

boto3.client('lakeformation').grant_permissions(
    Principal={
        'DataLakePrincipalIdentifier': 'arn:aws:iam::445817184045:user/op2'
    },
    Resource={
        'Table': {
            'CatalogId': '174772361029',
            'DatabaseName': 'glue_db_destination',
            'Name': 'customer_orders'
        }
    },
    Permissions=[
        'DESCRIBE',
        'SELECT'
    ]
)

// AI generated
import { LakeFormationClient, GrantPermissionsCommand } from "@aws-sdk/client-lakeformation";

new LakeFormationClient({ region: "us-east-1" }).send(
  new GrantPermissionsCommand({
    Principal: {
      DataLakePrincipalIdentifier: "arn:aws:iam::445817184045:user/op2"
    },
    Resource: {
      Table: {
        CatalogId: "174772361029",
        DatabaseName: "glue_db_destination",
        Name: "customer_orders"
      }
    },
    Permissions: [
      "DESCRIBE",
      "SELECT"
    ]
  })
);

Ceci est un octroi inter-comptes. Cela déclenche normalement une invitation de partage RAM, mais puisque nous utilisons la version 5 de Lake Formation, l'intégralité du catalogue a déjà été partagée.

En vérifiant les permissions accordées, nous pouvons identifier les principaux cibles de souscription par :

• AllIAMPrincipals : un octroi conditionnel (conditional grant) du compte local avec une expression régulière correspondant à SMUS et à l'identifiant du projet.
• <account-id>:IAMPrincipals : un octroi conditionnel inter-comptes avec une expression régulière correspondant à SMUS et à l'identifiant du projet.

L'octroi sur op2 apparaît également avec l'identifiant de compte externe. Il ne correspond pas au modèle d'octroi conditionnel utilisé par SMUS, mais il donne un accès complet à l'actif sans condition. En utilisant ce rôle, vous pouvez accéder à l'actif depuis n'importe quel autre service.

L'exemple ci-dessus accorde l'accès à l'actif partagé inter-comptes et inter-régions. En allant dans Athena avec le principal accordé, nous pouvons voir que l'actif est accessible dans la région eu-west-1.

L'accès est total. Si les actifs ont été partagés dans le projet avec des filtres de lignes et de colonnes, ces filtres ne seront pas visibles ici, car les filtres sont appliqués sur l'octroi (grant) Lake Formation au moment où la souscription est accordée. Les mêmes filtres doivent être ajoutés à l'octroi manuel inter-comptes ci-dessus si vous en avez besoin.

L'évolution du partage RAM Lake Formation est un changement rafraîchissant. Cela permet au catalogage SMUS de fonctionner parfaitement à l'échelle, et il est formidable de voir les services évoluer de manière à faciliter le catalogage des actifs de données, non seulement à grande échelle mais aussi avec une capacité maillée (mesh). Si vous exécutez votre propre solution de catalogage Lake Formation sur les API AWS, la version 5 réduit considérablement l'empreinte opérationnelle et rend l'automatisation à la fois facile et robuste.

SMUS peut tirer pleinement parti de cela, offrant d'excellentes fonctionnalités de catalogage aux services de données et aux applications qui s'y exécutent.