¿DynamoDB admite TTL?

Sí. DynamoDB admite Time to Live (TTL). Designas un atributo Number que contiene una marca de tiempo de caducidad epoch Unix en segundos; DynamoDB elimina entonces los Items caducados en segundo plano — normalmente a los pocos días de la caducidad — sin coste adicional y sin consumir capacidad de escritura. Los Items caducados pero aún no borrados pueden seguir apareciendo en las lecturas hasta que se eliminen.

Cómo activarlo

Activa el TTL para la tabla y nombra el atributo que contiene la caducidad. Ese atributo debe ser un Number que almacene una marca de tiempo epoch Unix en segundos (no en milisegundos). Los Items cuyo valor esté en el pasado pasan a ser aptos para el borrado.

Qué esperar

Gratis — el borrado automático no consume unidades de capacidad de escritura. Hacer esa misma limpieza tú mismo cuesta una unidad de escritura por Item: diez millones de Items caducados de 1 KB son diez millones de unidades de escritura, 6,25 $ en us-east-1 bajo demanda, más unos 1,64 $ por cada scan completo sobre una tabla de 100 GB para encontrarlos. (Una excepción: en una tabla global, el borrado replicado a cada otra región sí consume allí capacidad de escritura replicada.)
No es instantáneo — DynamoDB normalmente elimina los Items caducados a los pocos días de su caducidad.
Aún se pueden leer — hasta que se borran físicamente, los Items caducados pueden aparecer en lecturas, consultas y scans, así que fíltralos si la exactitud importa.

La forma en que nunca se dispara, en silencio

DynamoDB no valida el atributo al que apuntaste el TTL. Ambas escrituras devolvieron HTTP 200 en una tabla con el TTL activado sobre expiresAt, y ninguno de los dos Items caducará jamás:

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

El primero guarda la marca de tiempo como String. AWS es explícito en que "items with a TTL attribute that is not a Number type are ignored by the TTL process", y nada te avisa al escribir, ni al activarlo, ni después.

El segundo es el que ocurre de verdad, porque el tipo es correcto y el valor vino de Date.now(). 1790812800000 es el 1 de octubre de 2026 en milisegundos. Leído como segundos, que es la única forma en que lo lee el TTL, esa marca de tiempo aterriza en el año 58718. El Item está bien formado, es consultable, se factura por almacenamiento y está programado para caducar dentro de cincuenta y seis mil años.

Nada en la API saca a la luz ninguno de los dos errores, así que la comprobación tiene que ocurrir antes de escribir. Nuestro conversor de TTL trata cualquier valor por encima de 1e12 como milisegundos por esta razón, y te muestra la fecha a la que se resuelve el valor.

Usos habituales

Registros de sesión, tokens de verificación y resultados cacheados que deberían limpiarse solos — los casos de uso clásicos de TTL. Combínalo con DynamoDB Streams para reaccionar a los borrados.

Profundiza

Lee la guía de TTL de DynamoDB y DynamoDB Streams. Descarga DynoTable para ver y fijar atributos de TTL.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba; TTL.html revisado de nuevo el 2026-07-28.

Ambas escrituras de arriba se ejecutaron el 2026-07-28 contra DynamoDB Local 3.3.0 mediante @aws-sdk/client-dynamodb 3.1095.0 y fueron aceptadas con HTTP 200. Los costes de limpieza se calcularon con las tarifas bajo demanda de us-east-1 de nuestra tabla de precios de AWS sincronizada.