31 juil. 2026

De DataZone à SageMaker Unified Studio : Évolution du Blueprint DataLakehouse

Dans cet article, nous allons explorer en profondeur les différences entre le blueprint DataLakehouse d'Amazon DataZone et celui d'Amazon SageMaker Unified Studio (SMUS).

Nous aborderons les changements majeurs de procédure lors de la publication de données et de la création d'abonnements. Étant donné que le nouveau blueprint de SMUS présente des différences notables, nous examinerons comment reproduire le même comportement que sur DataZone v1 en utilisant des modèles personnalisés.

Le Blueprint DataLakehouse

Le blueprint DataLakehouse offre aux projets la possibilité d'accéder aux ressources AWS Lake Formation v3 Glue, de les publier sur un portail, de les rendre disponibles pour des abonnements par d'autres projets et de les interroger dans les environnements Athena ou Redshift. Dans DataZone, cela était possible au sein d'un même compte, en cross-account, et plus récemment en cross-account / cross-region depuis le même domaine. Cela permet d'offrir aux utilisateurs un accès unique à un catalogue de données organisé avec des métadonnées avancées, des capacités d'IA générative et un traçage détaillé (lineage). Le tout est géré par DataZone une fois le projet correctement configuré.

En coulisses, le blueprint est une stack CloudFormation qui déploie de multiples ressources pour supporter ces opérations : des permissions, un groupe de travail Athena et deux bases de données Glue. L'une contient les données que nous souhaitons publier sur DataZone via ce blueprint, tandis que l'autre contient les ressources souscrites par d'autres projets (la majorité des ressources créées ici seront des liens Glue vers les ressources d'origine).

Avec Lake Formation v3, nous pouvons autoriser l'accès au niveau de la base de données ou de la table. Cependant, cet accès est assez permissif : les permissions Lake Formation sont propagées et peuvent être exploitées par un autre service, comme Redshift, pour interroger la même donnée dès lors que cet accès est accordé.

Transition vers SageMaker Unified Studio

Dans SageMaker Unified Studio (SMUS), nous avons la capacité d'effectuer toutes les opérations mentionnées ci-dessus tout en bénéficiant de fonctionnalités ETL, d'IA générative et d'apprentissage automatique. La quasi-totalité des flux peut être implémentée via CloudFormation, comme nous l'avons vu dans les précédents articles sur SMUS.

Cependant, cette transition s'accompagne de changements pour le blueprint DataLakehouse, notamment en ce qui concerne les permissions et les ressources. Désormais, le blueprint provisionne beaucoup moins de ressources, se résumant presque exclusivement à une seule base de données qui joue simultanément le rôle de base de publication et d'abonnement.

L'accès à Athena et Redshift peut également se faire directement depuis le studio à l'aide de connecteurs.

En matière de permissions, SMUS utilise au minimum Lake Formation v4 (Lake Formation v5 est recommandé), où les accès offrent une granularité très poussée s'étendant à travers le service jusqu'à l'identifiant du projet de la ressource. Cela rend la configuration d'accès à la fois plus robuste et plus flexible.

Reproduire la structure DataZone sur SMUS

Si vous prévoyez une migration et souhaitez conserver la même structure de bases de données, il est indispensable d'utiliser des blueprints personnalisés. Cela vous permettra de provisionner deux bases de données ainsi que la configuration requise pour obtenir le même comportement qu'avec le blueprint DataLakehouse sur DataZone v1.

Créez un blueprint personnalisé provisionnant deux bases de données, l'une dédiée aux abonnements et l'autre aux publications. Après la création du projet avec ce blueprint, nous devons configurer le projet pour qu'il reconnaisse ces bases de données.

Source de données (Datasource)

C'est littéralement la source de données du projet où nous pouvons ajouter des ressources directement au niveau du projet. Nous y trouvons de multiples réglages, allant de la base de données Glue à utiliser pour récupérer les ressources, à la découverte à la demande, entre autres.

Cette source de données doit être créée sur le projet. Il existe plusieurs types de sources de données ; nous devons utiliser et configurer celle de type datalake.

Configuration de la source de données

