Hat DynamoDB Trigger?

Ja. DynamoDB-Trigger bestehen aus DynamoDB Streams plus AWS Lambda: Der Stream erfasst jede Änderung auf Item-Ebene, und eine Lambda-Funktion, die den Stream abonniert hat, läuft daraufhin automatisch. Ein CREATE-TRIGGER-Statement gibt es nicht — der Trigger-Code lebt in Lambda, außerhalb der Datenbank.

Wie ein Trigger funktioniert

Du aktivierst DynamoDB Streams auf der Tabelle und verknüpfst dann die ARN des Streams mit einer Lambda-Funktion. Jedes Anlegen, Ändern und Löschen wird als Stream-Record erfasst; der Lambda-Dienst pollt den Stream viermal pro Sekunde und ruft deine Funktion synchron mit Batches neuer Records auf. Du kannst Events außerdem filtern, damit die Funktion nur für die Änderungen läuft, die dich interessieren.

Was die Funktion tatsächlich bekommt

Wir haben einen Stream mit StreamViewType: NEW_AND_OLD_IMAGES aktiviert, eine Bestellung geschrieben, ihren Status geändert, sie gelöscht und dann den Shard mit GetRecords zurückgelesen. Drei Records kamen heraus: INSERT, MODIFY, REMOVE. Hier ist der mittlere, wortgetreu:

{
  "eventID": "77dabd57-20e1-4827-83e9-0fa20153adb0",
  "eventName": "MODIFY",
  "eventVersion": "1.1",
  "eventSource": "aws:dynamodb",
  "awsRegion": "ddblocal",
  "dynamodb": {
    "ApproximateCreationDateTime": 1785266820,
    "Keys": {"pk": {"S": "ORDER#1"}},
    "NewImage": {
      "total": {"N": "42"},
      "pk": {"S": "ORDER#1"},
      "status": {"S": "SHIPPED"}
    },
    "OldImage": {
      "total": {"N": "42"},
      "pk": {"S": "ORDER#1"},
      "status": {"S": "PENDING"}
    },
    "SequenceNumber": "000000000000000019180",
    "SizeBytes": 67,
    "StreamViewType": "NEW_AND_OLD_IMAGES"
  }
}

Beide Images stecken im Record. PENDING zu SHIPPED lässt sich innerhalb der Funktion beantworten, ohne Rückfrage an die Tabelle. Ein GetItem in einem Trigger kostet einen Read und läuft gegen den nächsten Write — es kann dir also einen dritten Zustand liefern, den keines der beiden Images beschreibt.

Der View-Typ wird beim Aktivieren des Streams festgelegt, und bereits geschriebene Records tragen nur das, was er verlangt hat. Wähle KEYS_ONLY oder NEW_IMAGE, und es gibt später kein OldImage, gegen das du diffen könntest.

Lambda übergibt deiner Funktion genau diese Records in einem Records-Array und ergänzt ein eventSourceARN-Feld. Das awsRegion oben liest sich als ddblocal, weil dieser Lauf DynamoDB Local nutzte; gegen den Dienst steht dort die Region.

Wofür Trigger verwendet werden

Klassische Einsätze sind unter anderem Benachrichtigungen schicken, wenn sich ein Wert ändert, Workflows anstoßen, Aggregate und Zähler pflegen und jede Änderung in dauerhaften Speicher (etwa S3) kopieren, um einen permanenten Audit Trail zu haben. Wirft die Funktion einen Fehler, wiederholt Lambda den Batch, bis er gelingt oder die Records verfallen — mit konfigurierbarem Retry- und Batching-Verhalten.

Limits, die du kennen solltest

AWS empfiehlt, höchstens zwei Lambda-Funktionen an einen Stream zu hängen — mehr können Read-Drosselung verursachen. Trigger-Funktionen sollten kurzlebig sein; für schwere Verarbeitung übergibst du an einen asynchronen Workflow, statt lange Logik inline laufen zu lassen.

Tiefer einsteigen

Beginne mit dem Leitfaden zu DynamoDB Streams für das Stream-Modell selbst, nutze den Expression Builder, um die Writes zu bauen, auf die deine Trigger reagieren, und lade DynoTable herunter, um die Item-Änderungen zu beobachten, die deinen Stream speisen.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Der Stream-Record wurde am 2026-07-28 gegen DynamoDB Local 3.3.0 mit @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 aufgezeichnet und ist bis auf die Einrückung unverändert wiedergegeben.