Lake Formation Can Now Govern Writes in AWS Glue 5.1: A Fine-Grained Access Migration Guide

Introduction

Imaginez un job Spark de production qui lit sans difficulté des tables gouvernées par AWS Lake Formation, mais qui échoue, ou bascule discrètement vers un rôle IAM plus permissif, lorsqu’on lui demande d’exécuter un MERGE ou un UPDATE. Un tel incident compromet l’intégrité des données : certaines écritures deviennent invisibles pour des lecteurs autorisés, tandis que d’autres s’exécutent en mode « full access ». Une écriture gouvernée par Lake Formation dépend simultanément du runtime Spark et de ses connecteurs, du catalogue et de ses autorisations, du stockage Amazon S3 et des clés AWS KMS, ainsi que du mécanisme de commit transactionnel. Selon l’annonce AWS du 28 avril 2026 sur la disponibilité de Glue 5.1, la version introduit Spark 3.5.6, Iceberg v3 et le contrôle d’accès fin aux opérations d’écriture DML et DDL. Une incohérence documentaire subsiste toutefois : cette annonce présente les écritures FGAC comme prises en charge, tandis que la page AWS consacrée aux considérations relatives au contrôle fin indique encore que les écritures avec des autorisations accordées par Lake Formation ne sont pas prises en charge. Ce guide explique comment inventorier les jobs et autorisations, choisir entre FGAC et Full-Table Access, qualifier le runtime et S3A, puis valider et surveiller les écritures avant toute promotion en production.

1. Glue 5.1 Change le Runtime et le Chemin d’Autorisation

Glue 5.1 modifie à la fois le moteur Spark et le chemin d’autorisation. Les notes de version AWS Glue indiquent Spark 3.5.6, Python 3.11, Java 17, Hudi 1.0.2, Iceberg 1.10.0 et Delta Lake 3.3.2. Elles indiquent également que Glue 5.1 devient la version par défaut des jobs créés sans version explicite, ce qui augmente le risque d’adoption involontaire. Iceberg peut utiliser le format v3, avec notamment des valeurs par défaut et des vecteurs de suppression. Côté sécurité, Glue 5.1 étend le contrôle d’accès fin aux opérations DML et DDL, alors que Glue 5.0 se limitait à la lecture. Le guide AWS de migration vers Glue 5.1 précise aussi que le connecteur S3A remplace EMRFS et que le paramètre spark.hadoop.fs.s3a.endpoint.region doit être validé. Pour Hudi et Delta Lake, l’écriture relève du mode Full-Table Access, distinct du FGAC. Le tableau suivant résume les changements à qualifier :

Ces évolutions peuvent casser des jobs existants: un script qui écrivait via IAM pourrait échouer si FGAC devient actif. De même, sans vigilance Glue 5.1 pourrait rediriger un job vers un rôle IAM plus permissif (même si Lake Formation est configuré). D’où l’importance de tester chaque combinaison runtime et format (p. ex. Iceberg vs Hudi) avant de passer en production.

2. Inventorier les Jobs, Tables, Principaux Acteurs et Chemins d’Écriture Actuels

Avant toute modification, commencez par un inventaire exhaustif des jobs Glue et des données concernées. L’objectif est de cartographier chaque job ETL, sa version Glue, son rôle IAM, la base de données et la table qu’il lit ou écrit, le format et la version du format de table, ainsi que le préfixe S3 utilisé et les dépendances en aval. Un extrait d’exemple (simplifié):

Chaque ligne du tableau illustre un flux de données: notez la version Glue du job, le rôle exécutant (et ses droits IAM actuels), la table cible, le format de stockage et le type d’opération (lecture/écriture). Dans la colonne Lake Formation?, indiquez si la table est déjà sous contrôle LF (par exemple avec location enregistrée) ou pas. Cet inventaire permet de détecter les cas mixtes: par exemple, un job qui utilise LF pour la lecture mais IAM pour l’écriture, ce qui crée des écarts de sécurité.

