View a markdown version of this page

Solução de problemas dos códigos de erro da API do Amazon Bedrock - Amazon Bedrock
AccessDeniedExceptionFTUFormNotFilledIncompleteSignatureInternalFailureInvalidActionInvalidClientTokenIdAWS O contrato do Marketplace falhou em 15 minutosAWS Contrato do Marketplace pendente após 15 minutosMPAgreementBeingCreatedNotAuthorizedRequestExpiredServiceUnavailableThrottlingExceptionValidationErrorResourceNotFoundTempo limite de conexão ou redefinição em conexões de longa duração ou ociosas

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

Solução de problemas dos códigos de erro da API do Amazon Bedrock

Esta seção fornece informações detalhadas sobre os erros comuns que você pode encontrar ao usar as APIs do Amazon Bedrock, a causa do erro e a solução para resolvê-lo.

AccessDeniedException

Código de status HTTP: 403

Causa: você não tem permissões suficientes para realizar a ação solicitada

Solução:

  • Verifique se o usuário ou o perfil do IAM tem as permissões necessárias para a ação que você está tentando.

  • Se você usar credenciais de segurança temporárias, verifique se elas não expiraram.

FTUFormNotFilled

Código de status HTTP: 404

Causa: os detalhes do caso de uso do modelo não foram enviados para a conta em questão.

Solução:

  • Preencha o formulário de detalhes de caso de uso da Anthropic antes de usar o modelo.

IncompleteSignature

Código de status HTTP: 400

Causa: A assinatura da solicitação não está em conformidade com os AWS padrões.

Solução:

  • Verifique se você está usando uma versão do AWS SDK compatível com o Amazon Bedrock.

  • Verifique se o ID da chave de AWS acesso e a chave secreta estão configurados corretamente.

  • Se você estiver assinando solicitações manualmente, sugerimos verificar novamente o processo de cálculo da assinatura.

InternalFailure

Código de status HTTP: 500

Causa: falha no processamento da solicitação por causa de um erro no servidor

Solução:

InvalidAction

Código de status HTTP: 400

Causa: a ação ou a operação solicitada é inválida

Solução:

  • Sugerimos verificar novamente a ortografia e a formatação do nome da ação na solicitação.

  • Verifique se a chamada de ação é compatível com o Amazon Bedrock e está documentada corretamente, conforme mostrado na Referência de API do Amazon Bedrock.

  • Verifique se você está usando a versão mais atualizada do AWS SDK ou da CLI.

InvalidClientTokenId

Código de status HTTP: 403

Causa: O ID do X.509 certificado ou da chave de AWS acesso fornecido não existe em nossos registros.

Solução:

  • Verifique se você está usando a ID da chave de AWS acesso correta.

  • Se você tiver criado chaves de acesso recentemente, verifique se está usando as novas credenciais, e não as anteriores.

AWS O contrato do Marketplace falhou em 15 minutos

Código de status HTTP: 403

Causa: O Contrato do AWS Marketplace falhou devido a um problema subjacente.

Solução:

AWS Contrato do Marketplace pendente após 15 minutos

Código de status HTTP: 403

Causa: O Contrato do AWS Marketplace não foi bem-sucedido e já se passaram 15 minutos desde que a solicitação foi feita.

Solução:

  • Tente solicitar novamente a cada 15 minutos. Se o problema persistir, entre em contato com o AWS Support Center e dê detalhes sobre a solicitação e o erro que você está encontrando.

MPAgreementBeingCreated

Código de status HTTP: 403

Causa: sua conta não está autorizada a acessar o modelo em questão. Sua assinatura AWS do Marketplace para esse modelo ainda está sendo processada

Solução:

  • Tente novamente após 15 minutos.

NotAuthorized

Código de status HTTP: 400

Causa: você não tem permissão para realizar a ação.

Solução:

  • Analise as permissões do IAM e verifique se você tem os direitos necessários para realizar a ação solicitada em recursos do Amazon Bedrock.

  • Se você estiver usando um perfil do IAM, verifique se o perfil tem as permissões e relações de confiança indicadas.

  • Verifique se há políticas organizacionais ou políticas de controle de serviços que possam estar restringindo o acesso.

RequestExpired

Código de status HTTP: 400

Causa: a solicitação não é mais válida devido a carimbos de data/hora expirados.

Solução:

  • Verifique se o relógio do sistema está sincronizado corretamente com uma fonte de tempo confiável.

  • Se você estiver fazendo solicitações em fusos horários diferentes, saiba que pode haver discrepâncias no carimbo de data/hora.

ServiceUnavailable

Código de status HTTP: 503

Causa: O serviço está temporariamente impossibilitado de processar a solicitação. Os erros 503 indicam que o serviço está enfrentando alta demanda ou restrições temporárias de capacidade. Isso não está relacionado às cotas ou limites de taxa em nível de sua conta (que retornam 429). ThrottlingException

Solução:

Práticas recomendadas

  • Garanta que a aplicação possa processar códigos de status 503 da maneira devida na lógica de tratamento de erros e repetição.

  • Consulte o AWS Service Health Dashboard para ver se há problemas anunciados ou manutenções programadas que possam afetar o serviço.

Se você tiver erros 503 frequentes ou se eles afetarem significativamente as operações, entre em contato com o AWS Support para obter ajuda adicional e orientação personalizadas para o caso de uso específico.

ThrottlingException

Código de status HTTP: 429

