AgentCore Gateway HTTP Passthrough: A UK Production Gate for B2B Backends

HTTP passthrough is the B2B front door — not another MCP merge

Amazon Bedrock AgentCore Gateway supports HTTP passthrough targets: the gateway forwards requests to an HTTPS endpoint without protocol translation, acting as a secure proxy with unified inbound auth, outbound credential injection, policy/Guardrails (when a schema is available), and observability. Official docs position passthrough for agent URLs, external APIs, A2A agents, external MCP servers, and custom inference endpoints, addressed by path-based routing.

This is a different production pattern from MCP targets (capability sync / semantic tool search / aggregation) and from Runtime targets (direct forward to an AgentCore Runtime agent — already covered in our Runtime targets UK production gate). Use passthrough when you need to front an existing HTTP/B2B backend through one governed gateway URL.

Network and gateway architecture

What AWS documents (facts for CAB)

Release-note placement: AWS documents passthrough in the same Gateway HTTP-targets wave as Runtime targets GA (not as a Sep-only headline). Treat the developer guide as the contract for CAB — not a marketing month label.

Contrast: MCP vs Runtime vs HTTP passthrough

Passthrough MCP protocolType is still direct route to one MCP server — not the aggregated MCP-target experience.

Adjacent Gateway items (brief — keep focus on passthrough)

• Configurable rate limits (Aug 2026 release notes): dimensional RPS/RPM, token TPM, connection rates — tighten multi-tenant fairness; fails open on transient enforcement errors.
• Enforce inbound-from-gateway (Runtime): block direct Runtime invoke via aws:SourceArn (IAM) or allowedWorkloadConfiguration (JWT). Pair with passthrough when the downstream is Runtime; for pure HTTP backends, rely on gateway auth + outbound credentials instead.
• Do not reopen the full Runtime-targets GA checklist here — link that playbook for Runtime-specific gates.

UK production gate — numbered steps

1. Pick the right target type before you write IaC

1. If the backend is an AgentCore Runtime agent → use Runtime target (and gateway-only invoke).
2. If you need aggregated MCP tools → use MCP target.
3. If you are fronting a partner HTTPS API / A2A / single external MCP / custom inference → HTTP passthrough.
4. Record protocolType explicitly (CUSTOM for most B2B REST) so observability and policy evaluation stay meaningful.

2. Region, DPIA and endpoint hygiene

1. Prefer eu-west-1 / eu-west-2 for UK data-path notes where architecture allows.
2. Endpoint must be HTTPS; document data residency of the partner service.
3. For CUSTOM, store OpenAPI/Smithy in an approved S3 bucket (or inline) before you claim Guardrails coverage.
4. Note method limits: design clients for POST/GET/DELETE only.

3. Wire auth correctly (inbound and outbound)

1. Choose gateway inbound authorizer (JWT or IAM) consistent with callers.
2. Select outbound: OAUTH, API_KEY, GATEWAY_IAM_ROLE, CALLER_IAM_CREDENTIALS, or JWT_PASSTHROUGH.
3. Never embed long-lived partner secrets in agent code — inject via AgentCore Identity / token vault.
4. For sticky B2B sessions, configure stickiness so weighted routes do not bounce mid-session.

4. Prove path routing and negative cases

1. Invoke /{targetName}/{path} and confirm the partner receives /{path} with expected auth headers.
2. Negative test: unsupported methods return gateway errors (not silent partner 405 confusion).
3. Negative test: caller without gateway credentials cannot reach the partner “around” the gateway if network policy allows only gateway egress.
4. If Guardrails are in scope, attach schema and prove a blocked prompt/tool path in non-prod.

5. CAB evidence pack

• Architecture diagram: client → Gateway → passthrough target → partner HTTPS.
• protocolType, schema source, outbound auth type, Region.
• Rate-limit dimensions (if multi-tenant) from the Aug 2026 controls — optional but recommended.
• Link to Runtime-targets playbook only if a Runtime sibling exists; do not duplicate that gate.
• DPIA delta for partner data and token passthrough.

Closing

HTTP passthrough lets UK platform teams put one governed front door in front of messy B2B and agent HTTP estates — without pretending those backends are MCP aggregates or AgentCore Runtimes. Choose the target type deliberately, lock Region/auth/schema, prove path routing and method limits, then promote with CAB evidence. Keep rate limits and inbound-from-gateway as adjacent controls, and keep Runtime-target GA work on its own playbook.