Classifier les Formats de Table et Opérations d’Écriture

Les formats de table dictent les capacités d’écriture gouvernée. Les tables Apache Iceberg, ainsi que les tables Hive/Parquet compatibles, utilisent le FGAC pour les opérations DML et DDL avec Glue 5.1. Pour Hudi et Delta Lake, la documentation AWS sur le Full-Table Access décrit un modèle d’accès à la table entière, sans filtrage fin. Pour chaque format, vérifiez les points suivants :

• Iceberg v3 (Glue 5.1) : permet les opérations MERGE, UPDATE et DELETE via FGAC. Par exemple, une requête MERGE sur analytics.sales exigera une permission INSERT pour les nouvelles lignes et DELETE pour les lignes modifiées. Pour le contexte fonctionnel du format, consultez l’analyse de la consolidation d’Apache Iceberg comme format de table ouvert.

• Apache Hudi : sous Glue 5.1, utilisez le mode Full-Table Access avec les configurations Hudi appropriées. Le rôle doit disposer des privilèges Lake Formation requis sur la table. Certains modes avancés, notamment Merge-on-Read (MOR) et le clustering, imposent des configurations spécifiques et peuvent restreindre les chemins pris en charge.

• Delta Lake: même principe que Hudi: seules les permissions globales (par ex. ALL) s’appliquent en écriture. Assurez-vous que le rôle Glue possède les autorisations nécessaires pour le catalogue et S3; en mode FTA, la granularité LF n’est pas utilisée.

Cartographier IAM, Lake Formation, Catalogue et Permissions S3

Pour chaque job et table, recensez:

• Rôles IAM et politiques: actions glue:*, s3:PutObject/Delete, etc., attachées au rôle du job.

• Permissions Lake Formation: grants actuels sur bases de données et tables (utilisez list-permissions ou la console LF). Par exemple, identifiez si IAMAllowedPrincipals détient encore Super sur vos objets.

• Locations S3 enregistrées en LF: si un emplacement de données est enregistré dans Lake Formation, le rôle Glue n’accède aux données qu’avec les identifiants stockés par LF. Testez qu’un rôle non inscrit n’arrive pas à lire même s’il a les droits IAM S3 classiques.

• Resource links inter-comptes: vérifiez que les tables partagées ont des liens de ressources (Resource Links) configurés correctement. Chaque lien doit porter le même nom que la table source, sans quoi les requêtes intercompte échoueront.

• Clés KMS et politique de bucket : recensez les clés de chiffrement utilisées. Le rôle Glue et, selon le chemin d’accès, le rôle d’enregistrement des emplacements Lake Formation doivent disposer des autorisations Encrypt et Decrypt nécessaires. La politique du bucket doit également autoriser les principaux concernés à accéder aux objets. Validez la configuration avec un test S3.

Ce travail d’inventaire engage à la fois l’équipe données (choix des modèles et owners des tables) et l’équipe plateforme (gestion des rôles IAM). L’objectif est d’aboutir à un tableau complet “qui peut lire/écrire quoi, comment” avant de modifier les autorisations.

3. Choisir Fine-Grained Access ou Full-Table Access Délibérément

Lake Formation offre deux modes distincts pour gouverner les écritures : le contrôle d’accès fin (FGAC) et le Full-Table Access (FTA). La documentation AWS sur le Full-Table Access confirme qu’il s’agit d’une architecture et d’un modèle de permissions distincts. Il faut donc choisir l’un ou l’autre pour chaque job :

En pratique, choisissez FGAC si vous avez besoin de filtrer des lignes/colonnes et que vous travaillez sur des formats supportés (par ex. Iceberg). Choisissez FTA pour les tables Hudi/Delta (où FGAC n’existe pas) ou lorsque vous préférez un modèle IAM plus lâche. Ne tentez pas de mixer FGAC et FTA dans un même job: scindez vos jobs par type de gouvernance pour éviter les conflits de mode.

