View a markdown version of this page

Risoluzione dei problemi dei codici di errore del’API Amazon Bedrock - Amazon Bedrock

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi dei codici di errore del’API Amazon Bedrock

Questa sezione fornisce informazioni dettagliate sugli errori comuni che potrebbero verificarsi durante l’utilizzo delle API di Amazon Bedrock, sulla causa dell’errore e sulla soluzione per risolverlo.

AccessDeniedException

Codice di stato HTTP: 403

Causa: l’utente non dispone delle autorizzazioni sufficienti per eseguire l’azione richiesta.

Soluzione::

  • Verificare che l’utente o il ruolo IAM dispongano delle autorizzazioni necessarie per l’azione che sta tentando di eseguire.

  • Se sta utilizzando credenziali di sicurezza temporanee, accertarsi che non siano scadute.

FTUFormNotFilled

Codice di stato HTTP: 404

Causa: i dettagli del caso d’uso del modello non sono stati inviati per questo account.

Soluzione::

  • Compilare il modulo con i dettagli del caso d’uso di Anthropic prima di utilizzare il modello

IncompleteSignature

Codice di stato HTTP: 400

Causa: la firma della richiesta non è conforme agli AWS standard.

Soluzione::

  • Assicurati di utilizzare una versione AWS SDK che supporti Amazon Bedrock.

  • Verifica che l'ID della chiave di AWS accesso e la chiave segreta siano configurati correttamente.

  • Se l’utente firma manualmente le richieste, consigliamo di ricontrollare il processo di calcolo della firma.

InternalFailure

Codice di stato HTTP: 500

Causa: l’elaborazione della richiesta non è riuscita a causa di un errore del server.

Soluzione::

InvalidAction

Codice di stato HTTP: 400

Causa: l’azione o l’operazione richiesta non è valida.

Soluzione::

  • Consigliamo di ricontrollare l’ortografia e la formattazione del nome dell’azione nella richiesta.

  • Verificare che la chiamata dell’azione sia supportata da Amazon Bedrock e sia documentata correttamente, come mostrato nella documentazione di riferimento dell’API Amazon Bedrock.

  • Assicurati di utilizzare la versione più aggiornata dell' AWS SDK o della CLI.

InvalidClientTokenId

Codice di stato HTTP: 403

Causa: l'ID del X.509 certificato o della chiave di AWS accesso fornito non esiste nei nostri archivi.

Soluzione::

  • Verifica di utilizzare l'ID della chiave di AWS accesso corretto.

  • Se di recente l’utente ha creato nuove chiavi di accesso, assicurarsi che utilizzi le nuove credenziali e non quelle vecchie.

AWS Contratto Marketplace fallito entro 15 minuti

Codice di stato HTTP: 403

Causa: il AWS Marketplace Agreement non è riuscito a causa di un problema di fondo.

Soluzione::

AWS Contratto Marketplace in sospeso dopo 15 minuti

Codice di stato HTTP: 403

Causa: il AWS Marketplace Agreement non è riuscito e sono trascorsi 15 minuti da quando è stata effettuata la richiesta.

Soluzione::

  • Riprovare a eseguire la richiesta ogni 15 minuti. Se il problema persiste, contattare il Centro di supporto AWS e fornire dettagli sulla richiesta e sull’errore riscontrato.

MPAgreementBeingCreated

Codice di stato HTTP: 403

Causa: l’account non è autorizzato ad accedere a questo modello. Il tuo abbonamento al AWS Marketplace per questo modello è ancora in fase di elaborazione

Soluzione::

  • Riprovare dopo 15 minuti

NotAuthorized

Codice di stato HTTP: 400

Causa: l’utente non disponi delle autorizzazioni per eseguire questa azione.

Soluzione::

  • Verificare le autorizzazioni IAM e assicurarsi di disporre dei diritti necessari per eseguire l’azione richiesta sulle risorse Amazon Bedrock.

  • Se l’utente utilizza un ruolo IAM, accertarsi che il ruolo disponga delle autorizzazioni e delle relazioni di attendibilità appropriate.

  • Verificare eventuali policy organizzative o di controllo dei servizi che potrebbero limitare l’accesso.

RequestExpired

Codice di stato HTTP: 400

Causa: la richiesta non è più valida a causa di timestamp scaduti.

Soluzione::

  • Assicurarsi che l’orologio di sistema sia sincronizzato correttamente con un’origine di orario affidabile.

  • Se l’utente sta effettuando richieste da fusi orari diversi, tenere presente le potenziali discrepanze nei timestamp.

ServiceUnavailable

Codice di stato HTTP: 503

Causa: il servizio non è temporaneamente in grado di gestire la richiesta. Gli errori 503 indicano che il servizio presenta una domanda elevata o limiti temporanei di capacità. Ciò non è correlato alle quote o ai limiti di tariffa a livello di account (che restituiscono 429). ThrottlingException

Soluzione::

Best practice

  • Assicurarsi che l’applicazione sia in grado di gestire i codici di stato 503 in modo appropriato nella logica di gestione degli errori e dei tentativi.

  • Controlla il AWS Service Health Dashboard per eventuali problemi annunciati o manutenzione programmata che potrebbero influire sul servizio.