Avant de créer la source de données sur notre projet provisionné avec notre blueprint personnalisé, un identifiant de connexion est requis. Par défaut, le projet prend en charge plusieurs connexions, il faut donc trouver celle correspondant à notre blueprint.

Pour lister les connexions, utilisez les appels suivants :

Lister les Connexions

 # Validé et testé
response = client.list_connections(
    domainIdentifier='dzd-domain-id',
    projectIdentifier='project_id',
) 
 # Généré par IA
aws datazone list-connections \
  --domain-identifier "dzd-domain-id" \
  --project-identifier "project_id" 
 // Généré par IA
const command = new ListConnectionsCommand({
  domainIdentifier: "dzd-domain-id",
  projectIdentifier: "project_id",
});

const response = await client.send(command); 

La connexion que nous cherchons doit avoir :

name : project.default_lakehouse
type : LAKEHOUSE

Une fois l'identifiant de la connexion obtenu, créez la source de données :

Créer la Source de Données

 # Validé et testé
response = client.create_data_source(
    name='data_source_name',
    description='data_source_description',
    domainIdentifier='dzd-domain-id',
    projectIdentifier='project_id',
    connectionIdentifier='connection_id',
    type='GLUE',
    configuration={
        'glueRunConfiguration': {
            'relationalFilterConfigurations': [
                {
                    'databaseName': 'name_of_source_pub_db'
                }
            ]
        }
    },
    enableSetting='ENABLED',
    schedule={
        'timezone': 'UTC',
        'schedule': 'cron(* * * * * *)'
    },
    publishOnImport=True, # ou False
    clientToken='random_string'
) 
 # Généré par IA
aws datazone create-data-source \
  --name "data_source_name" \
  --description "data_source_description" \
  --domain-identifier "dzd-domain-id" \
  --project-identifier "project_id" \
  --connection-identifier "connection_id" \
  --type "GLUE" \
  --configuration '{"glueRunConfiguration": {"relationalFilterConfigurations": [{"databaseName": "name_of_source_pub_db"}]}}' \
  --enable-setting "ENABLED" \
  --schedule '{"timezone": "UTC", "schedule": "cron(* * * * * *)"}' \
  --publish-on-import \
  --client-token "random_string" 
 // Généré par IA
const command = new CreateDataSourceCommand({
  name: "data_source_name",
  description: "data_source_description",
  domainIdentifier: "dzd-domain-id",
  projectIdentifier: "project_id",
  connectionIdentifier: "connection_id",
  type: "GLUE",
  configuration: {
    glueRunConfiguration: {
      relationalFilterConfigurations: [
        {
          databaseName: "name_of_source_pub_db",
        },
      ],
    },
  },
  enableSetting: "ENABLED",
  schedule: {
    timezone: "UTC",
    schedule: "cron(* * * * * *)",
  },
  publishOnImport: true, // ou false
  clientToken: "random_string",
});

const response = await client.send(command); 

Sur la source de données, nous pouvons :

Configurer les exécutions automatiques en utilisant les expressions cron AWS et les fuseaux horaires.
Configurer la publication lors de la découverte des ressources (ex: mode automatique).
Configurer la base de données source des ressources à utiliser.

Cible d'Abonnement (Subscription Target)

Il faut considérer "où" et "qui" lors du stockage et de l'accès aux ressources du projet. Nous pouvons configurer de multiples paramètres utilisateurs sur la cible d'abonnement.

Même si la base de données est définie à ce stade, la cible d'abonnement va généralement se contenter d'assigner les permissions correctes sans créer le lien sur la base d'abonnement choisie. Pour cette raison, nous devons ajouter une autre configuration indiquant que la ressource souscrite doit également être créée avec un lien (Resource Link). Globalement, nous avons 3 méthodes :

Tout faire manuellement
Configuration pour automatiser la création de liens
Méthode RBAC (accès par rôle) par défaut du lakehouse sur la cible d'abonnement

Configuration de la cible d'abonnement

Nous devons d'abord trouver l'environnement auquel nous allons attacher la cible d'abonnement. Puisque nous avons créé un blueprint personnalisé, nous devons rechercher l'environnement par son nom et obtenir son identifiant.

