InternalServerError (HTTP 500)

TL;DR — DynamoDB 無法處理該請求；故障在伺服器端，而重試是文件中記載的應對方式——AWS 宣告這些錯誤在表的生命週期中是預期之內的，失敗的請求可以立即重試。唯一的微妙之處：一次_寫入_上的 500 是有歧義的（它可能成功了也可能失敗了），所以在盲目重新應用之前，先把項目讀回來或使用一個冪等模式。

這是什麼意思

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

與本板塊上的 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'}}
```
- 當冪等是硬性要求時，使用帶 ClientRequestToken 的 TransactWriteItems——在 token 視窗內的重複嘗試只計一次。
TransactWriteItems 上的一個 500 可以原樣安全重試——事務要麼提交了要麼沒有；token 會去重。
只在它持續時才上報——跨越數分鐘的持續 5xx 是一個服務問題：檢查 health dashboard，並用失敗響應中的 RequestId 開一個支援工單。

在一次有歧義的寫入之後，在重新執行你的任務之前先看看實際儲存的內容——DynoTable 桌面應用一眼顯示實時的項目狀態，而如果你在重新驅動一個批次，DynamoDB 定價計算器幫你估算重試流量的規模。

在 DynoTable 中重試之前

寫入 500 後，開啟 DynoTable 中的項目並讀取實時狀態，然後再重新驅動作業。暫存 (⌘S) 允許你在提交之前準備糾正性編輯並檢查差異 - 比盲目重播PutItem更安全。 Profile 切換 (⌘P) 會在出現故障的同一帳戶/區域上不斷重試。如果你要重播批次，請使用 pricing calculator 調整額外流量，並使用 item size calculator 檢查項目形狀。分鐘內持續 5xx 是一個 AWS 健康問題；保留失敗的 SDK 響應中的 RequestId 以獲取支援。

來源

Error handling with DynamoDB — InternalServerError（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。