You can run MCP on Cloud Run, Functions, AgentCore, Kubernetes, or a VM. The protocol is open (intro). The question is whether you want to own everything the protocol leaves unspecified.
Self-hosting: you own
| Layer | Work |
|---|---|
| Compute | Containers/functions/VMs |
| Transport edge | Streamable HTTP MCP endpoint (transports) |
| Auth | OAuth resource server / keys (authorization) |
| Security | Confused deputy, SSRF, sessions, local install risks (security best practices) |
| Tools | Validation, rate limits, sanitization (tools security) |
| Ops | Deploys, logs, tool metrics, rollback |
| Identity of on-call | Your SRE/platform team |
Cloud vendors may document MCP-oriented patterns; they rarely ship a full multi-server MCP product surface.
Managed hosting: you buy
| Layer | Typical product |
|---|---|
| Artifact → URL | Git/Docker/package deploy |
| Isolation defaults | Container/runtime hardening |
| Auth toggles | Keys/OAuth at the edge |
| UX | Dashboard, CLI, agent tools |
| Observability | Logs + tool analytics |
MCPLambda example: deployment strategies.
Decision table
| Priority | Lean |
|---|---|
| Ship this week / small team | Managed |
| Existing platform team + cloud mandate | Self-host on that cloud |
| VPC-only / approved-vendor list | Self-host in tenant |
| Many custom MCP products, little platform staff | Managed |
| Differentiated multi-tenant runtime is the product | Self-host (carefully) |
Deep dive comparisons: hyperscalers, Vercel.
Non-negotiables either path
Whether managed or DIY, production remote MCP should:
- Prefer Streamable HTTP for new remotes
- Authenticate clients
- Validate Origin on HTTP transports
- Avoid token passthrough
- Rate-limit and validate tools
- Log enough to debug
tools/callfailures - Keep secrets out of git
Official sources for each: transports, authorization, security best practices, tools security (linked above).
Cost honesty
| Cheap on paper | Expensive in practice |
|---|---|
| Function/GB-second pricing | Engineer weeks on auth edge cases |
| “We already have AWS” | Tool analytics DIY |
| One demo server | N environments × N servers without a control plane |
Worked scenario: The “we already have AWS” trap
Leadership assumes MCP is “just another container.” Three months later you have half-finished OAuth, inconsistent logging, and no tool-level metrics—while product teams wait.
You reframe: self-host when a cloud mandate or platform team already owns the landing zone end-to-end. Otherwise buy a managed MCP control plane for artifact→URL, auth toggles, and tool analytics, and spend engineers on tools—not on re-implementing Streamable HTTP edge cases.
Either path still owes the protocol: auth, Origin validation, rate limits, and safe tool design.
Checklist for this topic
- List protocol non-negotiables (auth, transports, tool security)
- Inventory platform staff and mandates honestly
- Estimate TCO including on-call, not only compute
- Choose managed unless mandate/staff force DIY
- If DIY, budget for tool-level observability
- Revisit annually as MCP footprint grows
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Endless platform project | DIY without staff | Managed control plane |
| Compliance blocks SaaS host | Tenant requirement | Self-host in VPC |
| Cheap compute, expensive outages | No tool metrics | Invest in observability |
| Mixed undocumented deploys | No standard path | Pick one primary approach |
Related guides
Managed vs build · Securing remote · Hyperscaler compare
In practice: 90-day DIY budget
If you choose self-host, budget explicitly for:
- Streamable HTTP edge + TLS + Origin
- Auth implementation and rotation
- Tool-level metrics
- On-call runbooks
- Load testing
If finance only approved “one small container,” you chose managed without admitting it—and you will pay later in incidents.
Questions to force an honest DIY choice
- Who gets paged at 2am when auth breaks?
- Who implements Origin validation and OAuth edge cases?
- Who builds tool-level dashboards?
- What is the deadline for the first production server?
If answers are “we’ll figure it out,” managed hosting is the responsible choice until a mandate forces otherwise.
Takeaways
For Self-Hosting MCP on Cloud vs Managed MCP Hosting, remember three things:
- Be specific to this problem — the worked scenario “The “we already have AWS” trap” is the failure mode you should design against, not a generic outage narrative.
- Self-host only when policy or data gravity forces it and a platform team owns day-2 ops.
- Managed hosting wins when time-to-production and tool-level ops matter more than raw IaaS control.
If you only remember one habit: “we already have AWS” is not a hosting strategy for MCP product velocity. If DIY is mandatory, staff it like a product: roadmap, SLOs for initialize success and tool error rate, and a quarterly security review against the official MCP security best practices document.
Sources
- Architecture
- Transports — 2025-11-25
- Authorization — 2025-11-25
- Security Best Practices
- Tools security
- Connect to remote MCP servers