Lister les Environnements

 response = client.list_environments(
    domainIdentifier='dzd-domain-id',
    projectIdentifier='project_id'
) 
 # Généré par IA
aws datazone list-environments \
  --domain-identifier "dzd-domain-id" \
  --project-identifier "project_id" 
 // Généré par IA
const command = new ListEnvironmentsCommand({
  domainIdentifier: "dzd-domain-id",
  projectIdentifier: "project_id",
});

const response = await client.send(command); 

Une fois l'identifiant de l'environnement récupéré, nous pouvons créer la cible d'abonnement :

Créer la Cible d'Abonnement

 response = client.create_subscription_target(
    domainIdentifier='dzd-domain-id',
    environmentIdentifier='environment_id',
    name='subscription_target_name',
    type='GlueSubscriptionTargetType',
    subscriptionTargetConfig=[
        {
            'formName': 'GlueSubscriptionTargetConfigForm',
            'content': json.dumps(
                {
                    "databaseName": "name_of_source_sub_db",
                    "createResourceLinks": "ALWAYS"
                }
            )
        },
    ],
    authorizedPrincipals=[
        'authorized_arns',
    ],
    manageAccessRole='datazone_usr_role_<>_<>', # Trouvé sur la page d'accueil du projet
    applicableAssetTypes=[
        'GlueTableAssetType',
        'GlueViewAssetType'
    ],
    provider='Amazon SageMaker',
    clientToken='random_string'
) 
 # Généré par IA
aws datazone create-subscription-target \
  --domain-identifier "dzd-domain-id" \
  --environment-identifier "environment_id" \
  --name "subscription_target_name" \
  --type "GlueSubscriptionTargetType" \
  --subscription-target-config '[{"formName": "GlueSubscriptionTargetConfigForm", "content": "{\"databaseName\": \"name_of_source_sub_db\", \"createResourceLinks\": \"ALWAYS\"}"}]' \
  --authorized-principals "authorized_arns" \
  --manage-access-role "datazone_usr_role_<>_<>" \
  --applicable-asset-types "GlueTableAssetType" "GlueViewAssetType" \
  --provider "Amazon SageMaker" \
  --client-token "random_string" 
 // Généré par IA
const command = new CreateSubscriptionTargetCommand({
  domainIdentifier: "dzd-domain-id",
  environmentIdentifier: "environment_id",
  name: "subscription_target_name",
  type: "GlueSubscriptionTargetType",
  subscriptionTargetConfig: [
    {
      formName: "GlueSubscriptionTargetConfigForm",
      content: JSON.stringify({
        databaseName: "name_of_source_sub_db",
        createResourceLinks: "ALWAYS",
      }),
    },
  ],
  authorizedPrincipals: [
    "authorized_arns",
  ],
  manageAccessRole: "datazone_usr_role_<>_<>",
  applicableAssetTypes: [
    "GlueTableAssetType",
    "GlueViewAssetType",
  ],
  provider: "Amazon SageMaker",
  clientToken: "random_string",
});

const response = await client.send(command); 

La liste authorizedPrincipals contiendra les ARN des rôles accédant à cette ressource après l'abonnement. Assurez-vous d'y ajouter les rôles nécessaires. SMUS gérera automatiquement les attributions de permissions sur ces principaux afin qu'ils puissent accéder à la ressource présente dans la base de données cible.

Veuillez noter que la création automatique des ressources sur la base de données de la cible d'abonnement n'est autorisée que si l'une des conditions suivantes est remplie :

La cible d'abonnement utilise des principaux ABAC (abac:CURRENT_PROJECT), ce que le blueprint DataLakehouse géré fait automatiquement et créera par conséquent la ressource à l'intérieur de la base de données sélectionnée.
La configuration GlueSubscriptionTargetConfigForm de la cible d'abonnement doit inclure "createResourceLinks": "ALWAYS".

Supprimer "createResourceLinks": "ALWAYS" empêchera la cible d'abonnement de créer automatiquement la ressource dans la base de données cible, bien que les attributions de permissions restent automatiques. En conséquence, après un abonnement, votre base de données d'abonnement pourrait être vide, et vous devriez potentiellement créer vous-même le lien Glue au lieu que SMUS ne le fasse.

