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 se Servicio de AWS produce un error en una solicitud debido a un error transitorio o a una limitación, el SDK puede volver a intentarlo automáticamente. En esta página, se explica cómo configurar los reintentos y cómo funcionan internamente.

Configuración de reintentos

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

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 tradicional.

Modo estándar (predeterminado)

El modo estándar reintenta las solicitudes fallidas mediante un retraso exponencial con fluctuación de fase. Utiliza retrasos más cortos para los errores transitorios (como los tiempos de espera de la red) y más largos 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 reabastece cuando las solicitudes se aceptan. 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 se repitan los intentos, que es poco probable que se realicen correctamente. 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 completa 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 (grupo 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 en el lado del cliente. El limitador de velocidad rastrea las respuestas de limitación 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 o el recurso de la API a los que se dirijan.

Cuándo usar el modo adaptativo:

Cuándo no usar el modo adaptativo:

No se recomienda el modo adaptativo como predeterminado general.

Modo heredado

El modo heredado es el comportamiento de reintento que utilizaba cada SDK antes de la introducción del 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 tradicional, pero el comportamiento no es uniforme en todos los SDK. Sin una cuota estandarizada, el cliente sigue reintentándolo a toda velocidad durante las interrupciones del servicio. Esto bloquea los hilos y las conexiones de las solicitudes con pocas probabilidades de éxito y, al mismo tiempo, añade una carga que puede retrasar la recuperación del servicio.

El modo heredado varía según los SDK. El número 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 tradicional puede comportarse de forma diferente cuando se mueve de un SDK a otro.

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

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

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

Vuelva a intentar la configuración

Los siguientes ajustes controlan el comportamiento de los reintentos. 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. Establece el número máximo de intentos 1 para deshabilitar por completo los reintentos.

Prioridad de configuración

Al especificar 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 estableces AWS_RETRY_MODE=adaptive como variable de entorno y dentro~/.aws/config, retry_mode=standard el SDK usa el modo adaptativo.

Language-specific configuración

La configuración de varios 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 del SDK para conocer las opciones de configuración específicas del idioma, como las estrategias de reducción personalizadas, los errores adicionales que se pueden volver a intentar y el ajuste de la cuota de reintentos.

Cómo funcionan los reintentos

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

¿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 realice correctamente, se alcance el número máximo de intentos, se agote la cuota de reintentos o se produzca un error que no se pueda volver a intentar. Todo el proceso es automático. Su solicitud ve una respuesta correcta o un error final.

¿Qué errores se vuelven a intentar?

El SDK clasifica cada solicitud fallida en una de estas tres categorías: 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 corto (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 al 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 la capacidad. Consulta los retrasos ¿Cuánto tiempo espera el SDK específicos.

¿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 la distribución aleatoria permite distribuir las solicitudes de varios clientes.

Retrasos básicos por tipo de error

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

Fórmula de retroceso

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

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

Donde:

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

Ejemplos resueltos

Ejemplo 1: error transitorio, máximo 3 intentos

La latencia total agregada tiene un promedio de 75 ms en ambos reintentos.

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

La latencia total agregada tiene un promedio de unos 1500 ms en ambos reintentos.

Ejemplo 3: Error transitorio, al alcanzar el límite de espera

Con un retraso base de 50 ms, el retraso calculado antes del límite sería:

El límite entra en vigor al décimo reintento (undécimo intento) en el caso de errores transitorios. En el caso de los errores de aceleración con una base de 1000 ms, el límite entra en vigor al 6º reintento.

¿Por qué es importante la fluctuación

El multiplicador aleatorio se denomina fluctuación total. Sin él, todos los clientes que detecten 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 de la «manada a rabiar»). La fluctuación total distribuye los reintentos de manera uniforme en toda la ventana 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 un 503 al mismo tiempo. La fluctuación total distribuye sus primeros reintentos de manera uniforme en una ventana de 50 ms, en lugar de hacer que los 1000 reintentos se realicen exactamente a 50 ms.

Server-directed Tiempo de reintento

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 utiliza el retraso especificado por el servidor, limitado 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 retardo calculado tiene un límite de 20 segundos, el retardo máximo efectivo dirigido por el servidor es de 25 segundos. El SDK no aplica una fluctuación de fase a este valor, ya que se espera que el servicio la altere. Esto permite que el servicio se comunique exactamente cuando espera tener capacidad disponible.

Cuota de reintentos (grupo de fichas)

El SDK mantiene un presupuesto interno de fichas que registra la proporción de solicitudes aprobadas y rechazadas. 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 que se repitan los intentos, que es poco probable que se realicen correctamente. 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 comienza completo. Cada reintento deduce los tokens. Cuando un reintento se realiza correctamente, el SDK restaura los tokens consumidos en 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 volver a intentarlo y devuelve los errores directamente al código.

El mayor coste de los reintentos transitorios refleja su diferente patrón de fallos. Los errores transitorios, como los 500, y los fallos de conexión suelen indicar un problema en todo el servicio. En estas situaciones, es poco probable que los reintentos continuos tengan éxito. Añade latencia a las llamadas, agota 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 aceptarse. El SDK espera más tiempo entre reintentos para aumentar las probabilidades de éxito.

¿Cuándo se vuelve a intentar el bloque de cuotas

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

Un reintento exitoso solo restaura su propio coste simbólico (14 o 5 fichas), no el coste 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 reintentos múltiples 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 se traducen en errores transitorios sostenidos, o más de aproximadamente el 32% en el caso de errores de limitación. Por debajo de estas tasas, las solicitudes correctas reponen el presupuesto más rápido que los reintentos fallidos lo agotan.

El saldo inicial del presupuesto, de 500 fichas, proporciona un amortiguador que absorbe las pequeñas ráfagas de errores. Un breve aumento de errores, aunque sea grave, no bloquea los reintentos a menos que persista 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 para volver a intentarlo:

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

Esto es importante porque las operaciones de sondeos prolongados suelen tener lugar en un bucle cerrado. El código llamaReceiveMessage, procesa cualquier mensaje y ReceiveMessage vuelve a llamar inmediatamente. Sin el retraso forzoso, si se agotara el presupuesto de fichas, el SDK generaría errores sin demora. Tu ciclo 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 retardo de espera forzado rompe este ciclo, lo que permite gestionar el uso de los recursos del cliente y la frecuencia de sondeo durante los fallos.

Support de AWS SDK y herramientas

En la siguiente tabla, 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 del antes y el después y ejemplos de código, consulta el tema de seguimiento. GitHub