Este documento indica que el uso de aws sdk le brinda una funcionalidad de reintento lista para usar.

Entonces este documento dice

 // The maximum number of times that a request will be retried for failures. // Defaults to -1, which defers the max retry setting to the service // specific configuration. MaxRetries *int

lo que me dice que la configuración lógica de reintento ocurre en el nivel de servicio.

Si este es el caso, espero que los servicios individuales documenten su configuración lógica de reintento. No solo no es el caso en realidad, sino que varios (acciones de) servicios parecen implicar que no proporcionan lógica de reintento y, en cambio, analizan cómo se podría implementar esto a nivel de aplicación. Ver por ejemplo dynamodb :

Si DynamoDB devuelve elementos sin procesar, debe volver a intentar la operación por lotes en esos elementos. Sin embargo, le recomendamos encarecidamente que utilice un algoritmo de retroceso exponencial. Si vuelve a intentar la operación por lotes de inmediato, las solicitudes de lectura o escritura subyacentes aún pueden fallar debido a la limitación en las tablas individuales. Si retrasa la operación por lotes mediante el retroceso exponencial, es mucho más probable que las solicitudes individuales del lote tengan éxito.

y cuadrados :

El ID de intento de solicitud de recepción es el token que se utiliza para la eliminación de datos duplicados de las llamadas de ReceiveMessage.

Durante una interrupción prolongada de la red que provoca problemas de conectividad entre su SDK y Amazon SQS, se recomienda proporcionar el ID de intento de solicitud de recepción y volver a intentarlo con el mismo ID de intento de solicitud de recepción si la operación del SDK falla.

Mi pregunta es ¿cómo sé cuándo un servicio está manejando la lógica de reintento y cuándo tengo que implementarlo a nivel de aplicación?