AWS rend l’écriture en masse DynamoDB disponible : des fichiers S3 chargés dans des tables existantes sur capacité séparée dès 0,10 dollar le Go en USA Est, mais les enregistrements sans condition écrasent, les consommateurs de flux voient les écritures et les tables globales ne sont pas prises en charge

Le 5 novembre 2026, AWS a annoncé la disponibilité générale de l’écriture en masse d’éléments (bulk put items) pour Amazon DynamoDB. C’est une fonction gérée qui écrit des données d’Amazon S3 dans une table existante. Auparavant, charger dans une table en service des fichiers produits par d’autres systèmes demandait en général un pipeline sur mesure, une tâche AWS Glue ou Amazon EMR et une gestion soigneuse de la capacité de la table. Avec bulk put items, on indique à DynamoDB l’emplacement S3 des fichiers d’entrée, on désigne un emplacement de sortie pour un rapport et on choisit un niveau. L’annonce dit que les écritures n’affectent pas la charge de travail existante, et le billet de lancement ainsi que le guide du développeur précisent qu’elles utilisent une capacité séparée et ne consomment aucune capacité de lecture ou d’écriture de la table.

Les fichiers d’entrée sont du JSON DynamoDB délimité par ligne ou de l’Amazon Ion, éventuellement compressés en gzip ou zstd. Chaque enregistrement peut porter sa propre expression de condition, de même syntaxe que PutItem. Une condition comme attribute_not_exists sur la clé de partition donne des écritures en insertion seule, et une comparaison sur un attribut de version n’écrit l’élément que si la copie entrante est plus récente. Un même fichier peut mêler enregistrements inconditionnels, en insertion seule et protégés par version. Deux détails méritent l’attention. Un enregistrement sans condition est écrit sans condition et écrase tout élément existant ayant la même clé. Et si tous les éléments doivent respecter la même condition, elle doit être répétée sur chaque enregistrement des fichiers. Un élément ignoré à cause de sa condition n’est pas un échec : il compte comme traité et apparaît dans le rapport si l’on demande les échecs de vérification de condition.

L’opération est asynchrone. L’appel de démarrage renvoie l’ARN de l’opération et porte un jeton client pour qu’un démarrage répété ne lance pas un doublon ; les premières minutes servent à la préparation, de sorte que les compteurs peuvent afficher zéro au début. L’identité qui la lance a besoin d’autorisations au niveau du compte et de la table, d’un accès en lecture au compartiment d’entrée, d’un accès en écriture au compartiment du rapport et des clés AWS KMS concernées. Une opération se termine par COMPLETED, COMPLETED_WITH_ERRORS, FAILED ou CANCELLED. L’annulation n’annule pas les éléments déjà écrits : une importation annulée laisse donc la table partiellement mise à jour. Le rapport liste les enregistrements non écrits avec l’objet source, la position dans cet objet et la raison ; pour une condition non satisfaite, il montre le nouvel élément et l’élément existant. Le billet conseille de traiter COMPLETED_WITH_ERRORS comme un cas normal, de corriger les enregistrements en erreur et de ne réimporter que ceux-ci.

Il y a deux niveaux. Standard est le niveau par défaut et le moins cher, prévu pour les travaux à calendrier souple comme l’enrichissement périodique et les remplissages. Accelerated vise un débit plus élevé pour les travaux à échéance comme les migrations et la reprise. Pour une table bien dimensionnée, un espace de clés de partition à forte cardinalité réparti uniformément, des entrées divisées en plusieurs objets S3 de taille similaire et aucune réplication vers des index secondaires globaux, AWS donne des estimations pour Accelerated : moins de 10 minutes pour 10 millions d’éléments de 1 Ko, moins d’une heure pour 100 millions et 2 à 4 heures pour un milliard. AWS les qualifie de points de départ illustratifs. Il prévient aussi que les premières exécutions peuvent dépasser la mise à l’échelle de la table et que les durées ne se stabilisent qu’après trois à cinq exécutions d’un fichier de même forme.

La facturation se fait à l’octet. Dans la région USA Est (Virginie du Nord), le billet indique 0,10 dollar par Go pour Standard et 0,20 dollar par Go pour Accelerated, avec un minimum de 1 Ko par élément, appliqué séparément à la table et à chaque index. Une vérification de condition échouée est facturée, pas les éléments rejetés par la validation. Le même billet donne un exemple de 100 millions d’éléments de 1 Ko à 10,00 dollars en Standard et 20,00 dollars en Accelerated. Nous ne reprenons ces chiffres que pour cette région ; l’annonce renvoie aux pages de tarifs pour les autres.

Les limites sont précises. Une seule opération de bulk put items peut s’exécuter par table à la fois, et pas pendant la création d’un index. Chaque compte peut avoir jusqu’à cinq opérations Standard et cinq Accelerated en cours. Une opération peut couvrir jusqu’à 100 Go en Standard et 1 To en Accelerated, et la table cible doit être active. Les tables globales ne sont pas prises en charge au lancement, et l’on ne peut pas ajouter de réplique pendant qu’une opération s’exécute. Pour les tables avec un index vectoriel, seul Standard est pris en charge. La fonction écrit des éléments entiers et ne met pas à jour d’attributs isolés ; UpdateItem reste l’outil pour cela. Standard est disponible dans toutes les régions commerciales et dans les régions AWS GovCloud (US), tandis qu’Accelerated l’est seulement dans les régions listées sur une page distincte : la disponibilité de Standard ne se lit donc pas comme celle d’Accelerated.

Notre lecture : l’absence d’impact est vraie pour la capacité de la table et pour les métriques de lecture et d’écriture de l’application, mais le billet lui-même cite d’autres effets. Les éléments importés apparaissent dans DynamoDB Streams et Kinesis comme des écritures d’application ; une grosse importation peut donc submerger les consommateurs de flux, sauf s’ils sont dimensionnés pour le débit supplémentaire ou si le débit d’écriture de l’opération est plafonné avec MaxWriteRequestUnits. Le billet avertit qu’un plafond trop bas peut allonger l’exécution au-delà de sa limite de temps et la faire échouer, mais aucune des pages enregistrées n’indique cette limite. Une transaction en cours sur un élément a priorité sur l’importation. Comme les écritures en masse n’apparaissent pas dans les métriques de capacité consommée, les alarmes de la table ne signaleront pas un problème d’importation ; le signal à surveiller est l’état de l’opération. Pour quelques éléments, PutItem et BatchWriteItem restent les bons outils.