AWSAWS Certified Generative AI Developer - Professional2026-102.1 Implement agentic AI solutions and tool integrations
Choose MCP hosting by state lifetime
Completed by the knowledge check
Learning objective
Choose lightweight stateless Lambda MCP servers versus ECS-hosted MCP servers for stateful or complex tools.
Core idea
Choose the execution environment from the tool’s lifecycle, not from whether its interface says MCP. A short, self-contained lookup can fit a stateless Lambda handler. Long-lived connections, process-local sessions, or complex continuously running servers can favor Amazon Elastic Container Service (Amazon ECS). ECS also suits long-running stateless services; containers do not imply stateful hosting.
AWS’s MCP protocol contract distinguishes stateful servers, which carry state within a session across requests, from stateless servers, which keep state in an application-managed backing store and pass explicit state handles. Session state and durable business state are separate decisions; container memory does not become durable. See 2.1.12 for protocol compatibility and 2.1.3 for state isolation.
How it works
Make the Lambda request self-contained
A Lambda-hosted MCP server needs an HTTP entry point and an implementation that translates the incoming exchange into the chosen MCP contract. Lambda function URLs provide a dedicated HTTP(S) endpoint; Amazon API Gateway is another documented HTTP entry option. The endpoint alone does not implement discovery, schemas, tool calls, or MCP error responses. Those responsibilities belong to your server implementation or protocol adapter.
For a stateless design, every tool request carries the validated arguments and explicit identifiers needed to find its business context. Put durable job, action, and session records in a backing store, such as DynamoDB, and authorize access to those records for each request. Reconstruct any required working context from that store. Do not depend on the next invocation reaching the same warm execution environment.
AWS documents Lambda as compute for short-lived tasks that do not retain or rely on state between invocations. Treat reusable connections as an optimization and keep trusted tenant state in the backing store.
An alternative is to put a Lambda function behind AgentCore Gateway. This is a Lambda tool target, rather than a standalone MCP server inside the function. Gateway provides the agent-facing MCP boundary. The Lambda handler receives a map of the inputSchema properties in its event and must return valid JSON that Gateway can parse. A multi-tool handler reads bedrockAgentCoreToolName from the context, strips the ${target_name}___ prefix, and dispatches by tool name; see 2.1.12 for client-side exact names.
AgentCore Runtime is a managed hosting alternative with default stateless mode (stateless_http=True) and support for stateful mode; its Mcp-Session-Id routes requests to the same microVM (see 2.1.4 for deployment).
Check the limits of the actual invocation path
For the synchronous Lambda tool path discussed here, the function timeout limit is 900 seconds (15 minutes). The quota documentation separately describes a 5,400-second limit for qualifying asynchronous and event-source-mapping invocations on Lambda Managed Instances. That exception does not extend a synchronous MCP request to 90 minutes.
Lambda memory allocation ranges from 128 MB to 10,240 MB. The synchronous buffered invocation payload limit is 6 MB each for request and response. Lambda also documents streamed responses up to 200 MB, so saying that Lambda cannot stream is incorrect. Streaming support and limits still need to match the selected endpoint and server implementation. An upstream endpoint or client deadline can end the request before the Lambda timeout.
Test dependencies, initialization, and response serialization against the whole request deadline. Return a durable job handle for asynchronous work when the client contract permits it; subsequent calls can check that job. A longer business process does not necessarily require a longer HTTP request or in-memory session.
Give ECS an explicit service and recovery contract
An ECS-hosted server runs from a task definition. An ECS service maintains the desired number of task instances and replaces tasks that stop or fail. desiredCount controls the number of tasks the service maintains; maximumPercent influences replacement capacity during unhealthy-task recovery. Configure container or load-balancer health checks that detect whether the server can actually process requests.
An Application Load Balancer can route HTTP/HTTPS traffic to ECS tasks. For tasks using awsvpc networking, its target group must use target type ip, rather than instance. Plan connection draining and client reconnect behavior when tasks are replaced or deployments move traffic.
ECS gives you a process lifecycle suitable for maintaining connection state and substantial runtime dependencies, but scaling adds a state-routing problem. If a session lives only in one task’s memory, another replica cannot reconstruct it automatically. For ALB duration-based stickiness, configure stickiness.enabled and stickiness.lb_cookie.duration_seconds. It requires a cookie-capable client and enabled cross-zone load balancing. The client must retain ALB cookies; an Mcp-Session-Id header alone does not establish cookie affinity. Stickiness does not copy state when a task stops. Use shared DynamoDB records for recoverable business state.
Service replacement restores compute capacity, not unfinished business transactions. Persist job progress and action outcomes outside the task when they must survive termination. A reconnect must not silently repeat a mutation; preserve the idempotency and reconciliation contract from 2.1.11. Budget for task definitions, image releases, health checks, scaling, and recovery.
Key distinctions and trade-offs
Use the following comparison to locate the deciding constraint:
| Requirement | Lambda design | ECS design |
|---|---|---|
| Short independent requests | Self-contained invocations with explicit context handles | A service can serve them, with ongoing task management |
| Process-local MCP session state | Externalize state or change the interaction contract | Maintain it in a task, with routing and loss recovery |
| Long-running or complex server process | Split durable work from the synchronous tool request | Run the server continuously with health and deployment controls |
| Durable business state | Store outside the execution environment | Store outside replaceable task memory |
| Bursty versus sustained demand | Evaluate initialization and concurrency under burst tests | Evaluate desired task capacity, scaling, and utilization |
Neither platform wins solely because it uses containers or is described as serverless. Measure the whole path’s latency and operating cost under representative demand. A Lambda tool that updates a database can remain stateless at the compute boundary.
Authentication also needs an explicit owner. Function URLs offer AuthType: AWS_IAM or NONE. NONE bypasses IAM authentication; it does not supply an MCP authorization policy. Choose an entry point compatible with the client’s credentials and enforce the business access checks behind it. AgentCore access boundaries are covered in 2.1.4.
Architecture / decision scenario
A procurement assistant uses two tools. A supplier lookup completes in seconds and needs only an authorized supplier ID. A negotiation tool maintains interactive connection context and loads a substantial dependency stack while a reviewer examines proposals.
The team implements a stateless Lambda MCP server for the lookup and exposes it through a function URL configured with AWS_IAM. The approved client supplies compatible credentials. The server implements the selected protocol revision, validates tool arguments, and reads supplier data using explicit tenant context. The request and response remain below the synchronous payload limit, and the configured deadline leaves headroom for the dependency call. No session data relies on a warm environment.
The negotiation server runs as an ECS service behind an Application Load Balancer with ip targets for its awsvpc tasks. The cookie-capable client retains ALB stickiness cookies to reach the session owner. The team tests what happens when that task fails. Durable proposal revisions and approved action IDs remain outside task memory. A replacement task restores the server, and the client resumes or explicitly restarts the interaction from the recorded revision.
Before approving ECS, the team also evaluates a stateless alternative: start negotiation work, return a durable handle, and poll through short Lambda tools. It retains ECS because the required interactive lifecycle needs the continuously running process. If that requirement changes, durable business state alone is not a reason to retain stateful hosting.
Common exam traps
- Equating database-backed business state with a stateful compute process.
- Treating a Lambda target behind Gateway as a full MCP server in Lambda.
- Extending synchronous Lambda requests using the Managed Instances asynchronous timeout exception.
- Assuming that Lambda cannot stream or that streaming removes deadlines.
- Assuming an ECS replacement preserves in-memory sessions or unfinished effects.
- Choosing multiple replicas without deciding how session ownership survives routing changes.
What to remember
- Choose from request duration, connection lifecycle, and resource requirements.
- Keep Lambda calls self-contained and durable state external.
- Separate standalone MCP serving from Gateway-backed Lambda tools.
- Use ECS service and load-balancer controls with explicit session recovery.
- Preserve business action identity across compute replacement and reconnects.
Knowledge check
A supplier-lookup MCP tool finishes in under a second. Each call reads and updates a supplier record in DynamoDB using an authorized supplier ID passed in the arguments, and nothing has to survive in the server between calls. Which hosting fits?
An MCP server runs as an ECS service of three tasks behind an Application Load Balancer, with duration-based stickiness and session context held in task memory. One task fails its health check and the service replaces it. What happens to the sessions that task held?
Mcp-Session-Id header routes them to whichever task now holds themA team puts a Lambda function behind AgentCore Gateway as a tool target and asks who must implement tools/list, schema publication, and MCP error responses. Which division is correct?
inputSchema properties; the handler dispatches by tool name and returns valid JSON that Gateway can parse.A report-generation MCP tool on Lambda must sometimes run for 40 minutes, and clients call it synchronously. An engineer notes that Lambda allows timeouts up to 5,400 seconds. What should the design do?