DynamoDB TTL

Time to Live (TTL) permite a DynamoDB borrar Items automáticamente una vez que pasa una marca de tiempo que almacenas en ellos. Nombras un atributo que contiene una caducidad Unix-epoch, y DynamoDB cosecha los Items caducados en segundo plano — sin trabajo de cosecha, sin coste extra.

En el escenario del registro de auditoría cada tenant tiene una política de retención: conservar los eventos durante 90 días, o 1 año, o 7 para los más exigentes en cumplimiento. TTL es la forma de aplicar eso sin ejecutar tu propio barrido de borrado.

¿Cómo funciona el TTL de DynamoDB?

DynamoDB TTL elimina automáticamente los Items una vez que pasa una marca de tiempo Unix-epoch (en segundos) que almacenas en un atributo designado. Activas TTL en la tabla, nombras el atributo de caducidad, y DynamoDB cosecha los Items caducados en segundo plano — normalmente en un plazo de 48 horas, sin coste de capacidad de escritura. Los Items caducados siguen siendo legibles hasta que se borran físicamente.

• TTL es un atributo que contiene una marca de tiempo Unix-epoch (segundos). Cuando pasa ese momento, el Item se vuelve elegible para el borrado.
• El borrado es en segundo plano y de mejor esfuerzo — normalmente en un par de días tras la caducidad, no en el segundo exacto. AWS apunta a un plazo de 48 horas.
• Los borrados por TTL son gratis — no consumen capacidad de escritura.
• Los Items caducados pero aún no borrados siguen apareciendo en las lecturas, así que filtra por el atributo de caducidad si necesitas ocultarlos de inmediato.

El problema: caducar los datos antiguos por tu cuenta es caro

Sin TTL, aplicar "elimina los eventos de más de 90 días" significa ejecutar tu propio cosechador: escanear (o consultar) en busca de Items antiguos según un horario y DeleteItem cada uno. Ese Scan quema capacidad de lectura, los borrados queman capacidad de escritura, y tú eres el dueño del horario, de los fallos y de los reintentos.

Para un registro de auditoría de alto volumen eso es un impuesto constante y creciente solo para tirar datos. TTL traslada todo el trabajo a DynamoDB, gratis.

Cómo funciona TTL

Activas TTL en una tabla y le dices qué atributo contiene la caducidad. Según el anuncio de AWS, "especificas un atributo del Item que contiene una marca de tiempo de caducidad Unix-epoch, y DynamoDB gestiona el borrado automáticamente en segundo plano — sin afectar al rendimiento de la tabla".

Dos propiedades importan para la corrección:

• Es de mejor esfuerzo, no exacto. DynamoDB escanea en busca de Items caducados y los borra en segundo plano; AWS apunta al borrado en un plazo de 48 horas tras la caducidad. Un Item es elegible en su marca de tiempo pero puede demorarse brevemente.
• Los Items caducados siguen siendo legibles hasta que se cosechan. Un Query puede devolver un Item cuyo TTL ha pasado pero que aún no se ha borrado — así que añade una FilterExpression sobre el atributo de caducidad si "caducado = invisible de inmediato" es un requisito estricto.

Y los borrados por TTL no consumen capacidad de escritura, que es lo que lo hace estrictamente más barato que un cosechador propio.

Un ejemplo práctico: retención por tenant

Cada evento de auditoría lleva un atributo expiresAt fijado cuando se escribe el evento — ahora + la ventana de retención del tenant, en segundos epoch:

TTL se activa con expiresAt como atributo de TTL. Cuando el evento de 90 días de acme cruza 1758873600, DynamoDB lo borra por su cuenta en aproximadamente dos días. Los eventos del tenant de cumplimiento llevan un expiresAt muy lejano en el futuro, así que sobreviven — misma tabla, mismo mecanismo, distinta retención por Item.

El lado de la escritura es solo añadir un número cuando creas el evento. Puedes componer la cláusula SET expiresAt = :ttl y verificar el valor tipado :ttl en el DynamoDB Expression Builder.

Para ocultar de inmediato de una lectura un evento caducado pero no cosechado, añade expiresAt > :now a la FilterExpression de la consulta — aunque recuerda que un filtro no reduce el coste de lectura (Query vs Scan).

Hazlo en DynoTable

El bug clásico de TTL es un expiresAt equivocado: almacenado en milisegundos en lugar de segundos, o como una cadena ISO, de modo que el Item o nunca caduca o desaparece de inmediato. La única forma de detectarlo es mirar el valor realmente almacenado y su tipo.

DynoTable muestra los atributos de cada Item con sus tipos de DynamoDB, así que puedes confirmar que expiresAt es un Number en segundos epoch — no una String, no milisegundos — antes de confiar a TTL una retención real.

Trampas y próximos pasos

• Segundos epoch, como un Number. Este es el error de TTL más común. Un valor en milisegundos empuja la caducidad ~50.000 años al futuro; una cadena ISO se ignora por completo. Verifica el tipo y la unidad.
• No te fíes del momento del borrado. Pueden pasar hasta ~48 horas entre la caducidad y el borrado. Si importa "desaparecido en el instante en que caduca", filtra por el atributo en las lecturas; no asumas que la fila se ha ido físicamente.
• Los borrados por TTL aparecen en Streams. Un borrado por TTL emite un registro de stream marcado como generado por el sistema — el hook estándar para archivar eventos que caducan en S3 antes de que desaparezcan. Ver DynamoDB Streams.
• Los borrados por TTL también afectan a los GSI. Quitar un Item también lo quita de cualquier índice secundario en el que estuviera — que es la limpieza pretendida, pero conviene saberlo si un índice alimentaba un conteo.

TTL gestiona el final de la vida de un evento de forma barata. La siguiente pregunta es qué pagas por las escrituras en primer lugar — capacidad On-Demand vs Provisioned.

Descargar DynoTable para inspeccionar los tipos de atributo de tus Items y confirmar que tu atributo de TTL es un Number Unix-epoch antes de activar TTL.