Configuration de la cible Création d'une cible de transfert HTTP Invocation d'une cible de transfert HTTP Autorisation de sortie

Cibles de transfert HTTP

Vous pouvez ajouter une cible de transfert HTTP pour acheminer le trafic via la passerelle vers n'importe quel point de terminaison HTTP. La passerelle transmet les demandes au point de terminaison cible sans traduction de protocole, agissant comme une couche proxy sécurisée. Les cibles passthrough sont donc idéales pour présenter les URL des agents, les API externes ou tout autre service HTTP auquel vous souhaitez accéder par le biais de l'authentification centralisée, de l'application des politiques et de l'observabilité de la passerelle.

L'ajout d'une cible HTTP passthrough à votre passerelle est utile lorsque vous souhaitez :

Des services d'agent frontal (tels que des agents A2A, des serveurs MCP externes ou des points de terminaison d'inférence personnalisés) basés sur un point de terminaison passerelle unique avec un contrôle d'accès unifié.
Acheminez le trafic vers des services externes tandis que la passerelle gère l'authentification entrante et l'injection d'informations d'identification sortantes.
Appliquez des politiques de passerelle telles que des barrières de sécurité et un contrôle d'accès aux demandes destinées à des points de terminaison externes.
Utilisez le routage basé sur le chemin (/{targetName}/{path}) pour accéder à plusieurs services externes via une seule passerelle.

Configuration de la cible

Lorsque vous créez une cible intermédiaire HTTP, vous fournissez l'URL du point de terminaison cible et un type de protocole qui indique le protocole d'application que la cible implémente. La passerelle utilise le type de protocole pour l'observabilité et l'évaluation des politiques, mais n'effectue pas de traduction de protocole.

La configuration cible d'une cible HTTP passthrough utilise la structure suivante :


{
    "http": {
        "passthrough": {
            "endpoint": "https://partner-agent.example.com",
            "protocolType": "A2A"
        }
    }
}

L'exemple suivant montre une cible intermédiaire dotée d'un protocole personnalisé et d'un schéma d'API explicite :


{
    "http": {
        "passthrough": {
            "endpoint": "https://my-service.example.com",
            "protocolType": "CUSTOM",
            "schema": {
                "source": {
                    "s3": {
                        "uri": "s3://DOC-EXAMPLE-BUCKET/service-schema.yaml"
                    }
                }
            }
        }
    }
}

point de terminaison (obligatoire) — URL HTTPS du service cible. La passerelle transmet les demandes à ce point de terminaison.
ProtocolType (obligatoire) — Protocole d'application implémenté par la cible. Valeurs valides :
- MCP— La cible est un serveur MCP. Utilisez-le lors du routage vers un seul serveur MCP auquel vous souhaitez accéder directement (non agrégé avec d'autres cibles MCP).
- A2A— La cible implémente le protocole Agent-to-Agent (A2A).
- INFERENCE— La cible est un point de terminaison d'inférence.
- CUSTOM— La cible implémente un protocole personnalisé ou propriétaire.
schéma (facultatif) — Schéma d'API qui décrit la structure de demande et de réponse de la cible intermédiaire. La passerelle utilise ce schéma pour activer les fonctionnalités du moteur de politiques telles que les glissières de sécurité. Le format du schéma est automatiquement détecté comme OpenAPI ou Smithy.

Le schéma requis dépend du type de protocole :
- Pour les types de A2A protocole MCP et, un schéma par défaut est appliqué automatiquement. Il n'est pas nécessaire de fournir un schéma, sauf si vous souhaitez remplacer le schéma par défaut.
- Pour les types de INFERENCE protocoles avec des fournisseurs connus (OpenAI, Anthropic ou Amazon Bedrock), un schéma par défaut est appliqué en fonction du domaine du point de terminaison.
- Pour les types de CUSTOM protocole, vous devez fournir un schéma pour utiliser des glissières de sécurité.
  
  L'schemaobjet contient un source qui indique où se trouve le contenu du schéma :
- s3 — Un URI S3 pointant vers le fichier de schéma (par exemple,s3://DOC-EXAMPLE-BUCKET/service-schema.yaml).
- InlinePayload — Le contenu du schéma fourni directement sous forme de chaîne.

Création d'une cible de transfert HTTP

Les exemples suivants créent une cible intermédiaire qui achemine vers différents types de points de terminaison : un agent A2A, un serveur MCP externe, un service IAM-authenticated interne et une API externe authentifiée par une clé d'API.

Exemple

AgentCore CLI

Route vers un agent A2A à l'aide d'un identifiant OAuth :


agentcore add gateway-target \
  --name partner-agent \
  --type passthrough \
  --passthrough-endpoint https://partner-agent.example.com \
  --passthrough-protocol A2A \
  --outbound-auth oauth \
  --credential-name partner-oauth \
  --gateway MyGateway
agentcore deploy

Route vers un serveur MCP externe à l'aide d'un identifiant OAuth :


agentcore add gateway-target \
  --name slack-mcp \
  --type passthrough \
  --passthrough-endpoint https://mcp-slack.example.com \
  --passthrough-protocol MCP \
  --outbound-auth oauth \
  --credential-name slack-oauth \
  --gateway MyGateway
agentcore deploy

Route vers un service interne à l'aide de l'authentification basée sur les rôles IAM (SigV4), avec un CUSTOM protocole et un schéma S3 :


agentcore add gateway-target \
  --name internal-service \
  --type passthrough \
  --passthrough-endpoint https://internal-service.example.com \
  --passthrough-protocol CUSTOM \
  --schema s3://amzn-s3-demo-bucket/internal-service-schema.yaml \
  --signing-service execute-api \
  --signing-region us-west-2 \
  --gateway MyGateway
agentcore deploy

Route vers une API externe à l'aide d'un identifiant de clé d'API :


agentcore add gateway-target \
  --name external-api \
  --type passthrough \
  --passthrough-endpoint https://api.example.com \
  --passthrough-protocol CUSTOM \
  --outbound-auth api-key \
  --credential-name my-api-key \
  --credential-parameter-name x-api-key \
  --gateway MyGateway
agentcore deploy

AWS CLI

Route vers un agent A2A à l'aide d'un identifiant OAuth :


aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "partner-agent",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://partner-agent.example.com",
                "protocolType": "A2A"
            }
        }
    },
    "credentialProviderConfigurations": [
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:token-vault/default/oauthcredentialprovider/partner-oauth"
                }
            }
        }
    ]
}'

