DynamoDB TTL

Le Time to Live (TTL) permet à DynamoDB de supprimer des items automatiquement une fois qu'un timestamp que tu y stockes est dépassé. Tu nommes un attribut contenant une date d'expiration en epoch Unix, et DynamoDB faucarde les items expirés en arrière-plan — pas de job de nettoyage, pas de coût supplémentaire.

Dans le scénario du journal d'audit, chaque tenant a une politique de rétention : garder les événements pendant 90 jours, ou 1 an, ou 7 pour les plus chargés en conformité. Le TTL est ce qui te permet d'appliquer ça sans lancer ton propre balayage de suppression.

Comment fonctionne le TTL de DynamoDB ?

Le TTL de DynamoDB supprime automatiquement les items une fois qu'un timestamp en epoch Unix (secondes) que tu stockes dans un attribut désigné est dépassé. Tu actives le TTL sur la table, tu nommes l'attribut d'expiration, et DynamoDB faucarde les items expirés en arrière-plan — typiquement dans les 48 heures, sans coût de capacité d'écriture. Les items expirés restent lisibles jusqu'à leur suppression physique.

• Le TTL est un attribut contenant un timestamp en epoch Unix (secondes). Quand ce moment est dépassé, l'item devient éligible à la suppression.
• La suppression est en arrière-plan et au mieux — généralement dans les quelques jours suivant l'expiration, pas à la seconde exacte. AWS vise dans les 48 heures.
• Les suppressions par TTL sont gratuites — elles ne consomment pas de capacité d'écriture.
• Les items expirés mais pas encore supprimés apparaissent toujours dans les lectures, donc filtre sur l'attribut d'expiration si tu dois les masquer immédiatement.

Le problème : faire expirer les vieilles données toi-même coûte cher

Sans TTL, appliquer « supprimer les événements de plus de 90 jours » signifie lancer ton propre nettoyeur : scanner (ou interroger) les vieux items selon un planning et faire un DeleteItem sur chacun. Ce scan brûle de la capacité de lecture, les suppressions brûlent de la capacité d'écriture, et tu possèdes le planning, les défaillances et les réessais.

Pour un journal d'audit à fort volume, c'est une taxe constante et croissante juste pour jeter des données. Le TTL déplace tout ce travail dans DynamoDB, gratuitement.

Comment fonctionne le TTL

Tu actives le TTL sur une table et tu lui indiques quel attribut porte l'expiration. D'après l'annonce AWS, tu « spécifies un attribut d'item contenant un timestamp d'expiration en epoch Unix, et DynamoDB gère la suppression automatiquement en arrière-plan — sans affecter les performances de la table ».

Deux propriétés comptent pour la justesse :

• C'est au mieux, pas exact. DynamoDB scanne les items expirés et les supprime en arrière-plan ; AWS vise une suppression dans les 48 heures suivant l'expiration. Un item est éligible à son timestamp mais peut traîner brièvement.
• Les items expirés restent lisibles jusqu'à leur faucardage. Une Query peut renvoyer un item dont le TTL est dépassé mais qui n'a pas encore été supprimé — donc ajoute une FilterExpression sur l'attribut d'expiration si « expiré = invisible immédiatement » est une exigence stricte.

Et les suppressions par TTL ne consomment pas de capacité d'écriture, ce qui est ce qui les rend strictement moins chères qu'un nettoyeur auto-géré.

Un exemple concret : rétention par tenant

Chaque événement d'audit porte un attribut expiresAt défini au moment où l'événement est écrit — maintenant + la fenêtre de rétention du tenant, en secondes epoch :

Le TTL est activé avec expiresAt comme attribut TTL. Quand l'événement à 90 jours d'acme franchit 1758873600, DynamoDB le supprime de lui-même dans les deux jours environ. Les événements du tenant conformité portent un expiresAt très lointain, donc ils survivent — même table, même mécanisme, rétention différente par item.

Le côté écriture, c'est juste ajouter un nombre quand tu crées l'événement. Tu peux composer la clause SET expiresAt = :ttl et vérifier la valeur typée :ttl dans le DynamoDB Expression Builder.

Pour masquer immédiatement d'une lecture un événement expiré mais non faucardé, ajoute expiresAt > :now à la FilterExpression de la requête — en gardant cependant à l'esprit qu'un filtre ne réduit pas le coût de lecture (query vs scan).

Fais-le dans DynoTable

Le bug TTL classique est un expiresAt erroné : stocké en millisecondes au lieu de secondes, ou en chaîne ISO, si bien que l'item soit n'expire jamais, soit disparaît immédiatement. La seule façon de l'attraper est de regarder la valeur réellement stockée et son type.

DynoTable affiche les attributs de chaque item avec leurs types DynamoDB, donc tu peux confirmer qu'expiresAt est un Number en secondes epoch — pas une String, pas des millisecondes — avant de confier au TTL une vraie rétention.

Pièges et étapes suivantes

• Secondes epoch, en tant que Number. C'est l'erreur TTL la plus courante. Une valeur en millisecondes repousse l'expiration d'environ 50 000 ans ; une chaîne ISO est ignorée entièrement. Vérifie le type et l'unité.
• Ne te fie pas au timing de suppression. Jusqu'à ~48 heures peuvent s'écouler entre l'expiration et la suppression. Si « disparu à l'instant où il expire » importe, filtre sur l'attribut dans les lectures ; ne suppose pas que la ligne est physiquement partie.
• Les suppressions par TTL apparaissent dans Streams. Une suppression par TTL émet un enregistrement de stream marqué comme généré par le système — le point d'accroche standard pour archiver les événements qui expirent vers S3 avant qu'ils ne disparaissent. Voir DynamoDB Streams.
• Les suppressions par TTL frappent aussi les GSI. Supprimer un item le retire aussi de tout index secondaire où il se trouvait — c'est le nettoyage prévu, mais bon à savoir si un index alimentait un comptage.

Le TTL gère la fin de la vie d'un événement à bas coût. La question suivante est ce que tu paies pour les écritures en premier lieu — capacité On-Demand vs Provisioned.

Télécharge DynoTable pour inspecter les types d'attributs de tes items et confirmer que ton attribut TTL est un Number en epoch Unix avant d'activer le TTL.