Two reference architectures for an MCP server: minimal cost and enterprise scale

A 6 November 2026 deployment audit and pricing review found that the same MCP website-search service costs about US$7 per month at 100,000 searches in a minimal single-region Azure Container Apps design, versus roughly US$8,400, US$13,200 or US$81,300 monthly at one million searches for a proposed two-region Azure enterprise design holding 100 GB, 1 TB or 10 TB of source content. The minimal design runs one warm replica at 0.25 vCPU and 0.5 GiB of memory with a maximum of two replicas, calls OpenRouter's text-embedding-3-small endpoint and searches an in-memory index published to Blob Storage, while the enterprise proposal moves retrieval to Azure AI Search and keeps business records in their own database. The author cautions that the estimates depend on how much text is extracted, how it is indexed and how often it changes, and that neither source size nor monthly request count establishes peak capacity.

Two reference architectures for an MCP server: minimal cost and enterprise scale · 13 min read I wanted to understand how infrastructure costs change when the same website search service moves from a personal deployment to an enterprise design. The small deployment can cost a few dollars a month. The two-region proposal can cost thousands before it receives much traffic. The requirements behind those numbers deserve as much attention as the service icons. This comparison uses a deployment audit and pricing review from 6 November 2026. The small design follows mcp-my-site https://pournasserian.com/open-source/mcp-my-site , my open-source server that lets AI clients search and fetch website content through the Model Context Protocol MCP . The enterprise design is a proposed Azure-only version of that service. The static website’s hosting is outside both estimates. In brief 1. One warm Azure Container App and an in-memory index can suit a small service built around public content. The model estimates about US$7 per month at 100,000 searches. 2. Azure AI Search suits the enterprise document-retrieval layer, with business records kept in their database. At one million searches, the modeled two-region platform costs about US$8,400, US$13,200 or US$81,300 monthly for 100 GB, 1 TB or 10 TB of source content. 3. Those estimates depend on how much text is extracted, how it is indexed and how often it changes. Neither the source size nor the monthly request count establishes peak capacity. The minimal design: keep the serving path small The deployed service runs in one Azure region, with Cloudflare https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/ in front of Azure Container Apps https://learn.microsoft.com/en-us/azure/container-apps/overview . One replica stays warm, allocated 0.25 vCPU and 0.5 GiB of memory; the configured maximum is two replicas. The app sends a query to OpenRouter’s embedding endpoint https://openrouter.ai/openai/text-embedding-3-small , then searches an index held in memory. Embeddings turn text into numerical vectors used for similarity search. Blob Storage holds the published index files, so this design has no separate managed search service. Key Vault, managed identity, Application Insights and Log Analytics support secrets access and operations. I use Azure Monitor dashboards with Grafana https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/visualize-grafana-overview in the Azure portal to view that telemetry. The dashboard feature has no separate fee; collecting and retaining telemetry can still cost money. Open the scalable minimal diagram https://pournasserian.com/writing/mcp-infrastructure-minimal-enterprise/minimal-reference.svg . GitHub Actions rebuilds the index when content changes, reuses embeddings for unchanged chunks and publishes the files to Blob Storage. GitHub Container Registry holds the application image. Cloudflare, GitHub and OpenRouter are part of this design, so it is not an Azure-only stack. This is a practical starting point for a personal site or a small public-content service. It has one serving region, no running regional standby and no shared search engine. Its publicly readable index is suitable for the site’s public material. Protected documents would require an authorization design and private storage before using the same pattern. A compact database supporting full-text search FTS and vector queries is also a reasonable small-deployment option when you need persistent updates or shared access. That would be a variation of this design, with its own compute, storage and backup costs; it is not part of the audited deployment or the small-service estimate below. The enterprise design: separate retrieval from business data The enterprise proposal keeps search and content-fetch capabilities while moving application dependencies, AI inference, content, delivery and operations to Azure services. Region A normally serves traffic; Region B stays running and indexed. Azure Front Door Premium https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-enable-private-link-apim , with a web application firewall WAF , connects privately to an independent API Management Standard v2 gateway in each region. Microsoft Entra ID supplies identity; the gateway validates access tokens and applies policy. Each gateway uses outbound virtual-network integration to reach its private Container Apps backend. Open the scalable enterprise diagram https://pournasserian.com/writing/mcp-infrastructure-minimal-enterprise/enterprise-reference.svg . For mixed documents and structured business data, I would use Azure AI Search https://learn.microsoft.com/en-us/azure/search/search-what-is-azure-search , a managed service for indexing and retrieving content, as the document-search layer. Original documents stay in private Blob Storage. Transactional records stay in Azure SQL, PostgreSQL or Cosmos DB; answers requiring exact, current business values read the authoritative database. A database with vector search can also support an enterprise application. It can be the better choice when retrieval primarily concerns operational records and a separate index would introduce unwanted delay. Microsoft’s service comparison https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/vector-search helps distinguish that case from a shared search layer across many sources. I chose AI Search here for the heterogeneous corpus and independent search scaling. Each region keeps two API Management units, three warm app replicas, an Azure OpenAI embedding deployment in a Microsoft Foundry https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry resource, and a Search service with three replicas. Microsoft Foundry, previously Azure AI Foundry, provides the model deployment and governance context. Azure AI Search and Blob Storage remain independent resources with their own networking and access controls, as shown in Microsoft’s resource architecture https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture . Search partitions grow with the corpus. Azure Firewall, private endpoints, Key Vault and managed identities control service access. Azure DevOps and geo-replicated Azure Container Registry handle delivery; Azure Monitor, Policy and Defender support operations. This reference uses direct hybrid search. Foundry IQ https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/foundry-iq-faq , an optional knowledge and agentic-retrieval layer built on Azure AI Search, would introduce a different retrieval workflow and billing model. The application combines full-text and vector retrieval, with optional semantic reranking. Tenant and document permission filters must come from trusted identity context. It must recheck authorization before returning search hits, snippets or fetched content, including after failover. Search is eventually consistent; private networking alone does not prevent a stale permission from leaking a result. Make application health visible Application Insights https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview provides application performance monitoring for requests, dependencies, exceptions and distributed traces. I would instrument the API and ingestion workers with OpenTelemetry and use a workspace-based Application Insights resource and Log Analytics workspace in each region. Redact document content, sample noisy traces and track search latency, model throttling, queue age, permission freshness and index lag. For private dashboard access, this proposal uses Azure Managed Grafana https://learn.microsoft.com/en-us/azure/managed-grafana/overview , with one Standard X1 workspace in each region. Grafana queries existing telemetry; it does not require a second copy of the logs. Entra ID controls access, and Azure DevOps publishes the dashboard definitions to both workspaces. Azure Monitor alerts operate independently of dashboard availability. Use private endpoints for operator access and an Azure Monitor Private Link Scope https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/private-link-security for supported log and trace access. Networks sharing DNS should share the scope. Native platform metrics use their Azure APIs. The estimate includes Grafana zone redundancy, subject to support in the final regions, and assumes operators already have private network connectivity. Process changed content once, then update both regions The ingestion pipeline uses source-specific change data capture CDC , transactional outboxes or publishers to put versioned work references on Service Bus. Azure-hosted workers extract and chunk changed documents, generate embeddings once, and retain canonical chunks, vectors and source versions in Blob. Document Intelligence, part of the Foundry Tools offering https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/how-to-guides/create-document-intelligence-resource?view=doc-intel-4.0.0 , can provide optical character recognition OCR or layout extraction where required. Copy those artifacts to the second region, then let regional workers apply complete-document upserts and deletes to their local Search indexes. Include permission changes, stale-version rejection, retries, dead letters and reconciliation. Search indexes do not replicate automatically between regions https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search . The proposed Blob object replication https://learn.microsoft.com/en-us/azure/storage/blobs/object-replication-overview uses flat-namespace accounts with versioning; this mechanism does not support hierarchical-namespace ADLS Gen2 accounts. Routine updates keep one active index set. A full schema or embedding-model rebuild may temporarily need a second set, priced separately below. This design requires application adapters, authorization work and recovery testing before it can be implemented. Size the searchable projection I modeled 100 GB, 1 TB and 10 TB of original source content, with 1% replaced each day. Source bytes, index disk and resident vector memory are different quantities. For illustration, the calculation assumes 10% of source bytes become text, four bytes per token, 800-token chunks with 160-token overlap, and 512-dimension embeddings. It allows 8 KiB of total index disk per chunk and uses scalar int8 vector compression with full-precision originals retained for rescoring. | Original source | Estimated chunks | Live index disk | Resident vectors | Search in each region | |---|---|---|---|---| | 100 GB | 3.91 million | 32 GB | 3 GB | S1: 1 partition × 3 replicas | | 1 TB | 39.06 million | 320 GB | 30 GB | S2: 1 partition × 3 replicas | | 10 TB | 390.63 million | 3.2 TB | 300 GB | S3: 6 partitions × 3 replicas | These are capacity candidates with at least 30% modeled headroom, not benchmark results. Current Search limits https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity depend on tier, region and service creation or upgrade status. A single S3 index is limited to 2.34 TB under the selected limits, so the 10 TB scenario uses two logical indexes per region. The application routes queries or searches both and merges ranked results; a normal Search query addresses one index. The estimate assumes two-index fan-out for that scenario. Frequent updates also affect storage choices. The disk model omits the optional source-vector copy with stored:false , while retaining originals needed for scalar rescoring. With this option, every update must resend the vector, including permission-only updates. Otherwise an update can silently lose vector data. The canonical cache supports complete upserts; keeping stored:true is another option, requiring a larger measured storage budget. See vector storage options https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-storage-options . Estimated monthly costs The estimates use pay-as-you-go prices and a 730-hour month. Each modeled request includes one search and a 100-token query embedding; an agent session can make several requests. The enterprise estimate also allows a content read per request and 1% daily content replacement, with no net corpus growth. | Requests per month | Actual small deployment, USD | |---|---| | 1,000 | $5.90 | | 10,000 | $5.97 | | 100,000 | $6.65 | | 1 million | $22.83 | The small model covers the site’s public corpus. It does not provide the enterprise data scale or resilience. These figures depend on idle CPU billing and shared free allowances. At one million searches, billing the single replica as active for the whole month raises the estimate to about US$31.55. Extra replicas, a database or larger logs add cost. The enterprise table covers the incremental retrieval platform, including its fully running standby. Existing business databases and their CDC/export and disaster-recovery costs are additional. | Enterprise source content | 100,000 requests | 1 million requests | 5 million requests | |---|---|---|---| | 100 GB | $8,376 | $8,407 | $8,544 | | 1 TB | $13,128 | $13,159 | $13,297 | | 10 TB | $81,257 | $81,293 | $81,455 | All values are monthly USD. At one million requests, an added 20% contingency gives approximately US$10,088, US$15,791 and US$97,552. Using the illustrative US$1 = CA$1.40375 conversion, the base estimates are about CA$11,801, CA$18,472 and CA$114,115. Neither contingency nor conversion includes the excluded services. What drives the enterprise bill Search capacity is the largest line item in the 10 TB scenario. Both regions keep the same provisioned capacity, even while the standby serves no user traffic. | Component, both regions at 1M requests | 100 GB | 1 TB | 10 TB | |---|---|---|---| | Azure AI Search | $1,472 | $5,887 | $70,641 | | API Management, four units | $2,400 | $2,400 | $2,400 | | Firewall, two deployments | $1,825 | $1,825 | $1,825 | | Service Bus, two messaging units | $1,354 | $1,354 | $1,354 | | Changed-content embeddings | $21 | $206 | $2,063 | | Managed Grafana, two X1 workspaces with zone redundancy and five active users | $190 | $190 | $190 | | Additional private monitoring access | $33 | $33 | $33 | | Application Insights / Log Analytics ingestion | $70 | $77 | $157 | The totals also include warm application replicas, Front Door, Blob originals and cached vectors, workers, registry, delivery, network traffic and monitoring. The detailed sizing and cost companion https://pournasserian.com/writing/mcp-infrastructure-minimal-enterprise/enterprise-sizing-and-costs.md gives every line item, equations, CAD totals and exclusions. The calculated model https://pournasserian.com/writing/mcp-infrastructure-minimal-enterprise/enterprise-cost-model.json contains all nine scenarios. The Grafana allowance https://azure.microsoft.com/en-us/pricing/details/managed-grafana/ is about US$100 for compute, US$60 for zone redundancy and US$30 for five active users per month. Those users are charged once across both workspaces in the same subscription. Private monitoring adds about US$33 monthly at one million requests. Application Insights and Log Analytics share the telemetry-ingestion charge shown above. Together, Grafana and private monitoring contribute about US$222–223 per month; the small design’s portal dashboards add no separate fee. Cheaper capacity candidates deserve testing. At 1 TB, S1 with three partitions per region costs about US$4,415/month for Search, compared with US$5,887 for the proposed S2. At 10 TB, a fleet of S1 services costs about 52,980 USD for Search, while an L1 Storage Optimized configuration costs about 50,444 USD, compared with 70,641 USD for S3. Those are monthly Search-only costs with both regions included. S1 adds service/index routing complexity at 10 TB; Storage Optimized tiers https://learn.microsoft.com/en-us/azure/search/search-sku-tier target less frequently updated indexes and typically higher query latency. This review has not established which is fastest or cheapest for the actual workload. Updates, first load and optional features The following sensitivity holds Search and app capacity fixed at one million requests/month. A higher update rate may also require extra capacity and retention beyond these estimates. | Source changed each day | 100 GB | 1 TB | 10 TB | |---|---|---|---| | 0.1% | $8,381 | $12,905 | $78,756 | | 1% | $8,407 | $13,159 | $81,293 | | 10% | $8,660 | $15,696 | $106,666 | The initial load adds approximately US$91, US$912 or US$9,119 in variable processing costs for the three corpus sizes, plus the running platform and any OCR. These use an illustrative worker allowance, not measured processing times. Completing the 10 TB first load in seven days would need roughly 31 million embedding tokens per minute on average; that quota has not been secured. At 1% daily change, it still needs roughly 2.17 million embedding tokens per minute on average. A seven-day full blue/green rebuild would add approximately US$0, US$1,355 or US$16,257 in Search capacity. The smallest case fits both versions within its modeled capacity but still consumes worker and query resources. Unchanged vectors can be replayed from the cache; a new model or chunking strategy can require regeneration. Optional semantic ranking on every search adds about US$100, US$1,000 or US$5,000 at the three request volumes for the single-index cases. The two-index 10 TB case doubles those additions. OCR is priced separately by pages: one million pages cost about US$1,500 with Document Intelligence Read or US$10,000 with Prebuilt/Layout. At ten million pages, the modeled Read tiers total US$6,900. Do not add a separate Read charge when the chosen Layout operation already extracts the text. See Search pricing https://azure.microsoft.com/en-us/pricing/details/search/ and Document Intelligence pricing https://azure.microsoft.com/en-us/pricing/details/document-intelligence/ . These estimates cover retrieval and embeddings. The model charges already include the proposed Azure OpenAI embedding deployment in Foundry; Foundry IQ and Agent Service features are outside this baseline. The service does not generate chat answers. A generated-answer feature would need a separate model and input/output-token budget. Choose the next component from a requirement I would start with the small design for public content when an occasional interruption and a manual recovery are acceptable. I would add shared search when the corpus or workload needs it, private content access when documents require protection, and a second serving region when the recovery objective justifies its ongoing cost. | Requirement | Design work it introduces | |---|---| | Restrict documents by user or tenant | Identity, trusted permission filters and private content reads | | Recover from a regional outage | A current second-region index, reserved capacity and rehearsed failover | | Grow beyond the local index | Managed search, retrieval evaluation and measured sizing | | Control delivery and service access centrally | Private networking, workload identities and controlled release pipelines | A monthly request count cannot select those controls. Five million requests spread evenly over a month is about 1.9 requests per second; a burst or many long-lived MCP connections can need much more capacity. I would use peak concurrency, latency and recovery tests to set the final replica and service sizes. Method and caveats The small configuration was checked against deployed resources, billing records and aggregate telemetry on 6 November 2026. Its traffic projections assume one warm replica, roughly one additional active second per search and 6 KB of telemetry per search. The sample contained few successful searches, so these are planning assumptions rather than a benchmark. The forecast allocates no additional Cloudflare or GitHub cost; their account-wide plans and invoices were not audited. The enterprise design has not been deployed or load-tested. Its estimate uses North American regional price proxies for both stacks and a separate regional embedding-rate proxy; final regions and AI quota remain unselected. Search capacity changes with the corpus but stays fixed across request volumes. The model budgets all six app replicas at active rates, 10 KB of logs per request, extra logs for index fan-out and ingestion, and one worker-hour per changed source GB. These are allowances to validate. The 10% text-extraction assumption matters substantially. At one million requests and 1% daily change, using 5% or 50% extracted text changes the 10 TB estimate to approximately US$44,817 or US$302,461 after resizing Search. These are scenarios, not uncertainty bounds. Compressed sources can expand further. Sample the actual documents and schema, then measure retrieval quality, disk use, vector memory, update lag and peak load before selecting capacity. The calculations use Azure’s public retail pricing https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices , Container Apps billing rules https://learn.microsoft.com/en-us/azure/container-apps/billing , Azure Monitor prices https://azure.microsoft.com/en-us/pricing/details/monitor/ and OpenRouter pricing https://openrouter.ai/pricing . Source databases and CDC/export, taxes, engineering, support, nonproduction, applicable Entra premium licenses, new VPN or ExpressRoute connectivity and unspecified long-term backup storage are additional. Shared free grants are assumed available. Security is a provisional allowance; replace it with the chosen protection plans before approving a production budget. The diagrams use Microsoft’s Azure architecture icons https://learn.microsoft.com/en-us/azure/architecture/icons/ and Entra architecture icons https://learn.microsoft.com/en-us/entra/architecture/architecture-icons/ . They describe the serving and operating patterns; the source audit’s account identifiers and private deployment details are omitted.