# Objectifs d'Amazon Bedrock AgentCore Runtime
<a name="gateway-target-http-runtime"></a>

Vous pouvez ajouter un agent Amazon Bedrock AgentCore Runtime comme cible de passerelle. La passerelle envoie le trafic directement à l'agent d'exécution sans agrégation ni traduction de protocole. Contrairement aux cibles MCP qui combinent les fonctionnalités des outils dans un serveur MCP virtuel unifié, la cible AgentCore Runtime transmet les demandes et les réponses entre les clients et l'agent d'exécution sans modification.

L'ajout AgentCore d'une cible Runtime à votre passerelle est utile lorsque vous souhaitez :
+ Offrez une gestion centralisée des accès à vos agents d'exécution via un point de terminaison passerelle unique.
+ Utilisez l'authentification et l'observabilité intégrées de la passerelle pour vos agents d'exécution.
+ Acheminez les demandes vers des agents d'exécution spécifiques à l'aide d'un routage basé sur le chemin lorsque plusieurs cibles sont attachées à une passerelle.
+ Optimisez les performances de votre agent en utilisant l' AgentCore optimisation d'Amazon Bedrock pour générer des recommandations à partir des traces des agents, A/B tester les modifications avec le trafic en direct via la passerelle et déployer des configurations gagnantes. Pour plus d'informations, consultez la section [AgentCore Optimisation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/optimization.html).

