AWS MCP Gateway: Three Shapes AWS Ships for MCP

Short answer: An AWS MCP gateway is not one product. AWS documents three distinct AWS-side shapes, and they solve different problems. Amazon Bedrock AgentCore Gateway is a fully managed gateway that converts APIs, Lambda functions and existing services into MCP-compatible tools and fronts agents, HTTP services and model routing through one endpoint. The AWS MCP Server is a managed remote MCP server that exposes AWS operations to a client. A self-hosted MCP server on Lambda with API Gateway, Amazon ECS, Amazon EKS or Amazon EC2 is the pattern set for running the front yourself. This page maps the three, says which scenario each one fits, and points to the official AWS document that settles each.

Key takeaways

• "AWS MCP gateway" describes three AWS-side shapes — a managed gateway, a managed remote MCP server, and a self-hosted MCP server — not one service, and the three are documented in different places.
• AgentCore Gateway is the managed gateway: it turns APIs, Lambda functions and existing services into MCP-compatible tools, and its three target categories (MCP, HTTP, inference) decide whether traffic is aggregated, passed through, or routed to a model.
• The AWS MCP Server is a managed remote MCP server for AWS operations, with two documented authentication paths; it is not a tool gateway for your own APIs.
• When you host it yourself, AWS Prescriptive Guidance lists five patterns to choose between, and the choice turns on scaling, security, cost and operational preference — not on a feature checklist.
• Start by writing one line: are you exposing AWS's own capabilities to an agent, or exposing your APIs to an agent? That line picks the shape, and the official document under it is where every number lives.

---

aws mcp gateway: the three shapes AWS actually ships

The phrase is a search term, not an AWS product name. AWS does not sell a service called "AWS MCP gateway"; it documents three separate ways to put a gateway in front of tools, each answering a different question.

The first shape is a managed gateway: Amazon Bedrock AgentCore Gateway. AWS describes it as a fully managed AI gateway providing a single secure entry point for agentic traffic. It converts APIs, Lambda functions and existing services into Model Context Protocol (MCP)-compatible tools; fronts other agents and HTTP services through passthrough targets, including agent-to-agent traffic; and routes inference across model providers through a model-based routing endpoint. AWS lists OpenAPI, Smithy and Lambda as tool input types and names six capabilities on that page — Security Guard, Translation, Composition, Secure Credential Exchange, Semantic Tool Selection and an Infrastructure Manager. Read this shape first if the question is how to expose many existing things to an agent without writing a tool server for each.

The second shape is a managed remote MCP server: the AWS MCP Server, documented in the Agent Toolkit for AWS. It is a managed remote MCP server that gives a client access to AWS operations over MCP, and AWS documents two authentication paths for it — OAuth for browser and web clients, and SigV4 for terminal and IDE-based agents that can run a local proxy. Note carefully what it is and is not: it is an MCP server that exposes AWS's own surface, not a gateway that aggregates your own services. Teams that conflate the two end up looking for target configuration on a page that only documents how to connect a client.

The third shape is self-hosted: you run the MCP server, and possibly a front, on your own compute. AWS Prescriptive Guidance has a dedicated guide, Model Context Protocol (MCP) Deployment Patterns on AWS, whose stated objective is to help you evaluate five AWS deployment patterns for hosting remote MCP servers: Amazon Bedrock AgentCore, Lambda with API Gateway, Amazon ECS, Amazon EKS, and Amazon EC2. It also links an open-source repository of implementation examples and deployment scripts. This is the shape to read when the first two do not fit — because the runtime is yours, because the network is specific, or because the service already exists on your own compute.

Three shapes, three documents, three different jobs. The rest of this page walks each one and says which scenario it fits.

mcp gateway open source: what AWS publishes openly, and where it stops

The phrase "MCP gateway open source" pulls in two different questions, and AWS's own pages separate them cleanly. One question is whether the gateway software is open source. The other is whether AWS publishes open-source pieces you can build with. The answers are not the same, and mixing them up is how a team spends a week looking for a repository that was never offered.

On the first question, the managed gateway is exactly that — managed. AgentCore Gateway is described by AWS as a fully managed service with serverless infrastructure that scales on demand; you configure it and consume its endpoint, and AWS operates it. AWS does not present it as an open-source project you self-deploy. If your requirement is "the gateway code must be mine", the honest reading is that you are choosing the self-hosted shape, not asking the managed service to be something it is not.

