InternalServerError (HTTP 500)

TL;DR — DynamoDB konnte den Request nicht verarbeiten; der Fehler liegt auf Service-Seite, und die dokumentierte Reaktion ist ein Retry — laut AWS sind solche Fehler über die Lebensdauer einer Tabelle zu erwarten, und gescheiterte Requests dürfen sofort wiederholt werden. Die eine Feinheit: Ein 500 bei einem Write ist mehrdeutig (er kann erfolgreich gewesen sein oder nicht), lies das Item also zurück oder nutze ein idempotentes Muster, bevor du ihn blind erneut anwendest.

Was es bedeutet

InternalServerError: The server encountered an internal error trying to
fulfill the request.
HTTP 500 — retryable service-side Exception (Programming.Errors)

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

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.
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.
Ein 500 bei TransactWriteItems ist unverändert sicher zu wiederholen — die Transaktion wurde entweder committet oder nicht; das Token dedupliziert.
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.

Vor dem Retry in DynoTable

Nachdem a 500 on a write, open the item in DynoTable and read the live state bevor du re-drive the job. Staging (⌘S) lässt dich einen korrigierenden Edit vorbereiten und den Diff vor dem Commit reviewen — sicherer als blind PutItem zu replayen. Profilwechsel (⌘P) hält Retries auf demselben Account/region that saw the fault.

Wenn you are replaying a batch, size the extra traffic with the Pricing-Rechner and check item shape with the Item-Size-Rechner. Persistent 5xx across minutes is an AWS Health issue; keep the RequestId from the failing SDK responses for support.

Quellen

Error handling with DynamoDB — InternalServerError (verifiziert 2026-07-13)

Referenzen

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