View a markdown version of this page

Beheben der API-Fehlercodes von Amazon Bedrock - Amazon Bedrock
AccessDeniedExceptionFTUFormNotFilledIncompleteSignatureInternalFailureInvalidActionInvalidClientTokenIdAWS Die Marketplace-Vereinbarung ist innerhalb von 15 Minuten fehlgeschlagenAWS Die Marketplace-Vereinbarung steht nach 15 Minuten noch ausMPAgreementBeingCreatedNotAuthorizedRequestExpiredServiceUnavailableThrottlingExceptionValidationErrorResourceNotFoundVerbindungstimeout oder Reset bei Verbindungen mit langer Laufzeit oder im Leerlauf

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben der API-Fehlercodes von Amazon Bedrock

Dieser Abschnitt enthält detaillierte Informationen zu den häufigsten Fehlern, die bei der Verwendung von Amazon-Bedrock-APIs auftreten können, zur Ursache des Fehlers und zu dessen Lösung.

AccessDeniedException

HTTP-Statuscode: 403

Ursache: Sie verfügen nicht über die erforderlichen Berechtigungen, um die angefragte Aktion durchzuführen.

Lösung:

  • Überprüfen Sie, ob Ihr IAM-Benutzer oder Ihre IAM-Rolle über die erforderlichen Berechtigungen für die Aktion verfügt, die Sie versuchen auszuführen.

  • Wenn Sie temporäre Sicherheitsanmeldeinformationen verwenden, stellen Sie sicher, dass diese nicht abgelaufen sind.

FTUFormNotFilled

HTTP-Statuscode: 404

Ursache: Für dieses Konto wurden keine Details zum Modellanwendungsfall übermittelt.

Lösung:

  • Füllen Sie das Formular mit den Details zum Anthropic-Anwendungsfall aus, bevor Sie das Modell verwenden.

IncompleteSignature

HTTP-Statuscode: 400

Ursache: Die Anforderungssignatur entspricht nicht den AWS Standards.

Lösung:

  • Stellen Sie sicher, dass Sie eine AWS SDK-Version verwenden, die Amazon Bedrock unterstützt.

  • Stellen Sie sicher, dass Ihre AWS Zugriffsschlüssel-ID und Ihr geheimer Schlüssel korrekt konfiguriert sind.

  • Wenn Sie Anforderungen manuell signieren, empfehlen wir Ihnen, Ihren Signaturberechnungsprozess noch einmal zu überprüfen.

InternalFailure

HTTP-Statuscode: 500

Ursache: Die Anforderungsverarbeitung ist aufgrund eines Serverfehlers fehlgeschlagen.

Lösung:

InvalidAction

HTTP-Statuscode: 400

Ursache: Die angeforderte Aktion oder Operation ist ungültig.

Lösung:

  • Wir empfehlen, die Schreibweise und Formatierung des Aktionsnamens in Ihrer Anforderung zu überprüfen.

  • Stellen Sie sicher, dass der Aktionsaufruf von Amazon Bedrock unterstützt wird und korrekt dokumentiert ist, wie in der Referenz zur Amazon-Bedrock-API gezeigt.

  • Stellen Sie sicher, dass Sie die aktuellste Version des SDK oder der CLI verwenden. AWS

InvalidClientTokenId

HTTP-Statuscode: 403

Ursache: Die angegebene X.509 Zertifikat- oder AWS Zugriffsschlüssel-ID ist in unseren Aufzeichnungen nicht vorhanden.

Lösung:

  • Stellen Sie sicher, dass Sie die richtige AWS Zugriffsschlüssel-ID verwenden.

  • Wenn Sie kürzlich neue Zugriffsschlüssel erstellt haben, stellen Sie sicher, dass Sie die neuen Anmeldeinformationen verwenden und nicht die alten.

AWS Die Marketplace-Vereinbarung ist innerhalb von 15 Minuten fehlgeschlagen

HTTP-Statuscode: 403

Ursache: Die AWS Marketplace-Vereinbarung ist aufgrund eines zugrunde liegenden Problems fehlgeschlagen.

Lösung:

AWS Die Marketplace-Vereinbarung steht nach 15 Minuten noch aus

HTTP-Statuscode: 403

Ursache: Die AWS Marketplace-Vereinbarung war nicht erfolgreich und es sind 15 Minuten vergangen, seit die Anfrage gestellt wurde.

Lösung:

  • Wiederholen Sie die Anforderung alle 15 Minuten. Wenn das Problem weiterhin besteht, wenden Sie sich an das AWS Support Center und geben Sie Einzelheiten zu Ihrer Anforderung und dem aufgetretenen Fehler an.