Se si verificano errori 503 frequenti o se influiscono in modo significativo sulle operazioni, contattare il Supporto AWS per ricevere ulteriore assistenza e indicazioni personalizzate in base al caso d’uso specifico.

ThrottlingException

Codice di stato HTTP: 429

Causa: la richiesta è stata rifiutata a causa del superamento delle quote dell’account per Amazon Bedrock.

Soluzione::

ValidationError

Codice di stato HTTP: 400

Causa: l’input non riesce a soddisfare i vincoli specificati da Amazon Bedrock.

Soluzione::

  • Consultare la documentazione dell’API per assicurarsi che tutti i parametri richiesti siano inclusi e formattati correttamente.

  • Verificare che i valori di input rientrino negli intervalli consentiti o siano conformi ai modelli previsti.

  • Consigliamo di prestare attenzione a tutte le regole di convalida specifiche menzionate nella documentazione di riferimento dell’API per l’azione in uso.

ResourceNotFound

Codice di stato HTTP: 404

Causa: impossibile trovare la risorsa richiesta.

Soluzione::

  • Verificare la correttezza dell’ID modello, del nome dell’endpoint o di altri identificatori di risorse nella richiesta.

  • Implementare un meccanismo di fallback per utilizzare modelli o endpoint alternativi quando non viene trovata una risorsa principale.

Best practice

  • ListFoundationModelsUtilizzalo per scoprire i modelli Amazon Bedrock Foundation disponibili che puoi utilizzare.

  • Consigliamo di implementare una procedura di sincronizzazione periodica per aggiornare il catalogo di risorse locali.

Se l’utente continua a riscontrare problemi dopo aver provato queste soluzioni, deve contattare il Supporto AWS per richiedere ulteriore assistenza e indicazioni personalizzate in base al caso d’uso specifico.

Timeout o ripristino della connessione in caso di connessioni a lunga durata o inattive

Sintomo: le chiamate API falliscono con reimpostazioni o timeout della connessione, in particolare per richieste di lunga durata come streaming, pensiero esteso o risposte di inferenza di grandi dimensioni, quando il traffico passa attraverso gateway NAT, endpoint VPC di interfaccia o Network Load Balancer. I sintomi possono manifestarsi anche come una lunga latenza di avvio a freddo (ad esempio, la prima chiamata dopo un periodo di inattività impiega più di 70 secondi invece dei soliti pochi) quando una connessione inattiva in pool viene riutilizzata dopo che la rete l'ha interrotta silenziosamente.

Causa: i gateway NAT, gli endpoint VPC di interfaccia e i Network Load Balancer hanno un timeout di connessione inattivo fisso di 350 secondi. Se una connessione TCP rimane inattiva più a lungo di questo periodo, la connessione viene interrotta senza avvisare il client. Il client potrebbe non rilevare la connessione interrotta fino alla richiesta successiva, a quel punto deve attendere il nuovo tentativo o il timeout del OS-level protocollo TCP prima di ristabilire la connessione.

Quando ciò si applica:

  • Applicazioni in esecuzione su Amazon EKS o Amazon ECS in cui il traffico dei pod verso Amazon Bedrock esce attraverso un gateway NAT o un endpoint di interfaccia VPC.

  • Applicazioni in esecuzione su istanze Amazon EC2 dietro un gateway NAT, un endpoint VPC di interfaccia per Amazon Bedrock o un Network Load Balancer.

  • Long-running o carichi di lavoro intensi in cui le connessioni client Amazon Bedrock rimangono inattive in un pool di connessioni tra una chiamata e l'altra.

Soluzione::

L'abilitazione di TCP keep-alive sul client Amazon Bedrock richiede la combinazione di due impostazioni. Impostarne solo una non è sufficiente.

  1. Abilita TCP keep-alive nel tuo client SDK AWS. L'Configoggetto boto3 accetta un tcp_keepalive parametro, il cui valore predefinito è. False Impostalo su True durante la creazione del client Amazon Bedrock:

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

    Per altri SDK AWS, consulta la documentazione di configurazione del client HTTP corrispondente.

  2. Configura l'intervallo OS-level keep-alive in modo che venga attivato prima del timeout di inattività di 350 secondi. L'impostazione predefinita di Linux è net.ipv4.tcp_keepalive_time = 7200 (2 ore), che è molto più lunga del timeout di inattività dell'endpoint NAT o VPC, quindi il solo keep-alive non ha alcun effetto. SDK-level Abbassa l'impostazione del kernel a un valore sicuro inferiore a 350 secondi (ad esempio, 45 secondi):

    sysctl -w net.ipv4.tcp_keepalive_time=45

    Su Amazon EKS e Amazon ECS, applica sysctl nel pod o nel tasksecurityContext, in un contenitore init o in un nodo AMI personalizzato. Su Amazon EC2, impostalo in /etc/sysctl.d/ modo che il valore persista anche dopo i riavvii.

Per una discussione più approfondita sulle connessioni TCP a lunga durata nelle reti VPC, consulta Implementazione di connessioni TCP di lunga durata all'interno delle reti VPC nel blog Networking & Content Delivery. AWS

Se continui a riscontrare problemi di connessione dopo aver applicato entrambe le impostazioni, contatta AWS il Supporto per ulteriore assistenza.