Causa: a solicitação foi negada porque as cotas da conta referentes ao Amazon Bedrock foram excedidas.

Solução:

  • Verifique as cotas de serviço do Amazon Bedrock no console de cotas de serviço do Amazon Bedrock para saber mais sobre os limites alocados à conta.

  • Sugerimos empregar a abordagem AWS recomendada de usar novas tentativas com recuo exponencial. e instabilidade aleatória para maior confiabilidade.

  • Se você tiver requisitos de throughput elevados, sugerimos explorar o throughput provisionado para seu caso de uso.

  • Solicite um aumento de cota entrando em contato com o gerente da conta ou com o AWS Support caso o tráfego de workload exceda as cotas da conta.

ValidationError

Código de status HTTP: 400

Causa: a entrada não atende às restrições especificadas pelo Amazon Bedrock.

Solução:

  • Analise a documentação da API para garantir que todos os parâmetros necessários sejam incluídos e formatados corretamente.

  • Verifique se os valores de entrada estão dentro dos intervalos permitidos ou estão em conformidade com os padrões esperados.

  • Sugerimos prestar atenção em todas as regras de validação específicas mencionadas na referência de API para a ação que você está usando.

ResourceNotFound

Código de status HTTP: 404

Causa: não foi possível encontrar o recurso solicitado.

Solução:

  • Verifique a exatidão do ID do modelo, do nome do endpoint ou de outros identificadores de recurso na solicitação.

  • Implemente um mecanismo de fallback para usar modelos ou endpoints alternativos quando um recurso primário não for encontrado.

Práticas recomendadas

  • Use ListFoundationModelspara saber mais sobre os modelos de fundação Amazon Bedrock disponíveis que você pode usar.

  • Sugerimos implementar um processo de sincronização periódica para atualizar o catálogo de recursos local.

Se você continuar enfrentando problemas depois de tentar essas soluções, entre em contato com o AWS Support para obter ajuda adicional e orientação personalizadas ao caso de uso específico.

Tempo limite de conexão ou redefinição em conexões de longa duração ou ociosas

Sintoma: as chamadas de API falham com redefinições ou tempos limite de conexão, especialmente para solicitações de longa duração, como streaming, pensamento estendido ou grandes respostas de inferência, quando o tráfego passa por gateways NAT, endpoints de interface VPC ou balanceadores de carga de rede. Os sintomas também podem aparecer como uma longa latência de inicialização a frio (por exemplo, a primeira chamada após um período de inatividade leva mais de 70 segundos em vez dos poucos habituais) quando uma conexão ociosa em pool é reutilizada depois que a rede a desliga silenciosamente.

Causa: Gateways NAT, endpoints VPC de interface e balanceadores de carga de rede têm um tempo limite fixo de conexão ociosa de 350 segundos. Se uma conexão TCP permanecer inativa por mais tempo do que esse período, a conexão será interrompida sem notificar o cliente. O cliente pode não detectar a queda da conexão até a próxima solicitação. Nesse momento, ele deve aguardar a nova tentativa de OS-level TCP ou o tempo limite antes de restabelecer a conexão.

Quando isso se aplica:

  • Aplicativos em execução no Amazon EKS ou no Amazon ECS, nos quais o tráfego de pod para o Amazon Bedrock sai por meio de um gateway NAT ou endpoint de interface VPC.

  • Aplicativos executados em instâncias do Amazon EC2 por trás de um NAT Gateway, um endpoint VPC de interface para o Amazon Bedrock ou um Network Load Balancer.

  • Long-running ou cargas de trabalho intermitentes em que as conexões de clientes do Amazon Bedrock ficam ociosas em um pool de conexões entre as chamadas.

Solução:

Habilitar o TCP keep-alive no cliente Amazon Bedrock exige que duas configurações funcionem juntas. Definir apenas um não é suficiente.

  1. Habilite o TCP keep-alive em seu cliente do AWS SDK. O Config objeto boto3 aceita um tcp_keepalive parâmetro, cujo padrão é. False Configure-o como True ao construir o cliente Amazon Bedrock:

    import boto3
from botocore.config import Config

config = Config(tcp_keepalive=True)
client = boto3.client("bedrock-runtime", config=config)

    Para outros SDKs da AWS, consulte a documentação de configuração do cliente HTTP correspondente.

  2. Configure o intervalo de OS-level manutenção de atividade para ser acionado antes do tempo limite de inatividade de 350 segundos. O padrão do Linux é net.ipv4.tcp_keepalive_time = 7200 (2 horas), o que é muito mais do que o tempo limite de inatividade do terminal NAT ou VPC, portanto, manter a atividade sozinho não tem efeito. SDK-level Reduza a configuração do kernel para um valor com segurança abaixo de 350 segundos (por exemplo, 45 segundos):

    sysctl -w net.ipv4.tcp_keepalive_time=45

    No Amazon EKS e no Amazon ECS, aplique o sysctl no pod ou na tarefasecurityContext, em um contêiner inicial ou em uma AMI de nó personalizada. No Amazon EC2, configure-o /etc/sysctl.d/ para que o valor persista nas reinicializações.

Para uma discussão mais aprofundada sobre conexões TCP de longa duração em redes VPC, consulte Implementação de conexões TCP de longa duração em redes VPC no blog Networking & Content Delivery. AWS

Se você continuar enfrentando problemas de conexão após aplicar as duas configurações, entre em contato com o AWS Support para obter mais assistência.