Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Comportamiento de los reintentos

Cuando una solicitud a una persona Servicio de AWS falla debido a un error transitorio o a una limitación, el SDK puede volver a intentar la solicitud automáticamente. En esta página se explica cómo configurar los reintentos y cómo funcionan internamente.

Configurar los reintentos

Tú controlas qué estrategia de reintento usa el SDK y cuántas veces lo hace.

Elegir un modo de reintento

El modo de reintento determina cómo se comporta el SDK cuando se produce un error en una solicitud. Hay tres modos disponibles: estándar, adaptativo y heredado.

Modo estándar (predeterminado)

El modo estándar reintenta las solicitudes fallidas mediante un retraso exponencial con fluctuación. Utiliza demoras más cortas para los errores transitorios (como los tiempos de espera de la red) y demoras más largas para los errores de limitación (por ejemplo). ThrottlingException

El modo estándar incluye una cuota de reintentos, un depósito de fichas que deduce las fichas por cada reintento y las repone cuando las solicitudes se realizan correctamente. Cuando se agotan los tokens disponibles, el SDK devuelve el error sin volver a intentarlo, por lo que la aplicación falla rápidamente en lugar de esperar a que pasen los reintentos que probablemente no tengan éxito. Esto también ayuda a que las interrupciones del servicio se resuelvan más rápido al reducir el tráfico de reintentos. Durante el funcionamiento normal, la cuota permanece llena y no tiene ningún efecto. La cuota de reintentos nunca retrasa ni bloquea la solicitud inicial. Solo se ven afectados los reintentos. Para obtener más información, consulte Cuota de reintentos (depósito de fichas).

Utilice el modo estándar a menos que tenga un motivo específico para elegir otro modo.

Modo adaptativo

El modo adaptativo incluye todo lo que hay en el modo estándar, además de un limitador de velocidad del lado del cliente. El limitador de velocidad rastrea las respuestas que limitan la velocidad y ajusta la velocidad a la que el SDK envía las solicitudes. A diferencia del modo estándar, el modo adaptativo puede retrasar o bloquear la solicitud inicial, no solo los reintentos, cuando se detecta una limitación.

El limitador de velocidad funciona por instancia de cliente del SDK. Todas las solicitudes de un cliente comparten el mismo límite de velocidad, independientemente de la operación de API o el recurso al que se dirijan.

Cuándo usar el modo adaptativo:

Cuándo no usar el modo adaptativo:

El modo adaptativo no se recomienda como opción predeterminada general.

Modo heredado

El modo heredado es el comportamiento de reintento que utilizaba cada SDK antes de que se introdujera el modo estándar. No incluye una cuota de reintentos estandarizada. Algunos SDK (como Java) tenían sus propias implementaciones de cuotas de reintentos en el modo antiguo, pero el comportamiento no es uniforme en todos los SDK. Sin una cuota estandarizada, un cliente continúa reintentándolo a toda velocidad durante las interrupciones del servicio. Esto bloquea los subprocesos y las conexiones de las solicitudes con pocas probabilidades de éxito, al tiempo que añade carga y puede retrasar la recuperación del servicio.

El modo heredado varía según los SDK. El recuento de reintentos, el tiempo de espera, los conjuntos de errores que se pueden volver a intentar y el comportamiento de limitación varían de un idioma a otro. El código que depende del comportamiento de reintento heredado puede comportarse de manera diferente cuando se mueve de un SDK a otro.

Disponible en: Java, Python, Ruby, PHP, C++ y CLI

No disponible en: .NET, Go, Kotlin, Rust, Swift, JavaScript

El modo Legacy existe por motivos de compatibilidad con versiones anteriores. Si actualmente usa el modo heredado, cambie al modo estándar.

Vuelva a intentar la configuración

La siguiente configuración controla el comportamiento de reintento. Puede configurarlos mediante variables de entorno, el archivo de configuración compartido (~/.aws/config) o la configuración del cliente en código.

Un valor máximo de intentos 3 significa que el SDK realiza una solicitud inicial y hasta dos reintentos. Establezca el número máximo de intentos 1 para deshabilitar los reintentos por completo.

Prioridad de configuración

Cuando especificas la misma configuración en varios lugares, el SDK resuelve el valor con la siguiente prioridad, de mayor a menor:

Esto sigue la prioridad de configuración estándar del AWS SDK. Un valor establecido en un nivel superior siempre anula un valor establecido en un nivel inferior. Por ejemplo, si lo configuras AWS_RETRY_MODE=adaptive como variable de entorno y retry_mode=standard en~/.aws/config, el SDK usa el modo adaptativo.

Language-specific configuración