Ce comportement n'est pas encore documenté. Par défaut, si vous créez la cible d'abonnement sans cette option, la création de la ressource ne sera pas gérée par SMUS.

Pièges lors de la Publication (Gotchas)

En matière d'automatisation des permissions, certaines actions relèvent désormais de la responsabilité de l'utilisateur, que ce soit pour les projets avec blueprints personnalisés ou gérés.

Examinons un scénario de test avec deux projets utilisant le blueprint DataLakehouse géré :

Premier Projet : Possède la base glue_db_ sur sa cible d'abonnement et va s'abonner à une ressource du nouveau projet.
Second Projet : Possède la base glue_db_destination qui sera le projet producteur auquel le Premier Projet va s'abonner.

Créer un projet SMUS

J'ai créé une ressource gérée par Lake Formation sur la base glue_db_destination (le bucket S3 hébergeant la table est bien enregistré sur Lake Formation).

Créer une table Glue

Après l'exécution de la source de données, je constate que la ressource a bien été découverte :

Exécuter la source de données

Lors de la première publication d'une ressource, vous pourriez rencontrer cet avertissement :

Avertissement publication table

Il indique que l'accès n'est pas géré, mais cela est souvent dû à des permissions manquantes sur la base de publication/abonnement. Ce message est un peu trompeur. Dans ce cas, nous pouvons récupérer le rôle de projet créé par SMUS (généralement visible sur la page d'accueil du projet) :

Accueil du projet

Puis lui accorder les droits DESCRIBE, SELECT ainsi que les droits LF (Lake Formation grants) sur la base de données pub/sub pour l'ensemble des tables. Lors d'une nouvelle tentative de publication, l'avertissement aura complètement disparu. Si la ressource n'est pas gérée par Lake Formation ou présente d'autres problèmes d'accès, cet avertissement réapparaîtra.

Correction permissions LF 1 Correction permissions LF 2 Publier la ressource

Une fois la ressource publiée, nous pouvons nous y abonner depuis le Premier Projet :

Abonnement projet

Après la procédure d'abonnement, les permissions et liens sont créés automatiquement et nous pouvons interroger la ressource depuis SMUS sur la page Assets du Premier Projet, via le connecteur Athena :

Interrogation de la ressource

Suite à cette attribution de droits, vous devriez pouvoir publier vos tables et vous y abonner sans aucun problème. Ceci s'applique également aux blueprints personnalisés, mais contrairement à DataZone, nous devons ici gérer nous-mêmes les permissions Lake Formation des rôles de projet sur les bases de données (particulièrement la base de publication).

Si vous disposez en production de multiples projets DataZone v1 utilisant ce blueprint avec deux bases de données et que vous souhaitez migrer vers SMUS, la meilleure marche à suivre est d'utiliser un blueprint personnalisé et de migrer/importer la base de publication. Vous pouvez alors recréer une base d'abonnement ou n'en garder qu'une seule. Depuis DataZone, rassemblez l'inventaire des abonnements existants, republiez massivement les données sur SMUS, puis rétablissez les abonnements. La seule perte sera la date de création originelle des abonnements.

Le passage de DataZone à SMUS offre d'énormes avantages en termes de stabilité. Avec l'arrivée de Lake Formation v5, nous pouvons espérer un système encore plus robuste. Au niveau de RAM (Resource Access Manager), LF v5 partage l'intégralité du catalogue Glue au lieu de cibler les bases de données individuellement, pour ensuite appliquer des filtres d'accès via des conditions. Cela rend le passage à l'échelle des abonnements en production beaucoup plus stable que sur DataZone, évitant les conditions de course (race conditions) et erreurs liées aux événements. Sur la v3, chaque opération de base de données nécessitait une invitation RAM ; sur la v5, une seule invitation est nécessaire au niveau du catalogue.

Bien que SMUS implique une plus grande responsabilité concernant les attributions de droits, une bonne compréhension de son fonctionnement (notamment de Lake Formation et d'AWS RAM) reste cruciale pour concevoir des architectures à grande échelle, sûres et faciles à maintenir.