MPAgreementBeingCreated

HTTP-Statuscode: 403

Ursache: Ihr Konto ist nicht berechtigt, auf dieses Modell zuzugreifen. Ihr AWS Marketplace-Abonnement für dieses Modell wird noch bearbeitet

Lösung:

  • Versuchen Sie es nach 15 Minuten erneut.

NotAuthorized

HTTP-Statuscode: 400

Ursache: Sie haben keine Berechtigung zum Ausführen dieser Aktion.

Lösung:

  • Überprüfen Sie Ihre IAM-Berechtigungen und stellen Sie sicher, dass Sie über die erforderlichen Rechte verfügen, um die angeforderte Aktion mit Amazon Bedrock-Ressourcen durchzuführen.

  • Wenn Sie eine IAM-Rolle verwenden, stellen Sie sicher, dass die Rolle über die entsprechenden Berechtigungen und Vertrauensbeziehungen verfügt.

  • Suchen Sie nach Unternehmensrichtlinien oder SCP, die Ihren Zugriff einschränken könnten.

RequestExpired

HTTP-Statuscode: 400

Ursache: Die Anforderung ist aufgrund abgelaufener Zeitstempel nicht mehr gültig.

Lösung:

  • Stellen Sie sicher, dass Ihre Systemuhr korrekt mit einer zuverlässigen Zeitquelle synchronisiert ist.

  • Wenn Sie Anforderungen aus verschiedenen Zeitzonen senden, achten Sie auf mögliche Abweichungen bei den Zeitstempeln.

ServiceUnavailable

HTTP-Statuscode: 503

Ursache: Der Dienst kann die Anfrage vorübergehend nicht bearbeiten. 503-Fehler deuten darauf hin, dass für den Dienst eine hohe Nachfrage oder vorübergehende Kapazitätsengpässe besteht. Dies hat nichts mit Ihren Kontingenten oder Preislimits auf Kontoebene zu tun (die ThrottlingException 429 zurückgeben).

Lösung:

Best Practices

  • Stellen Sie sicher, dass Ihre Anwendung 503-Statuscodes in Ihrer Fehlerbehandlungs- und Wiederholungslogik angemessen verarbeiten kann.

  • Suchen Sie im AWS Service Health Dashboard nach allen angekündigten Problemen oder geplanten Wartungsarbeiten, die sich auf den Service auswirken könnten.

Wenn Sie häufig auf 503-Fehler stoßen oder diese Ihren Betrieb erheblich beeinträchtigen, wenden Sie sich bitte an den AWS Support, um weitere Unterstützung und Anleitungen zu erhalten, die auf Ihren speziellen Anwendungsfall zugeschnitten sind.

ThrottlingException

HTTP-Statuscode: 429

Ursache: Die Anforderung wurde abgelehnt, da die Kontokontingente für Amazon Bedrock überschritten wurden.

Lösung:

ValidationError

HTTP-Statuscode: 400

Ursache: Die Eingabe erfüllt nicht die von Amazon Bedrock definierten Einschränkungen.

Lösung:

  • Überprüfen Sie die API-Dokumentation, um sicherzustellen, dass alle erforderlichen Parameter enthalten und korrekt formatiert sind.

  • Vergewissern Sie sich, dass Ihre Eingabewerte innerhalb der zulässigen Bereiche liegen oder den erwarteten Mustern entsprechen.

  • Wir empfehlen, alle spezifischen Validierungsregeln zu beachten, die in der API-Referenz für die von Ihnen verwendete Aktion aufgeführt sind.

ResourceNotFound

HTTP-Statuscode: 404

Ursache: Die angeforderte Ressource wurde nicht gefunden.

Lösung:

  • Überprüfen Sie die Richtigkeit der Modell-ID, des Endpunktnamens oder anderer Ressourcen-IDs in Ihrer Anforderung.

  • Implementieren Sie einen Fallback-Mechanismus, um alternative Modelle oder Endpunkte zu verwenden, wenn keine primäre Ressource gefunden wird.

Best Practices

  • Verwenden Sie ListFoundationModels, um mehr über die verfügbaren Amazon Bedrock Foundation-Modelle zu erfahren, die Sie verwenden können.

  • Wir empfehlen, einen regelmäßigen Synchronisierungsprozess zu implementieren, um Ihren lokalen Ressourcenkatalog zu aktualisieren.