4. Définir la Frontière de la Migration en Mode Hybride

AWS présente le mode hybride comme un chemin de transition dans le guide AWS de mise à niveau des autorisations du Data Catalog : IAM et Lake Formation coexistent temporairement. Cette coexistence doit être strictement encadrée :

• Opt-in progressif: sélectionnez un sous-ensemble de tables et de rôles pour démarrer. Par exemple, activez Lake Formation sur des tables non sensibles et accordez uniquement aux rôles désignés les permissions LF nécessaires, tout en conservant les droits IAM pour d’autres tables.

• Coexistence explicite: documentez les cas où un rôle a à la fois des permissions IAM (ex. accès S3) et des grants LF sur une même ressource. Par exemple, notez « Rôle X: IAM glue:*, plus LF SELECT, INSERT sur la table Y ». Cela évite les zones d’ombre.

• Critères d’arrêt du mode hybride: définissez d’avance les conditions pour supprimer les accès IAM classiques. Par exemple, une fois que tous les jobs critiques ont été validés en FGAC, retirez le groupe IAMAllowedPrincipals (et donc le privilège Super IAM) sur ces tables.

• Responsabilités claires: attribuez la gestion des anciens et nouveaux accès. Typiquement, l’équipe données gère les GRANT Lake Formation et l’équipe infra gère les politiques IAM de base. Prévoyez une revue croisée (une double validation) pour chaque déploiement LF.

• Mesures compensatoires: en attendant la fin de la migration, activez des alertes ou un audit additionnel. Par exemple, configurez CloudWatch pour avertir en cas de multiplication d’erreurs d’accès IAM sur des tables censées être sous LF.

Ce mode hybride doit rester temporaire: inscrivez ces étapes dans votre document de conception et planifiez la date limite pour éliminer totalement les accès IAM anciens. Le plan d’adoption doit préciser qui « fait quoi et quand » pour chaque rôle et table.

5. Qualifier le Runtime Glue 5.1 Avant de Changer les Permissions

Avant de modifier les autorisations, vérifiez que vos traitements tournent correctement sur Glue 5.1:

• Dépendances et bibliothèques : exécutez vos scripts Spark et ETL sur Glue 5.1, puis vérifiez toutes les bibliothèques utilisées, notamment boto3, pandas et les pilotes additionnels. Glue 5.1 utilise boto3 1.40.61. Testez votre code et vos fonctions définies par l’utilisateur (UDF), y compris les UDF Hive. La documentation AWS sur l’activation des permissions Lake Formation pour Glue précise aussi les exigences d’architecture FGAC, dont l’usage des DataFrames.

• Configuration Spark: comparez les paramètres (mémoire, partitions, shuffle). Vérifiez les jobs bookmarks sur de grands datasets. Toute différence (ex. modification de spark.sql.sources.useV1SourceList) doit être adaptée. Utilisez un job de référence pour valider la parité fonctionnelle.

• Connecteurs externes: relancez les jobs qui accèdent à des sources externes (bases JDBC, S3, etc.). Vérifiez que les pilotes (JDBC, ODBC) et plugins Spark sont compatibles. Par exemple, un ancien driver MySQL peut ne pas fonctionner en Spark 3.5.

• Résultats : exécutez chaque job sur un jeu de test et comparez les données de sortie, les fichiers produits et les tables cibles. L’objectif est d’obtenir le même résultat fonctionnel qu’avant, hors écarts de performance attendus. Ce contrôle empêche qu’un changement de runtime crée une divergence de données.

• Performances : mesurez les durées d’exécution et l’utilisation des ressources. Les jobs FGAC nécessitent davantage de capacité, avec un minimum documenté de quatre workers dans le chemin décrit par AWS. Surveillez les temps de traitement et les coûts, puis ajustez la configuration si nécessaire.

