DynamoDB TTL : le guide complet pour faire expirer les items

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

Dans le scénario du journal d'audit, chaque locataire a une politique de rétention : garder les événements 90 jours, ou 1 an, ou 7 ans pour ceux fortement soumis à la conformité. Le TTL, c'est la façon d'appliquer ça sans faire tourner ton propre balayage de suppression.

Comment fonctionne le TTL de DynamoDB ?

Le TTL de DynamoDB supprime automatiquement les items une fois qu'un horodatage Unix-epoch (en 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 purge les items expirés en arrière-plan — généralement en quelques jours, sans coût en capacité d'écriture. Les items expirés restent lisibles jusqu'à leur suppression physique.

• Le TTL est un attribut contenant un horodatage Unix-epoch (en secondes). Quand ce moment est passé, l'item devient éligible à la suppression.
• La suppression est en arrière-plan et au mieux (best-effort) — généralement en quelques jours après l'expiration, pas à la seconde près.
• Les suppressions par TTL sont gratuites — elles ne consomment pas de capacité d'écriture, même si sur une table globale la suppression répliquée coûte une écriture dans chaque autre région de réplique.
• 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 : expirer les vieilles données toi-même coûte cher

Sans TTL, appliquer « supprimer les événements de plus de 90 jours » signifie faire tourner ta propre purge : scanner (ou interroger) les vieux items sur 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 es responsable du planning, des échecs et des reprises.

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 le travail dans DynamoDB, gratuitement.

Comment fonctionne le TTL

Tu actives le TTL sur une table et tu lui indiques quel attribut contient l'expiration. D'après l'annonce AWS, tu désignes un attribut d'item contenant un horodatage d'expiration au format Unix-epoch, 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 ; la suppression a généralement lieu dans les quelques jours suivant l'expiration. Un item est éligible à son horodatage mais peut subsister brièvement.
• Les items expirés restent lisibles jusqu'à leur purge. Une Query peut renvoyer un item dont le TTL est dépassé mais qui n'a pas encore été supprimé — ajoute donc 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 les rend strictement moins chères qu'une purge que tu ferais tourner toi-même.

Un exemple concret : rétention par locataire

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 locataire, en secondes epoch :

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

Côté écriture, il suffit d'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 Générateur d'expressions DynamoDB.

Pour masquer immédiatement d'une lecture un événement expiré mais non purgé, ajoute expiresAt > :now à la FilterExpression de la requête — même si, rappelle-toi, 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 sous forme de 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, pour que tu puisses confirmer qu'expiresAt est un Number en secondes epoch — pas une String, pas des millisecondes — avant de confier une vraie rétention au TTL.

Pièges et étapes suivantes

• Des secondes epoch, en Number. C'est l'erreur de TTL la plus courante. Une valeur en millisecondes repousse l'expiration d'environ 50 000 ans ; une chaîne ISO est ignorée purement et simplement. Vérifie le type et l'unité. Colle la valeur dans le convertisseur TTL — il détecte automatiquement secondes vs millisecondes et signale exactement cette erreur.
• Ne te fie pas au moment de la suppression. Quelques jours peuvent s'écouler entre l'expiration et la suppression. Si « disparu à l'instant où il expire » compte, 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 flux marqué comme généré par le système — le point d'ancrage standard pour archiver vers S3 les événements qui expirent avant qu'ils ne disparaissent. Voir DynamoDB Streams.
• Les suppressions par TTL touchent aussi les GSI. Supprimer un item le retire également de tout index secondaire dans lequel il figurait — c'est le nettoyage voulu, mais bon à savoir si un index alimentait un comptage.

Le TTL gère la fin de vie d'un événement à moindre 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 Unix-epoch avant d'activer le TTL.