Stateless MCP Server Architecture Diagram: AWS Well-Architected After 2026-07-28 Spec

On September 1, 2026 the AWS Architecture Blog described the MCP revision dated 2026-07-28: the protocol core is stateless, the initialize handshake is gone, and so is the Mcp-Session-Id header clients used to echo. Every request carries its own protocol version and client context, so any server instance can answer, including a first message that is already a tool call. This news diagram is that deployment shape on AWS. The post says it is for teams who run the stack themselves. If you sit behind Amazon Bedrock AgentCore Gateway, the authors say protocol management and backward compatibility are handled for you — that is their statement about the managed gateway, not a walkthrough of its internals.

What this stateless MCP server architecture diagram AWS shows

Stateless is the protocol, not the application. The post’s coat-check analogy: the server returns an identifier, any instance can continue, and the state stays in your datastore. The model carries the key. server/discover returns versions, capabilities, and identity. Servers must implement it; clients may skip it. That skip is a protocol option, not a label on the art.

The problem this architecture is solving

A session used to live on the instance that created it, so scale meant sticky routing or a shared store. The 2026-07-28 core needs neither for new clients. The post’s table is the legend: ALB stickiness becomes round-robin; a DynamoDB or ElastiCache session becomes an id in the tool arguments; body parsing becomes Mcp-Method and Mcp-Name; Lambda no longer needs a handshake workaround; tool lists can carry ttlMs and cacheScope; logging moves to stderr or OpenTelemetry with W3C trace keys in _meta; Last-Event-ID resumption becomes an idempotent retry. Keep the old lane while any pre-2026-07-28 client remains. Log protocol version and set a sunset date before you delete stickiness. The post’s “about $23 a month” ElastiCache example (two cache.t4g.micro nodes, Pricing Calculator, July 2026) is an illustration, not a quote.

Main components and trust boundaries

Clients, an ALB without stickiness for the new protocol, a fleet (the post names Lambda as a natural fit and also the general case of any instance), and your tools and datastores. Identity checks move to the application. Because the model can see and change identifiers, the post says servers must enforce ownership on every call. The protocol will not stop a caller from presenting someone else’s id. requestState tokens are untrusted input: the spec, as the post reports it, requires HMAC or AEAD and a reject on failure. Clients must validate iss per RFC 9207. Clients must declare application_type at registration so a desktop or CLI client is not treated as a web app. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Tool input and output schemas are validated against JSON Schema 2020-12. cacheScope: "public" on tenant-specific data lets a shared cache serve one tenant’s list to another. The post says to default to private.

Request or data path, step by step

A new-protocol call can land on any healthy target. Mcp-Method and Mcp-Name expose the operation without a body parse. Responses set resultType to complete or input_required. Lists carry ttlMs and cacheScope. Trace context sits in _meta. A confirmation, sample, or root query uses Multi Round-Trip Requests: input_required, an inputRequests map, and requestState. The client resends with inputResponses and the same token. Any instance, including Lambda, can resume because the connection was not held. Broken streams are re-issued, so tools should be idempotent. The post’s error ranges are -32000 to -32019 (implementation) and -32020 to -32099 (MCP). Resource-not-found moves from -32002 to -32602.

The diagram: labeled boxes and failure or isolation edges

Solid path: clients, round-robin ALB, any MCP instance, datastores behind opaque ids. Dashed and marked retired, not on the live path: session stickiness and the session store, with one dashed edge into that box. MRTR is a note on the art, a response token, not a loop and not a server session. No session table on the new path. subscriptions/listen can still hold a POST open, so idle timeouts still matter if you use it. Roots, Sampling, Logging, and HTTP+SSE are deprecated with a twelve-month floor (earliest removal July 2027). ping, logging/setLevel, and notifications/roots/list_changed are already removed. MCP Apps (server HTML in a sandboxed iframe) is a governance callout, not a default box.

What the source does not claim (preview, case study, or limits)

This is one AWS Architecture Blog post dated September 1, 2026, reading the MCP 2026-07-28 specification against the Well-Architected Agentic AI Lens. It is not an AWS product launch, a conformance certificate, or a performance study. It does not say every deployment must move today: protocol versions are frozen snapshots, and a 2025-11-25 server still works with clients that speak it. It says hosts retire old versions on their own schedule, GitHub’s MCP server shipped support ahead of the release, and 2025-11-25 is frozen so later fixes land on 2026-07-28 or after. AgentCore Gateway is one sentence of scope, not a design for that service. The $23 figure is a calculator example. No CRD fields appear.

How this differs from a nearby pattern on ByteDiagram

The MCP gateway architecture diagram is a generic gateway in front of tools. This picture is a stateless MCP server fleet after 2026-07-28: round-robin, no session stickiness, opaque ids, and MRTR. A later IAM-focused diagram, secure AI agent MCP access on AWS, is about who may call a tool, not about deleting the session store. Those three stay separate diagrams.

FAQ

Does stateless MCP mean the server cannot remember anything?

No. The September 1, 2026 AWS post says stateless describes the protocol, not the application. Continuity is an identifier the tool returns and the client sends back. The state stays in your datastore. Any server instance can serve the next call because it does not depend on a session pinned to one process.

When can you delete ALB stickiness and the session store?

Not while you still serve clients older than the 2026-07-28 spec. The post says the backward-compatible lane keeps session semantics for those clients, so stickiness and a DynamoDB or ElastiCache session store stay until old-version traffic is zero. Log the protocol version and set a sunset date before you decommission them.

What replaced a server pushing a question mid-call?

Multi Round-Trip Requests. The server returns input_required with an inputRequests map and an opaque requestState token, then releases the connection. The client resends the original call with inputResponses and the same token. Any instance can resume, which is why the post says this fits AWS Lambda. Treat requestState as untrusted and verify it with HMAC or AEAD.

Conclusion

After the 2026-07-28 spec, as the September 1, 2026 AWS Architecture Blog post reads it, the picture runs from clients to a round-robin load balancer, any MCP server instance, and datastores that hold state behind opaque IDs. Session stickiness and the session store are dashed and marked retired, not a live legacy lane. Pre-2026-07-28 clients still need that store until their traffic is gone, but it is not on the live path. Multi Round-Trip Requests replace a held-open stream. This is not the generic MCP gateway diagram. Browse more on the ByteDiagram blog.