InternalServerError (HTTP 500)

TL;DR — DynamoDB konnte die Anfrage nicht verarbeiten; der Fehler liegt auf der Serverseite, und Wiederholen ist die dokumentierte Reaktion — AWS stellt fest, dass diese Fehler während der Lebensdauer einer Tabelle zu erwarten sind und fehlgeschlagene Anfragen sofort wiederholt werden können. Die eine Feinheit: ein 500 bei einem Write ist mehrdeutig (er kann erfolgreich gewesen oder fehlgeschlagen sein), lies das Item also zurück oder verwende ein idempotentes Muster, bevor du es blind erneut anwendest.

Was es bedeutet

InternalServerError: The server encountered an internal error trying to
fulfill the request.

Anders als die 400er-Fehler in diesem Hub bedeutet ein 5xx nicht, dass deine Anfrage falsch war — es bedeutet, dass DynamoDB beim Verarbeiten auf einen internen Fehler gestoßen ist. Der verwandte ServiceUnavailable (HTTP 503) signalisiert ein temporäres Verfügbarkeitsproblem und ist ebenfalls wiederholbar. Die AWS SDKs wiederholen beide bereits automatisch mit exponentiellem Backoff, sodass du einen 500 typischerweise erst siehst, nachdem die Retries des SDK erschöpft waren.

Warum es passiert

• Transiente serverseitige Fehler — AWS dokumentiert, dass gelegentliche interne Fehler während der Lebensdauer einer Tabelle zu erwarten sind; sie werden nicht durch die Form deiner Anfrage verursacht.
• Ein echtes Service-Ereignis — wenn 5xx-Antworten über Retries hinweg bestehen bleiben, prüfe das AWS Health Dashboard auf ein Betriebsproblem in deiner Region.

So behebst du es

1. Wiederhole mit exponentiellem Backoff — oder lass es einfach das SDK tun; jedes AWS SDK wiederholt 5xx-Antworten automatisch. Erst nach anhaltendem Fehlschlag solltest du es als Vorfall behandeln.
2. Behandle die Write-Mehrdeutigkeit — ein 500 bei PutItem/UpdateItem/DeleteItem könnte angewendet worden sein. Die dokumentierten Optionen:

   • lies den Zustand des Items vor dem Wiederholen, und/oder

   • schütze den Retry mit einer Condition-Expression, sodass er korrekt bleibt, egal ob der erste Versuch angekommen ist, z. B. eine Versionsprüfung:

     ConditionExpression: 'version = :expected',
     ExpressionAttributeValues: {':expected': {'N': '7'}}

   • verwende TransactWriteItems mit einem ClientRequestToken, wenn Idempotenz eine harte Anforderung ist — doppelte Versuche innerhalb des Token-Fensters zählen einmal.

3. Ein 500 bei TransactWriteItems ist unverändert sicher zu wiederholen — die Transaktion wurde entweder committet oder nicht; das Token dedupliziert.
4. Eskaliere nur, wenn es anhält — anhaltende 5xx über Minuten sind ein Service-Problem: prüfe das Health Dashboard und öffne einen Support-Fall mit der RequestId aus den fehlschlagenden Antworten.

Sieh dir nach einem mehrdeutigen Write an, was tatsächlich gespeichert ist, bevor du deinen Job erneut ausführst — die DynoTable Desktop-App zeigt den Live-Zustand des Items auf einen Blick, und der DynamoDB Pricing-Rechner hilft, den Retry-Traffic zu dimensionieren, wenn du einen Batch erneut abarbeitest.

Verwandte Fehler

• ThrottlingException — der wiederholbare 400, der ähnlich aussieht, aber eine Kapazitätsursache hat.
• TransactionInProgressException — Retry-Timing bei Transaktionen.
• Learn: DynamoDB-Konsistenz

References

• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• TransactWriteItems (ClientRequestToken idempotency) — Amazon DynamoDB API Reference
• Query (InternalServerError, HTTP 500) — Amazon DynamoDB API Reference

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