DynamoDB bulk put items charge une table vivante depuis S3 sans toucher à son débit

5 novembre 2026. AWS annonce la disponibilité générale de bulk put items pour Amazon DynamoDB. Un job managé. C’est ce que devient le chargement de données depuis S3 vers une table déjà en service. Aucun impact sur le débit. Les écritures passent par une capacité système dédiée, qui ne compte ni dans vos métriques CloudWatch ni dans vos règles d’auto scaling. Pourquoi c’est important : la plupart des équipes chargent encore leurs fichiers d’enrichissement via des pipelines maison — Glue, EMR, Lambda — qui entrent en concurrence avec le trafic applicatif sur la même table.

Ce que remplace bulk put items

DynamoDB tient sa réputation de sa latence à un chiffre en millisecondes, à n’importe quelle échelle. Cette même qualité rendait le chargement en masse historiquement délicat. Un import est une charge bursty, qui arrive par-dessus une table en train de servir du trafic réel. Jusqu’ici, la réponse standard était de bâtir un pipeline dédié — AWS Glue, Amazon EMR, ou une chaîne de Lambda — puis de surveiller la capacité de la table pour que les écritures de l’import n’étouffent pas celles de l’application.

Bulk put items supprime cette couche. Vous indiquez un emplacement S3 contenant des fichiers en JSON DynamoDB ligne à ligne ou en Amazon Ion, éventuellement compressés en gzip ou zstd. Le service lit les objets, valide chaque enregistrement, puis écrit les items en arrière-plan. Ce qui ne passe pas est consigné dans un rapport livré dans un bucket S3 de votre choix.

Deux détails changent la donne opérationnelle. D’abord, les écritures utilisent une capacité système dédiée : elles ne comptent pas dans vos métriques de lecture/écriture CloudWatch, donc vos alarmes et vos règles d’auto scaling continuent de fonctionner telles quelles. Ensuite, le chargement est multi-comptes : une équipe de données peut produire les fichiers et lancer l’import depuis un compte, pour écrire dans une table de production possédée par un autre.

Les conditions portées par l’enregistrement

C’est là que le code de pipeline maison avait tendance à s’empiler. Avec bulk put items, la gestion des conflits s’exprime dans les données elles-mêmes. Chaque ligne porte l’item et, en option, sa propre condition d’expression, avec la même grammaire que PutItem.

{"Item": {"Artist": {"S": "No One You Know"}, "SongTitle": {"S": "Call Me Today"}}}
{"Item": {"Artist": {"S": "Acme Band"}, "SongTitle": {"S": "Happy Day"}, "Origin": {"S": "import"}}, "ConditionExpression": "attribute_not_exists(Artist)"}
{"Item": {"Artist": {"S": "The Ternaries"}, "SongTitle": {"S": "Blue"}, "Version": {"N": "12"}}, "ConditionExpression": "#v < :v", "ExpressionAttributeNames": {"#v": "Version"}, "ExpressionAttributeValues": {":v": {"N": "12"}}}

Une condition attribute_not_exists(Artist) donne une écriture insert-only qui ne touche pas aux données existantes. Une condition qui compare un attribut de version n’écrit que si la copie entrante est plus récente que celle en table — de sorte qu’un fichier d’export ne puisse pas écraser les items que l’application a mis à jour entre-temps. Comme la condition voyage avec l’enregistrement, un seul fichier peut mélanger écritures inconditionnelles, insert-only et gardées par version. Un item écarté par sa condition n’est pas un échec : il compte dans le total traité et figure au rapport.

Standard ou Accelerated : choisir son palier

Chaque opération s’exécute sur l’un des deux paliers de performance, choisi au lancement.

• Standard — le palier le plus économique, adapté à l’essentiel des chargements : enrichissement périodique, peuplement d’arrière-plan, backfills récurrents. Son débit dépend du nombre d’items, de leur taille et du nombre d’index secondaires globaux à propager.
• Accelerated — vise un débit supérieur pour les travaux à échéance : migrations, scénarios de reprise avec RTO, chargements récurrents à fenêtre fixe. Le billet de la base de données cite un temps inférieur à une heure pour 100 millions d’items de 1 Ko.

Le coût est facturé selon le palier, et AWS insiste sur un point que les équipes doivent connaître avant de lancer : annuler une opération ne revient pas sur les items déjà écrits. Le chargement est idempotent par enregistrement — via les conditions — pas transactionnel dans son ensemble.

Ce que ça change pour les pipelines d’ingestion

Le cas d’usage type n’est pas une migration de zéro, mais un enrichissement continu. Des insights de machine learning, des mises à jour de catalogue produit, des backfills d’attributs : des données produites hors DynamoDB arrivent sous forme de fichiers dans S3 et doivent atterrir dans une table qui sert déjà du trafic.

Bulk put items ramène cette boucle à trois décisions : où sont les fichiers, quel palier, quelles conditions. Il ne remplace pas AWS Glue ou EMR pour la transformation — vous devez toujours produire des fichiers conformes — mais il remplace la partie orchestration d’écriture, qui était la plus fragile.

Le point de vigilance reste le même qu’avec tout chargement massif : le rapport de rejets. Les items rejetés par validation ou écartés par condition sont consignés, pas réécrits. Une équipe qui ne relit pas ce rapport croit avoir chargé un catalogue alors qu’une partie a été silencieusement ignorée.

Verdict

Si vous chargez régulièrement des fichiers S3 — enrichissements, catalogues, backfills — dans une table DynamoDB de production, basculez sur bulk put items et supprimez le pipeline d’écriture maison : le palier Standard suffit, et la capacité dédiée vous évite de recalibrer l’auto scaling à chaque import. Portez une condition attribute_not_exists ou une comparaison de version sur chaque enregistrement pour rendre le chargement idempotent, et branchez une alerte sur le rapport de rejets. Réservez le palier Accelerated aux migrations et aux fenêtres à RTO, où l’heure de complétion vaut le surcoût — et gardez en tête que l’annulation ne rembobine pas les écritures déjà passées.

Références

• AWS Database Blog — « Introducing bulk put items for Amazon DynamoDB: Load data from Amazon S3 into existing tables at scale » (Lee Hannigan et Anugrah Prakash, 5 novembre 2026)
• AWS News Blog — « AWS Weekly Roundup: AgentCore Runtime V2, Amazon DynamoDB bulk put items, and more » (Daniel Abib, 9 novembre 2026)
• ETTAYEB — notre analyse de la migration Hive vers Iceberg dans S3 Tables