Route vers un serveur MCP externe à l'aide d'un identifiant OAuth :


aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "slack-mcp",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://mcp-slack.example.com",
                "protocolType": "MCP"
            }
        }
    },
    "credentialProviderConfigurations": [
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:token-vault/default/oauthcredentialprovider/slack-oauth"
                }
            }
        }
    ]
}'

Route vers un service interne à l'aide de l'authentification basée sur les rôles IAM, avec un CUSTOM protocole et un schéma S3 :


aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "internal-service",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://internal-service.example.com",
                "protocolType": "CUSTOM",
                "schema": {
                    "source": {
                        "s3": {
                            "uri": "s3://DOC-EXAMPLE-BUCKET/internal-service-schema.yaml"
                        }
                    }
                }
            }
        }
    },
    "credentialProviderConfigurations": [
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ]
}'

Route vers une API externe à l'aide d'un identifiant de clé d'API :


aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "external-api",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://api.example.com",
                "protocolType": "CUSTOM"
            }
        }
    },
    "credentialProviderConfigurations": [
        {
            "credentialProviderType": "API_KEY",
            "credentialProvider": {
                "apiKeyCredentialProvider": {
                    "providerArn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:token-vault/default/apikeycredentialprovider/my-api-key",
                    "credentialParameterName": "x-api-key"
                }
            }
        }
    ]
}'

Invocation d'une cible de transfert HTTP

Pour appeler une cible intermédiaire HTTP via la passerelle, envoyez une demande à la cible à l'aide d'un routage basé sur le chemin. Le format de l'URL est le suivant :


https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/{path}

La passerelle transmet la demande {endpoint}/{path} à la cible. {gatewayId}Remplacez-le par votre ID de passerelle, {region} par la AWS région, {targetName} par le nom de la cible et {path} par le chemin à suivre.

L'exemple suivant envoie un message A2A à un agent partenaire via la passerelle :


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"
            }
        }
    }'

L'exemple suivant appelle un serveur MCP via la passerelle :


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"}'

Autorisation de sortie

Les cibles HTTP passthrough prennent en charge les types d'autorisation sortante suivants :

IAM (SigV4) (GATEWAY_IAM_ROLE) — La passerelle assume le rôle de service de passerelle pour signer les demandes adressées à la cible.
OAuth (OAUTH) — La passerelle récupère les jetons OAuth auprès des fournisseurs d'informations d'identification configurés dans la cible via le service d'identité Amazon Bedrock. AgentCore
Informations d'identification IAM de l'appelant (CALLER_IAM_CREDENTIALS) — La passerelle utilise l'identité IAM et les autorisations de l'appelant pour signer les demandes adressées à la cible à l'aide de SigV4. Disponible uniquement pour les passerelles avec AWS_IAM ou type d'AUTHENTICATE_ONLYautorisateur.
Token passthrough (JWT_PASSTHROUGH) — La passerelle valide le jeton entrant et le transmet à la cible sans modification.
Clé d'API (API_KEY) — La passerelle récupère une clé d'API auprès d'un fournisseur d'informations d'identification configuré dans le coffre de jetons et l'injecte dans les demandes sortantes sous forme d'en-tête de demande spécifié.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

AgentCore Temps d'exécution

Cibles d'inférence