• Pratiques CI/CD : automatisez ces tests dans votre pipeline de déploiement, en vous appuyant sur les outils et pratiques du data engineering adaptés à votre environnement. Validez Glue 5.1 en développement avant toute promotion en production.

L’idée est de vérifier la parité runtime avant de toucher aux permissions de sécurité. Si un job se casse en 5.1 pour une raison non liée à Lake Formation, corrigez ce point d’abord.

6. Tester S3A, Dépendances, Réseau et Points de Terminaison Régionaux

La migration vers S3A dans Glue 5.1 peut engendrer des effets réseaux à tester:

• Région par défaut de S3A : en l’absence de configuration, S3A utilise la région us-east-2 par défaut, ce qui peut ajouter de la latence pour les buckets hébergés ailleurs. Définissez spark.hadoop.fs.s3a.endpoint.region=REGION_CIBLE, puis testez la lecture et l’écriture dans chaque bucket principal.

• VPC et PrivateLink: pour les jobs en VPC, vérifiez que les endpoints VPC pour S3 sont compatibles avec S3A. Par exemple, effectuez une lecture depuis un bucket privé via l’endpoint VPC. Corrigez toute erreur de résolution DNS ou de route.

• Accès interrégions/intercomptes: exécutez un job Glue dans une région/compte accédant à un bucket dans une autre région/compte. Vérifiez que les rôles IAM ont les droits adéquats (s3:GetObject, kms:Decrypt sur la clé du bucket). Testez aussi l’accélération S3 si utilisée.

• Latence et timeouts: simulez une surcharge réseau (désactiver l’endpoint VPC) pour voir le message d’erreur produit. Ajustez les délais (spark.network.timeout, etc.) si besoin.

• Intégrité du chiffrement: si vos données sont chiffrées, garantissez que le rôle Glue dispose bien de kms:Decrypt/Encrypt pour toutes les clés liées aux tables. Par exemple, si Iceberg utilise une clé gérée par Lake Formation, testez que les métadonnées peuvent être lues.

• Logs d’erreur S3: exécutez un job avec une mauvaise configuration S3 pour observer le message d’échec (ex. Access Denied ou timeout). Cette étape vous permettra de mieux interpréter ensuite les erreurs lors des tests LF.

Documentez chaque test et sa conclusion. Ainsi, vous vous assurez que les changements liés à S3A ne masqueront pas des problèmes de permissions lors de la migration.

7. Accorder et Valider les Permissions d’Écriture DML

Passez à la configuration des autorisations Lake Formation et validez chaque opération d’écriture:

• INSERT : accordez au rôle Glue la permission Lake Formation INSERT, ainsi que SELECT sur les colonnes nécessaires. Exécutez un job Spark avec INSERT INTO table_cible. Vérifiez que les données apparaissent dans S3 et que le job se termine sans erreur. Sans INSERT, le job doit échouer avec une erreur AccessDenied.

• DELETE : accordez la permission DELETE sur la table et testez DELETE FROM table_cible WHERE condition. Confirmez que seules les lignes correspondant au prédicat sont supprimées.

• UPDATE/MERGE : testez une commande MERGE qui combine insertions et suppressions. Le rôle doit disposer d’INSERT, de DELETE et de SELECT sur les colonnes utilisées. Exécutez, par exemple, MERGE INTO table_cible USING mises_a_jour. Si DELETE manque, la requête doit échouer, ce qui valide le contrôle Lake Formation.

• Scénarios négatifs: délibérément, exécutez une opération d’écriture avec un rôle non autorisé (par ex. un simple INSERT avec un rôle ne possédant que SELECT). Le job doit produire un message d’erreur clair mentionnant le refus Lake Formation.

• Vérification d’intégrité: après chaque écriture réussie, contrôlez les métadonnées: Iceberg crée un nouveau snapshot dans S3, Delta/Hudi génèrent un nouveau log. Vérifiez que les fichiers attendus (_metadata, delta.log, etc.) sont bien écrits.

