Unterstützt DynamoDB TTL?

Ja. DynamoDB unterstützt Time to Live (TTL). Du bestimmst ein Number-Attribut, das einen Unix-Epoch-Ablaufzeitstempel in Sekunden enthält; DynamoDB entfernt abgelaufene Items dann im Hintergrund — typischerweise innerhalb weniger Tage nach Ablauf — ohne Zusatzkosten und ohne Write-Kapazität zu verbrauchen. Abgelaufene, aber noch nicht gelöschte Items können bis zur Entfernung weiterhin in Lesevorgängen auftauchen.

Wie du es aktivierst

Schalte TTL für die Tabelle ein und benenne das Attribut, das den Ablauf enthält. Dieses Attribut muss ein Number sein, das einen Unix-Epoch-Zeitstempel in Sekunden speichert (nicht in Millisekunden). Items, deren Wert in der Vergangenheit liegt, werden zum Löschen freigegeben.

Was dich erwartet

Kostenlos — das automatische Löschen verbraucht keine Write-Kapazitätseinheiten. Dieselbe Aufräumarbeit selbst zu machen kostet eine Write-Einheit pro Item: Zehn Millionen abgelaufene 1-KB-Items sind zehn Millionen Write-Einheiten, 6,25 $ On-Demand in us-east-1, plus etwa 1,64 $ für jeden vollständigen Scan über eine 100-GB-Tabelle, um sie zu finden. (Eine Ausnahme: Auf einer Global Table verbraucht das in jede andere Region replizierte Delete dort sehr wohl replizierte Write-Kapazität.)
Nicht sofort — DynamoDB entfernt abgelaufene Items typischerweise innerhalb weniger Tage nach Ablauf.
Weiterhin lesbar — bis sie physisch gelöscht sind, können abgelaufene Items in Reads, Queries und Scans auftauchen; filtere sie also heraus, wenn Genauigkeit zählt.

Die Art, wie es still nie auslöst

DynamoDB validiert das Attribut nicht, auf das du TTL gerichtet hast. Beide dieser Writes gaben HTTP 200 auf einer Tabelle mit auf expiresAt aktiviertem TTL zurück, und keines der beiden Items wird je ablaufen:

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

Das erste speichert den Zeitstempel als String. AWS sagt ausdrücklich, dass "items with a TTL attribute that is not a Number type are ignored by the TTL process", und nichts sagt es dir beim Schreiben, beim Aktivieren oder danach.

Das zweite ist das, was tatsächlich passiert, denn der Typ stimmt und der Wert kam aus Date.now(). 1790812800000 ist der 1. Oktober 2026 in Millisekunden. Als Sekunden gelesen — und nur so liest TTL ihn — landet dieser Zeitstempel im Jahr 58718. Das Item ist wohlgeformt, abfragbar, für Speicher abgerechnet und darauf angesetzt, in sechsundfünfzigtausend Jahren abzulaufen.

Nichts in der API zeigt einen der beiden Fehler an, die Prüfung muss also stattfinden, bevor du schreibst. Unser TTL-Konverter behandelt jeden Wert über 1e12 aus genau diesem Grund als Millisekunden und zeigt dir das Datum, zu dem der Wert aufgelöst wird.

Häufige Einsatzzwecke

Sitzungsdatensätze, Verifizierungs-Token und gecachte Ergebnisse, die sich selbst aufräumen sollen — die klassischen TTL-Anwendungsfälle. Kombiniere es mit DynamoDB Streams, um auf Löschungen zu reagieren.

Tiefer einsteigen

Lies den Leitfaden zu DynamoDB TTL und zu DynamoDB Streams. Lade DynoTable herunter, um TTL-Attribute anzusehen und zu setzen.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation; TTL.html am 2026-07-28 erneut geprüft.

Beide Writes oben wurden am 2026-07-28 gegen DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 ausgeführt und mit HTTP 200 angenommen. Die Aufräumkosten sind aus den On-Demand-Raten für us-east-1 in unserer synchronisierten AWS-Preistabelle berechnet.