DynamoDB TTL

Time to Live (TTL) lässt DynamoDB Items automatisch löschen, sobald ein Zeitstempel, den du auf ihnen speicherst, verstreicht. Du benennst ein Attribut, das einen Unix-Epoch-Ablauf hält, und DynamoDB erntet abgelaufene Items im Hintergrund — kein Reaper-Job, keine Zusatzkosten.

Im Audit-Log-Szenario hat jeder Mandant eine Aufbewahrungsrichtlinie: Events 90 Tage behalten, oder 1 Jahr, oder 7 für die compliance-lastigen. TTL ist die Art, wie du das durchsetzt, ohne deinen eigenen Lösch-Sweep zu betreiben.

Wie funktioniert DynamoDB TTL?

DynamoDB TTL löscht Items automatisch, sobald ein Unix-Epoch-Zeitstempel (Sekunden), den du in einem festgelegten Attribut speicherst, verstreicht. Du aktivierst TTL auf der Tabelle, benennst das Ablauf-Attribut, und DynamoDB entfernt abgelaufene Items im Hintergrund — in der Regel innerhalb von 48 Stunden, ohne Schreibkapazität zu verbrauchen. Abgelaufene Items bleiben lesbar, bis sie physisch gelöscht werden.

• TTL ist ein Attribut, das einen Unix-Epoch-Zeitstempel (Sekunden) hält. Wenn diese Zeit verstreicht, wird das Item zum Löschen freigegeben.
• Das Löschen geschieht im Hintergrund und nach bestem Bemühen — typischerweise innerhalb von ein paar Tagen nach dem Ablauf, nicht zur exakten Sekunde. AWS zielt auf innerhalb von 48 Stunden ab.
• TTL-Löschungen sind kostenlos — sie verbrauchen keine Schreibkapazität.
• Abgelaufene, aber noch nicht gelöschte Items erscheinen weiterhin in Lesevorgängen, also filtere auf das Ablauf-Attribut, wenn du sie sofort verstecken musst.

Das Problem: alte Daten selbst ablaufen zu lassen ist teuer

Ohne TTL bedeutet „Events älter als 90 Tage verwerfen" durchzusetzen, deinen eigenen Reaper zu betreiben: nach alten Items per Scan (oder Query) auf einem Zeitplan suchen und jedes per DeleteItem löschen. Dieser Scan verbrennt Lesekapazität, die Löschungen verbrennen Schreibkapazität, und du verantwortest den Zeitplan, die Fehler und die Retries.

Für ein Audit-Log mit hohem Volumen ist das eine konstante, wachsende Steuer nur dafür, Daten wegzuwerfen. TTL verlagert die gesamte Arbeit in DynamoDB, kostenlos.

Wie TTL funktioniert

Du aktivierst TTL auf einer Tabelle und sagst ihr, welches Attribut den Ablauf hält. Laut der AWS-Ankündigung „gibst du ein Item-Attribut an, das einen Unix-Epoch-Ablaufzeitstempel enthält, und DynamoDB übernimmt das Löschen automatisch im Hintergrund — ohne die Tabellen-Performance zu beeinträchtigen."

Zwei Eigenschaften sind für die Korrektheit wichtig:

• Es ist nach bestem Bemühen, nicht exakt. DynamoDB sucht nach abgelaufenen Items und löscht sie im Hintergrund; AWS zielt auf Löschung innerhalb von 48 Stunden nach dem Ablauf. Ein Item ist zu seinem Zeitstempel freigegeben, kann aber kurz verweilen.
• Abgelaufene Items sind bis zur Ernte weiterhin lesbar. Ein Query kann ein Item zurückgeben, dessen TTL verstrichen ist, das aber noch nicht gelöscht wurde — füge also eine FilterExpression auf das Ablauf-Attribut hinzu, wenn „abgelaufen = sofort unsichtbar" eine harte Anforderung ist.

Und TTL-Löschungen verbrauchen keine Schreibkapazität, was es strikt günstiger macht als ein selbstbetriebener Reaper.

Ein durchgerechnetes Beispiel: Aufbewahrung pro Mandant

Jedes Audit-Event trägt ein expiresAt-Attribut, das gesetzt wird, wenn das Event geschrieben wird — now + das Aufbewahrungsfenster des Mandanten, in Epoch-Sekunden:

TTL ist mit expiresAt als TTL-Attribut aktiviert. Wenn acmes 90-Tage-Event 1758873600 überschreitet, löscht DynamoDB es von selbst innerhalb von etwa zwei Tagen. Die Events des Compliance-Mandanten tragen ein weit in der Zukunft liegendes expiresAt, also überleben sie — gleiche Tabelle, gleicher Mechanismus, unterschiedliche Aufbewahrung pro Item.

Die Schreibseite ist nur das Hinzufügen einer Zahl, wenn du das Event erstellst. Du kannst die SET expiresAt = :ttl-Klausel komponieren und den typisierten :ttl-Wert im DynamoDB Expression Builder prüfen.

Um ein abgelaufenes, aber nicht geerntetes Event sofort aus einem Lesevorgang zu verstecken, füge expiresAt > :now zur FilterExpression der Query hinzu — denk aber daran, dass ein Filter die Lesekosten nicht reduziert (Query vs. Scan).

In DynoTable umsetzen

Der klassische TTL-Bug ist ein falsches expiresAt: gespeichert in Millisekunden statt Sekunden oder als ISO-String, sodass das Item entweder nie abläuft oder sofort verschwindet. Der einzige Weg, das zu erwischen, ist, sich den tatsächlich gespeicherten Wert und seinen Typ anzusehen.

DynoTable zeigt die Attribute jedes Items mit ihren DynamoDB-Typen, sodass du bestätigen kannst, dass expiresAt ein Number in Epoch-Sekunden ist — kein String, keine Millisekunden —, bevor du TTL mit echter Aufbewahrung vertraust.

Fallstricke und nächste Schritte

• Epoch-Sekunden, als Number. Das ist der mit Abstand häufigste TTL-Fehler. Ein Millisekunden-Wert schiebt den Ablauf ~50.000 Jahre nach hinten; ein ISO-String wird komplett ignoriert. Prüfe Typ und Einheit.
• Verlass dich nicht auf das Löschtiming. Bis zu ~48 Stunden können zwischen Ablauf und Löschung vergehen. Wenn „weg, sobald es abläuft" zählt, filtere auf das Attribut in Lesevorgängen; nimm nicht an, dass die Zeile physisch weg ist.
• TTL-Löschungen erscheinen in Streams. Eine TTL-Löschung emittiert einen Stream-Record, der als systemgeneriert markiert ist — der Standard-Hook, um ablaufende Events nach S3 zu archivieren, bevor sie verschwinden. Siehe DynamoDB Streams.
• TTL-Löschungen treffen weiterhin GSIs. Ein Item zu entfernen, entfernt es auch aus jedem Secondary Index, in dem es war — was die beabsichtigte Bereinigung ist, aber wissenswert, falls ein Index eine Zählung getrieben hat.

TTL behandelt das Ende der Lebensdauer eines Events günstig. Die nächste Frage ist, was du für die Schreibvorgänge überhaupt zahlst — On-Demand vs. Provisioned-Kapazität.

DynoTable herunterladen, um die Attribut-Typen deiner Items zu inspizieren und zu bestätigen, dass dein TTL-Attribut ein Unix-Epoch-Number ist, bevor du TTL einschaltest.