> ## Content Index > Fetch the complete content index at: https://www.takeyourpills.tech/llms.txt > Use this file to discover other available public pages before exploring further. # MCP Just Went Stateless: Time to Delete Your AWS Sticky Sessions and Save Big - URL: https://www.takeyourpills.tech/mcp-just-went-stateless-time-to-delete-your-aws-sticky-sessions-and-save-big/ - Published: 2026-09-11T22:44:13.000Z - Updated: 2026-09-11T22:44:13.000Z - Description: MCP's core protocol is now stateless, eliminating the need for sticky sessions and session stores on AWS. This post details how to align your MCP server deployments with the AWS Well-Architected Agentic AI Lens, showcasing significant architectural and cost benefits from the new stateless design.... - Author: Youre Pena - Tags: Software Architecture, Cloud Computing, Systems Engineering ![audio-thumbnail](https://www.takeyourpills.tech/content/images/2026/09/cover-3.png) MCP Just Went Stateless: Time to Delete Your AWS Sticky Sessions and Save Big 0:00 /0 1× Clinical Summary Diagnosis Previous versions of the **MCP** forced developers to maintain stateful sessions, requiring expensive infrastructure like **ElastiCache** clusters and sticky **ALB** routing just to handle connection handshakes and mitigate uneven load distribution. Prescription - **Upgrade SDKs:** Target the 2026-07-28 revision to adopt the new stateless protocol and eliminate legacy session handshakes. - **Adopt MRTR:** Leverage Multi Round-Trip Requests to pass state tokens via the model context, making serverless **AWS Lambda** deployments a natural fit. - **Decommission Infrastructure:** Delete sticky routing rules and session stores to immediately reclaim costs once legacy client traffic reaches zero. Side Effects State management complexity shifts to your application layer, requiring strict idempotency for tools and cryptographic validation of untrusted state tokens using **HMAC** or **AEAD**. Potency Eliminates an entire category of idle infrastructure cost, unlocking true scale-to-zero serverless architectures. #### Script ## MCP is Now Stateless: Time to Delete Infrastructure MCP went stateless in the 2026-07-28 revision. If you're running MCP servers on AWS, that means you can start deleting infrastructure. **Not next quarter. This quarter.** Picture this. It's Tuesday morning. You're looking at your infrastructure dashboard, and there's the ElastiCache cluster you run solely to hold MCP session state. There's the sticky-session rule on your Application Load Balancer. There's the Lambda workaround you maintain just to handle the initialize handshake. Until last month, all of that was necessary. The Model Context Protocol was built around sessions. A client started with an initialize handshake. The server minted a session ID. Every request after that had to carry the same `Mcp-Session-Id` header, and if you were running more than one instance, that session had to land on the same server every time. You either pinned clients with sticky sessions, or you externalized state to a shared store like DynamoDB or ElastiCache. Both were correct. Neither was cheap. Sticky routing also distributes load unevenly, which means your compute fleet had to pad capacity for the instances that happened to hold long-lived sessions. That design is gone. The new protocol core is stateless. No handshake. No `Mcp-Session-Id` header. A client can send its first message as an actual tool call, and any server instance can answer it. Every request carries its own protocol version and client context. If you were maintaining session affinity rules in ALB, you can delete them. If you were running an ElastiCache cluster just to hold protocol session state, you can shut it down. A two-node cache.t4g.micro is about twenty-three dollars a month, but the real savings is eliminating an entire category of infrastructure and the operational burden that comes with it. Uneven load distribution goes away too, so the fleet you keep can run closer to its real utilization instead of padding for pinned sessions. ## How Your Architecture Changes This is exactly what changes in your architecture. Your ALB goes from sticky sessions to plain round-robin. Your gateway routes and throttles using `Mcp-Method` and `Mcp-Name` headers instead of parsing request bodies. AWS Lambda becomes a natural fit instead of a workaround, because request in and response out is exactly what Lambda does. Tool lists now return in deterministic order, which helps with LLM prompt cache hits, and the protocol includes `ttlMs` and `cacheScope` fields so your gateway can cache responses without guessing at staleness. For observability, W3C Trace Context moves into the `_meta` field on every request, and the proprietary MCP logging channel is deprecated in favor of stderr or OpenTelemetry. ## Where Did the State Go? But stateless describes the protocol, not your application. Stateful use cases still work. The difference is whose problem the state becomes. Think of it like a coat check. Under the old protocol, the server was a valet who remembered your face. You had to keep dealing with that same valet, and nobody else could help you. Now you get a numbered ticket, and any attendant can serve you because the ticket carries the reference. When a server needs continuity across calls, a tool returns an identifier for the stored state. The model includes that identifier on later calls. The state lives in your datastore. The model carries only the key. That's ordinary REST discipline, and it has an advantage over the old model. The identifier sits in the model's context rather than hidden in a header, so the model can reason about it and thread it across different tools. One immediate behavioral change to plan for. ## Introducing Multi Round-Trip Requests (MRTR) Servers can no longer push a request to a client mid-call over a held-open stream. Confirmations, sampling, and root queries used to work that way. The spec replaces that pattern with Multi Round-Trip Requests, or MRTR. When a server needs input, it returns an `input_required` result containing an `inputRequests` map and an opaque `requestState` token. The client fulfills the requests, then re-sends the original call with `inputResponses` and the echoed `requestState`. Any instance can pick that up because the token carries all the context the server needs to resume. No shared session store is required. The server does not hold the connection open. This is what makes the pattern work on Lambda. The old pattern required holding a connection open while waiting for the client to respond. Lambda is not designed for that. MRTR turns the interaction into discrete request-response cycles. The server returns a result, Lambda freezes, and when the client comes back with `inputResponses`, any warm instance can pick it up. You no longer need provisioned concurrency just to keep session context alive. ## The Pushback: New Responsibilities Now, the pushback. The state didn't disappear. It moved. You're still responsible for storing it, securing it, and enforcing ownership on every call. The protocol will not stop a caller from presenting an identifier that isn't theirs, so you still need gateway-level authorization to validate that the requesting identity owns the resource it references. Those `requestState` tokens are **untrusted input**. The spec requires servers to treat them as untrusted and protect their integrity with HMAC or AEAD, rejecting any token that fails verification. If a response stream breaks, stream resumption is gone. The client must re-issue the call, which means your tools need to be **idempotent** so re-issued requests produce no duplicate side effects. The spec allocates standardized error code ranges too, giving gateways canonical signals for retry, backoff, and circuit-breaking decisions. The complexity didn't vanish. It shifted from protocol plumbing into your application design, your security boundaries, and your retry semantics. ## Migration and Deprecations There's also the migration clock to respect. The spec includes a backward-compatible lane that preserves session semantics for older clients. If you still serve 2025-era clients, your ALB stickiness rules and session store must stay in place until that traffic reaches zero. Instrument your gateway to log protocol version per request. Set a sunset date for the legacy lane, communicate it to client teams, and only decommission the session infrastructure after the old version hits zero traffic. Deleting too early is how you break someone's production workflow on a Tuesday morning. The same goes for deprecations that still have a clock. Roots, Sampling, Logging, and the HTTP plus SSE transport are deprecated with a twelve-month floor before removal. The earliest any of these can disappear is July 2027\. Plan the exits now rather than at the deadline. ## The Well-Architected Perspective From a Well-Architected perspective, this revision validates what the Agentic AI Lens already recommended. Stateless transport means instance loss is a non-event. Retries need no session affinity. Scale-in never drains sessions. Gateways get per-operation signals for metrics and alarms from headers instead of payload inspection. ### Cost Optimization For cost optimization, the Lens identifies always-on infrastructure serving bursty agent traffic as the highest source of idle cost. Stateless architecture eliminates an entire category of that cost. Session infrastructure that runs constantly to serve unpredictable traffic should be replaced with consumption-based patterns that scale to zero. ### Sustainability For sustainability, static provisioning for bursty traffic is the primary source of wasted capacity. Stateless design means no instance holds a session, so you can right-size against actual traffic patterns instead of theoretical peaks. ## Your Action Plan This Week If you're deciding what to do this week, here's the framework. ### Building a New MCP Server? Target 2026-07-28 directly. Go stateless from the start. Skip Roots, Sampling, and MCP Logging entirely. Use explicit state identifiers and rely on the built-in caching headers. Make your tools idempotent from day one. ### Running an Existing Server? Upgrade your SDK and opt in to the new revision. Speaking the new revision is never automatic. Audit your code for hidden session assumptions. Migrate off the experimental Tasks API if you used it, because Tasks is now an official extension with a redesigned interface. Plan your exits for the four deprecations. Change your resource-not-found error code from `-32002` to `-32602`. Set a firm date to stop supporting 2025-11-25 clients. Then collect the savings by deleting session stores, sticky routing rules, and handshake infrastructure. ### Running a Platform or Gateway Team? Add header-based routing and per-operation throttling on `Mcp-Method`. Honor `ttlMs` and `cacheScope` in your caching layer, but default `cacheScope` to `private`. Setting it to `public` on a response that contains tenant-specific data lets shared intermediaries serve one tenant's list to another. **That is a multi-tenant disclosure risk**, so widen it deliberately only for responses that are genuinely identical across callers. Propagate W3C Trace Context end to end. And set a governance policy for MCP Apps before any server in your fleet exposes one, because server-supplied HTML inside your host is a new attack surface that deserves deliberate review, not passive acceptance. ## The Path Forward Before you ship, validate against the official conformance suite. Start in a test environment, promote to production once you pass, and remember that protocol versions are frozen snapshots. 2025-11-25 servers keep working with clients that still speak it, but future capabilities and fixes land on 2026-07-28 or later. The community is already moving. GitHub's MCP server shipped support ahead of the release. The session-based protocol was correct for the constraints it operated under. Those constraints are gone. If you are deploying MCP servers on AWS, the 2026-07-28 specification is the Well-Architected path forward. Migrate your servers, sunset your legacy lane, and delete the infrastructure that existed only to compensate for a protocol limitation that no longer applies. **Just don't pretend the complexity disappeared. It moved into your tool design, your token validation, and your idempotency guarantees.** Handle those correctly, and you'll end up with a simpler, cheaper, more scalable system that actually fits how AWS wants you to build. [TAKEYOURPILLS.TECH](https://takeyourpills.tech/?ref=takeyourpills.tech). Go ship something. ## References - [MCP went stateless: Is your AWS MCP server deployment well-architected?](https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/?ref=takeyourpills.tech) \- AWS Architecture Blog