The second question has a real answer: AWS publishes an open-source collection of MCP servers for AWS under the awslabs organisation on GitHub, whose stated purpose is to let assistants interact with AWS services under proper security controls — with the older AWS API MCP server in it marked as superseded by the official managed AWS MCP Server. The MCP deployment-patterns guide separately links an open-source repository of implementation examples and deployment scripts. So the open-source surface is real: the servers and the reference stacks, not the managed gateway.

That distinction sets the decision. If what you want is to consume a gateway, the managed shapes are the ones to read. If what you want is to own the code and the runtime, the open-source servers and the deployment-pattern repositories are the raw material, and the self-hosted section below is your starting point. Either way, the phrase "open source MCP gateway" should not be read as "AWS ships an open-source gateway" — it does not say that anywhere, and assuming it wastes the search.

mcp gateway registry: how targets and tools are registered

A registry is where a tool is recorded so that something else can find it. In the AWS managed shape that record is not a separate product you install; it is the gateway's target configuration and the MCP catalog the gateway serves.

The gateway's targets come in three categories. MCP targets operate in aggregation mode: the gateway acts as an MCP server whose capabilities combine those of all its MCP targets, so a client sees a single consolidated tools/list response that includes the tools from every attached MCP target. HTTP targets are the opposite arrangement — the gateway sends traffic directly to them without aggregation or protocol translation, which is what you want when the backend already speaks the protocol you need and you just want a single authenticated front. Inference targets route model traffic to providers with model-based routing, giving a unified endpoint across providers. AWS notes that you can attach different credential providers to different targets, which is how per-target access is controlled.

Inside the MCP category, the target types are enumerated on AWS's MCP-target page: AWS Lambda function targets, Amazon API Gateway REST API stages as targets, OpenAPI schema targets, Smithy model targets, MCP servers targets, built-in templates from integration providers, and built-in connectors. The same page records three properties a planner should notice: capability synchronization, semantic tool search, and three-legged OAuth at the target level. There is also a documented topic on how AgentCore Gateway tools are named — worth reading before you design client-side tool selection, because the tool name is the handle an agent uses.

The practical consequence is that "registry" here means the gateway's own target list plus the tools/list catalog it serves, not a separate registry service you stand up alongside it. You add a target, the gateway either aggregates it into the virtual MCP server or passes traffic through, and the client discovers tools from that single endpoint. A standalone registry of unrelated third-party gateways is a different concept from the one AWS implements; the official targets page settles the difference.

The self-hosted gateway question: running MCP on AWS without a managed gateway

Not every team wants the gateway managed, and AWS does not pretend otherwise: the deployment-patterns guide exists precisely because many organisations host MCP servers themselves. The question is not "managed or not" in the abstract; it is which runtime shape your operational reality actually fits.

AWS Prescriptive Guidance frames the choice around five patterns — Amazon Bedrock AgentCore, Lambda with API Gateway, Amazon ECS, Amazon EKS and Amazon EC2 — and states that each addresses different operational requirements, scaling needs and management preferences. Its stated objective is to help you evaluate the five patterns for hosting remote MCP servers and select one by scaling, security, cost and operational requirement. That is the whole decision framework: the pattern follows the requirement, not novelty.

Read that way, the self-hosted decision decomposes into a few honest questions. Does the workload need a long-lived process with warm state, or is a short-lived invocation per call acceptable? Where does traffic come from — the public internet, another VPC, a private network — and what sits in front of it? Who owns the credentials the tool backend needs, and where must they live? And if you already operate one of these runtimes, the cheapest correct answer is often the one your platform team already knows.

Two warnings save time. First, a self-hosted MCP server does not remove the gateway problem: as soon as several clients call several backends, someone must own the front door, the credential exchange and the tool catalog. Second, the five-pattern guide is AWS's own mapping of pattern to requirement; treat its linked repository as the worked example. This page does not rank the patterns, because the ranking turns on constraints AWS cannot see — your network, your team and your existing compute.

open source mcp gateway: assembling the pieces on AWS

Building an open-source-shaped gateway on AWS is a composition exercise, and naming the parts is most of the work. You are assembling four things: the MCP servers that hold the capabilities, a runtime that hosts them, a front that authenticates and routes, and the operational record that tells you what happened.

The first part is available off the shelf. AWS publishes an open-source collection of MCP servers for AWS under awslabs, and the deployment-patterns guidance points at a repository of implementation examples and scripts. So the server layer rarely starts from zero; the useful labour is deciding which server exposes which capability and under whose credentials.