**Topics**
+ [Principales considérations et limites](#gateway-target-http-runtime-considerations)
+ [Configuration cible](#gateway-target-http-runtime-config)
+ [Invocation d'une cible AgentCore d'exécution](#gateway-target-http-runtime-invoke)
+ [Autorisation de sortie](#gateway-target-http-runtime-auth)
+ [Impliquer le trafic via la passerelle](#gateway-target-http-runtime-source-validation)
+ [Comparaison des capacités avec les cibles MCP](#gateway-target-http-runtime-comparison)

## Principales considérations et limites
<a name="gateway-target-http-runtime-considerations"></a>

Lorsque vous travaillez avec des cibles AgentCore d'exécution, tenez compte des points suivants :
+ La passerelle envoie le trafic directement aux cibles AgentCore d'exécution sans fonctionnalités d'agrégation.
+ AgentCore Des cibles d'exécution peuvent être ajoutées aux passerelles pour lesquelles aucun type de protocole n'est défini. Ils ne peuvent pas être ajoutés aux passerelles de type protocole MCP.
+ Aucune synchronisation des capacités ni aucune recherche d'outil sémantique n'est disponible pour les cibles AgentCore d'exécution. Les clients doivent s'adresser à chaque cible individuellement par le biais d'un routage basé sur le chemin.
+ Server-Sent Le streaming d'événements (SSE) est pris en charge pour les cibles AgentCore d'exécution.
+ Les fonctions Lambda de l'intercepteur de requêtes et de réponses sont prises en charge en mode tampon. Les intercepteurs ne sont pas encore pris en charge en mode streaming.

## Configuration cible
<a name="gateway-target-http-runtime-config"></a>

Lorsque vous créez une cible AgentCore d'exécution, vous fournissez l'ARN d'exécution et un qualificatif facultatif. La passerelle résout le point de terminaison d'exécution en interne, vous n'avez donc pas besoin de créer vous-même l'URL d'exécution.

La configuration cible d'une cible AgentCore d'exécution utilise la structure suivante :

```
{
    "http": {
        "agentcoreRuntime": {
            "arn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID",
            "qualifier": "DEFAULT",
            "schema": {
                "source": {
                    "s3": {
                        "uri": "s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml"
                    }
                }
            }
        }
    }
}
```
+  **arn** (obligatoire) — L'ARN de l'agent Amazon Bedrock AgentCore Runtime.
+  **qualificatif** (facultatif) — Le qualificatif d'exécution. La valeur par défaut est `DEFAULT` .
+  **schéma** (facultatif) : schéma d'API qui décrit la structure de demande et de réponse de la cible d'exécution. 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.

  Pour les agents d'exécution qui utilisent les protocoles MCP ou A2A, un schéma par défaut est appliqué automatiquement et il n'est pas nécessaire d'en fournir un. Pour les agents d'exécution qui utilisent le protocole HTTP, vous devez fournir un schéma pour utiliser des barrières de sécurité.

  L'`schema`objet 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/agent-schema.yaml`).
  +  **InlinePayload** — Le contenu du schéma fourni directement sous forme de chaîne.

**Note**  
Si votre agent d'exécution utilise le protocole HTTP et que vous souhaitez appliquer des garde-fous via le moteur de politique de la passerelle, vous devez fournir un schéma. Pour les agents d'exécution qui utilisent les protocoles MCP ou A2A, un schéma par défaut est automatiquement appliqué.

## Invocation d'une cible AgentCore d'exécution
<a name="gateway-target-http-runtime-invoke"></a>

Pour appeler une cible AgentCore Runtime via la passerelle, envoyez une requête POST à l'URL d'invocation de la cible. Le format de l'URL est le suivant :

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

`{gatewayId}`Remplacez-le par votre ID de passerelle, `{region}` par la AWS région et `{targetName}` par le nom de la cible.

L'exemple suivant utilise curl pour appeler une cible AgentCore Runtime :

```
curl -X POST https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target/invocations \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer <token>" \
    -d '{"input": {"prompt": "Hello"}}'
```

Vous pouvez également utiliser le AgentCore SDK Amazon Bedrock en remplaçant l'URL du point de terminaison :

```
aws bedrock-agentcore invoke-agent-runtime \
    --endpoint-url https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target \
    --runtimeArn arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID
```

## Autorisation de sortie
<a name="gateway-target-http-runtime-auth"></a>

AgentCore Les cibles d'exécution prennent en charge les types d'autorisation sortante suivants :
+  **IAM (SigV4)** — La passerelle assume le rôle de service de passerelle pour obtenir les informations d'identification nécessaires à la signature des demandes adressées à la cible d'exécution. Lorsque vous configurez l'autorisation IAM, vous pouvez utiliser des politiques IAM pour restreindre l'accès exclusivement au rôle de passerelle, afin de garantir que toutes les demandes d'exécution transitent par la passerelle.
+  **Informations d'identification IAM de l'appelant** : la passerelle utilise les informations d'identification IAM de l'appelant pour signer les demandes adressées à la cible d'exécution. La passerelle joue un rôle au nom de l'appelant et signe la demande sortante avec l'identité de l'appelant.
+  **OAuth (JWT)** — 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 
+  Transfert de **jetons** : la passerelle valide le jeton entrant et le transmet à la cible d'exécution sans modification. Cela est utile lorsque le moteur d'exécution gère ses propres autorisations.

## Impliquer le trafic via la passerelle
<a name="gateway-target-http-runtime-source-validation"></a>

Vous pouvez équiper votre AgentCore environnement d'exécution d'une AgentCore passerelle afin que celle-ci devienne le point d'entrée unique et régi vers l'environnement d'exécution. Vous bénéficiez ainsi d'une autorisation basée sur des règles, d'Amazon Bedrock Guardrails, d'intercepteurs de requêtes et de réponses et d'une observabilité unifiée, le tout appliqué en dehors de l'environnement de l'agent. Pour une justification complète, voir [Façonner votre environnement d'exécution avec une AgentCore passerelle](runtime-security-best-practices.md#security-bp-front-with-gateway). Mais cela n'est utile que si vous ne pouvez pas contourner la passerelle et accéder directement au runtime. Vous pouvez désormais y parvenir, que le moteur d'exécution utilise l'autorisation entrante IAM (SigV4) ou OAuth (JWT).

Vous configurez cette restriction au moment de l'exécution. La passerelle estampille la source de chaque demande qu'elle transmet, et le moteur d'exécution valide cette source à l'entrée. Le mécanisme spécifique dépend du type d'autorisation entrante du runtime :
+  **Runtimes IAM (SigV4)** : associez une politique basée sur les ressources qui limite l'invocation au rôle d'exécution de votre passerelle. Pour connaître la politique et le renforcement des politiques de confiance nécessaires, consultez [Restreindre l'appel entrant IAM (SigV4) vers votre passerelle](runtime-oauth.md#runtime-restrict-iam-gateway).
+  **Runtimes OAuth (JWT)** : configurez `allowedWorkloadConfiguration` les environnements d'exécution `customJWTAuthorizer` pour autoriser uniquement la charge de travail de votre passerelle. Pour la configuration et la référence aux champs, voir [Restreindre l'invocation à votre passerelle](runtime-oauth.md#deploy-agent-allowed-workload).

## Comparaison des capacités avec les cibles MCP
<a name="gateway-target-http-runtime-comparison"></a>

Vous pouvez intégrer des serveurs MCP à la AgentCore passerelle Amazon Bedrock en utilisant deux approches : en utilisant le type de cible MCP en mode agrégation ou en utilisant le type de cible AgentCore Runtime. Le tableau suivant compare les fonctionnalités de chaque approche.


| Capacité | Passerelle MCP avec cibles MCP | AgentCore Cible d'exécution | 
| --- | --- | --- | 
| Tool/capability agrégation | Regroupe les capacités de toutes les cibles MCP dans un seul serveur MCP virtuel unifié. Les clients voient une `tools/list` réponse consolidée. | Fonctionne de manière isolée. La passerelle envoie le trafic directement à la cible sans fonctionnalités de fusion. Les clients doivent s'adresser à chaque cible individuellement par le biais d'un routage basé sur le chemin. | 
| Recherche d'outils sémantiques | Indexe les descriptions des outils et permet de les découvrir par le biais de requêtes en langage naturel. | Indisponible. La passerelle n'ingère ni n'indexe les fonctionnalités. Les clients doivent connaître le nom exact des outils ou utiliser le nom du serveur`tools/list`. | 
| Intercepteur de réponse Lambda | Prend en charge les intercepteurs de demandes et de réponses pour les opérations MCP non liées au streaming. | Prend en charge les fonctions Lambda de l'intercepteur de requêtes et de réponses en mode tampon. Les intercepteurs ne sont pas encore pris en charge en mode streaming. |