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:**:
+ [Suggeriamo di utilizzare l'approccio AWS consigliato di utilizzare nuovi [tentativi con backoff esponenziale](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html) e jitter casuale per una maggiore affidabilità.](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ Se il problema persiste, contattare il [Centro di supporto AWS](https://aws.amazon.com/support) e fornire dettagli sulla richiesta e sull’errore riscontrato.
## 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](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_Operations.html).
+ 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:**:
+ Esaminare il messaggio di errore e risolvere il problema sottostante. I problemi di fondo più comuni sono l’errore di pagamento non valido e la geolocalizzazione limitata.
+ Per un errore di pagamento non valido, consulta la [sezione Restrizioni sugli acquisti con carta di credito e debito per i clienti AISPL che utilizzano AWS Marketplace](https://aws.amazon.com/blogs/awsmarketplace/restriction-on-credit-and-debit-card-purchases-for-aispl-customers-using-aws-marketplace/) e [INVALID\_PAYMENT\_INSTRUMENT](https://repost.aws/questions/QU0UOsutrWSSS4nOqgHcIUJg/invalid-payment-instrument-after-requesting-model-access-in-amazon-bedrock) dopo aver richiesto l'accesso al modello in Amazon Bedrock. .
## 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](https://aws.amazon.com/support) 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:**:
+ [Suggeriamo di utilizzare l'approccio AWS consigliato di utilizzare nuovi [tentativi con backoff esponenziale](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html) e jitter casuale per una maggiore affidabilità.](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ Valuta la possibilità di passare a un'altra regione Regione AWS se il problema persiste nella tua regione attuale. Regioni diverse possono avere livelli di carico e disponibilità diversi.
+ [Usa l' Cross-Region inferenza](https://docs.aws.amazon.com//bedrock/latest/userguide/cross-region-inference.html) per gestire senza problemi i picchi di traffico non pianificati utilizzando l'elaborazione tra diversi sistemi. Regioni AWS
+ Se l’utente ha requisiti di throughput elevati, consigliamo di consultare [Throughput assegnato](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html) per il caso d’uso.
**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](https://aws.amazon.com/support) 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](https://docs.aws.amazon.com/general/latest/gr/bedrock.html#limits_bedrock) per conoscere i limiti assegnati all’account.
+ Suggeriamo di utilizzare l'approccio AWS consigliato di utilizzare nuovi [tentativi con backoff](https://docs.aws.amazon.com//prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html) esponenziale. [e jitter casuale per una maggiore affidabilità.](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ Se l’utente ha requisiti di throughput elevati, consigliamo di consultare [Throughput assegnato](https://docs.aws.amazon.com//bedrock/latest/userguide/prov-throughput.html) per il caso d’uso.
+ Richiedere un aumento della quota contattando l’account manager o il [Supporto AWS](https://aws.amazon.com/support) 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**
+ [ListFoundationModels](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_ListFoundationModels.html)Utilizzalo 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](https://aws.amazon.com/support) 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'`Config`oggetto 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.
1. **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 task`securityContext`, 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](https://aws.amazon.com/blogs/networking-and-content-delivery/implementing-long-running-tcp-connections-within-vpc-networking/) & Content Delivery. AWS
Se continui a riscontrare problemi di connessione dopo aver applicato entrambe le impostazioni, contatta [AWS il Supporto](https://aws.amazon.com/support) per ulteriore assistenza.