The second part is the runtime, and this is the five-pattern question again: Lambda with API Gateway, Amazon ECS, Amazon EKS, or Amazon EC2, with Bedrock AgentCore as the managed end of the same spectrum. The third part is the front — the single authenticated endpoint clients meet. The fourth part is the record: what was called, with which key, and what it cost. That fourth part is the one teams most often leave implicit, and it is the one an audit or a budget review will ask for by name; treat it as a component you assemble on purpose, not as something the runtime gives you for free.

The honest trade-off of the open-source route is control against work. You gain the exact software you audited, on the network you designed, with the credential handling you require. You take on the front door, the credential exchange, the catalog, the observability and the patching of all of it. AWS's managed gateway exists because that list is real work; its deployment-patterns guide exists because many teams choose to do the work anyway. Neither document calls one path better, and this page will not invent a verdict AWS does not give.

what is mcp gateway: the definition AWS implements

Strip the products away and the definition is short. MCP is, in AWS's own wording, an open protocol that enables integration between AI applications and external data sources and tools. A gateway is the component that puts one endpoint in front of many such tools, so a client discovers and invokes them through a single surface rather than being wired to each backend individually.

The AWS implementation makes the definition concrete in three moves. It translates: an incoming MCP request is converted into an API request or a Lambda invocation, which is how an existing HTTP API becomes an MCP tool without being rewritten. It composes: multiple APIs, functions, tools, agents and model providers sit behind one endpoint, and for MCP targets this means the gateway itself behaves as an MCP server whose tool list is the union of its targets. It secures: authorization is handled at the gateway, credentials for each backend are injected per target, and the same front can require an authenticated caller before a tool is ever reached. AWS describes those three moves as capabilities — Translation, Composition and Secure Credential Exchange — under a Security Guard that enforces OAuth.

Two distinctions worth carrying into a design review. A gateway is not a server: a server exposes a set of capabilities, a gateway aggregates several such sets and adds the front-door concerns — auth, routing, credential exchange, a consolidated tool catalog. And a gateway is not the model: inference routing is a capability some gateways add, but the definition stands without it. The vendor-neutral mechanics of that request path belong to the MCP gateway definition; this section only fixes the definition in the terms AWS uses.

agentcore mcp gateway: the managed option in detail

"AgentCore MCP gateway" is the managed end of this page, and three similarly named things sit close together, so read it in a set order.

The gateway itself is Amazon Bedrock AgentCore Gateway. AWS's page for it leads with the promise — a single secure entry point for agentic traffic — and lists the mechanics: conversion of APIs, Lambda functions and existing services into MCP-compatible tools; passthrough targets for agents and HTTP services, including agent-to-agent traffic; model-based routing across providers; and inbound plus outbound authentication as a managed service. The target page splits capabilities into MCP, HTTP and inference categories, and the MCP-target page enumerates the seven target types and their three per-target properties (capability synchronization, semantic tool search, three-legged OAuth). A separate page documents client-facing use: which MCP protocol versions the gateway supports and the operations a client may call, including tools/list, tools/call, prompts and resources, and server-initiated features such as elicitation and sampling. That set of pages, not this one, is the source of truth for versions and behaviour.

The second similarly named thing is the AgentCore MCP Server, which AWS documents as helping you transform and deploy AgentCore work rather than as a gateway you route production traffic through. The third is the AWS MCP Server covered above, a managed remote MCP server for AWS operations. Keep the three apart: the gateway-use page settles protocol versions, and the AWS MCP Server setup page settles agent access to your AWS account.

This page states no AgentCore price or quota as a fact. AWS publishes those numbers on its own pricing and service pages, and a capacity plan should read them there rather than from any third-party summary — including this page.

ai api gateway: where API Gateway and Bedrock meet MCP

The last keyword in this cluster is "AI API gateway", and on AWS it lands on a genuinely useful seam: Amazon API Gateway has added MCP proxy support. AWS's announcement describes it as the ability to transform existing REST APIs into MCP-compatible endpoints, through integration with Amazon Bedrock AgentCore's Gateway service, so that organisations can make their APIs accessible to AI agents and MCP clients. The same announcement lists three concrete benefits: protocol translation, so existing REST APIs can talk to agents without application changes or extra infrastructure; dual authentication, which verifies the agent inbound and manages the connection to the REST API outbound; and semantic search, so an agent can find the most relevant API for a prompt.

The API Gateway documentation shows the operational shape. A REST API stage becomes a target on an AgentCore Gateway; the gateway then translates incoming MCP requests into HTTP requests and formats the responses, MCP clients retrieve the API documentation through tools/list and invoke it through tools/call, and the console flow is "create an MCP target" from a deployed stage. The announcement also notes the feature is available in the AWS Regions where Bedrock AgentCore is available and points to the AgentCore pricing page for the cost of the feature — again, numbers that belong to AWS's pages, not to this one.

This closes the loop for teams who built their API estate on API Gateway: they need not re-platform the API or hand-write a tool server for every endpoint, because a stage becomes a discoverable MCP target and the gateway supplies the front-door concerns. If your "AI API gateway" question is really "how do I expose my existing AWS APIs to an agent", read this first.

The three shapes side by side

The table is a map, not a ranking; each row points at the official AWS document that settles the details.

Shape	What it is	Pick it when	Official starting point
Amazon Bedrock AgentCore Gateway	A fully managed gateway that converts APIs, Lambda functions and services into MCP-compatible tools and fronts agents, HTTP services and model routing through one endpoint	You want the gateway itself managed, with inbound and outbound auth, composition and semantic tool selection	AWS's AgentCore Gateway page
AWS MCP Server	A managed remote MCP server that exposes AWS operations to a client	The agent needs to act on AWS itself and you want no local proxy	AWS's AWS MCP Server setup page
Self-hosted on Lambda + API Gateway, ECS, EKS or EC2	You run the MCP server and the front on your own compute	The runtime, the network or an existing platform forces the choice	AWS Prescriptive Guidance, MCP Deployment Patterns on AWS

Read the rows in order of how much you want to operate: the managed gateway trades control for one endpoint AWS runs; the managed remote MCP server answers a different question; the self-hosted patterns trade operating effort for exact control of runtime, network and credentials. The companion pages each take one vendor's shape on its own stack — see the Microsoft MCP gateway, the Composio MCP gateway, the Kong MCP gateway, the TrueFoundry MCP gateway and the LiteLLM MCP gateway — while this page stays on AWS.

Where SmartGate fits

SmartGate is not an AWS service and does not pretend to be one; it is a cloud-neutral, MCP-native algorithm gateway, and the honest reason to mention it here is that the front-door concerns the AWS shapes describe — one authenticated endpoint, per-key limits, credential exchange, a record of what was called — exist as a product before you build them yourself.

If your tools live on AWS and you want AWS's managed gateway, AgentCore Gateway is the right page and this section is irrelevant to you. If your tools span clouds, or you want the enforcement layer to stay portable, a neutral gateway is the alternative: the limits move with the tier — monthly token caps of 2M, 20M, 100M and 200M+, MCP requests per minute per key of 120, 300, 600 and 1200, audit-log retention of 7, 30, 90 or 180 days, and 2, 10, 30 or unlimited team keys — and the authoritative table is the pricing page, where those figures must be read before a capacity or retention decision is committed.

Nothing above is a claim about AWS. The comparison a reader should make is narrow: does the enforcement point need to be AWS-native, or portable? This page gives the AWS map; the second question is the reader's.

What AgentCore manages, and what our own deployment still writes down

The sections above describe what AWS runs for you. This one reads the other half — where those same concerns land when the gateway is ours to operate — from the deployment configuration of the gateway that serves this site, read on 2026-10-08 from deploy/environments/production.yml (and the edge configuration in wrangler.jsonc).

When the gateway is self-hosted, the things a managed service absorbs reappear as named fields in a deployment description:

• The runtime is a pair of containers, not an endpoint. Our production environment names one Next.js container and one Python container, and the API is served by the Python one behind an nginx template whose server_name is the API host. A managed gateway hands you an endpoint; the self-hosted shape hands you an image to build, mount and keep running.
• State is a volume you own. The models live in a named Docker volume mounted into the Python container, and the deploy refuses to start without it (models_mount_required: true). That is the concrete form of "the runtime is yours" — a managed gateway never asks where its weights live.
• Scale is a number written down. Replicas and worker counts (python_replicas, gunicorn_workers) are chosen and deployed rather than autoscaled behind an account. Where the managed shape sells capacity on demand, the self-hosted shape records the number you picked.
• The deploy scope is enforced, not advisory. The environment declares a production deploy scope, and the deploy tooling resolves the scope before it acts — a guard that exists because a wrong deploy is one the operator owns, not the vendor.
• The edge and the origin are two halves. The same repository carries the Cloudflare Worker that serves the site (wrangler.jsonc: the Worker entry, its compatibility flags, the static-asset binding and its Durable Object bindings) beside the container deploy. Our estate splits exactly where the AWS decomposition draws its line — one shape authenticates and routes at the edge, another holds the credential and the model weights behind it.

None of this argues that self-hosting is better. It argues that "managed" is a real line with real contents, and that at the deployment layer those contents have names: a container, a volume, a worker count, a deploy scope, a Worker binding. Read the five-pattern guidance with those five in hand and the choice stops being abstract, because each pattern is a different answer to where they land.

