View a markdown version of this page

Risoluzione dei problemi dei codici di errore del’API Amazon Bedrock - Amazon Bedrock
AccessDeniedExceptionFTUFormNotFilledIncompleteSignatureInternalFailureInvalidActionInvalidClientTokenIdAWS Contratto sul Marketplace non riuscito entro 15 minutiAWS Contratto di Marketplace in sospeso dopo 15 minutiMPAgreementBeingCreatedNotAuthorizedRequestExpiredServiceUnavailableThrottlingExceptionValidationErrorResourceNotFoundTimeout o ripristino della connessione in caso di connessioni di lunga durata o inattive

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 utilizzi credenziali di sicurezza temporanee, assicurati 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 registri.

Soluzione::

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

  • Se di recente hai creato nuove chiavi di accesso, assicurati di utilizzare le nuove credenziali e non quelle vecchie.

AWS Contratto sul Marketplace non riuscito entro 15 minuti

Codice di stato HTTP: 403

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

Soluzione::

AWS Contratto di Marketplace in sospeso dopo 15 minuti

Codice di stato HTTP: 403

Causa: l'accordo AWS sul Marketplace non è andato a buon fine 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. L'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::

  • Verifica le tue autorizzazioni IAM e assicurati 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::

  • Assicurati che l'orologio di sistema sia sincronizzato correttamente con una fonte di tempo 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 tariffari a livello di account (che restituiscono 429). ThrottlingException

Soluzione::

Best practice

  • Assicuratevi 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.

  • Consulta il AWS Service Health Dashboard per eventuali problemi annunciati o interventi di 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::

  • Controllare le quote del servizio di Amazon Bedrock nella console Amazon Bedrock Service Quotas per conoscere i limiti assegnati all’account.

  • Suggeriamo di utilizzare l'approccio AWS consigliato di utilizzare i tentativi con backoff esponenziale. e jitter casuale per una maggiore affidabilità.

  • Se l’utente ha requisiti di throughput elevati, consigliamo di consultare Throughput assegnato per il caso d’uso.

  • Richiedere un aumento della quota contattando l’account manager o il Supporto AWS se il traffico del carico di lavoro supera le quote dell’account.

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 conoscere 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 di lunga durata o inattive

Sintomo: le chiamate API hanno esito negativo in caso di ripristino o timeout della connessione, in particolare per richieste di lunga durata come streaming, extended thinking o risposte di grandi dimensioni, quando il traffico passa attraverso i gateway NAT, gli endpoint VPC di interfaccia o i Network Load Balancer. I sintomi possono anche manifestarsi come una lunga latenza di avvio a freddo (ad esempio, la prima chiamata dopo un periodo di inattività richiede più di 70 secondi anziché i soliti pochi) quando una connessione in pool inattiva 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 inattiva fisso di 350 secondi. Se una connessione TCP rimane inattiva per più di questo periodo, la connessione viene interrotta senza avvisare il client. Il client può rilevare l'interruzione della connessione solo 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 interminabili in cui le connessioni dei client Amazon Bedrock rimangono inattive in un pool di connessioni tra una chiamata e l'altra.

Soluzione::

L'attivazione del protocollo TCP keep-alive sul client Amazon Bedrock richiede che due impostazioni funzionino insieme. Impostarne una sola non è sufficiente.

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

    import boto3
from botocore.config import Config

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

    Per altri AWS SDK, 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. Il valore predefinito di Linux è net.ipv4.tcp_keepalive_time = 7200 (2 ore), che è molto più lungo del timeout di inattività degli endpoint NAT o VPC, quindi keep-alive da solo non ha alcun effetto. SDK-level Riduci 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'AMI con nodo 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 di lunga durata nelle reti VPC, consulta Implementazione di connessioni TCP di lunga durata all'interno di reti VPC nel blog Networking & Content Delivery. AWS

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