InternalServerError (HTTP 500)

TL;DR — DynamoDB はリクエストを処理できませんでした。障害はサービス側にあり、再試行がドキュメント化された対応です。AWS は、これらのエラーはテーブルのライフタイム中に想定されるもので、失敗したリクエストは即座に再試行できると述べています。1つの微妙な点: 書き込み での 500 は曖昧です（成功したかもしれないし失敗したかもしれない）。そのため、やみくもに再適用する前に、アイテムを読み戻すか冪等なパターンを使ってください。

意味

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

このハブの 400 系エラーとは異なり、5xx はリクエストが誤っていたことを意味しません。DynamoDB がそれを処理する際に内部障害に遭遇したことを意味します。関連する ServiceUnavailable（HTTP 503）は一時的な可用性の問題を示し、同様に再試行可能です。AWS SDK はすでに両方を指数バックオフで自動的に再試行するため、通常は SDK のリトライが尽きた後にのみ 500 が現れます。

発生する理由

一時的なサービス側の障害 — AWS は、時折の内部エラーがテーブルのライフタイム中に想定されるとドキュメント化しています。リクエストの形状によって引き起こされるものではありません。
本物のサービスイベント — 5xx レスポンスがリトライをまたいで続く場合は、AWS Health Dashboard でリージョンの運用上の問題を確認してください。

修正方法

指数バックオフで再試行します — または単に SDK に任せます。すべての AWS SDK は 5xx レスポンスを自動的に再試行します。恒常的な失敗の後にのみ、インシデントとして扱うべきです。
書き込みの曖昧さを処理します — PutItem/UpdateItem/DeleteItem での 500 は適用されている可能性があります。ドキュメント化された選択肢:
- 再試行する前に アイテムの状態を読み取る、および/または
- 条件式でリトライをガードする — 最初の試行が到達したかどうかに関わらず正しく保たれるように。例: バージョンチェック:
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- 冪等性が厳格な要件のとき TransactWriteItems を ClientRequestToken とともに使う — トークンウィンドウ内の重複試行は1回として数えられます。
TransactWriteItems での 500 はそのまま再試行しても安全です — トランザクションはコミットされたかされなかったかのどちらかで、トークンが重複を排除します。
続く場合にのみエスカレートします — 数分にわたって続く 5xx はサービスの問題です。Health Dashboard を確認し、失敗したレスポンスの RequestId でサポートケースを開きます。

曖昧な書き込みの後、ジョブを再実行する前に実際に格納されているものを見ましょう。DynoTable デスクトップアプリはライブのアイテム状態を一目で表示し、DynamoDB 料金計算ツールはバッチを再駆動する場合のリトライトラフィックのサイズ設定に役立ちます。

References

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

InternalServerError (HTTP 500)

意味

発生する理由

修正方法

関連するエラー

References