# HTTP-Passthrough-Ziele Sie können ein HTTP-Passthrough-Ziel hinzufügen, um den Datenverkehr über das Gateway an einen beliebigen HTTP-Endpunkt weiterzuleiten. Das Gateway leitet Anfragen ohne Protokollübersetzung an den Zielendpunkt weiter und fungiert so als sichere Proxyschicht. Dadurch eignen sich Passthrough-Ziele ideal für Front-Agent-URLs, externe APIs oder andere HTTP-Dienste, auf die Sie über die zentrale Authentifizierung, Richtliniendurchsetzung und Beobachtbarkeit des Gateways zugreifen möchten. Das Hinzufügen eines HTTP-Passthrough-Ziels zu Ihrem Gateway ist nützlich, wenn Sie: + Front-Agent-Dienste (wie A2A-Agenten, externe MCP-Server oder benutzerdefinierte Inferenzendpunkte) hinter einem einzigen Gateway-Endpunkt mit einheitlicher Zugriffskontrolle. + Leiten Sie den Datenverkehr an externe Dienste weiter, während das Gateway die eingehende Authentifizierung und die Eingabe ausgehender Anmeldeinformationen verwaltet. + Wenden Sie Gateway-Richtlinien wie Leitplanken und Zugriffskontrolle auf Anfragen an, die für externe Endgeräte bestimmt sind. + Verwenden Sie pfadbasiertes Routing (`/{targetName}/{path}`), um mehrere externe Dienste über ein einziges Gateway zu erreichen. **Topics** + [Zielkonfiguration](#gateway-target-http-passthrough-config) + [Ein HTTP-Passthrough-Ziel erstellen](#gateway-target-http-passthrough-create) + [Aufrufen eines HTTP-Passthrough-Ziels](#gateway-target-http-passthrough-invoke) + [Ausgehende Autorisierung](#gateway-target-http-passthrough-auth) ## Zielkonfiguration Wenn Sie ein HTTP-Passthrough-Ziel erstellen, geben Sie die Zielendpunkt-URL und einen Protokolltyp an, der das Anwendungsprotokoll angibt, das das Ziel implementiert. Das Gateway verwendet den Protokolltyp für die Beobachtbarkeit und die Richtlinienbewertung, führt jedoch keine Protokollübersetzung durch. Die Zielkonfiguration für ein HTTP-Passthrough-Ziel verwendet die folgende Struktur: ``` { "http": { "passthrough": { "endpoint": "https://partner-agent.example.com", "protocolType": "A2A" } } } ``` Das folgende Beispiel zeigt ein Passthrough-Ziel mit einem benutzerdefinierten Protokoll und einem expliziten API-Schema: ``` { "http": { "passthrough": { "endpoint": "https://my-service.example.com", "protocolType": "CUSTOM", "schema": { "source": { "s3": { "uri": "s3://DOC-EXAMPLE-BUCKET/service-schema.yaml" } } } } } } ``` + **endpoint** (erforderlich) — Die HTTPS-URL des Zieldienstes. Das Gateway leitet Anfragen an diesen Endpunkt weiter. + **ProtocolType** (erforderlich) — Das Anwendungsprotokoll, das das Ziel implementiert. Zulässige Werte: + `MCP`— Das Ziel ist ein MCP-Server. Verwenden Sie dies, wenn Sie zu einem einzelnen MCP-Server weiterleiten, auf den Sie direkt zugreifen möchten (nicht aggregiert mit anderen MCP-Zielen). + `A2A`— Das Ziel implementiert das Agent-to-Agent (A2A) -Protokoll. + `INFERENCE`— Das Ziel ist ein Inferenzendpunkt. + `CUSTOM`— Das Ziel implementiert ein benutzerdefiniertes oder proprietäres Protokoll. + **schema** (optional) — Das API-Schema, das die Anforderungs- und Antwortstruktur des Passthrough-Ziels beschreibt. Das Gateway verwendet dieses Schema, um Policy-Engine-Funktionen wie Leitplanken zu aktivieren. Das Schemaformat wird automatisch entweder als OpenAPI oder Smithy erkannt. Die Schemaanforderung hängt vom Protokolltyp ab: + Für `A2A` Protokolltypen `MCP` und -typen wird automatisch ein Standardschema angewendet. Sie müssen kein Schema angeben, es sei denn, Sie möchten das Standardschema überschreiben. + Für `INFERENCE` Protokolltypen mit bekannten Anbietern (OpenAI, Anthropic oder Amazon Bedrock) wird ein Standardschema angewendet, das auf der Endpunktdomäne basiert. + Für `CUSTOM` Protokolltypen müssen Sie ein Schema zur Verwendung von Guardrails angeben. Das `schema` Objekt enthält ein`source`, das angibt, wo sich der Schemainhalt befindet: + **s3** — Ein S3-URI, der auf die Schemadatei verweist (z. B.`s3://DOC-EXAMPLE-BUCKET/service-schema.yaml`). + **inlinePayload** — Der direkt als Zeichenfolge bereitgestellte Schemainhalt. ## Ein HTTP-Passthrough-Ziel erstellen In den folgenden Beispielen wird ein Passthrough-Ziel erstellt, das an verschiedene Arten von Endpunkten weiterleitet: einen A2A-Agenten, einen externen MCP-Server, einen IAM-authenticated internen Dienst und eine externe API, die mit einem API-Schlüssel authentifiziert wird. **Example** 1. Mit OAuth-Anmeldeinformationen zu einem A2A-Agenten weiterleiten: ``` 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 ``` Mit OAuth-Anmeldeinformationen zu einem externen MCP-Server weiterleiten: ``` 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 ``` Weiterleitung zu einem internen Dienst mithilfe der rollenbasierten IAM-Authentifizierung (SigV4) mit einem Protokoll und einem S3-Schema: `CUSTOM` ``` 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 ``` Mit einem API-Schlüssel zu einer externen API weiterleiten: ``` 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 ``` 1. Mit OAuth-Anmeldeinformationen zu einem A2A-Agenten weiterleiten: ``` 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" } } } ] }' ``` Mit OAuth-Anmeldeinformationen zu einem externen MCP-Server weiterleiten: ``` 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" } } } ] }' ``` Weiterleitung zu einem internen Dienst mithilfe der rollenbasierten IAM-Authentifizierung mit einem Protokoll und einem S3-Schema: `CUSTOM` ``` 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"} ] }' ``` Mithilfe eines API-Schlüssels zu einer externen API weiterleiten: ``` 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" } } } ] }' ``` ## Aufrufen eines HTTP-Passthrough-Ziels Um ein HTTP-Passthrough-Ziel über das Gateway aufzurufen, senden Sie mithilfe von pfadbasiertem Routing eine Anfrage an das Ziel. Das URL-Format ist: ``` https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/{path} ``` Das Gateway leitet die Anfrage an das Ziel `{endpoint}/{path}` weiter. `{gatewayId}`Ersetzen Sie es durch Ihre Gateway-ID, `{region}` durch die AWS Region, `{targetName}` durch den Zielnamen und durch den Pfad, `{path}` den Sie weiterleiten möchten. Im folgenden Beispiel wird eine A2A-Nachricht über das Gateway an einen Partneragenten gesendet: ``` 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 " \ -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" } } }' ``` Im folgenden Beispiel wird ein MCP-Server über das Gateway aufgerufen: ``` 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 " \ -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' ``` ## Ausgehende Autorisierung HTTP-Passthrough-Ziele unterstützen die folgenden Autorisierungstypen für ausgehende Anfragen: + **IAM (SigV4) (`GATEWAY_IAM_ROLE`)** — Das Gateway übernimmt die Gateway-Servicerolle, um Anfragen an das Ziel zu signieren. + **OAuth** (`OAUTH`) — Das Gateway ruft über den Amazon Bedrock Identity Service OAuth-Token von Anmeldeinformationsanbietern ab, die im Ziel konfiguriert sind. AgentCore + **IAM-Anmeldeinformationen des Anrufers** (`CALLER_IAM_CREDENTIALS`) — Das Gateway verwendet die IAM-Identität und die Berechtigungen des Anrufers, um Anfragen an das Ziel mithilfe von SigV4 zu signieren. Nur für Gateways mit Autorisierungstyp oder verfügbar. `AWS_IAM` `AUTHENTICATE_ONLY` + **Token-Passthrough** (`JWT_PASSTHROUGH`) — Das Gateway validiert das eingehende Token und leitet es unverändert an das Ziel weiter. + **API-Schlüssel** (`API_KEY`) — Das Gateway ruft einen API-Schlüssel von einem im Token-Vault konfigurierten Anmeldeinformationsanbieter ab und fügt ihn als angegebenen Anforderungsheader in ausgehende Anfragen ein.