L'attribut TTL DynamoDB doit être un Number

TL;DR — Le Time to Live de DynamoDB ne supprime un élément que lorsque son attribut TTL désigné contient un Number représentant un horodatage epoch Unix en secondes. Une String comme "1735689600", une valeur en millisecondes, une date ISO-8601 ou un attribut manquant est ignoré silencieusement — l'élément n'expire jamais. Stocke le TTL sous forme de Number en secondes epoch et réécris les éléments concernés.

Ce que ça signifie

# A second UpdateTimeToLive call within one hour of the first raises:
ValidationException  (TTL settings can only be modified once per table per hour)

# The quieter failure — no error at all, item just never expires:
TTL attribute "expiresAt" = "2026-01-01T00:00:00Z"   ← String, ignored
TTL attribute "expiresAt" = 1735689600000            ← milliseconds: tens of thousands of years away

Activer le TTL (UpdateTimeToLive) réussit même quand l'attribut n'existe pas encore ou est du mauvais type — DynamoDB ne vérifie pas son type en amont. L'échec apparaît plus tard : le processus TTL en arrière-plan ne supprime un élément que lorsque l'attribut est un Number contenant un horodatage epoch Unix en secondes situé dans le passé (et pas plus de cinq ans dans le passé). Tout le reste est traité comme « pas d'expiration ».

Pourquoi ça arrive

Stocké comme une String — la valeur est {"S": "1735689600"} au lieu de {"N": "1735689600"}. Le TTL ignore les types non-N.
Des millisecondes au lieu de secondes — Date.now() (JavaScript) renvoie des millisecondes ; une valeur à 13 chiffres se situe des dizaines de milliers d'années dans le futur, donc l'élément n'expire de fait jamais.
Une chaîne de date ISO-8601 / lisible par un humain plutôt que des secondes epoch.
Un horodatage de plus de cinq ans dans le passé — le processus TTL l'ignore au lieu de supprimer l'élément.
Un nom d'attribut différent de celui enregistré auprès du TTL (le nom est sensible à la casse).
Rappeler UpdateTimeToLive trop tôt — la modification prend jusqu'à une heure pour se propager complètement, et tout appel UpdateTimeToLive supplémentaire pour la même table pendant cette heure déclenche une ValidationException.

Comment le corriger

Écris la valeur TTL sous forme de Number en secondes epoch — Math.floor(Date.now() / 1000) + ttlSeconds en JavaScript, int(time.time()) + ttl en Python. Ne stocke jamais des millisecondes.
Utilise le type N, pas S. Avec le client bas niveau, c'est {"N": "1735689600"} ; le Document Client sérialise un nombre natif pour toi.
Fais correspondre exactement le nom d'attribut enregistré, casse comprise. Confirme-le avec DescribeTimeToLive.
Corrige les éléments existants — les éléments écrits avant la correction portent toujours la mauvaise valeur ; réécris-les avec un Number en secondes epoch correct.
Attends une heure entre deux changements de configuration TTL — UpdateTimeToLive prend jusqu'à une heure pour se propager, et les appels supplémentaires pendant cette fenêtre sont rejetés avec une ValidationException.

Tu veux voir le type sur le fil de chaque attribut pendant que tu parcours une table ? L'application de bureau DynoTable affiche les étiquettes de type N/S/M en ligne, donc un TTL stocké comme String ressort avant de te coûter un élément qui n'a pas expiré.

FAQ

Pourquoi mon TTL DynamoDB ne supprime-t-il pas d'éléments ? L'attribut TTL doit être un Number contenant un horodatage epoch Unix en secondes. Une valeur String, une valeur en millisecondes, une date ISO ou un nom qui ne correspond pas à l'attribut TTL enregistré sont tous ignorés silencieusement, donc l'élément n'expire jamais. La suppression n'est pas non plus immédiate — DynamoDB retire généralement les éléments expirés dans les quelques jours suivant leur date d'expiration.

DynamoDB valide-t-il le type de l'attribut TTL quand j'active le TTL ? Non. UpdateTimeToLive réussit même si l'attribut est manquant ou du mauvais type. L'exigence de type (Number, secondes epoch) n'est appliquée que par le processus de suppression en arrière-plan, c'est pourquoi un mauvais TTL échoue en silence.

Erreurs liées

Float / decimal number types not supported — un piège de typage des nombres apparenté.
ValidationException (vue d'ensemble)
En savoir plus : DynamoDB TTL · DynamoDB data types

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.