DynamoDB TTL: Der vollständige Leitfaden zum Ablaufen von Items

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 eine Unix-Epoch-Ablaufzeit hält, und DynamoDB erntet abgelaufene Items im Hintergrund — kein Reaper-Job, keine Extrakosten.

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

Wie funktioniert DynamoDB TTL?

DynamoDB TTL löscht Items automatisch, sobald ein Unix-Epoch-Zeitstempel (Sekunden), den du in einem bestimmten Attribut speicherst, verstreicht. Du aktivierst TTL auf der Tabelle, benennst das Ablauf-Attribut, und DynamoDB erntet abgelaufene Items im Hintergrund — typischerweise innerhalb von wenigen Tagen, ohne Write-Capacity-Kosten. Abgelaufene Items bleiben lesbar, bis sie physisch gelöscht sind.

• TTL ist ein Attribut, das einen Unix-Epoch-Zeitstempel (Sekunden) hält. Wenn diese Zeit verstreicht, wird das Item zum Löschen berechtigt.
• Das Löschen ist Hintergrund und Best-Effort — typischerweise innerhalb von wenigen Tagen nach Ablauf, nicht auf die exakte Sekunde.
• TTL-Deletes sind kostenlos — sie verbrauchen keine Write-Capacity, auch wenn auf einer Global Table das replizierte Delete in jeder anderen Replikat-Region einen Write kostet.
• Abgelaufene-aber-noch-nicht-gelöschte Items erscheinen weiterhin in Reads, also filtere auf das Ablauf-Attribut, wenn du sie sofort verbergen musst.

Das Problem: alte Daten selbst ablaufen zu lassen ist teuer

Ohne TTL bedeutet das Durchsetzen von „verwirf Events, die älter als 90 Tage sind", deinen eigenen Reaper laufen zu lassen: nach alten Items scannen (oder querien) auf einem Zeitplan und jedes DeleteItemn. Dieser Scan verbrennt Lesekapazität, die Deletes verbrennen Write-Capacity, und du besitzt den Zeitplan, die Ausfälle und die Retries.

Für ein hochvolumiges Audit-Log ist das eine konstante, wachsende Steuer, nur um Daten wegzuwerfen. TTL verlagert die gesamte Aufgabe 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 benennst du ein Item-Attribut, das einen Unix-Epoch-Ablaufzeitstempel hä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 Best-Effort, nicht exakt. DynamoDB scannt nach abgelaufenen Items und löscht sie im Hintergrund; das Löschen geschieht typischerweise innerhalb von wenigen Tagen nach Ablauf. Ein Item ist zu seinem Zeitstempel berechtigt, kann aber kurz verweilen.
• Abgelaufene Items sind noch lesbar, bis sie geerntet sind. Eine Query kann ein Item zurückgeben, dessen TTL verstrichen ist, das aber noch nicht gelöscht wurde — also füge eine FilterExpression auf das Ablauf-Attribut hinzu, wenn „abgelaufen = sofort unsichtbar" eine harte Anforderung ist.

Und TTL-Deletes verbrauchen keine Write-Capacity, was es strikt günstiger macht als einen selbst betriebenen Reaper.

Ein durchgearbeitetes Beispiel: Aufbewahrung pro Tenant

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

TTL ist mit expiresAt als TTL-Attribut aktiviert. Wenn das 90-Tage-Event von acme 1782259200 überschreitet, löscht DynamoDB es von selbst innerhalb von rund zwei Tagen. Die Events des Compliance-Tenants tragen ein weit in der Zukunft liegendes expiresAt, sie überleben also — dieselbe Tabelle, derselbe Mechanismus, unterschiedliche Aufbewahrung pro Item.

Die Schreibseite ist einfach 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 verifizieren.

Um ein abgelaufenes-aber-nicht-geerntetes Event sofort vor einem Read zu verbergen, 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 fangen, ist, 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 eine 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. Verifiziere den Typ und die Einheit. Füge den Wert in den TTL-Konverter ein — er erkennt automatisch Sekunden vs. Millisekunden und markiert genau diesen Fehler.
• Verlass dich nicht auf das Lösch-Timing. Zwischen Ablauf und Löschen können ein paar Tage vergehen. Wenn „weg in dem Moment, in dem es abläuft" wichtig ist, filtere auf das Attribut in Reads; nimm nicht an, dass die Zeile physisch weg ist.
• TTL-Deletes erscheinen in Streams. Ein TTL-Delete emittiert einen Stream-Record, der als systemgeneriert markiert ist — der Standard-Hook zum Archivieren ablaufender Events nach S3, bevor sie verschwinden. Siehe DynamoDB Streams.
• TTL-Deletes treffen weiterhin GSIs. Ein Item zu entfernen entfernt es auch aus jedem Sekundärindex, in dem es war — was die beabsichtigte Bereinigung ist, aber wissenswert, falls ein Index eine Zählung getrieben hat.

TTL erledigt das Ende des Lebens eines Events günstig. Die nächste Frage ist, was du für die Writes überhaupt zahlst — On-Demand vs. Provisioned Capacity.

Lade DynoTable herunter, um die Attributtypen deiner Items zu inspizieren und zu bestätigen, dass dein TTL-Attribut eine Unix-Epoch-Number ist, bevor du TTL einschaltest.