• Logs d’audit : consultez CloudTrail et les logs Glue pour les événements Lake Formation. Un INSERT réussi peut, selon le chemin utilisé, produire un événement lié à la mise à jour des objets de table. Conservez cet événement avec l’identifiant d’exécution du job afin de prouver le commit gouverné.

N’oubliez pas que l’accès physique S3 sous-jacent utilise les droits IAM du rôle Glue. Par conséquent, le rôle doit aussi avoir les permissions S3 (Put/Delete) sur le bucket/table pour que le travail de commit puisse s’exécuter physiquement. Toute erreur S3 (via IAM) doit être distinguée des erreurs LF.

8. Accorder et Valider les Permissions DDL

Les modifications de schéma (DDL) requièrent des grants spécifiques:

• CREATE TABLE: accordez CREATE_TABLE sur la base de données concernée à votre rôle (ou ALL sur le catalogue). Testez CREATE TABLE dbX.new_table (...). En cas de succès, la table apparaît dans Glue Data Catalog et un dossier de métadonnées est créé dans S3.

• ALTER TABLE / DROP TABLE : accordez ALTER pour les modifications de structure et DROP pour la suppression. Exécutez ALTER TABLE table_cible ADD COLUMN ... ou DROP TABLE table_cible. Vérifiez que seuls les principaux autorisés peuvent le faire. Sans ALTER, le job doit échouer avec une erreur de permission.

• Propriété d’objet : dans Lake Formation, le créateur d’un objet peut recevoir automatiquement des droits étendus selon les options d’octroi. Vérifiez ce comportement afin qu’un principal non prévu ne puisse pas créer, modifier ou supprimer des tables sans contrôle.

• Audit: chaque DDL est tracé dans CloudTrail. Par exemple, un CREATE TABLE entraîne un événement LakeFormation CreateTable dans les logs, et un DROP TABLE un événement LakeFormation DropTable. Ces traces confirment l’identité de la personne/rôle ayant effectué l’opération.

• Validation de fin à fin: testez un flux complet de DDL. Par exemple, un job Glue peut créer une table, écrire dedans puis supprimer la table. Vérifiez les états intermédiaires dans Glue et S3 à chaque étape.

Notez que les API Glue (glue:CreateTable, glue:UpdateTable, etc.) doivent aussi être autorisées pour le rôle Glue. Mais c’est la vérification Lake Formation qui prévaut à l’exécution du Spark SQL. Assurez-vous donc que vos grants couvrent tous les objets du schéma concerné (tables et bases).

9. Protéger les Frontières du Catalogue, du Stockage et des Liens de Ressources

Pendant la migration, il est crucial de vérifier l’intégrité des frontières d’accès:

• Partages intercomptes: pour les tables partagées entre comptes, utilisez AWS RAM et des resource links. Chaque lien doit porter le même nom que la table source. Testez qu’un rôle d’un autre compte peut accéder via ce lien aux mêmes données (vérifiez les droits Lake Formation correspondants dans chaque compte).

• Emplacements S3 enregistrés dans Lake Formation : lorsqu’un bucket ou un préfixe est enregistré, l’accès emprunte les identifiants gérés pour cet emplacement, même si un rôle dispose de droits S3 classiques. Si datalake/processed/ est enregistré, testez qu’un job doté du bon chemin Lake Formation peut écrire et qu’un autre rôle, autorisé uniquement par IAM, reste bloqué.

• Politique de bucket et clés KMS: assurez-vous que la stratégie du bucket S3 autorise bien les opérations pour les rôles concernés. Si le bucket est chiffré, le rôle Glue doit avoir les permissions kms:Decrypt/Encrypt. Testez un accès avec et sans ces permissions pour valider vos configurations.

• Droits croisés : si un rôle doit accéder à la fois à une base Glue et au stockage S3 gouverné, vérifiez que les permissions sont complètes dans les deux systèmes. Par exemple, un rôle d’analyste en lecture doit disposer de DESCRIBE et SELECT sur la table, ainsi que de l’accès requis à l’emplacement de données.

