AWS torna padrão o novo comportamento de retry em todos os SDKs

O que mudou

A AWS tornou padrão, a partir de 10 de novembro de 2026, o comportamento de retry que vinha sendo testado como opt-in desde maio de 2026 (flag AWS_NEW_RETRIES_2026). A mudança afeta os modos standard e adaptive de retry em praticamente todos os AWS SDKs, no AWS CLI e no AWS Tools for PowerShell, e também torna standard o modo padrão em SDKs que antes usavam legacy (Python, Ruby, PHP e Swift).

Na prática, três coisas mudam:

• Backoff mais rápido: erros transitórios (reset de conexão, HTTP 500/502/503/504) agora usam delay-base de 50 ms, e erros de throttling usam 1.000 ms. Antes, cada SDK tinha seu próprio valor.
• Quota de retry mais cara: cada tentativa de retry por erro transitório agora consome 14 tokens da quota (antes eram 5 ou 10, dependendo do SDK), e cada retry de throttling consome 5. Isso faz a quota se esgotar mais cedo durante uma falha prolongada.
• DynamoDB com regras próprias: operações do Amazon DynamoDB e do DynamoDB Streams passam a usar delay-base de 25 ms e no máximo 4 tentativas; antes, alguns SDKs chegavam a permitir 12 tentativas.

Operações de long-polling, como ReceiveMessage do Amazon SQS, agora aplicam um delay de backoff antes de devolver erro quando a quota se esgota, em vez de falhar imediatamente.

Onde está disponível

Esse comportamento não é uma feature regional: é uma mudança de biblioteca cliente, aplicada no código que roda na sua máquina ou no seu container, não em um serviço gerenciado numa região específica. A fonte não menciona nenhuma restrição por região, o que significa que o novo retry vale igualmente em qualquer região, incluindo São Paulo (sa-east-1), porque o comportamento depende da versão do SDK instalada, não de onde a chamada é feita.

A disponibilidade varia por SDK e versão. Alguns exemplos da tabela publicada pela AWS:

Java 2.x e Kotlin ainda não têm data definida; no Kotlin dá para testar agora com 1.9.0 ou mais recente, usando opt-in manual.

Quanto custa

Não há cobrança associada: é uma mudança de comportamento de biblioteca cliente, não um serviço novo. O único "custo" é operacional, e aparece na seção seguinte: menos tentativas de retry em alguns cenários pode significar erro chegando mais cedo na sua aplicação.

Como começar

A AWS recomenda não simplesmente deixar o latest do seu gerenciador de pacotes puxar a nova versão em produção sem teste. O caminho sugerido:

1. Atualize para a versão listada na tabela (por exemplo, botocore>=1.44.0 ou aws-cli>=2.40.0) em um ambiente que não seja produção.
2. Rode sua carga de trabalho normalmente e observe taxa de erro, latência de retry e comportamento sob throttling.
3. Se seu workload dependia de um valor anterior, como um max_attempts mais alto, configure-o explicitamente, porque o SDK não preserva esse valor sozinho.
4. Remova a variável AWS_NEW_RETRIES_2026 do ambiente: a partir das versões listadas ela é simplesmente ignorada, então mantê-la não quebra nada, mas também não faz mais nada.

Para reverter total ou parcialmente, duas opções, dependendo do SDK:

# Opção 1: voltar ao modo legacy (nem todo SDK aceita)
export AWS_RETRY_MODE=legacy

# Opção 2: restaurar só o número de tentativas
export AWS_MAX_ATTEMPTS=5

Importante: em alguns SDKs, definir legacy causa erro ao carregar a configuração ou faz o profile inteiro ser ignorado (inclusive credenciais e região). Se várias ferramentas compartilham o mesmo ~/.aws/config, prefira setar o retry mode em código ou num profile exclusivo daquela aplicação.

O que muda para quem já usa

Para quem escreve pipelines de deploy e scripts de automação com AWS CLI ou SDK dentro de steps de CI/CD, essa é uma mudança silenciosa: um pip install -U boto3, npm update aws-sdk ou bump de dependência no go.mod já traz o novo comportamento, sem aviso em tempo de execução. Agentes de código que geram ou ajustam infraestrutura chamando SDKs programaticamente herdam o mesmo retry novo assim que a versão sobe, o que pode mudar a semântica de retries em scripts gerados anteriormente com suposições antigas.

O efeito prático depende de como seu projeto estava configurado antes:

• Sem configuração explícita de retry: você sente tudo de uma vez, incluindo a troca de legacy para standard nos SDKs que usavam o modo antigo (Python, Ruby, PHP, Swift).
• retry_mode já setado para standard ou adaptive: o modo continua o mesmo, mas o timing de backoff, o custo da quota e os defaults do DynamoDB mudam por baixo.
• max_attempts ou backoff customizados: esses valores específicos continuam valendo; só o que você não sobrescreveu muda.
• Já estava com AWS_NEW_RETRIES_2026=true: a maior parte do comportamento já era essa desde maio; só pequenas mudanças específicas de cada SDK, listadas na issue de tracking no GitHub, se somam agora.
• AWS_NEW_RETRIES_2026=false: depois do upgrade, essa flag passa a ser ignorada e o novo comportamento entra de qualquer forma.

O ponto de atenção real para deploy em produção é a quota de retry mais cara (14 tokens por retry transitório contra 5 ou 10 antes): em uma instabilidade prolongada, a aplicação para de tentar e devolve erro mais cedo, o que libera threads e conexões antes, mas também significa que um pico de 500 responses pode esgotar a quota de retry mais rápido do que seu workload está acostumado a ver.

Fonte: AWS Developer Tools Blog