How to get started

The first four steps are reading.

1. Write one line: are you exposing AWS's own capabilities to an agent, or your own APIs to an agent? The first points at the AWS MCP Server; the second points at AgentCore Gateway or the self-hosted patterns.
2. If it is your own APIs, read the AgentCore Gateway page and its supported targets to see whether your backend fits an MCP, HTTP or inference target.
3. If the runtime must be yours, read MCP Deployment Patterns on AWS and pick the pattern by your scaling, security, cost and operational requirement.
4. If you already run REST APIs on API Gateway, read the MCP proxy documentation before writing any code — a stage may already be most of the way to a tool.
5. If the enforcement layer needs to be portable across clouds, start free with an MCP-speaking client and read the pricing page once your own call volume tells you which tier you need.

Limitations

This page is an AWS-side map, not a benchmark: it ranks no pattern, prices nothing, and states no AWS quota, limit or capacity figure as fact, because those live on AWS's own pages and change. It describes what AWS documents about three shapes for putting a gateway in front of tools on AWS; it does not claim that any pattern is correct for a specific team, and it does not compare AWS with any other vendor.

The shape names and behaviour above come from AWS's own documentation at the pages linked in Sources. Where a detail is versioned or region-specific — protocol versions, available Regions, target types on a given date — the page points at the AWS document instead of restating a value that will drift; nothing here substitutes for reading that page before you build.

Because this page carries no code excerpt — the reason is recorded in the Method note below — it makes no line-numbered or implementation-level claim. Statements about how the gateway translates, composes or authenticates are summaries of AWS's published descriptions of its service, not independent verification of its internals.

Sources

• Amazon Bedrock AgentCore Gateway — the gateway page, for the single-entry-point description, the six named capabilities, and the OpenAPI, Smithy and Lambda tool input types.
• Amazon Bedrock AgentCore — supported gateway targets and MCP targets, for the MCP, HTTP and inference target categories, aggregation mode, and the enumerated MCP target types with their per-target properties.
• Amazon Bedrock AgentCore — use an AgentCore gateway, for the supported MCP protocol versions and the client-facing operations.
• Amazon Bedrock AgentCore — the AgentCore MCP Server, the differently named companion to the gateway.
• AWS Agent Toolkit — set up the AWS MCP Server, for the managed remote MCP server, its two authentication paths and its regional endpoints.
• AWS Prescriptive Guidance — MCP Deployment Patterns on AWS, for the five deployment patterns and the selection criteria.
• AWS — Amazon API Gateway adds MCP proxy support and the API Gateway MCP target documentation, for the REST-to-MCP proxy, dual authentication and semantic search.
• Open-source reference material named by AWS — the MCP servers for AWS collection, whose AWS API MCP server is marked superseded by the official AWS MCP Server.
• The Model Context Protocol specification — modelcontextprotocol.io/specification, for the protocol an MCP gateway is expected to speak.
• Demand figures are this project's own measurement: DataForSEO Google Ads, United States, 12-month window, measured 2026-10-03, recorded in this project's search_volume.json and research_brief.md.
• The deployment-layer section is our own implementation, read on 2026-10-08 from the gateway's own deploy configuration (deploy/environments/production.yml, wrangler.jsonc, origin/main). It states what a self-hosted deployment writes down — containers, volumes, replica counts, deploy scope and Worker bindings — and nothing about AWS beyond what its documentation already says.

Method note

This page carries no code excerpt, and that is a recorded finding rather than an omission. The slice matcher pinned 0 of 8 sections for this page (0 abstention(s), 8 no-slice verdict(s)): rule A found no unique symbol for any of the eight section keywords in the scanned repository, and the remote symbol-candidates fallback returned only generic collisions shared across unrelated files. A pinned generic name would have given the page the shape of a verified article with none of the substance, so every section above is written from AWS's own published documentation, linked in Sources. The section keyword quoted above each heading comes from this project's own paid measurement run, not from a third-party tool. No code, batch fingerprints, auction data or internal hosts are transcribed, so there is nothing here that has to be asserted verbatim.

One section is our own implementation rather than a citation. "What AgentCore manages, and what our own deployment still writes down" reads the gateway's own deployment configuration — the per-environment deploy file and the edge Worker config named in that section — and states what a self-hosted gateway has to write down where a managed one hands over an endpoint. It is the page's first-hand segment: the values are ours and the files are named. It deliberately adds no AWS price or quota, because those belong to AWS's own pages.