Exam-style
A team is publishing two MCP servers to the same agent. The first wraps a DynamoDB lookup and returns in about 40ms. The second holds a 6GB in-memory graph that takes ninety seconds to build, then answers path queries against it in milliseconds. Where should each one run?
Reveal the answer
B. The lookup as a Lambda target, and the graph server as a long-running task on Amazon ECS with AWS Fargate behind the gateway
Run the statelessness test on each server separately. The DynamoDB lookup carries nothing between calls, so it is a clean fit for Lambda functions to implement stateless MCP servers: the gateway invokes it, it reads a row, it returns, and nothing is lost when the instance freezes. The graph server fails that test on its first line. Lambda gives you no instance affinity, so the request that arrives after the ninety-second build lands wherever the service puts it, and an instance that has answered once is frozen between invocations rather than kept alive on your terms. Provisioned concurrency buys warm instances, not the same instance, and it bills for the whole keep-warm window whether or not the agent calls. Rebuilding per invocation turns a millisecond query into a ninety-second one, and paying for 10GB of memory does not change any of that: the graph still has to be built inside a fifteen-minute execution ceiling, and the ninety seconds of loading lands in the cold-start path of every new instance. State that has to stay warm belongs in a container, which is Amazon ECS to implement MCP servers that provide complex tools. Putting the 40ms lookup in a container as well is not wrong so much as wasteful, since it pays for an idle task to do work that finishes before a request-scoped runtime would even notice.
Q. One MCP server wraps a DynamoDB lookup and answers in 40ms. The other builds a 6GB in-memory graph over ninety seconds, then answers path queries against it. Where does each run?
A. The lookup goes on Lambda. The graph server goes in a long-running container on Amazon ECS with AWS Fargate, published through the same gateway.
Why? Ask what survives between calls. The lookup keeps nothing, so a frozen instance costs it nothing. The graph server keeps six gigabytes and ninety seconds of build time, and Lambda offers no instance affinity to keep them on: the next call may land on a fresh instance, and a warm one is frozen rather than yours. Anything that must stay hot, hold a connection pool or carry a session runs in a container. The fifteen-minute execution ceiling and the weight of loading that state on every cold start are the second and third tells, and they usually confirm what the first one already said. Both servers are model extension frameworks in the same catalogue, reached by the agent through the same MCP client libraries; where they run is a property of their state, not of their interface.