• Zéro contournement : confirmez qu’aucun principal ne contourne Lake Formation par un chemin S3 direct. Après la migration, les nouvelles données doivent être écrites par les mécanismes Glue et Lake Formation prévus, et non par des appels S3 PutObject directs non gouvernés.

Créez, par exemple, une matrice récapitulative ou un schéma de réseau listant pour chaque ressource de données qui a accès et comment (IAM vs LF). Cela aidera à ne laisser aucun « trou » entre comptes ou services, et à préparer les audits futurs.

10. Valider la Concurrence, les Transactions et la Reprise sur Échec

Testez le comportement du système en conditions de charge ou de panne:

• Écritures concurrentes: lancez deux jobs Glue simultanés sur la même table. Par exemple, deux jobs MERGE dans sales. Avec Iceberg, l’un des commits devrait l’emporter (l’autre abandonne ou génère un conflit), tandis que Delta fusionne les changements dans le journal. Notez le résultat exact (tuples finaux, erreurs affichées).

• Reprises partielles: simulez un crash (kill) d’un job en plein commit. Après redémarrage du job, vérifiez qu’il n’y a pas de doublons et qu’un nouveau snapshot ou log intègre toutes les opérations sans corruption.

• Fichiers orphelins: après un échec forcé, scrutez le bucket S3. Idéalement, aucun fichier de données partiellement écrit ne doit rester. Si des artefacts persistent, ajoutez une étape de nettoyage dans le runbook pour les supprimer (par ex. fichiers temporaires _SUCCESS,.crc, etc.).

• Verrous et conflits : pour Hudi en mode Merge-on-Read (MOR), lancez deux jobs d’écriture concurrents et vérifiez que la table de verrouillage DynamoDB, ou le mécanisme de verrouillage configuré, garantit l’exclusivité attendue. Pour Iceberg, vérifiez qu’un conflit transactionnel provoque un échec contrôlé ou un rollback, jamais une corruption.

• Idempotence: relancez un job de traitement sur le même dataset plusieurs fois. Le résultat final ne doit pas contenir de duplication anormale. Iceberg réécrit les snapshots, Delta/Hudi créent de nouvelles versions; validez que le comportement correspond aux attentes métiers.

• Critères de succès : fixez des seuils, par exemple « 0 erreur sur 100 insertions concurrentes » ou « 100 % de reprise réussie lors de la seconde exécution ». Tout dépassement constitue un point bloquant.

Ces tests garantissent que la couche transactionnelle de votre table (snapshot Iceberg, timeline Hudi, log Delta) fonctionne sous charge. Documentez les cas de défaillance et la stratégie de reprise (rollback), pour pouvoir intervenir rapidement en cas d’incident réel.

11. Surveiller les Échecs d’Autorisation, Spark et de Commit

Mettez en place une observabilité pour détecter tout problème de permission ou d’exécution:

• Logs CloudWatch / Spark: configurez des alertes sur les erreurs métier dans les logs Glue. Par exemple, surveillez les AccessDeniedException, LakeFormationAccessDeniedException ou autres erreurs Spark liées aux permissions. Consultez également les métriques Glue (durée, erreurs) pour détecter les anomalies.

• CloudTrail / Lake Formation : activez la journalisation des opérations Lake Formation. Les changements de permissions et les refus d’accès apparaissent dans CloudTrail. Créez un tableau de bord qui corrèle les événements liés aux objets de table et les refus d’accès aux noms de tables, aux rôles et aux responsables des flux.

• Alertes et runbook : catégorisez les erreurs critiques. Trois échecs successifs avec AccessDenied déclenchent un incident de permission confié à l’équipe données. Une erreur Spark de mémoire insuffisante déclenche un ajustement de capacité confié à l’équipe plateforme. Le runbook doit nommer le responsable de chaque catégorie.

