DynamoDB prend-il en charge le TTL ?

Oui. DynamoDB prend en charge le Time to Live (TTL). Tu désignes un attribut Number contenant un horodatage d'expiration Unix epoch en secondes ; DynamoDB retire ensuite les éléments expirés en arrière-plan — généralement dans les quelques jours qui suivent l'expiration — sans frais supplémentaires et sans consommer de capacité d'écriture. Les éléments expirés mais pas encore supprimés peuvent toujours apparaître dans les lectures jusqu'à leur retrait.

Comment l'activer

Active le TTL sur la table et nomme l'attribut qui contient l'expiration. Cet attribut doit être un Number stockant un horodatage Unix epoch en secondes (pas en millisecondes). Les éléments dont la valeur est dans le passé deviennent éligibles à la suppression.

À quoi s'attendre

Gratuit — la suppression automatique ne consomme aucune unité de capacité d'écriture. Faire le même ménage toi-même coûte une unité d'écriture par élément : dix millions d'éléments expirés de 1 Ko, c'est dix millions d'unités d'écriture, 6,25 $ en à la demande dans us-east-1, plus environ 1,64 $ pour chaque scan complet d'une table de 100 Go pour les trouver. (Une exception : sur une table globale, la suppression répliquée vers chaque autre Région y consomme bien de la capacité d'écriture répliquée.)
Pas instantané — DynamoDB retire généralement les éléments expirés dans les quelques jours qui suivent l'expiration.
Toujours lisibles — jusqu'à leur suppression physique, les éléments expirés peuvent apparaître dans les lectures, les requêtes et les scans : filtre-les si l'exactitude compte.

La façon dont il ne se déclenche jamais, en silence

DynamoDB ne valide pas l'attribut sur lequel tu as pointé le TTL. Ces deux écritures ont renvoyé HTTP 200 sur une table dont le TTL est activé sur expiresAt, et aucun des deux éléments n'expirera jamais :

{"pk": {"S": "sess#1"}, "expiresAt": {"S": "1790812800"}}
{"pk": {"S": "sess#2"}, "expiresAt": {"N": "1790812800000"}}

Le premier stocke l'horodatage comme String. AWS est explicite : "items with a TTL attribute that is not a Number type are ignored by the TTL process", et rien ne te le dit à l'écriture, ni à l'activation, ni après.

Le second est celui qui arrive vraiment, parce que le type est bon et que la valeur vient de Date.now(). 1790812800000, c'est le 1er octobre 2026 en millisecondes. Lu comme des secondes — la seule façon dont le TTL le lit — cet horodatage tombe en l'an 58718. L'élément est bien formé, interrogeable, facturé au stockage, et programmé pour expirer dans cinquante-six mille ans.

Rien dans l'API ne fait remonter l'une ou l'autre erreur : le contrôle doit donc avoir lieu avant l'écriture. Notre convertisseur TTL traite toute valeur au-dessus de 1e12 comme des millisecondes pour cette raison, et t'affiche la date à laquelle la valeur se résout.

Usages courants

Enregistrements de session, jetons de vérification et résultats en cache qui doivent se nettoyer tout seuls — les cas d'usage classiques du TTL. Associe-le à DynamoDB Streams pour réagir aux suppressions.

Aller plus loin

Lis le guide TTL DynamoDB et DynamoDB Streams. Télécharge DynoTable pour visualiser et définir des attributs TTL.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; TTL.html revérifié le 2026-07-28.

Les deux écritures ci-dessus ont été exécutées le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 et ont été acceptées avec un HTTP 200. Les coûts de nettoyage sont calculés à partir des tarifs à la demande us-east-1 de notre table de prix AWS synchronisée.