DynamoDB Streams : le guide complet (avec exemples)

DynamoDB Streams est un journal de capture des modifications (change data capture) : chaque insertion, mise à jour et suppression sur une table est capturée, dans l'ordre, sous la forme d'un flux d'enregistrements auxquels tu peux réagir. C'est ainsi que tu transformes une table en source d'événements sans avoir à l'interroger en boucle.

Dans le scénario du journal d'audit, tu veux réagir à l'instant même où un événement sensible arrive — déclencher une alerte quand quelqu'un exporte une facture ou attribue un rôle d'administrateur — sans scanner la table à intervalle régulier. Streams est le versant « push » de tout ça.

Comment fonctionnent les DynamoDB Streams ?

Les DynamoDB Streams capturent chaque insertion, mise à jour et suppression sur une table sous la forme d'un journal d'enregistrements ordonné dans le temps et dédupliqué, conservé jusqu'à 24 heures. Tu choisis ce que porte chaque enregistrement avec StreamViewType (les clés, la nouvelle image, l'ancienne image ou les deux), puis tu consommes le flux avec un déclencheur Lambda pour réagir aux changements d'item sans polling.

• Streams capture les changements au niveau de l'item sous la forme d'un journal ordonné dans le temps et dédupliqué, conservé jusqu'à 24 heures.
• Tu choisis ce que porte chaque enregistrement via StreamViewType : les clés seulement, la nouvelle image, l'ancienne image, ou l'ancienne et la nouvelle.
• Les enregistrements sont ordonnés par item — les changements d'un même item arrivent dans l'ordre où ils ont été écrits — et un flux est partitionné en shards de la même façon que la table.
• Le consommateur natif est Lambda — un déclencheur qui s'exécute par lot de nouveaux enregistrements, Kinesis Data Streams étant l'alternative pour une diffusion plus riche.

Le problème : réagir sans polling

Tu as besoin de « préviens-moi quand un événement role.granted est écrit ». L'approche naïve est un job planifié qui scanne les nouveaux événements chaque minute — ce qui lit toute la partition récente à chaque fois, coûte de la capacité, et a toujours au moins une minute de retard.

Ce que tu veux vraiment, c'est un push : DynamoDB te prévient à l'instant où un item change. C'est exactement ce que fournit Streams, avec l'enregistrement de changement livré à ton code au lieu que tu ailles le chercher.

Comment fonctionne Streams

D'après la documentation AWS, DynamoDB Streams conserve un journal dédupliqué et ordonné dans le temps des changements pendant 24 heures, avec une intégration native à Lambda (capture des modifications de données pour DynamoDB). Chaque enregistrement décrit une modification au niveau d'un item.

Quand tu actives un flux, tu choisis un StreamViewType, qui contrôle la part de l'item modifié que porte chaque enregistrement :

Les enregistrements sont ordonnés par item — les changements d'un même item apparaissent dans l'ordre où ils ont été écrits — et le flux est partitionné en shards suivant la même structure de partitions que la table. La rétention est de 24 heures — Streams est un tampon de réaction, pas un historique permanent. Pour un historique durable, tu stockes les événements eux-mêmes (ce qu'est justement déjà notre table de journal d'audit).

Le consommateur natif est un déclencheur Lambda : DynamoDB invoque ta fonction avec un lot de nouveaux enregistrements de flux à mesure qu'ils arrivent.

Un exemple concret : alerter sur les événements d'audit sensibles

La table de journal d'audit reçoit un flux avec NEW_IMAGE, donc chaque enregistrement porte le nouvel événement complet. Une Lambda consomme le lot et ne transmet que les enregistrements qui comptent :

La fonction ne touche jamais la table — elle réagit uniquement à ce que le flux lui remet. Pas de polling, pas de scan, et l'alerte se déclenche en quelques secondes après l'écriture. Les enregistrements du flux sont ordonnés par item, donc les changements successifs d'un même item-événement arrivent dans l'ordre où ils ont été écrits.

C'est aussi la manière standard de maintenir une copie en aval : un consommateur de flux peut projeter chaque événement dans OpenSearch pour une recherche d'audit en texte intégral, ou agréger des comptes — le tout dérivé du même journal de changements.

Fais-le dans DynoTable

Avant de câbler un consommateur de flux, tu dois connaître la forme exacte de l'item que ta Lambda recevra — quels attributs existent, à quoi ressemblent les maps et listes imbriquées, ce que contiendra réellement un enregistrement NEW_IMAGE.

Pour convertir un item d'exemple entre le JSON simple et la forme attribute-value qu'utilise un enregistrement de flux, le convertisseur JSON DynamoDB le fait dans ton navigateur. Et dans DynoTable, tu peux inspecter l'item complet — y compris sa forme DynamoDB-JSON — pour modéliser l'enregistrement NEW_IMAGE à partir de données réelles au lieu de deviner la forme des champs.

Si tu testes un consommateur en local, exécute la table sur DynamoDB Local et inspecte-la de la même façon — voir se connecter à DynamoDB Local.

Pièges et étapes suivantes

• 24 heures n'est pas un backlog. Si ton consommateur est arrêté pendant une journée, les enregistrements expirent et disparaissent. Streams sert à la réaction quasi temps réel, pas au rejeu durable — garde les événements eux-mêmes pour l'historique.
• Choisis le plus petit StreamViewType dont tu as besoin. NEW_AND_OLD_IMAGES double la charge utile ; si tu n'as besoin que de la clé pour aller relire l'item, KEYS_ONLY est moins cher.
• L'ordre est par item, pas par clé de partition ni global. DynamoDB ne garantit l'ordre que pour les changements successifs d'un même item ; il n'y a aucune garantie d'ordre entre items différents, même au sein d'une seule clé de partition.
• Les suppressions par TTL apparaissent comme des enregistrements de flux avec le marqueur d'attribut système, ce qui te permet d'archiver les items qui expirent — voir DynamoDB TTL.

Streams transforme le journal d'audit en source d'événements. La préoccupation opérationnelle suivante est l'autre extrémité de la vie d'un item — expirer automatiquement les vieux événements avec DynamoDB TTL.

Télécharge DynoTable pour inspecter la forme exacte de l'item que ton consommateur de flux recevra avant d'écrire une ligne de code Lambda.