EN
en direct

AWS Glue 6.0 baisse ses prix de 30 % et intègre l’intégralité d’Apache Iceberg v3

Le 21 août 2026, AWS lance Glue 6.0 avec 30 % de prix en moins et la spécification Apache Iceberg v3 complète sur Spark serverless, dont le type VARIANT avec shredding. Les équipes qui exploitent du semi-structuré ont une raison datée de planifier leur migration.

Un éclat de glace facetté posé sur une étagère métallique sombre, une seule arête éclairée d’ambre.

21 août 2026. AWS annonce la disponibilité générale de Glue 6.0. 30 % de prix en moins par rapport aux versions précédentes. Apache Spark 4.1, Python 3.12 et Scala 2.13 sous le capot. Et surtout, la spécification Iceberg v3 complète, construite sur Iceberg 1.11.0.

La version n’est pas une mise à jour de routine. Elle fait d’AWS Glue le service Spark serverless le plus complet sur Iceberg v3, au moment précis où le format de table ouvert achève sa standardisation. Pour une équipe data, la question n’est plus « faut-il adopter Iceberg ? » mais « quand basculer, et que gagne-t-on concrètement à la version 3 ? ».

Un prix en baisse, un runtime modernisé

La baisse de 30 % est le signal le plus simple à lire. AWS n’ajuste pas un tarif à la marge : il repositionne Glue face à une concurrence serverless — Databricks, BigQuery, et les moteurs maison — où le coût par job ETL est devenu un critère d’arbitrage. Une réduction sèche du prix unitaire se traduit directement sur la facture des pipelines récurrents, sans migration d’architecture.

Le runtime suit. Spark 4.1 remplace la génération précédente et apporte ses optimisations natives, tandis que Python 3.12 élimine la friction des versions dépassées. Ce n’est pas anecdotique pour un service managé : la combinaison d’un moteur récent et d’un prix en baisse change le calcul de tous les workloads qui n’avaient pas encore justifié un passage à la dernière génération.

Iceberg v3 complet : le type VARIANT change la donne

Le cœur de l’annonce tient en un mot : VARIANT. Glue 6.0 implémente le type VARIANT avec shredding, la fonctionnalité phare d’Iceberg v3 pour les données semi-structurées.

Concrètement : au lieu de stocker du JSON, des logs ou des événements dans une colonne string qu’il faut parser à chaque lecture, le shredding éclate les champs en colonnes internes dès l’écriture. Le résultat est une lecture nettement plus rapide, sans aplatissement manuel du schéma, sans copie de données dupliquées, et sans rupture de pipeline quand le schéma évolue.

C’est exactement le point de douleur des équipes qui ingèrent du semi-structuré à grande échelle : le schéma change en amont, le pipeline casse en aval, et on finit par écrire du code de parsing maison. VARIANT avec shredding supprime cette classe entière de maintenance.

Les autres ajouts Iceberg v3 complètent le tableau. Les types Geometry et Geography permettent du traitement spatial natif — SIG, intelligence géographique, pipelines géospatiaux — directement sur le Spark managé. Les horodatages à la nanoseconde couvrent les capteurs IoT, le calcul scientifique et la finance haute fréquence, au-delà de la précision milliseconde standard. Enfin, la gestion des types inconnus rend les pipelines résilients face aux schémas imprévus, au lieu d’échouer à la première évolution de source.

Un moteur qui simplifie l’écriture des pipelines

La deuxième moitié de la version porte sur la façon d’écrire les transformations.

Spark Declarative Pipelines change le modèle d’écriture : l’ingénieur déclare ce que la donnée doit devenir, et le moteur détermine lui-même l’ordre d’exécution et l’optimisation. C’est une réduction directe de la complexité d’orchestration et des erreurs de séquencement, le genre de dette qui s’accumule silencieusement dans les jobs PySpark vieillissants.

Les UDF et UDTF Python deviennent Arrow-native. L’exécution passe par le format colonnaire Arrow sans sérialisation aller-retour entre Python et la JVM, ce qui lève le goulot historique des fonctions Python dans Spark — souvent le poste le plus coûteux d’un pipeline réel.

Enfin, AWS annonce un streaming temps réel à latence de l’ordre de la milliseconde, un positionnement qui rapproche Glue des usages de traitement de flux jusqu’ici réservés à des moteurs dédiés.

Verdict

Si vous tournez déjà sur Glue, la migration vers 6.0 est la décision à plus faible risque de l’année : vous récupérez 30 % de baisse de prix et un runtime modernisé sans changer d’architecture, à condition de valider vos UDF et vos dépendances sur Python 3.12.

Si vous êtes en pleine décision lakehouse, la version 3 d’Iceberg — portée par le VARIANT avec shredding — est le moment de verrouiller votre choix de format. Les équipes qui ingèrent massivement du semi-structuré ont ici un argument mesurable, pas seulement une préférence de standard.

Si votre schéma bouge souvent en amont, le couple VARIANT + gestion des types inconnus cible précisément votre point de douleur. Planifiez un prototype sur un pipeline réel avant d’en faire une doctrine : la promesse de résilience se vérifie sur votre éventail de sources, pas sur un benchmark synthétique.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

AWS automatise la rotation du certificat racine d’EKS, avant l’expiration des clusters créés en 2018

Le 20 août 2026, Amazon EKS a annoncé la rotation automatisée de l’autorité de certification de chaque cluster, avec un cycle de vie géré et des garde-fous. Les clusters créés depuis 2018 arrivent au bout de la validité de dix ans de leur CA : la rotation est une responsabilité partagée, et la partie nœuds et clients externes reste à la charge de l’exploitant.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer