View a markdown version of this page

Résolution des codes d’erreur d’API Amazon Bedrock - Amazon Bedrock
AccessDeniedExceptionFTUFormNotFilledIncompleteSignatureInternalFailureInvalidActionInvalidClientTokenIdAWS Le Marketplace Agreement a échoué en 15 minutesAWS Contrat Marketplace en attente après 15 minutesMPAgreementBeingCreatedNotAuthorizedRequestExpiredServiceUnavailableThrottlingExceptionValidationErrorResourceNotFoundExpiration ou réinitialisation de la connexion en cas de connexions inactives ou de longue durée

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des codes d’erreur d’API Amazon Bedrock

Cette section fournit des informations détaillées sur les erreurs courantes que vous pouvez rencontrer lors de l’utilisation des API Amazon Bedrock, la cause de l’erreur et la solution pour la résoudre.

AccessDeniedException

Code d’état HTTP : 403

Cause : vous ne disposez pas des autorisations suffisantes pour effectuer l’action demandée.

Solution :

  • Vérifiez que votre utilisateur ou rôle IAM dispose des autorisations nécessaires pour l’action que vous tentez.

  • Si vous utilisez des informations d’identification de sécurité temporaires, assurez-vous qu’elles n’ont pas expiré.

FTUFormNotFilled

Code d’état HTTP :404

Cause : les détails du cas d’utilisation du modèle n’ont pas été soumis pour ce compte

Solution :

  • Remplissage du formulaire de détails du cas d’utilisation Anthropic avant d’utiliser le modèle

IncompleteSignature

Code d’état HTTP : 400

Cause : La signature de la demande n'est pas conforme aux AWS normes.

Solution :

  • Assurez-vous d'utiliser une version du AWS SDK compatible avec Amazon Bedrock.

  • Vérifiez que l'ID de votre clé d' AWS accès et votre clé secrète sont correctement configurés.

  • Si vous signez des demandes manuellement, nous vous suggérons de vérifier votre processus de calcul de signature.

InternalFailure

Code d’état HTTP : 500

Cause : le traitement de la demande a échoué en raison d’une erreur de serveur

Solution :

InvalidAction

Code d’état HTTP : 400

Cause : l’action ou l’opération demandée n’est pas valide.

Solution :

  • Nous vous conseillons de vérifier l’orthographe et le formatage du nom de l’action dans votre demande.

  • Vérifiez que l’appel à l’action est pris en charge par Amazon Bedrock et qu’il est correctement documenté, comme indiqué dans la référence d’ API Amazon Bedrock.

  • Assurez-vous d'utiliser la version la plus récente du AWS SDK ou de la CLI.

InvalidClientTokenId

Code d’état HTTP : 403

Cause : Le X.509 certificat ou AWS l'identifiant de clé d'accès fourni n'existe pas dans nos dossiers.

Solution :

  • Vérifiez que vous utilisez le bon identifiant de clé AWS d'accès.

  • Si vous avez récemment créé de nouvelles clés d’accès, assurez-vous d’utiliser les nouvelles informations d’identification et non les anciennes.

AWS Le Marketplace Agreement a échoué en 15 minutes

Code d’état HTTP : 403

Cause : Le AWS Marketplace Agreement a échoué en raison d'un problème sous-jacent.

Solution :

AWS Contrat Marketplace en attente après 15 minutes

Code d’état HTTP : 403

Cause : Le AWS Marketplace Agreement n'a pas abouti et cela fait 15 minutes que la demande a été faite.

Solution :

  • Répétez la demande toutes les 15 minutes. Si le problème persiste, veuillez contacter le Centre de support AWS et fournir des informations sur votre demande et l’erreur que vous rencontrez.

MPAgreementBeingCreated

Code d’état HTTP : 403

Cause : votre compte n’est pas autorisé à accéder à ce modèle. Votre abonnement AWS Marketplace pour ce modèle est toujours en cours de traitement

Solution :

  • Réessayez après 15 minutes

NotAuthorized

Code d’état HTTP : 400

Cause : vous ne disposez pas de l’autorisation nécessaire pour effectuer cette action.

Solution :

  • Vérifiez vos autorisations IAM et assurez-vous de disposer des droits nécessaires pour effectuer l’action demandée sur les ressources Amazon Bedrock.

  • Si vous utilisez un rôle IAM, vérifiez que le rôle dispose des autorisations et des relations de confiance appropriées.

  • Vérifiez les politiques organisationnelles ou les politiques de contrôle des services susceptibles de restreindre votre accès.

RequestExpired

Code d’état HTTP : 400

Cause : la demande n’est plus valide en raison de l’expiration des horodatages.

Solution :

  • Assurez-vous que l’horloge de votre système est correctement synchronisée avec une source de temps fiable.

  • Si vous faites des demandes depuis des fuseaux horaires différents, soyez conscient des éventuels écarts d’horodatage.

ServiceUnavailable

Code d'état HTTP : 503

Cause : Le service est temporairement incapable de traiter la demande. 503 erreurs indiquent que le service est confronté à une forte demande ou à des contraintes de capacité temporaires. Cela n'est pas lié aux quotas ou aux limites de taux au niveau de votre compte (qui renvoient 429 ThrottlingException).

Solution :

Bonnes pratiques

  • Assurez-vous que votre application peut gérer les codes d’état 503 de manière appropriée dans votre logique de gestion des erreurs et de nouvelle tentative.

  • Consultez le AWS Service Health Dashboard pour tout problème annoncé ou toute maintenance planifiée susceptible d'affecter le service.

Si vous rencontrez fréquemment des erreurs 503 ou si elles ont un impact significatif sur vos opérations, contactez le Support AWS pour obtenir une assistance supplémentaire et des conseils adaptés à votre cas d’utilisation spécifique.

ThrottlingException

Code d'état HTTP : 429

Cause : la demande a été refusée en raison du dépassement des quotas de compte pour Amazon Bedrock.

Solution :

ValidationError

Code d’état HTTP : 400

Cause : L’entrée ne satisfait pas les contraintes spécifiées par Amazon Bedrock.

Solution :

  • Consultez la documentation de l’API pour vous assurer que tous les paramètres requis sont inclus et correctement formatés.

  • Vérifiez que vos valeurs d’entrée se situent dans les plages autorisées ou qu’elles sont conformes aux modèles attendus.

  • Nous vous suggérons de prêter attention aux règles de validation spécifiques mentionnées dans la Référence des API pour l’action que vous utilisez.

ResourceNotFound

Code d’état HTTP :404

Cause : la ressource demandée est introuvable.

Solution :

  • Vérifiez l’exactitude de l’ID du modèle, du nom du point de terminaison ou des autres identifiants de ressource figurant dans votre demande.

  • Mettez en œuvre un mécanisme de secours pour utiliser des modèles ou des points de terminaison alternatifs lorsqu’aucune ressource principale n’est trouvée.

Bonnes pratiques

  • ListFoundationModelsÀ utiliser pour en savoir plus sur les modèles de fondations Amazon Bedrock disponibles que vous pouvez utiliser.

  • Nous vous suggérons de mettre en œuvre un processus de synchronisation périodique pour mettre à jour votre catalogue de ressources local.

Si vous continuez à rencontrer des problèmes après avoir essayé ces solutions, contactez le Support AWS pour obtenir une assistance supplémentaire et des conseils adaptés à votre cas d’utilisation spécifique.

Expiration ou réinitialisation de la connexion en cas de connexions inactives ou de longue durée

Symptôme : les appels d'API échouent en cas de réinitialisation ou d'expiration des délais de connexion, en particulier pour les demandes de longue durée telles que le streaming, la réflexion approfondie ou les réponses d'inférence volumineuses, lorsque le trafic passe par des passerelles NAT, des points de terminaison VPC d'interface ou des équilibreurs de charge réseau. Les symptômes peuvent également apparaître sous la forme d'une longue latence de démarrage à froid (par exemple, le premier appel après une période d'inactivité prend plus de 70 secondes au lieu des quelques secondes habituelles) lorsqu'une connexion groupée inactive est réutilisée après une interruption silencieuse du réseau.

Cause : les passerelles NAT, les points de terminaison VPC d'interface et les équilibreurs de charge réseau ont un délai d'inactivité fixe de 350 secondes. Si une connexion TCP reste inactive au-delà de cette période, elle est interrompue sans en informer le client. Le client peut ne pas détecter la connexion interrompue avant la prochaine demande. Il doit alors attendre la nouvelle tentative ou le délai d'expiration du OS-level protocole TCP avant de rétablir la connexion.

Lorsque cela s'applique :

  • Applications exécutées sur Amazon EKS ou Amazon ECS où le trafic du pod vers Amazon Bedrock sort via une passerelle NAT ou un point de terminaison d'interface VPC.

  • Applications exécutées sur des instances Amazon EC2 derrière une passerelle NAT, un point de terminaison VPC d'interface pour Amazon Bedrock ou un Network Load Balancer.

  • Long-running ou des charges de travail surchargées lorsque les connexions des clients Amazon Bedrock restent inactives dans un pool de connexions entre les appels.

Solution :

L'activation du protocole TCP keep-alive sur le client Amazon Bedrock nécessite que deux paramètres fonctionnent ensemble. Il ne suffit pas d'en définir un seul.

  1. Activez le protocole TCP keep-alive dans votre client SDK AWS. L'Configobjet boto3 accepte un tcp_keepalive paramètre, dont la valeur par défaut est. False Réglez-le sur True lors de la création du client Amazon Bedrock :

    import boto3
from botocore.config import Config

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

    Pour les autres kits SDK AWS, consultez la documentation de configuration du client HTTP correspondante.

  2. Configurez l'intervalle de OS-level maintien en vie pour qu'il se déclenche avant le délai d'inactivité de 350 secondes. Linux utilise par défaut net.ipv4.tcp_keepalive_time = 7200 (2 heures), ce qui est bien plus long que le délai d'inactivité du point de terminaison NAT ou VPC. Le maintien en vie seul n'a SDK-level donc aucun effet. Réduisez le paramètre du noyau à une valeur inférieure à 350 secondes en toute sécurité (par exemple, 45 secondes) :

    sysctl -w net.ipv4.tcp_keepalive_time=45

    Sur Amazon EKS et Amazon ECS, appliquez le sysctl dans le pod ou la tâchesecurityContext, dans un conteneur d'initialisation ou dans une AMI de nœud personnalisée. Sur Amazon EC2, configurez-le de /etc/sysctl.d/ manière à ce que la valeur persiste après les redémarrages.

Pour une discussion plus approfondie sur les connexions TCP de longue durée dans les réseaux VPC, consultez la section Implémentation de connexions TCP de longue durée au sein d'un réseau VPC sur le blog Networking & Content Delivery. AWS

Si vous continuez à rencontrer des problèmes de connexion après avoir appliqué les deux paramètres, contactez le AWS Support pour obtenir de l'aide.