La configuración entre SDK que se describe en esta página (retry_modeymax_attempts) funciona en todos los SDK. Sin embargo, la API para configurar los reintentos en el código varía según el idioma. Consulta la guía para desarrolladores de tu SDK para ver las opciones de configuración específicas para cada idioma, como las estrategias de espera personalizadas, los errores adicionales al volver a intentarlo y el ajuste de las cuotas de reintentos.

Cómo funcionan los reintentos

En esta sección, se describe cómo AWS los SDK gestionan las solicitudes fallidas: qué errores provocan los reintentos, cuánto tiempo espera el SDK entre intentos y cuándo deja de intentarlo.

Qué ocurre cuando se produce un error en una solicitud

Cuando realizas una llamada a la API a través de un AWS SDK, el SDK sigue esta secuencia:

El SDK repite este ciclo hasta que la solicitud se complete correctamente, se alcance el número máximo de intentos, se agote la cuota de reintentos o se produzca un error que no pueda volver a intentarlo. Todo el proceso es automático. Tu solicitud recibe una respuesta correcta o un error final.

¿Qué errores se vuelven a intentar

El SDK clasifica cada solicitud fallida en una de las tres categorías siguientes: transitoria, limitada o no reintentable. Esta clasificación determina si el SDK vuelve a intentar la solicitud y cuánto tiempo espera antes de volver a intentarlo.

La clasificación se basa en el código de error y el código de estado HTTP de la respuesta del servicio. Por ejemplo, un HTTP 400 con el código de error RequestTimeout se clasifica como transitorio y se vuelve a intentar. Un HTTP 400 con ValidationException se clasifica como no reintentable y se devuelve inmediatamente.

Clasificación de errores

Los errores transitorios se vuelven a intentar con un retraso base breve (50 ms):

Los errores de limitación se vuelven a intentar con un retraso base mayor (1000 ms):

Non-retryable los errores (comoAccessDeniedException,ValidationException,ResourceNotFoundException) se devuelven a tu código inmediatamente.

Los errores de limitación significan que el servicio ha rechazado activamente tu solicitud debido a los límites de velocidad, por lo que el SDK espera más tiempo antes de volver a intentar darle tiempo al servicio para que recupere su capacidad. Consulta los retrasos específicos¿Cuánto tiempo espera el SDK.

¿Cuánto tiempo espera el SDK

El SDK utiliza un retroceso exponencial con una fluctuación total. De media, cada reintento espera más tiempo que el anterior, y se distribuye de forma aleatoria las solicitudes de varios clientes.

Base los retrasos por tipo de error

El retraso base depende de si el error es transitorio o limitante:

Fórmula Backoff

El SDK calcula cada retraso de reintento con esta fórmula:

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

Donde:

El límite máximo de retroceso es de 20 segundos. Ningún retraso individual supera los 20 segundos, independientemente del número de intentos que se hayan realizado.

Ejemplos resueltos

Ejemplo 1: error transitorio, 3 intentos como máximo

La latencia total agregada promedia unos 75 ms en ambos reintentos.

Ejemplo 2: error de limitación, 3 intentos como máximo

La latencia total agregada promedia alrededor de 1500 ms en ambos reintentos.

Ejemplo 3: error transitorio que alcanzó el límite de retroceso

Con un retraso base de 50 ms, el retraso calculado antes de la limitación sería:

El límite se aplica en el décimo intento (undécimo intento) para los errores transitorios. En el caso de los errores de limitación con una base de 1000 ms, el límite entra en vigor en el sexto intento.

Por qué es importante la fluctuación

El multiplicador aleatorio se denomina fluctuación completa. Sin él, todos los clientes que produzcan un error al mismo tiempo volverían a intentarlo al mismo tiempo, lo que generaría una ráfaga de tráfico de reintentos (el problema del «rebaño atronador»). Full Jitter distribuye los reintentos de manera uniforme durante todo el período de espera, de modo que el servicio recibe un flujo constante de solicitudes en lugar de picos sincronizados.

Por ejemplo, supongamos que 1000 clientes reciben todos un 503 al mismo tiempo. Full Jitter distribuye sus primeros reintentos de manera uniforme en un intervalo de 50 ms, en lugar de tener los 1000 reintentos exactamente a los 50 ms.

Server-directed temporización de reintentos

Algunas Servicios de AWS incluyen un x-amz-retry-after encabezado en las respuestas de error. El valor del encabezado es un retraso en milisegundos. Cuando este encabezado está presente, el SDK usa el retraso especificado por el servidor, fijado a un mínimo del retraso de retroceso calculado y a un máximo del retraso de retroceso calculado más 5000 ms. Dado que el retraso calculado en sí mismo tiene un límite de 20 segundos, el retraso máximo efectivo dirigido por el servidor es de 25 segundos. El SDK no aplica fluctuación a este valor porque se espera que el servicio lo altere. Esto permite que el servicio se comunique exactamente cuando espera tener capacidad disponible.

