MCP Strategies on AWS, Part 3: Hosting, from Local to AWS

Fri, 19 Jun 2026 00:00:00 +0000

TL;DR: The AWS MCP guidance frames hosting as a ladder: local first, then remote, then a managed gateway. This post walks all three with code. The local rung is a stdio server with no auth, run as a subprocess. The remote rung is a real deploy: a Lambda Function URL with IAM authorization, which makes the server bounded to a single AWS account: every request must be SigV4-signed by an in-account principal, and an unsigned request gets a 403. I deployed it to a real account, connected a signing client that listed the tools and invoked one, confirmed the 403 on an unsigned call, then tore it down and verified the resources were gone. The post shows the actual output and the trap-based teardown that runs even if the process is killed. The gateway rung (Amazon Bedrock AgentCore Gateway) is the managed option, and I describe the path to extend the remote server to internet-facing without deploying it.

Disclaimer: I built and tore down the AWS resources in this post in my own test account. The deploy is deliberately bounded to a single account and is not internet-facing. If you run the companion code, you are deploying into your account and are responsible for the cost and teardown. The numbers and output here are from my run.

The tool-design post decided what your tools are. This one decides where they live. The AWS MCP guidance is candid that most MCP usage today is local, and it lays out a ladder you climb only as far as you need to [1]. All the code in this post (the local server, the CDK stack, the signing client, and the deploy/teardown scripts) is on GitHub.

schristoph.online

MCP Strategies on AWS, Part 3: Hosting, from Local to AWS