AWS just published the first major cloud provider pattern for hosting Model Context Protocol (MCP) servers as shared infrastructure. The integration between AgentCore Runtime and Amazon Quick shows how to deploy MCP servers once and let multiple clients consume them, rather than running duplicate local processes for every agent or workflow.
This is different from running MCP servers locally or porting them to cloud environments for single-session use. The pattern addresses multi-tenancy, session isolation, and versioning when the same MCP server instance serves multiple Amazon Quick chat agents and workflows.
The Deployment Shift
Running an MCP server locally means spawning a process per client session. The server lifecycle is tied to the client. State lives in memory. When the client disconnects, the server stops.
Hosting in AgentCore Runtime changes that model:
- Persistent process: The MCP server runs continuously, independent of client connections.
- Shared instance: Multiple Amazon Quick clients connect to the same server deployment.
- Centralized updates: You deploy once and all clients get the new version.
- Authentication boundary: The runtime handles client identity and authorization before tool calls reach the server.
This turns MCP servers into reusable infrastructure. A database query tool, a document retrieval agent, or a workflow orchestrator can be deployed once and consumed by dozens of Amazon Quick workflows without duplication.
Connection Lifecycle and State Management
When an Amazon Quick agent connects to an AgentCore Runtime hosted MCP server, the connection lifecycle looks like this:
- Client initiates: Amazon Quick sends a connection request with client credentials.
- Runtime authenticates: AgentCore Runtime validates the client identity and checks authorization policies.
- Session established: The runtime creates a session context and routes requests to the MCP server.
- Tool calls flow: The agent sends tool invocation requests through the runtime to the server.
- Session cleanup: When the agent finishes, the runtime tears down the session context but leaves the server running.
State management becomes critical. The MCP server cannot rely on in-memory state tied to a single client session. Instead:
- Session partitioning: Each client session gets a unique identifier. The server uses this ID to partition state (cache entries, temporary data, execution context).
- Stateless tools: Tools should be designed to accept all necessary context in the request payload, not rely on prior calls.
- External state stores: For persistent state (user preferences, workflow history), the server writes to an external store (DynamoDB, S3, RDS) keyed by session or user ID.
If the server holds state in memory without partitioning by session ID, one client’s tool call could leak data to another client’s session.
Isolation Boundaries
The runtime enforces several isolation layers:
| Boundary | Mechanism | What It Protects |
|---|---|---|
| Network | VPC isolation, security groups | Prevents unauthorized external access to the MCP server |
| Authentication | IAM roles, API keys, OAuth tokens | Ensures only authorized Amazon Quick clients can connect |
| Session context | Runtime-managed session IDs | Prevents cross-client data leakage within the same server instance |
| Tool permissions | Per-client authorization policies | Restricts which tools a specific client can invoke |
| Execution sandbox | Container or Lambda isolation | Limits blast radius if a tool execution fails or is compromised |
The runtime sits between Amazon Quick and the MCP server. It validates every request, attaches session metadata, and enforces authorization policies before forwarding tool calls. The MCP server itself does not handle authentication. It trusts the runtime to provide a valid session context.
Versioning and Updates
When you update an MCP server hosted in AgentCore Runtime, you need a strategy to avoid breaking existing clients:
- Versioned endpoints: Deploy new server versions to separate endpoints (e.g.,
/v1/tools,/v2/tools). Clients specify which version they want. - Backward-compatible changes: Add new tools or parameters without removing or renaming existing ones. Clients using the old contract continue to work.
- Deprecation window: Mark old tools as deprecated, give clients time to migrate, then remove them in a later version.
- Canary deployments: Route a small percentage of traffic to the new version, monitor errors, then roll out fully.
The runtime can route requests to different server versions based on client metadata. An Amazon Quick workflow created six months ago can continue using the old version while new workflows adopt the updated server.
Error Handling and Observability
Shared infrastructure means shared failure modes. If the MCP server crashes, all connected Amazon Quick clients lose access to those tools. Observability becomes critical:
- Health checks: The runtime pings the server periodically. If it fails, the runtime can restart the server or route traffic to a standby instance.
- Request tracing: Each tool call gets a trace ID that spans the Amazon Quick request, runtime routing, and server execution. This makes debugging easier when a tool fails.
- Metrics per client: Track error rates, latency, and tool usage per Amazon Quick client. If one client is hammering the server with bad requests, you can throttle or block it without affecting others.
- Circuit breakers: If the server returns errors above a threshold, the runtime can stop forwarding requests temporarily to prevent cascading failures.
The runtime should log every authentication attempt, tool invocation, and error. Without this, diagnosing why a specific Amazon Quick workflow failed to call a tool becomes guesswork.
Architecture Example
Here is a simplified deployment shape:
# AgentCore Runtime deployment for MCP server
runtime:
service: agentcore-runtime
region: us-east-1
vpc:
subnets: [subnet-abc123, subnet-def456]
security_groups: [sg-mcp-server]
mcp_server:
image: my-org/mcp-database-tools:v2.1
port: 8080
health_check: /health
environment:
- DATABASE_URL: ${ssm:/mcp/db/url}
- SESSION_STORE: dynamodb
- SESSION_TABLE: mcp-sessions
authentication:
provider: iam
allowed_principals:
- arn:aws:iam::123456789012:role/AmazonQuickAgentRole
authorization:
policies:
- client: quick-workflow-*
allowed_tools: [query_database, list_tables]
- client: quick-chat-*
allowed_tools: [query_database]
observability:
logs: cloudwatch
traces: xray
metrics: cloudwatchThe runtime handles the connection from Amazon Quick, validates the IAM role, checks the authorization policy, and forwards the tool call to the MCP server container. The server reads session state from DynamoDB using the session ID provided by the runtime.
Failure Modes
Several things can go wrong:
- Server crash: The runtime restarts the container, but in-flight tool calls fail. Clients need retry logic.
- Session state corruption: If the server writes bad data to the session store, subsequent tool calls for that session may fail. The runtime should expose a session reset endpoint.
- Authorization drift: If you update the authorization policy but forget to redeploy the runtime, clients may get unexpected permission errors.
- Cold start latency: If the server runs in Lambda, the first tool call after a period of inactivity will be slow. Pre-warming or keeping a minimum instance count helps.
- Cross-client resource exhaustion: One client sends a flood of requests, consuming all server capacity. Rate limiting per client is essential.
Technical Verdict
Use AgentCore Runtime hosted MCP servers when:
- You have multiple Amazon Quick workflows or agents that need the same tools (database queries, document retrieval, API integrations).
- You want centralized versioning and updates without redeploying every client.
- You need strong isolation and authorization between different client sessions.
- You have the infrastructure to monitor, trace, and debug shared services.
Avoid this pattern when:
- Your MCP server holds sensitive state that cannot be safely partitioned by session ID.
- You need guaranteed single-tenant isolation (compliance, security posture).
- Your tools are tightly coupled to a specific agent’s workflow and will not be reused.
- You lack the observability tooling to debug multi-client failures.
The pattern works best when the MCP server exposes stateless or externally-stateful tools that can be safely shared across clients. If your server relies on in-memory state or complex session lifecycles, the added complexity of multi-tenancy may outweigh the reusability benefits.