Wenn Sie nach dem Ausprobieren dieser Lösungen weiterhin Probleme haben, wenden Sie sich an den AWS Support, um weitere Unterstützung und Anleitungen zu erhalten, die auf Ihren speziellen Anwendungsfall zugeschnitten sind.

Verbindungstimeout oder Reset bei Verbindungen mit langer Laufzeit oder im Leerlauf

Symptom: API-Aufrufe schlagen mit Verbindungsrücksetzungen oder Timeouts fehl, insbesondere bei Anfragen mit langer Laufzeit wie Streaming, erweitertem Denken oder umfangreichen Inferenzantworten, wenn der Datenverkehr über NAT-Gateways, Schnittstellen-VPC-Endpunkte oder Network Load Balancer geleitet wird. Symptome können auch als lange Kaltstartlatenz auftreten (z. B. dauert der erste Anruf nach einer Leerlaufzeit mehr als 70 Sekunden statt der üblichen Sekunden), wenn eine im Leerlauf befindliche Poolverbindung wiederverwendet wird, nachdem das Netzwerk sie stillschweigend unterbrochen hat.

Ursache: Für NAT-Gateways, Schnittstellen-VPC-Endpunkte und Network Load Balancer gilt ein fester Timeout von 350 Sekunden bei inaktiven Verbindungen. Wenn eine TCP-Verbindung länger als diesen Zeitraum inaktiv bleibt, wird die Verbindung getrennt, ohne den Client zu benachrichtigen. Der Client erkennt die unterbrochene Verbindung möglicherweise erst bei der nächsten Anfrage. Zu diesem Zeitpunkt muss er auf den OS-level TCP-Wiederholungsversuch oder das Timeout warten, bevor die Verbindung wiederhergestellt wird.

Wenn dies zutrifft:

  • Anwendungen, die auf Amazon EKS oder Amazon ECS ausgeführt werden und bei denen der Pod-Verkehr zu Amazon Bedrock über ein NAT-Gateway oder einen VPC-Schnittstellenendpunkt abgeht.

  • Anwendungen, die auf Amazon EC2-Instances hinter einem NAT-Gateway, einem Schnittstellen-VPC-Endpunkt für Amazon Bedrock oder einem Network Load Balancer ausgeführt werden.

  • Long-running Für überlastete Workloads, bei denen Amazon Bedrock-Client-Verbindungen in einem Verbindungspool zwischen Aufrufen inaktiv sind.

Lösung:

Um TCP-Keep-Alive auf dem Amazon Bedrock-Client zu aktivieren, müssen zwei Einstellungen zusammenarbeiten. Es reicht nicht aus, nur eine einzustellen.

  1. Aktivieren Sie TCP-Keep-Alive in Ihrem AWS SDK-Client. Das Config boto3-Objekt akzeptiert einen tcp_keepalive Parameter, dessen Standardeinstellung ist. False Stellen Sie ihn True bei der Erstellung des Amazon Bedrock-Clients auf ein:

    import boto3
from botocore.config import Config

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

    Weitere AWS SDKs finden Sie in der entsprechenden Dokumentation zur HTTP-Client-Konfiguration.

  2. Konfigurieren Sie das OS-level Keep-Alive-Intervall so, dass es vor dem Leerlauf-Timeout von 350 Sekunden ausgelöst wird. Linux ist standardmäßig auf net.ipv4.tcp_keepalive_time = 7200 (2 Stunden) eingestellt, was viel länger ist als das Leerlauf-Timeout für den NAT- oder VPC-Endpunkt, sodass SDK-level Keep-Alive allein keine Wirkung hat. Senken Sie die Kernel-Einstellung auf einen Wert, der sicher unter 350 Sekunden liegt (z. B. 45 Sekunden):

    sysctl -w net.ipv4.tcp_keepalive_time=45

    Wenden Sie auf Amazon EKS und Amazon ECS das sysctl im Pod oder in der TasksecurityContext, in einem Init-Container oder in einem benutzerdefinierten Knoten-AMI an. Stellen Sie es auf Amazon EC2 /etc/sysctl.d/ so ein, dass der Wert auch nach Neustarts erhalten bleibt.

Eine eingehendere Diskussion von TCP-Verbindungen mit langer Laufzeit im VPC-Netzwerk finden Sie unter Implementieren von TCP-Verbindungen mit langer Laufzeit in VPC-Netzwerken im Networking & Content Delivery Blog. AWS

Wenn Sie nach dem Anwenden beider Einstellungen weiterhin Verbindungsprobleme haben, wenden Sie sich an den Support, um weitere AWS Unterstützung zu erhalten.