• Corrélation de contextes: dans tous vos logs et alertes, incluez des tags pertinents (GlueJobName, TableName, LakeFormationResource). Ainsi, si un événement CloudTrail indique un DENY sur la table X, vous pouvez retrouver le job ou la demande d’accès incriminé en regardant les logs Glue du même job.

• Prévention: surveillez aussi l’évolution du modèle de permissions. Par exemple, mesurez le nombre de requêtes LF par table ou par principal via CloudWatch Metrics. Si un job change de comportement (augmentation d’erreurs), votre dashboard en sera informé.

Cette approche s’appuie sur une pile de logs Kafka et Spark, ainsi que sur l’orchestration Airflow, comme l’explique le guide consacré à l’outillage Kafka, Spark et Airflow. La surveillance croisée des logs Glue, des métriques Spark et des événements Lake Formation permet de détecter rapidement une défaillance de gouvernance ou de runtime.

12. Déployer sur des Versions et Formats Mixtes

Pendant la migration, vous aurez des environnements mixtes et devez adopter une approche progressive:

• Pilote (dev): migrez d’abord un petit nombre de jobs non critiques (par ex. un job ETL Iceberg en FGAC) sur Glue 5.1. Vérifiez toutes les opérations DML/DDL et les accès S3 associés. C’est le moment de peaufiner le processus de test complet.

• Anneau progressif (test/staging): étendez aux tables moins sensibles et à différents formats (ajoutez Hudi, Delta). Pendant cette phase hybride, certains jobs tournent encore en Glue 4/5.0 (IAM) et d’autres en 5.1 (LF). Assurez-vous de bien paramétrer la version Glue et le flag FGAC dans vos orchestrations.

• Staging avancé: migrez une fraction de la production (par exemple des partitions anciennes, ou un segment de charge modéré) avec le trafic réel. Testez la charge à 100 % sur ces tables et surveillez la consommation de ressources, puis passez progressivement aux données en aval (Data Warehouse, BI).

• Production finale: une fois la stabilité prouvée, basculez l’ensemble. Avant chaque « go live », définissez des gates de promotion (tests unitaires passés, revues de sécurité, etc.). Utilisez par exemple des tags Glue pour baliser les jobs migrés (ex. --GlueVersion 5.1, --enable-lakeformation-fine-grained-access=true).

Concrètement, planifiez vos migrations en anneaux comme dans l’exemple suivant:

Préparez également les rollbacks, par exemple avec des scripts capables de restaurer un snapshot Iceberg antérieur ou de rétablir temporairement le chemin IAM approuvé. Cette migration progressive reprend les principes du data engineering cloud native : chaque itération est validée avant l’élargissement du déploiement.

13. Exemple : Migration d’une Écriture Iceberg Gouvernée

Prenons un exemple concret sur une table Iceberg v3: analytics.sales. On souhaite passer un job de fusion (MERGE) sous FGAC.

1. Contexte : supposons que le rôle SalesBatchRole dispose des autorisations INSERT et DELETE sur analytics.sales, ainsi que de SELECT sur les colonnes nécessaires, et que la table est enregistrée dans Lake Formation. Le script Spark exécute un MERGE entre analytics.sales et un DataFrame updates.

2. Test de permission manquante: retirez la permission SELECT sur la colonne region, puis exécutez le job. Le MERGE échoue avec AccessDenied, indiquant que region n’est pas accessible. Ceci montre que FGAC bloque correctement l’écriture partielle.

3. Correction des droits: réaccordez SELECT(region) au rôle. Relancez le MERGE: cette fois, il réussit. Un nouveau snapshot est créé dans S3 (_metadata/00002.metadata.json). Les logs Glue CloudWatch montrent l’achèvement sans erreur.

4. Lecture intercompte: créez dans le compte B un resource-link sales pointant vers analytics.sales. Accordez SELECT à un rôle analyste. L’analyste exécute SELECT COUNT(*) FROM shared_db.sales et récupère les nouvelles données. Dans CloudTrail, on observe l’événement LakeFormation GetTableObjects sur analytics.sales initié par le rôle du compte B.

