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.
Destinos de acceso HTTP
Puede agregar un destino de acceso HTTP para enrutar el tráfico a través de la puerta de enlace a cualquier punto final HTTP. La puerta de enlace reenvía las solicitudes al punto final de destino sin necesidad de traducir el protocolo, actuando como una capa de proxy segura. Esto hace que los objetivos de acceso directo sean ideales para las URL de los agentes frontales, las API externas o cualquier servicio HTTP al que desee acceder mediante la autenticación, la aplicación de políticas y la observabilidad centralizadas de la puerta de enlace.
Añadir un destino de acceso HTTP a tu puerta de enlace es útil cuando quieres:
-
Servicios de intermediación (como agentes A2A, servidores MCP externos o terminales de inferencia personalizados) detrás de un único punto final de puerta de enlace con control de acceso unificado.
-
Dirija el tráfico a servicios externos mientras la puerta de enlace administra la autenticación entrante y la inyección de credenciales salientes.
-
Aplica políticas de puerta de enlace, como las barreras de protección y el control de acceso, a las solicitudes destinadas a puntos finales externos.
-
Utilice el enrutamiento basado en rutas (
/{targetName}/{path}) para llegar a varios servicios externos a través de una única puerta de enlace.
Temas
Configuración de destino
Al crear un destino de acceso directo HTTP, se proporciona la URL del punto final de destino y un tipo de protocolo que indica el protocolo de aplicación que implementa el destino. La puerta de enlace usa el tipo de protocolo para la observabilidad y la evaluación de políticas, pero no realiza la traducción de protocolos.
La configuración de destino para un destino de acceso directo HTTP utiliza la siguiente estructura:
{ "http": { "passthrough": { "endpoint": "https://partner-agent.example.com", "protocolType": "A2A" } } }
El siguiente ejemplo muestra un destino de acceso directo con un protocolo personalizado y un esquema de API explícito:
{ "http": { "passthrough": { "endpoint": "https://my-service.example.com", "protocolType": "CUSTOM", "schema": { "source": { "s3": { "uri": "s3://DOC-EXAMPLE-BUCKET/service-schema.yaml" } } } } } }
-
punto final (obligatorio): la URL HTTPS del servicio de destino. La puerta de enlace reenvía las solicitudes a este punto final.
-
ProtocolType (obligatorio): el protocolo de aplicación que implementa el destino. Valores válidos:
-
MCP— El objetivo es un servidor MCP. Utilícelo al enrutar a un único servidor MCP al que desee acceder directamente (no agregarlo a otros destinos MCP). -
A2A— El destino implementa el protocolo Agent-to-Agent (A2A). -
INFERENCE— El objetivo es un punto final de inferencia. -
CUSTOM— El objetivo implementa un protocolo personalizado o propietario.
-
-
esquema (opcional): el esquema de la API que describe la estructura de solicitudes y respuestas del objetivo de acceso directo. La puerta de enlace usa este esquema para habilitar las funciones del motor de políticas, como las barreras de protección. El formato del esquema se detecta automáticamente como OpenAPI o Smithy.
El requisito del esquema depende del tipo de protocolo:
-
Para los tipos de
A2AprotocoloMCPy, el esquema predeterminado se aplica automáticamente. No es necesario que proporciones un esquema a menos que quieras anular el predeterminado. -
Para los tipos de
INFERENCEprotocolo con proveedores conocidos (OpenAI, Anthropic o Amazon Bedrock), se aplica un esquema predeterminado en función del dominio del punto final. -
Para los tipos de
CUSTOMprotocolo, debe proporcionar un esquema para usar barandas.El
schemaobjeto contiene unsourceque especifica dónde se encuentra el contenido del esquema: -
s3: un URI de S3 que apunta al archivo de esquema (por ejemplo,
s3://DOC-EXAMPLE-BUCKET/service-schema.yaml). -
inlinePayload: el contenido del esquema se proporciona directamente como una cadena.
-
Creación de un destino de acceso HTTP
En los siguientes ejemplos, se crea un destino de acceso directo que se dirige a diferentes tipos de puntos finales: un agente A2A, un servidor MCP externo, un servicio IAM-authenticated interno y una API externa autenticada con una clave de API.
ejemplo
Invocar un destino de acceso HTTP
Para invocar un destino de acceso HTTP a través de la puerta de enlace, envíe una solicitud al destino mediante un enrutamiento basado en la ruta. El formato de la dirección URL es:
https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/{path}
La puerta de enlace reenvía la solicitud al {endpoint}/{path} destino. {gatewayId}Sustitúyala por tu ID de puerta de enlace, por la AWS región, {targetName} por el nombre del destino y {path} por la ruta a reenviar. {region}
El siguiente ejemplo envía un mensaje A2A a un agente asociado a través de la puerta de enlace:
curl -X POST https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/partner-agent/invocations \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{ "jsonrpc": "2.0", "id": "req-001", "method": "message/send", "params": { "message": { "role": "user", "parts": [{"kind": "text", "text": "What is the stock price of AMZN?"}], "messageId": "msg-001" } } }'
El siguiente ejemplo llama a un servidor MCP a través de la puerta de enlace:
curl -X POST https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/slack-mcp/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}'
Métodos HTTP compatibles
La puerta de enlace admite los métodos HTTP que utilizan los protocolos que implementan los objetivos de acceso: servidores MCP, agentes A2A y puntos finales de inferencia. Estos protocolos se basan en un subconjunto específico de métodos para invocar los servicios y enrutar el tráfico.
La puerta de enlace admite los siguientes métodos HTTP:
-
POST— Todos los protocolos de destino de acceso directo lo utilizan como método principal. MCP usa POST para enviar JSON-RPC mensajes, A2A usa POST para enviar mensajes y administrar tareas, y los terminales de inferencia usan POST para completar y enviar solicitudes de chat. -
GET— MCP lo utiliza para las suscripciones de SSE Stream, A2A para recuperar el estado de las tareas y enumerarlas, y los puntos finales de inferencia para los modelos de listas. -
DELETE— Lo utilizan A2A para eliminar las configuraciones de notificaciones push y los puntos finales de inferencia para eliminar recursos.
La puerta de enlace no admite PATCH métodos PUT ni. HEAD OPTIONS Los objetivos de transferencia están diseñados para invocar servicios y enrutar el tráfico, y estos métodos están fuera de ese ámbito.
Si un cliente envía una solicitud con un método HTTP no compatible, la puerta de enlace devuelve un error.
Autorización saliente
Los destinos de acceso HTTP admiten los siguientes tipos de autorización saliente:
-
IAM (SIGv4) (
GATEWAY_IAM_ROLE): la puerta de enlace asume la función de servicio de puerta de enlace para firmar las solicitudes en el destino. -
OAuth (
OAUTH): la puerta de enlace recupera los tokens de OAuth de los proveedores de credenciales configurados en el destino a través del servicio de identidad de Amazon Bedrock. AgentCore -
Credenciales de IAM de la persona que llama (
CALLER_IAM_CREDENTIALS): la puerta de enlace utiliza la identidad de IAM y los permisos de la persona que llama para firmar las solicitudes dirigidas al destinatario mediante SIGv4. Solo está disponible para puertas de enlace con o tipo de autorizador.AWS_IAMAUTHENTICATE_ONLY -
Token passthrough (
JWT_PASSTHROUGH): la puerta de enlace valida el token entrante y lo pasa al destino sin modificarlo. -
Clave de API (
API_KEY): la puerta de enlace recupera una clave de API de un proveedor de credenciales configurado en el almacén de tokens y la inyecta en las solicitudes salientes como un encabezado de solicitud específico.
