As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Comportamento de repetição
**Importante**
O comportamento descrito nesta página exige a aceitação até que se torne o comportamento padrão. Defina `AWS_NEW_RETRIES_2026=true` em seu ambiente. Sem essa configuração, seu SDK usa o comportamento de repetição anterior a 2026, que difere no tempo de recuo, nos custos da cota de repetição e nos padrões específicos do serviço. Para obter detalhes, consulte a [postagem do blog do anúncio](https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/).
Quando uma solicitação para um AWS service (Serviço da AWS) falha devido a um erro transitório ou limitação, o SDK pode repetir a solicitação automaticamente. Esta página aborda como configurar novas tentativas e como elas funcionam internamente.
+ [Configurando novas tentativas](#configuring-retries): escolha um modo de repetição, defina o máximo de tentativas e entenda a precedência da configuração.
+ [Como funcionam as novas tentativas](#how-retries-work): repita o fluxo, a classificação de erros, a fórmula de recuo, a mecânica da cota de repetição e o comportamento específico do serviço.
## Configurando novas tentativas
Você controla qual estratégia de repetição o SDK usa e quantas vezes ele tenta novamente.
### Escolhendo um modo de repetição
O modo de nova tentativa determina como o SDK se comporta quando uma solicitação falha. Três modos estão disponíveis: **padrão**, **adaptável** e **legado**.
| | Standard | Adaptativo | Legada |
| --- | --- | --- | --- |
| Repetir a cota | Sim | Sim | Varia de acordo com o SDK |
| Pode atrasar a solicitação inicial | Não | Sim | Não |
| Error-type-specific recuar | Sim | Sim | Varia de acordo com o SDK |
| Padronizado em todos os SDKs | Sim | Sim | Não |
| Recomendação | Padrão para todas as cargas de trabalho | Single-resource, com muita limitação de pressão, tolerante à latência | Somente compatibilidade com versões anteriores |
#### Modo padrão (padrão)
O modo padrão repete solicitações com falha usando recuo exponencial com instabilidade. Ele usa atrasos menores para erros transitórios (como tempos limite de rede) e atrasos maiores para erros de limitação (como). `ThrottlingException`
O modo padrão inclui uma **cota de repetição**, um token bucket que deduz os tokens para cada nova tentativa e os reabastece quando as solicitações são bem-sucedidas. Quando os tokens disponíveis se esgotam, o SDK retorna o erro sem tentar novamente, então seu aplicativo falha rapidamente em vez de esperar por novas tentativas que provavelmente não serão bem-sucedidas. Isso também ajuda a resolver as interrupções do serviço com mais rapidez, reduzindo o tráfego de novas tentativas. Durante a operação normal, a cota permanece cheia e não tem efeito. A cota de repetição nunca atrasa ou bloqueia a solicitação inicial. Somente as novas tentativas são afetadas. Para obter detalhes, consulte [Repetir a cota (token bucket)](#retry-quota-token-bucket).
Use o modo padrão, a menos que você tenha um motivo específico para escolher outro modo.
#### Modo adaptativo
O modo adaptativo inclui tudo no modo padrão, além de um limitador de taxa **do lado do cliente**. O limitador de taxa rastreia as respostas de limitação e ajusta a taxa na qual o SDK envia solicitações. Diferentemente do modo padrão, o modo adaptativo pode atrasar ou bloquear a solicitação *inicial*, e não apenas novas tentativas, quando a limitação é detectada.
O limitador de taxa opera por instância do cliente SDK. Todas as solicitações de um cliente compartilham o mesmo limite de taxa, independentemente de qual operação de API ou recurso elas segmentam.
**Quando usar o modo adaptativo:**
+ Seu cliente tem como alvo um único recurso (por exemplo, uma tabela do DynamoDB) e você espera respostas frequentes de limitação. Isso é comum em fluxos de trabalho automatizados, processadores em lote ou cargas de trabalho de IA que chamam uma única operação de API em alto volume.
+ Você quer que o SDK fique automaticamente lento quando o serviço sinalizar limitação.
**Quando não usar o modo adaptativo:**
+ Seu cliente envia solicitações para vários recursos ou atende a vários inquilinos. A limitação de um recurso faz com que o limitador de taxa reduza a velocidade de todas as solicitações desse cliente, incluindo solicitações para recursos não afetados.
+ Você precisa de uma latência previsível na solicitação inicial.
O modo adaptativo não é recomendado como padrão geral.
#### Modo legado
O modo legado é o comportamento de repetição que cada SDK usou antes da introdução do modo padrão. Ela não inclui uma cota de repetição padronizada. Alguns SDKs (como Java) tinham suas próprias implementações de cota de repetição no modo legado, mas o comportamento não é consistente em todos os SDKs. Sem uma cota padronizada, o cliente continua tentando novamente com a taxa máxima durante interrupções no serviço. Isso vincula threads e conexões em solicitações que provavelmente não serão bem-sucedidas, ao mesmo tempo em que adiciona carga que pode atrasar a recuperação do serviço.
O modo legado varia entre os SDKs. A contagem de novas tentativas, o tempo de recuo, os conjuntos de erros que podem ser repetidos e o comportamento de limitação diferem entre os idiomas. O código que depende do comportamento de repetição legado pode se comportar de forma diferente quando movido entre SDKs.
**Disponível em:** Java, Python, Ruby, PHP, C\+\+, CLI
**Não disponível em:** .NET, Go, Kotlin, Rust, Swift, JavaScript
O modo legado existe para compatibilidade com versões anteriores. Se você usa atualmente o modo legado, alterne para o modo padrão.
### Tentar novamente as configurações
As configurações a seguir controlam o comportamento de repetição. Você pode defini-las por meio de [variáveis de ambiente](environment-variables.md), do [arquivo de configuração compartilhado](file-format.md) (`~/.aws/config`) ou da configuração do cliente no código.
| Configuração | O que ele controla | Variável de ambiente | Chave do arquivo de configuração | Padrão |
| --- | --- | --- | --- | --- |
| Modo de nova tentativa | Qual estratégia de repetição usar | AWS\_RETRY\_MODE | retry\_mode | standard |
| Máximo de tentativas | Total de tentativas, incluindo a solicitação inicial | AWS\_MAX\_ATTEMPTS | max\_attempts | 3(ver notas) |
Um valor máximo de tentativas `3` significa que o SDK faz uma solicitação inicial e até duas novas tentativas. Defina o máximo de tentativas `1` para desativar totalmente as novas tentativas.
**nota**
Os clientes do DynamoDB e do DynamoDB Streams usam como padrão o máximo de tentativas. `4` Esses serviços usam um atraso de recuo básico menor (25 ms em vez de 50 ms) para corresponder ao perfil de baixa latência. A tentativa adicional mantém o recuo máximo da última tentativa comparável a outros serviços. Você pode substituir isso com as mesmas configurações mostradas na tabela anterior.
### Precedência de configuração
Quando você especifica a mesma configuração em vários lugares, o SDK resolve o valor usando a seguinte precedência, da maior para a menor:
1. **Configuração explícita do cliente no código.** Um valor definido diretamente no cliente SDK ou em seu objeto de configuração.
1. **[Variável de ambiente](environment-variables.md).** Por exemplo, `AWS_RETRY_MODE` ou `AWS_MAX_ATTEMPTS`.
1. **Arquivo de [configuração compartilhado](file-format.md).** A `max_attempts` chave `retry_mode` ou`~/.aws/config`.
1. **SDK padrão.** O padrão incorporado para a configuração.
Isso segue a [precedência de configuração padrão do AWS SDK](settings-reference.md). Um valor definido em um nível superior sempre substitui um valor definido em um nível inferior. Por exemplo, se você definir `AWS_RETRY_MODE=adaptive` como variável de ambiente e `retry_mode=standard` em`~/.aws/config`, o SDK usa o modo adaptativo.
### Language-specific configuração
As configurações entre SDKs descritas nesta página (`retry_mode`e`max_attempts`) funcionam em todos os SDKs. No entanto, a API para configurar novas tentativas no código varia de acordo com o idioma. Consulte o guia do desenvolvedor do SDK para ver as opções de configuração específicas do idioma, como estratégias de recuo personalizadas, erros adicionais que podem ser tentados novamente e ajuste de cota de repetição.
## Como funcionam as novas tentativas
Esta seção descreve como AWS os SDKs lidam com solicitações com falha: quais erros acionam novas tentativas, quanto tempo o SDK espera entre as tentativas e quando ele para de tentar novamente.
### O que acontece quando uma solicitação falha
Quando você faz uma chamada de API por meio de um AWS SDK, o SDK segue esta sequência:
1. **Somente [no modo adaptativo](#adaptive-mode):** o SDK verifica o limitador de taxa do lado do cliente. Se a limitação for detectada, o SDK poderá atrasar ou bloquear a solicitação antes de enviá-la.
1. O SDK envia a solicitação para o AWS service (Serviço da AWS) endpoint.
1. Se o serviço retornar uma resposta bem-sucedida, o SDK retornará o resultado para seu código.
1. *Se a solicitação falhar, o SDK classifica o erro como *transitório*, *limitador* ou não passível de nova tentativa.* Consulte [Quais erros são repetidos](#which-errors-are-retried).
1. Se o erro não puder ser repetido, o SDK retornará o erro para seu código imediatamente. Nenhuma tentativa é tentada novamente.
1. Se o erro puder ser repetido, o SDK verificará se ele atingiu o número máximo de tentativas. Nesse caso, ele retornará o erro para o seu código.
1. O SDK verifica o. [Repetir a cota (token bucket)](#retry-quota-token-bucket) Se o orçamento do token estiver esgotado, o SDK não tentará novamente e retornará o erro para seu código. Exceção: pois[Long-polling operações](#long-polling-operations), o SDK ainda aplica um atraso antes de retornar o erro.
1. O SDK calcula um atraso de recuo com base no tipo de erro e no número da tentativa de repetição. Consulte [Quanto tempo o SDK espera?](#how-long-does-the-sdk-wait).
1. O SDK aguarda o atraso computado e, em seguida, envia a solicitação novamente a partir da etapa 2.
O SDK repete esse loop até que a solicitação seja bem-sucedida, o número máximo de tentativas seja atingido, a cota de repetição seja esgotada ou ocorra um erro que não pode ser repetido. Todo o processo é automático. Seu aplicativo vê uma resposta bem-sucedida ou um erro final.
### Quais erros são repetidos
O SDK classifica cada solicitação com falha em uma das três categorias: transitória, limitadora ou não passível de nova tentativa. Essa classificação determina se o SDK repete a solicitação e quanto tempo espera antes de tentar novamente.
A classificação é baseada no **código de erro** e no **código de status HTTP** na resposta do serviço. Por exemplo, um HTTP 400 com o código de erro `RequestTimeout` é classificado como transitório e repetido. Um HTTP 400 com `ValidationException` é classificado como não passível de nova tentativa e retornado imediatamente.
#### Classificação de erros
**Os erros transitórios** são repetidos com um pequeno atraso básico (50 ms):
| Código de erro |
| --- |
| RequestTimeout |
| RequestTimeoutException |
| InternalError |
| IDPCommunicationError |
| I/O Falha (redefinição da conexão, falha na resolução do DNS, tempo limite do soquete) |
| (qualquer HTTP 500, 502, 503 ou 504 sem um código de erro reconhecido) |
**Os erros de limitação** são repetidos com um atraso base maior (1.000 ms):
| Código de erro |
| --- |
| Throttling |
| ThrottlingException |
| ThrottledException |
| RequestThrottledException |
| TooManyRequestsException |
| ProvisionedThroughputExceededException |
| TransactionInProgressException |
| LimitExceededException |
| PriorRequestNotComplete |
| RequestThrottled |
| EC2ThrottledException |
| RequestLimitExceeded |
| SlowDown |
| BandwidthLimitExceeded |
**Non-retryable erros** (como`AccessDeniedException`,`ValidationException`,`ResourceNotFoundException`) são retornados ao seu código imediatamente.
**nota**
Um HTTP 5XX com um código de erro de limitação é classificado como um erro de limitação, não um erro transitório, embora os erros 5XX sejam normalmente transitórios. O SDK corresponde primeiro ao código de erro e depois volta ao código de status HTTP.
Erros de limitação significam que o serviço rejeitou ativamente sua solicitação devido aos limites de taxa, então o SDK espera mais tempo antes de tentar dar tempo ao serviço para recuperar a capacidade. Consulte [Quanto tempo o SDK espera?](#how-long-does-the-sdk-wait) os atrasos específicos.
### Quanto tempo o SDK espera?
O SDK usa **recuo exponencial com instabilidade** total. Em média, cada nova tentativa espera mais do que a anterior, com randomização para distribuir solicitações de vários clientes.
#### Atrasos básicos por tipo de erro
O atraso básico depende se o erro é transitório ou limitador:
| Tipo de erro | Atraso básico | Lógica |
| --- | --- | --- |
| Transiente (sem limitação de pressão) | 50 ms | Os erros transitórios geralmente são resolvidos em milissegundos. Um pequeno atraso básico proporciona uma recuperação rápida. |
| Controle de utilização | 1.000 ms | O serviço limitou a taxa de solicitação. Um atraso básico maior dá tempo para recuperar a capacidade. |
#### Fórmula de recuo
O SDK calcula cada atraso de repetição usando esta fórmula:
```
delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)
```
Em que:
+ `random(0, 1)`retorna um valor uniformemente distribuído entre 0 e 1
+ `base_delay`é de 50 ms para erros transitórios ou 1.000 ms para erros de limitação
+ `retry`começa em 0 para a primeira tentativa (a segunda tentativa geral de solicitação)
O limite máximo de recuo é de **20 segundos.** Nenhum atraso individual excede 20 segundos, independentemente de quantas tentativas tenham ocorrido.
#### Exemplos trabalhados
**Exemplo 1: erro transitório, máximo de 3 tentativas**
| Etapa | O que acontece | Delay |
| --- | --- | --- |
| Tentativa 1 | Solicitação inicial. O serviço retorna HTTP 503. | (none) |
| Tentativa 2 | O SDK espera aleatoriamente (0, 50 ms). A nova tentativa falha com 503. | 0—50 ms (média de \~25 ms) |
| Tentativa 3 | O SDK espera aleatoriamente (0, 100 ms). A nova tentativa foi bem-sucedida. | 0—100 ms (média de \~50 ms) |
A latência total adicionada é em média de cerca de 75 ms em ambas as tentativas.
**Exemplo 2: erro de limitação, máximo de 3 tentativas**
| Etapa | O que acontece | Delay |
| --- | --- | --- |
| Tentativa 1 | Solicitação inicial. O serviço retorna 429Throttling. | (none) |
| Tentativa 2 | O SDK espera aleatoriamente (0, 1.000 ms). Tentar novamente retorna 429. | 0—1.000 ms (média de \~500 ms) |
| Tentativa 3 | O SDK espera aleatoriamente (0, 2.000 ms). A nova tentativa foi bem-sucedida. | 0—2.000 ms (média de \~1.000 ms) |
A latência total adicionada é em média de cerca de 1.500 ms em ambas as tentativas.
**Exemplo 3: erro transitório, atingindo a tampa de recuo**
Com um atraso base de 50 ms, o atraso calculado antes do limite seria:
| Tentativa de novo | Atraso máximo calculado | Depois de 20 s de boné |
| --- | --- | --- |
| 1 | 50 ms | 50 ms |
| 2 | 100 ms | 100 ms |
| 5 | 800 ms | 800 ms |
| 9 | 12.800 ms | 12.800 ms |
| 10 | 25.600 ms | 20.000 ms |
O limite entra em vigor na 10ª tentativa (11ª tentativa) para erros transitórios. Para erros de limitação com uma base de 1.000 ms, o limite entra em vigor na 6ª tentativa.
**nota**
Com o padrão de 3 tentativas máximas (1 solicitação inicial \+ 2 tentativas), o limite de recuo nunca é atingido. Esta tabela ilustra o que acontece se você aumentar `max_attempts` muito além do padrão.
#### Por que a instabilidade é importante
O multiplicador aleatório é chamado de instabilidade *total*. Sem isso, todos os clientes que encontrassem um erro ao mesmo tempo tentariam novamente ao mesmo tempo, criando uma explosão de tráfego de repetições (o problema do “rebanho trovejante”). A instabilidade total distribui as novas tentativas uniformemente por toda a janela de recuo, para que o serviço receba um fluxo constante de solicitações em vez de picos sincronizados.
Por exemplo, suponha que 1.000 clientes recebam um 503 no mesmo momento. A instabilidade total distribui suas primeiras tentativas uniformemente em uma janela de 50 ms, em vez de ter todas as 1.000 repetições em exatamente 50 ms.
#### Server-directed tempo de repetição
Alguns Serviços da AWS incluem um `x-amz-retry-after` cabeçalho nas respostas de erro. O valor do cabeçalho é um atraso em milissegundos. Quando esse cabeçalho está presente, o SDK usa o atraso especificado pelo servidor, limitado ao mínimo do atraso de recuo computado e ao máximo do atraso de recuo computado mais 5.000 ms. Como o recuo computado em si é limitado a 20 segundos, o atraso máximo efetivo direcionado ao servidor é de 25 segundos. O SDK não aplica instabilidade a esse valor, pois espera-se que o serviço o altere. Isso permite que o serviço se comunique exatamente quando espera ter capacidade disponível.
### Repetir a cota (token bucket)
O SDK mantém um orçamento interno de tokens que rastreia a proporção entre solicitações bem-sucedidas e falhas. Quando as falhas são generalizadas, o orçamento se esgota e o SDK retorna os erros diretamente. Seu aplicativo falha rapidamente em vez de esperar por novas tentativas que provavelmente não serão bem-sucedidas. Isso também reduz o tráfego de novas tentativas, ajudando a resolver as interrupções do serviço com mais rapidez.
#### Como funciona a cota de repetição
O orçamento do token começa cheio. Cada tentativa de nova tentativa deduz tokens. Quando uma nova tentativa é bem-sucedida, o SDK restaura os tokens consumidos por essa nova tentativa. Quando uma solicitação é bem-sucedida na primeira tentativa (sem necessidade de novas tentativas), o SDK restaura 1 token. Quando o orçamento chega a zero, o SDK para de tentar novamente e retorna os erros diretamente para o seu código.
| Parâmetro | Valor |
| --- | --- |
| Capacidade orçamentária | 500 fichas |
| Custo por nova tentativa transitória (sem limitação) | 14 fichas |
| Custo por nova tentativa de limitação | 5 fichas |
| Tokens restaurados em caso de sucesso após nova tentativa | Quantidade consumida pela última tentativa (14 ou 5) |
| Tokens restaurados em caso de sucesso, sem nova tentativa | 1 ficha |
O custo mais alto das novas tentativas transitórias reflete seus diferentes padrões de falha. Erros transitórios como 500s e falhas de conexão geralmente indicam um problema em todo o serviço. Nessas situações, é improvável que a repetição contínua seja bem-sucedida. Isso adiciona latência às suas chamadas, consome recursos do cliente e pode atrasar a recuperação de todos. Erros de limitação indicam que o serviço precisa de mais tempo para que a solicitação seja bem-sucedida. O SDK espera mais tempo entre as novas tentativas para aumentar a probabilidade de sucesso.
#### Quando a cota bloqueia novas tentativas?
A cota de repetição rastreia os tokens o tempo todo, mas só bloqueia novas tentativas quando o orçamento está esgotado. Durante a operação normal, quase todas as solicitações são bem-sucedidas e o orçamento permanece cheio. A cota não tem efeito observável nas novas tentativas.
Uma nova tentativa bem-sucedida restaura somente seu próprio custo de token (14 ou 5 tokens), não o custo de tentativas anteriores malsucedidas na mesma solicitação. Por exemplo, se a primeira tentativa falhar e a segunda for bem-sucedida, o orçamento perderá 14 tokens líquidos. O orçamento se esgota mais rapidamente quando as novas tentativas esgotam todas as tentativas sem sucesso, mas também se esgota gradualmente quando as solicitações precisam de várias tentativas antes de serem bem-sucedidas.
Com o padrão de no máximo 3 tentativas, a cota começa a diminuir quando mais de aproximadamente **22%** das solicitações resultam em falhas transitórias sustentadas ou mais de aproximadamente **32%** em erros de limitação. Abaixo dessas taxas, as solicitações bem-sucedidas reabastecem o orçamento mais rapidamente do que as tentativas malsucedidas o esgotam.
O saldo inicial de 500 tokens do orçamento fornece um buffer que absorve pequenas explosões de falhas. Um breve pico de erros, mesmo que grave, não bloqueia novas tentativas, a menos que persista por tempo suficiente para drenar o buffer.
#### Implicações práticas
+ **Baixas taxas de falha:** a cota não tem efeito. O orçamento permanece na capacidade máxima ou próxima.
+ **Durante uma interrupção do serviço:** se uma alta porcentagem de suas solicitações falhar por um período prolongado, a cota se esgota e seu cliente recupera os erros imediatamente, em vez de esperar por novas tentativas. Isso reduz a latência do lado do cliente, libera threads e conexões e ajuda o serviço a se recuperar mais rapidamente.
+ **Recuperação:** à medida que o serviço se recupera e as solicitações começam a ser bem-sucedidas novamente, as novas tentativas bem-sucedidas restauram o custo total do token e as tentativas bem-sucedidas restauram 1 token. O orçamento é reabastecido gradualmente e as tentativas são retomadas automaticamente.
+ **Escopo:** o orçamento do token normalmente tem como escopo uma única instância do cliente SDK. O escopo exato pode variar de acordo com o SDK. Ele não é compartilhado entre processos ou hosts.
### Service-specific comportamento
#### DynamoDB
Os clientes do DynamoDB usam padrões ajustados otimizados para o perfil de baixa latência do DynamoDB:
| Configuração | Padrão geral | Padrão do DynamoDB |
| --- | --- | --- |
| Atraso de base transitório (sem limitação) | 50 ms | 25 ms |
| Atraso de base de aceleração | 1.000 ms | 1.000 ms |
| Máximo de tentativas | 3 | 4 |
Esses padrões se aplicam tanto ao Amazon DynamoDB quanto ao DynamoDB Streams.
#### Long-polling operações
Certas AWS operações usam sondagens longas. Eles podem manter uma conexão aberta aguardando a chegada do trabalho. Essas operações recebem tratamento especial de repetição:
+ `SQS.ReceiveMessage`
+ `SFN.GetActivityTask`
+ `SWF.PollForActivityTask`
+ `SWF.PollForDecisionTask`
**Comportamento especial:** quando a cota de repetição se esgota e as tentativas são bloqueadas (etapa 7[O que acontece quando uma solicitação falha](#what-happens-when-a-request-fails)), o SDK ainda aplica um atraso antes de retornar o erro ao seu código.
Isso é importante porque as operações de sondagem longa geralmente são realizadas em um circuito fechado. Seu código liga`ReceiveMessage`, processa qualquer mensagem e liga imediatamente `ReceiveMessage` novamente. Sem o recuo forçado, um orçamento de token esgotado faria com que o SDK retornasse erros sem demora. Seu ciclo de pesquisa enviaria imediatamente a próxima solicitação, aumentando o uso da CPU do cliente e gerando tráfego adicional. O atraso forçado interrompe esse ciclo, mantendo o uso de recursos do cliente e a taxa de pesquisa gerenciáveis durante falhas.
## Support by AWS SDKs e ferramentas
A tabela a seguir lista a disponibilidade do comportamento de repetição atualizado em cada SDK. Para SDK-specific obter detalhes, incluindo a versão mínima, os padrões de antes e depois e exemplos de código, consulte o problema de rastreamento. GitHub
| SDK | Compatível | GitHub problema de rastreamento |
| --- | --- | --- |
| [SDK para Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-sdk-java-v2/discussions/6984) |
| [SDK para Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) | Sim | [Problema de rastreamento](https://github.com/boto/boto3/discussions/4789) |
| [SDK para .NET 4.x](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-sdk-net/issues/4411) |
| [Ferramentas para PowerShell V5](https://docs.aws.amazon.com/powershell/latest/userguide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-tools-for-powershell/issues/418) |
| [SDK para 3.x JavaScript ](https://docs.aws.amazon.com/sdk-for-javascript/latest/developer-guide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-sdk-js-v3/issues/8037) |
| [SDK para PHP 3.x](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-sdk-php/discussions/3285) |
| [SDK para Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin/latest/developer-guide/) | Sim | [Problema de rastreamento](https://github.com/aws/aws-sdk-kotlin/discussions/1885) |
| [SDK para Rust](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/) | Sim | [Problema de rastreamento](https://github.com/awslabs/aws-sdk-rust/discussions/1431) |
| [SDK para Swift](https://docs.aws.amazon.com/sdk-for-swift/latest/developer-guide/) | Veja o problema de rastreamento | [Problema de rastreamento](https://github.com/awslabs/aws-sdk-swift/discussions/2166) |
| [SDK para Ruby 3.x](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/) | Veja o problema de rastreamento | [Problema de rastreamento](https://github.com/aws/aws-sdk-ruby/discussions/3390) |
| [SDK para Go V2 (1.x)](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/) | Veja o problema de rastreamento | [Problema de rastreamento](https://github.com/aws/aws-sdk-go-v2/issues/3416) |
| [SDK para C\+\+](https://docs.aws.amazon.com/sdk-for-cpp/latest/developer-guide/) | Veja o problema de rastreamento | [Problema de rastreamento](https://github.com/aws/aws-sdk-cpp/issues/3832) |
| [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/) | Veja o problema de rastreamento | [Problema de rastreamento](https://github.com/aws/aws-cli/discussions/10329) |