5. Résolution après échec: simulez un kill du job juste après avoir écrit des fichiers temporaires. Relancez le même job (idempotence). Vérifiez qu’aucune donnée n’est dupliquée et qu’un seul snapshot final (00003) existe. Aucun fichier orphelin ne reste dans le dossier S3.

6. Éléments de preuve : vérifiez dans CloudTrail chaque étape, du refus initial à l’octroi des droits, puis à l’événement de mise à jour des objets de table. Cette traçabilité montre que la couche Lake Formation a filtré ou autorisé les opérations.

Cet exemple souligne l’importance des tests pas à pas. Chaque permission Lake Formation doit être validée en lançant un vrai job et son absence doit provoquer un échec clair. En particulier, on ne déploiera pas un MERGE en production sans être certain que toutes les permissions nécessaires (INSERT/DELETE/SELECT) sont accordées à l’avance.

14. Exécuter le Plan d’Adoption sur 90 Jours

Pour déployer à grande échelle, structurez un plan d’environ trois mois avec des jalons concrets :

• Jours 1–14 : inventaire et planification. Finalisez l’inventaire des jobs et tables, puis définissez les groupes pilotes décrits à la section 2. Préparez l’environnement de test Glue 5.1 et formez les équipes aux changements de Spark.

• Jours 15–28 : pilote technique. Migrez les premiers jobs, par exemple un flux Iceberg, en mode hybride. Vérifiez chaque opération de bout en bout dans l’environnement de développement et documentez les écritures, lectures et journaux.

• Jours 29–56 : staging élargi. Ajoutez davantage de jobs et de formats, notamment Hudi et Delta Lake, en mode hybride. Basculez une partie des charges de production, surveillez les logs et retirez les permissions IAM devenues obsolètes.

• Jours 57–84 : production restreinte. Migrez des workflows de complexité moyenne. Validez la concurrence, la charge et les accords de niveau de service sur plusieurs exécutions, puis préparez la bascule et le plan de rollback.

• Jours 85–90 : bascule finale. Activez FGAC ou FTA sur les jobs restants et organisez un contrôle go/no-go avant chaque lancement. À J+90, tous les jobs migrés utilisent Glue 5.1 avec les permissions Lake Formation prévues, et les anciens accès IAM ont été retirés des ressources concernées.

En pratique, rien ne remplace la rigueur : nommez un responsable pour chaque étape, qu’il s’agisse du propriétaire des données, de l’équipe DevOps ou de la sécurité, et fixez des critères d’acceptation explicites. Ces tâches mobilisent des compétences en pipelines, transformations Spark et sécurité, présentées dans l’article sur les tendances et compétences du data engineering.

Conclusion : les trois premières actions concrètes sont de réaliser l’inventaire complet des jobs et permissions, de préparer un job pilote sous Glue 5.1 en mode FGAC ou FTA, puis de valider dans un compte non productif l’ensemble du parcours runtime, S3A, DML et DDL pour chaque table cible. Le point d’attention principal reste la combinaison exacte du runtime et du format : l’annonce AWS présente le FGAC en écriture comme pris en charge, tandis qu’une page Glue contient encore une formulation contraire. Un simple octroi Lake Formation ne garantit donc pas à lui seul une écriture gouvernée de bout en bout : les permissions, le job Spark, le catalogue, le stockage et la structure de la table doivent rester cohérents.

Pour approfondir ces compétences, le Programme Data Engineering de Refonte Learning propose un cursus de trois mois, à raison de 12 à 14 heures par semaine, consacré notamment aux systèmes big data, aux pipelines, à la gouvernance et à la sécurité. La page du programme présente Matthias Schmidt comme mentor avec 16 ans d’expérience en data engineering. Cette base peut compléter les compétences clés des data engineers nécessaires pour aborder ce type de migration.