Error de servidor interno (HTTP 500)

TL;DR — DynamoDB no pudo procesar la solicitud; la falla está en el lado del servicio y reintentar es la respuesta documentada: AWS indica que estos errores se esperan durante la vida útil de una tabla y las solicitudes fallidas se pueden reintentar inmediatamente. La única sutileza: un 500 en una escritura es ambiguo (puede haber tenido éxito o fallar), así que lea el elemento nuevamente o use un patrón idempotente antes de volver a aplicarlo a ciegas.

Qué significa

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

A diferencia de los errores de la serie 400 de este hub, un 5xx no significa que tu solicitud fuera incorrecta — significa que DynamoDB tuvo un fallo interno al manejarla. El error relacionado ServiceUnavailable (HTTP 503) señala un problema temporal de disponibilidad y es igualmente reintentable. Los AWS SDK ya reintentan ambos automáticamente con retroceso exponencial, así que normalmente solo verás aparecer un 500 después de que se agoten los reintentos del SDK.

Por qué ocurre

Fallos transitorios del lado del servicio — AWS documenta que los errores internos ocasionales son esperables durante la vida de una tabla; no los causa la forma de tu solicitud.
Un evento de servicio genuino — si las respuestas 5xx persisten entre reintentos, revisa el AWS Health Dashboard por si hay un problema operativo en tu región.

Cómo solucionarlo

Reintenta con retroceso exponencial — o simplemente deja que el SDK lo haga; todo AWS SDK reintenta las respuestas 5xx automáticamente. Solo tras un fallo persistente deberías tratarlo como un incidente.
Maneja la ambigüedad de escritura — un 500 en PutItem/UpdateItem/DeleteItem puede haberse aplicado. Las opciones documentadas:
- lee el estado del Item antes de reintentar, y/o
- protege el reintento con una expresión de condición para que siga siendo correcto tanto si el primer intento aterrizó como si no, p. ej. una comprobación de versión:
```
ConditionExpression: 'version = :expected',
ExpressionAttributeValues: {':expected': {'N': '7'}}
```
- usa TransactWriteItems con un ClientRequestToken cuando la idempotencia sea un requisito estricto — los intentos duplicados dentro de la ventana del token cuentan una vez.
Un 500 en TransactWriteItems es seguro de reintentar tal cual — la transacción o se confirmó o no; el token deduplica.
Escala solo cuando persista — un 5xx sostenido durante minutos es un problema del servicio: revisa el health dashboard y abre un caso de soporte con el RequestId de las respuestas fallidas.

Tras una escritura ambigua, mira lo que hay realmente almacenado antes de reejecutar tu trabajo — la app de escritorio DynoTable muestra el estado en vivo del Item de un vistazo, y la calculadora de precios de DynamoDB ayuda a dimensionar el tráfico de reintentos si estás reejecutando un lote.

Antes de reintentar en DynoTable

Tras un 500 en una escritura, abre el Item en DynoTable y lee el estado en vivo antes de reejecutar el trabajo. El staging (⌘S) te permite preparar una edición correctiva y revisar el diff antes de confirmarla — más seguro que repetir PutItem a ciegas. El cambio de perfil (⌘P) mantiene los reintentos en la misma cuenta/región que vio el fallo.

Si estás reejecutando un lote, dimensiona el tráfico extra con la calculadora de precios y comprueba la forma del Item con la calculadora de tamaño de Item. Un 5xx persistente durante minutos es un problema de AWS Health; guarda el RequestId de las respuestas fallidas del SDK para soporte.

Fuentes

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

Errores relacionados

ThrottlingException — el 400 reintentable que parece similar pero tiene una causa de capacidad.
TransactionInProgressException — temporización de reintentos en transacciones.
Aprende: Consistencia de DynamoDB

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.