I Tried Running an MCP Server on AWS Lambda… Here’s What Happened

Ran Isenberg
5 days ago
4 min read

Two days ago, the official MCP Python SDK released support for streamable HTTP transport via FastMCP, which also supports FastAPI. As someone deeply involved in building secure and production-grade serverless services, I wanted to test the viability of running an MCP server serverlessly on AWS Lambda.

Let's just say—we're not there yet.

In this brief blog post, I'll share my experience and thoughts on the current state of serverless MCP servers.

Why MCP on Lambda?
Developer Experience: Rough and Raw
Comparing to Bedrock Agents on Lambda
What Needs to Improve

Why MCP on Lambda?

The real question should be, why not?

MCP (Model Context Protocol) is an open standard that aims to simplify how AI agents communicate with tools and resources. With its new HTTP transport support, it theoretically becomes deployable anywhere HTTP servers can run, like FastAPI.

But as you know, I'm an AWS serverless hero, so naturally, combining MCP, FastAPI, and AWS Lambda (with the Lambda Web Adapter) felt like an interesting experiment.

My architecture looked like this:

API Gateway → Lambda Web Adapter → FastAPI → FastMCP

FastAPI handles routing and server logic. FastMCP exposes the resources. The AWS Lambda Web Adapter (repo) enables this by allowing HTTP servers to run inside Lambda using a custom container image. I used my blog post about building Lambda functions from container images (which you can read here), and we were off to the races.

Dockerfile:

If you're curious to try it yourself, AWS published code samples: Stateless MCP on Lambda (Python). It uses SAM. I used CDK.

Developer Experience: Rough and Raw

Let's talk DevEx. It's confusing, inconsistent, and far from intuitive—but that's somewhat expected for a just-released integration. Still, here are the pain points:

IaC Support

It's not trivial at all. You need to figure out many things yourself and configure all the moving parts together, based on some documentation hints. ChatGPT and the like were not helpful at all.

Performance

Cold starts are brutal. I experienced delays of up to 5 seconds. That's unsurprising given the number of moving parts (you're spinning up a whole server!), But this setup is still unsuitable for latency-sensitive workloads.

Observability

Logging formats are all over the place. FastAPI and FastMCP each have their own loggers and settings. I use Powertools for AWS Lambda for logging.

I tried redirecting all logs through Power Tools for structured JSON logging, but failed to get it working (I haven't dug in enough yet).

In addition, you don't get access to the usual event and context objects since you're not writing a Lambda handler but spinning up a server. That breaks Powertools utilities like tracer and metrics. You can have tracing, but you can have inner handler/function segments at least, not with Powertools native decorators. I'm sure there's a way to get it working with some middleware for FastAPI.

No Standard Lambda Experience

This setup throws away the clean simplicity of writing a Lambda handler. You're running a server now, which means no easy integration with your typical Lambda-native tools like PowerTool's event handler. If you're used to event-driven Lambda development, this feels like stepping back in time. It just doesn't fit the handler-logic-DAL architectural layers formats (hexagonal arch.) we've been using with Lambda.

Testing

I had to manually configure VS Code to interact with the MCP server and send the correct payload—something I couldn't figure out without digging into the protocol's RFC.

You can run the server in stdio mode for local development, which helps. However, for testing, I wanted to construct requests directly in Pytest rather than relying on an MCP client (as most examples do). The current experience lacks developer-friendly wrappers and tooling.

It's doable—but far from seamless.

Comparing to Bedrock Agents on Lambda

Last July (this was 2024, mind you!), I wrote a blog post about using Bedrock agents with OpenAPI on Lambda. Within 30 minutes, I had a production-grade setup using:

Lambda handler with API GW + WAF
AWS Powertools (logging, tracing, metrics)
Excellent performance
Chat with an agent that triggered my APIs

So what's the difference?

Bedrock used proprietary protocol AWS built on-top of HTTP.

MCP is an open standard protocol with additional abstraction layers, BUT it's universally hyped and accepted.

It feels like a classic case of "one step forward, two steps back." But it's a step nonetheless, and I'm hopeful that tooling and performance will improve.