DynamoDB Streams: Der vollständige Leitfaden (mit Beispielen)

DynamoDB Streams ist ein Change-Data-Capture-Log: jedes Insert, Update und Delete auf einer Tabelle wird der Reihe nach als Stream von Records erfasst, auf die du reagieren kannst. So verwandelst du eine Tabelle in eine Event-Quelle, ohne sie zu pollen.

Im Audit-Log-Szenario willst du in dem Moment reagieren, in dem ein sensibles Event landet — einen Alarm auslösen, wenn jemand eine Rechnung exportiert oder eine Admin-Rolle vergibt — ohne die Tabelle nach einem Timer zu scannen. Streams ist die Push-Seite davon.

Wie funktionieren DynamoDB Streams?

DynamoDB Streams erfassen jedes Insert, Update und Delete auf einer Tabelle als ein zeitgeordnetes, dedupliziertes Log von Records, aufbewahrt für bis zu 24 Stunden. Du wählst mit StreamViewType, was jeder Record trägt (Keys, neues Image, altes Image oder beides), und konsumierst den Stream dann mit einem Lambda-Trigger, um auf Item-Änderungen zu reagieren, ohne zu pollen.

• Streams erfasst Änderungen auf Item-Ebene als ein zeitgeordnetes, dedupliziertes Log, aufbewahrt für bis zu 24 Stunden.
• Du wählst, was jeder Record trägt über StreamViewType: nur Keys, das neue Image, das alte Image oder sowohl altes als auch neues.
• Records sind pro Item geordnet — Änderungen an einem Item treffen in der Reihenfolge ein, in der sie geschrieben wurden — und ein Stream ist auf dieselbe Weise gesharded wie die Tabelle.
• Der native Consumer ist Lambda — ein Trigger, der pro Batch neuer Records läuft, mit Kinesis Data Streams als Alternative für reicheres Fan-out.

Das Problem: reagieren ohne Polling

Du brauchst „alarmiere mich, wenn ein role.granted-Event geschrieben wird". Der naive Ansatz ist ein geplanter Job, der jede Minute nach neuen Events scannt — was jedes Mal die ganze jüngste Partition liest, Kapazität kostet und immer mindestens eine Minute zu spät ist.

Was du eigentlich willst, ist ein Push: DynamoDB sagt dir in dem Moment, in dem sich ein Item ändert. Genau das liefert Streams, wobei der Change-Record an deinen Code geliefert wird, statt dass du danach jagst.

Wie Streams funktioniert

Laut den AWS-Docs führt DynamoDB Streams ein dedupliziertes, zeitgeordnetes Log von Änderungen für bis zu 24 Stunden, mit nativer Lambda-Integration (Change Data Capture für DynamoDB). Jeder Record beschreibt eine Modifikation auf Item-Ebene.

Wenn du einen Stream aktivierst, wählst du einen StreamViewType, der steuert, wie viel des geänderten Items jeder Record trägt:

Records sind pro Item geordnet — Änderungen an einem einzelnen Item erscheinen in der Reihenfolge, in der sie geschrieben wurden — und der Stream ist entlang derselben Partitionsstruktur wie die Tabelle gesharded. Die Aufbewahrung beträgt 24 Stunden — Streams ist ein Reaktionspuffer, keine permanente History. Für durable History speicherst du die Events selbst (was genau das ist, was unsere Audit-Log-Tabelle bereits ist).

Der native Consumer ist ein Lambda-Trigger: DynamoDB ruft deine Funktion mit einem Batch neuer Stream-Records auf, sobald sie eintreffen.

Ein durchgearbeitetes Beispiel: Alarm bei sensiblen Audit-Events

Die Audit-Log-Tabelle bekommt einen Stream mit NEW_IMAGE, sodass jeder Record das volle neue Event trägt. Ein Lambda konsumiert den Batch und leitet nur die Records weiter, die zählen:

Die Funktion berührt die Tabelle nie — sie reagiert rein auf das, was der Stream ihr übergibt. Kein Polling, kein Scan, und der Alarm feuert innerhalb von Sekunden nach dem Write. Stream- Records sind pro Item geordnet, sodass aufeinanderfolgende Änderungen an demselben Event-Item in der Reihenfolge eintreffen, in der sie geschrieben wurden.

Das ist auch der Standardweg, um eine nachgelagerte Kopie zu pflegen: Ein Stream- Consumer kann jedes Event in OpenSearch für die Audit-Volltextsuche projizieren oder Zählungen aggregieren — alles abgeleitet aus demselben Change-Log.

In DynoTable umsetzen

Bevor du einen Stream-Consumer verdrahtest, musst du die genaue Form des Items kennen, das dein Lambda erhalten wird — welche Attribute existieren, wie verschachtelte Maps und Lists aussehen, was ein NEW_IMAGE-Record tatsächlich enthalten wird.

Um ein Beispiel-Item zwischen reinem JSON und der Attribute-Value-Form zu konvertieren, die ein Stream- Record verwendet, tut es der DynamoDB JSON Converter in deinem Browser. Und in DynoTable kannst du das volle Item inspizieren — einschließlich seiner DynamoDB-JSON-Form — sodass du den NEW_IMAGE-Record gegen echte Daten modellierst statt die Feld-Form zu raten.

Wenn du einen Consumer lokal testest, lass die Tabelle gegen DynamoDB Local laufen und inspiziere sie auf dieselbe Weise — siehe Verbindung zu DynamoDB Local herstellen.

Fallstricke und nächste Schritte

• 24 Stunden sind kein Backlog. Wenn dein Consumer einen Tag lang ausfällt, altern Records aus und sind weg. Streams ist für Near-Real-Time-Reaktion, nicht für durables Replay — bewahre die Events selbst für die History auf.
• Wähle den kleinsten StreamViewType, den du brauchst. NEW_AND_OLD_IMAGES verdoppelt die Payload; wenn du nur den Key brauchst, um das Item neu zu lesen, ist KEYS_ONLY günstiger.
• Die Ordnung ist pro Item, nicht pro Partition Key oder global. DynamoDB garantiert die Ordnung nur für aufeinanderfolgende Änderungen an demselben Item; es gibt keine Ordnungsgarantie über verschiedene Items hinweg, selbst innerhalb eines Partition Keys.
• TTL-Deletes tauchen als Stream-Records auf mit dem Systemattribut-Marker, was die Art ist, wie du ablaufende Items archivierst — siehe DynamoDB TTL.

Streams verwandelt das Audit-Log in eine Event-Quelle. Die nächste operative Sorge ist das entgegengesetzte Ende des Lebens eines Items — alte Events automatisch ablaufen zu lassen mit DynamoDB TTL.

Lade DynoTable herunter, um die genaue Item-Form zu inspizieren, die dein Stream- Consumer erhalten wird, bevor du eine Zeile Lambda-Code schreibst.