Cuota de reintentos (depósito de fichas)

El SDK mantiene un presupuesto interno de tokens que monitorea la proporción entre solicitudes exitosas y solicitudes fallidas. Cuando los errores son generalizados, el presupuesto se agota y el SDK devuelve los errores directamente. La aplicación falla rápidamente en lugar de esperar a reintentos que probablemente no tengan éxito. Esto también reduce el tráfico de reintentos, lo que ayuda a que las interrupciones del servicio se resuelvan más rápido.

Cómo funciona la cuota de reintentos

El presupuesto simbólico empieza lleno. Cada reintento deduce los tokens. Cuando un reintento se realiza correctamente, el SDK restaura los tokens consumidos por ese reintento. Cuando una solicitud se realiza correctamente en el primer intento (no es necesario volver a intentarlo), el SDK restaura 1 token. Cuando el presupuesto llega a cero, el SDK deja de reintentarlo y devuelve los errores directamente a tu código.

El mayor costo de los reintentos transitorios refleja su diferente patrón de fracaso. Los errores transitorios, como los 500, y las fallas de conexión suelen indicar un problema que afecta a todo el servicio. En estas situaciones, es poco probable que los reintentos continuos tengan éxito. Añade latencia a las llamadas, reduce los recursos de los clientes y puede retrasar la recuperación para todos. Los errores de limitación indican que el servicio necesita más tiempo antes de que la solicitud pueda realizarse correctamente. El SDK espera más tiempo entre los reintentos para aumentar las probabilidades de éxito.

¿Cuándo bloquea la cuota los reintentos

La cuota de reintentos registra los tokens en todo momento, pero solo bloquea los reintentos cuando se agota el presupuesto. Durante el funcionamiento normal, casi todas las solicitudes se realizan correctamente y el presupuesto permanece lleno. La cuota no tiene ningún efecto observable en los reintentos.

Un reintento exitoso solo restaura el costo de su propio token (14 o 5 tokens), no el costo de los reintentos fallidos anteriores en la misma solicitud. Por ejemplo, si el primer reintento falla y el segundo tiene éxito, el presupuesto pierde 14 fichas netas. El presupuesto se agota más rápido cuando los reintentos agotan todos los intentos sin éxito, pero también se agota gradualmente cuando las solicitudes necesitan varios reintentos antes de tener éxito.

Con el valor predeterminado de 3 intentos como máximo, la cuota comienza a agotarse cuando más de aproximadamente el 22% de las solicitudes dan lugar a errores transitorios sostenidos, o más de aproximadamente el 32% a errores de limitación. Por debajo de estas tasas, las solicitudes exitosas reponen el presupuesto más rápido de lo que los reintentos fallidos lo agotan.

El saldo inicial del presupuesto, de 500 fichas, proporciona un amortiguador que absorbe las ráfagas breves de errores. Un breve aumento de los errores, incluso si es grave, no bloquea los reintentos, a menos que se prolongue lo suficiente como para agotar el búfer.

Implicaciones prácticas

Service-specific comportamiento

DynamoDB

Los clientes de DynamoDB utilizan valores predeterminados ajustados y optimizados para el perfil de baja latencia de DynamoDB:

Estos valores predeterminados se aplican tanto a Amazon DynamoDB como a DynamoDB Streams.

Long-polling operaciones

Algunas AWS operaciones utilizan sondeos prolongados. Pueden mantener una conexión abierta esperando a que llegue el trabajo. Estas operaciones reciben un tratamiento especial al volver a intentarlo:

Comportamiento especial: cuando se agota la cuota de reintentos y se bloquean los reintentos (paso 7 de la sección 7Qué ocurre cuando se produce un error en una solicitud), el SDK sigue retrasando el proceso antes de devolver el error al código.

Esto es importante porque las operaciones de sondeo prolongadas suelen ejecutarse en un bucle cerrado. Tu código llamaReceiveMessage, procesa los mensajes y ReceiveMessage vuelve a llamar inmediatamente. Sin el aplazamiento forzoso, un presupuesto de tokens agotado haría que el SDK devolviera errores sin demora. De este modo, el bucle de sondeo enviaría inmediatamente la siguiente solicitud, lo que aumentaría el uso de la CPU del cliente y generaría tráfico adicional. El retraso forzoso interrumpe este ciclo, lo que permite que el uso de los recursos del cliente y la tasa de sondeo sean manejables durante los fallos.

Soporte de AWS SDK y herramientas

En la tabla siguiente se muestra la disponibilidad del comportamiento de reintento actualizado en cada SDK. Para SDK-specific obtener más información, como la versión mínima, los valores predeterminados de antes y después y los ejemplos de código, consulta el tema del seguimiento. GitHub