View a markdown version of this page

Solución de códigos de error de la API de Amazon Bedrock - Amazon Bedrock
AccessDeniedExceptionFTUFormNotFilledIncompleteSignatureInternalFailureInvalidActionInvalidClientTokenIdAWS El acuerdo de Marketplace falló en 15 minutosAWS Acuerdo de Marketplace pendiente después de 15 minutosMPAgreementBeingCreatedNotAuthorizedRequestExpiredServiceUnavailableThrottlingExceptionValidationErrorResourceNotFoundSe agota el tiempo de espera de la conexión o se restablece en conexiones inactivas o de larga duración

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de códigos de error de la API de Amazon Bedrock

En esta sección se proporciona información detallada sobre los errores habituales que se pueden producir al utilizar las API de Amazon Bedrock, la causa del error y la solución para resolverlo.

AccessDeniedException

Código de estado HTTP: 403

Causa: no dispone de permisos suficientes para realizar la acción solicitada.

Solución:

  • Compruebe que el usuario o el rol de IAM tenga los permisos necesarios para la acción que está intentando realizar.

  • Si utiliza credenciales de seguridad temporales, asegúrese de que no hayan caducado.

FTUFormNotFilled

Código de estado HTTP: 404

Causa: no se han enviado los detalles del caso de uso del modelo para esta cuenta.

Solución:

  • Rellene el formulario de detalles del caso de uso de Anthropic antes de utilizar el modelo.

IncompleteSignature

Código de estado HTTP: 400

Causa: la firma de la solicitud no cumple con los AWS estándares.

Solución:

  • Asegúrese de utilizar una versión AWS del SDK compatible con Amazon Bedrock.

  • Compruebe que el identificador de la clave de AWS acceso y la clave secreta estén configurados correctamente.

  • Si firma las solicitudes de forma manual, le sugerimos que verifique el proceso de cálculo de firmas.

InternalFailure

Código de estado HTTP: 500

Causa: el procesamiento de la solicitud ha fallado debido a un error del servidor.

Solución:

InvalidAction

Código de estado HTTP: 400

Causa: la acción u operación solicitadas no son válidas.

Solución:

  • Le sugerimos que vuelva a comprobar la ortografía y el formato del nombre de la acción en la solicitud.

  • Compruebe que la llamada a la acción sea compatible con Amazon Bedrock y que esté correctamente documentada, tal como se muestra en la Referencia de la API de Amazon Bedrock.

  • Asegúrese de utilizar la versión más actualizada del AWS SDK o la CLI.

InvalidClientTokenId

Código de estado HTTP: 403

Causa: el identificador de X.509 certificado o clave de AWS acceso proporcionado no existe en nuestros registros.

Solución:

  • Compruebe que está utilizando el identificador de clave de AWS acceso correcto.

  • Si ha creado nuevas claves de acceso recientemente, asegúrese de utilizar las nuevas credenciales y no las antiguas.

AWS El acuerdo de Marketplace falló en 15 minutos

Código de estado HTTP: 403

Causa: el AWS Marketplace Agreement falló debido a un problema subyacente.

Solución:

AWS Acuerdo de Marketplace pendiente después de 15 minutos

Código de estado HTTP: 403

Causa: el Acuerdo de AWS Marketplace no se ha realizado correctamente y han pasado 15 minutos desde que se hizo la solicitud.

Solución:

  • Inténtelo de nuevo en 15 minutos. Si el problema persiste, contacte con el centro de soporte de AWS y proporcione detalles sobre la solicitud y el error que se está produciendo.

MPAgreementBeingCreated

Código de estado HTTP: 403

Causa: su cuenta no está autorizada a acceder a este modelo. Tu suscripción a AWS Marketplace para este modelo aún se está procesando

Solución:

  • Inténtelo de nuevo en 15 minutos.

NotAuthorized

Código de estado HTTP: 400

Causa: no tiene permiso para realizar esta acción.

Solución:

  • Revise sus permisos de IAM y asegúrese de que dispone de los derechos necesarios para realizar la acción solicitada en los recursos de Amazon Bedrock.

  • Si utiliza un rol de IAM, compruebe que dicho rol tenga los permisos y las relaciones de confianza adecuados.

  • Compruebe si hay políticas organizativas o políticas de control de servicios que puedan estar restringiendo su acceso.

RequestExpired

Código de estado HTTP: 400

Causa: la solicitud ha dejado de ser válida porque las marcas temporales han caducado.

Solución:

  • Asegúrese de que el reloj del sistema esté sincronizado correctamente con un origen de hora fiable.

  • Si realiza solicitudes desde diferentes zonas horarias, tenga en cuenta las posibles discrepancias en las marcas temporales.

ServiceUnavailable

Código de estado HTTP: 503

Causa: el servicio no puede tramitar la solicitud temporalmente. Los errores 503 indican que el servicio tiene una gran demanda o limitaciones de capacidad temporales. Esto no está relacionado con las cuotas o los límites de tarifas a nivel de cuenta (que arrojan 429 ThrottlingException puntos).

Solución:

Prácticas recomendadas

  • Asegúrese de que la aplicación pueda gestionar los códigos de estado 503 de forma adecuada en su lógica de gestión de errores y reintentos.

  • Consulte el AWS Service Health Dashboard para ver si hay algún problema anunciado o mantenimiento programado que pueda afectar al servicio.

Si experimenta errores 503 frecuentes o estos afectan significativamente a las operaciones, póngase en contacto con AWS Support para obtener más ayuda y orientación adaptadas a su caso de uso específico.

ThrottlingException

Código de estado HTTP: 429

Causa: la solicitud se ha denegado porque se han superado las cuotas de cuentas de Amazon Bedrock.

Solución:

ValidationError

Código de estado HTTP: 400

Causa: la entrada no satisface las limitaciones especificadas por Amazon Bedrock.

Solución:

  • Revise la documentación de la API para asegurarse de que se han incluido todos los parámetros necesarios y que tengan el formato correcto.

  • Compruebe que los valores de entrada estén dentro de los intervalos permitidos o que se ajusten a los patrones esperados.

  • Le sugerimos que preste atención a las reglas de validación específicas que se mencionen en la referencia de la API para la acción que esté realizando.

ResourceNotFound

Código de estado HTTP: 404

Causa: no se ha encontrado el recurso solicitado.

Solución:

  • Compruebe que el ID del modelo, el nombre del punto de conexión u otros identificadores de recursos de la solicitud sean correctos.

  • Implemente un mecanismo alternativo para utilizar modelos o puntos de conexión alternativos cuando no se encuentre un recurso principal.

Prácticas recomendadas

  • Úselo ListFoundationModelspara obtener información sobre los modelos de bases Amazon Bedrock disponibles que puede utilizar.

  • Le sugerimos implementar un proceso de sincronización periódico para actualizar su catálogo de recursos local.

Si sigue teniendo problemas después de probar estas soluciones, contacte con AWS Support para obtener más ayuda y orientación adaptadas a su caso de uso específico.

Se agota el tiempo de espera de la conexión o se restablece en conexiones inactivas o de larga duración

Síntoma: las llamadas a la API fallan cuando se restablece la conexión o se agota el tiempo de espera, especialmente en el caso de solicitudes de larga duración, como la transmisión, la reflexión prolongada o las respuestas de inferencia extensas, cuando el tráfico pasa por puertas de enlace NAT, puntos finales de VPC de interfaz o balanceadores de carga de red. Los síntomas también pueden aparecer como una latencia prolongada de arranque en frío (por ejemplo, la primera llamada tras un período de inactividad tarda más de 70 segundos en lugar de los habituales) cuando una conexión agrupada inactiva se reutiliza después de que la red la haya interrumpido silenciosamente.

Causa: las puertas de enlace NAT, los puntos finales de la interfaz de VPC y los balanceadores de carga de red tienen un tiempo de espera de conexión inactivo fijo de 350 segundos. Si una conexión TCP permanece inactiva durante más tiempo que este período, la conexión se interrumpe sin avisar al cliente. Es posible que el cliente no detecte la conexión interrumpida hasta la siguiente solicitud, momento en el que debe esperar a que se vuelva a intentar el OS-level TCP o se agote el tiempo de espera antes de restablecer la conexión.

Cuando esto ocurra:

  • Aplicaciones que se ejecutan en Amazon EKS o Amazon ECS, donde el tráfico de los pods hacia Amazon Bedrock sale a través de una puerta de enlace NAT o un punto final de interfaz de VPC.

  • Aplicaciones que se ejecutan en instancias de Amazon EC2 detrás de una puerta de enlace NAT, un punto de enlace de VPC de interfaz para Amazon Bedrock o un Network Load Balancer.

  • Long-running o cargas de trabajo en ráfagas en las que las conexiones de los clientes de Amazon Bedrock permanecen inactivas en un grupo de conexiones entre llamadas.

Solución:

La activación de TCP keep-alive en el cliente Amazon Bedrock requiere que dos configuraciones funcionen juntas. Establecer solo uno no es suficiente.

  1. Habilite TCP keep-alive en su cliente AWS SDK. El Config objeto boto3 acepta un tcp_keepalive parámetro, cuyo valor predeterminado es. False Configúrelo en True al crear el cliente Amazon Bedrock:

    import boto3
from botocore.config import Config

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

    Para ver otros SDK de AWS, consulte la documentación de configuración del cliente HTTP correspondiente.

  2. Configure el intervalo OS-level Keep-Alive para que se active antes de que se agote el tiempo de inactividad de 350 segundos. El valor predeterminado de Linux es net.ipv4.tcp_keepalive_time = 7200 (2 horas), que es mucho más largo que el tiempo de espera de inactividad del punto final de NAT o VPC, SDK-level por lo que mantener vivo por sí solo no tiene ningún efecto. Reduzca la configuración del núcleo a un valor seguro inferior a 350 segundos (por ejemplo, 45 segundos):

    sysctl -w net.ipv4.tcp_keepalive_time=45

    En Amazon EKS y Amazon ECS, aplique el sysctl en el pod o la tareasecurityContext, en un contenedor de inicio o en una AMI de nodo personalizado. En Amazon EC2, configúrelo /etc/sysctl.d/ para que el valor se mantenga tras los reinicios.

Para obtener más información sobre las conexiones TCP de larga duración en las redes de VPC, consulte Implementación de conexiones TCP de larga duración en las redes de VPC en AWS el blog Redes y entrega de contenido.

Si sigue teniendo problemas de conexión después de aplicar ambas configuraciones, póngase en contacto con AWS Support para obtener más ayuda.