# Enterprise retrieval: sizing and cost companion

Reference design and planning model reviewed 6 November 2026. All amounts are approximate USD unless marked CAD. This supersedes the earlier 10 GB-per-region enterprise estimate. It covers the incremental retrieval platform in an active region and a fully running standby, for mixed documents and structured business data. It is not a measured deployment, a capacity reservation or an Azure quote.

## Scope and recommendation

Use Azure AI Search Dedicated Standard for a separate, multi-source document retrieval layer. Keep original documents in private Azure Blob Storage and transactional records in their existing Azure SQL, Azure Database for PostgreSQL or Azure Cosmos DB systems. Index only fields that need search; use the authoritative database for exact, current transactional answers.

A vector-capable database can also be enterprise-grade. PostgreSQL with pgvector or Cosmos DB hybrid search can be a better fit when the application primarily searches operational records and needs updates searchable with minimal projection delay. The reason to choose AI Search here is the heterogeneous document corpus, independent search scaling and combined text/vector relevance features. See [Microsoft's vector-search service comparison](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/vector-search).

The source databases' compute, storage, high availability, regional disaster recovery, change export and query charges are excluded. These figures are an additional retrieval budget, not the complete cost of an enterprise's business systems. Document extraction/OCR, semantic ranking and generated answers have separate scope below.

## Serving and ingestion design

Azure DNS and Front Door Premium with WAF route authenticated clients to two independent API Management Standard v2 instances. Each uses inbound Private Link and outbound VNet integration to private Container Apps. Each region keeps three app replicas, regional Azure OpenAI embeddings, Search, Blob, Service Bus, Key Vault and network controls running. Azure DevOps, Azure-hosted agents and ACR provide delivery. Entra ID, Monitor, Policy and Defender support access and operations.

Each regional embedding deployment belongs to a Microsoft Foundry resource. Microsoft Foundry is the current name for Azure AI Foundry. Search and Blob remain independent Azure resources outside that resource boundary; see [the Foundry architecture](https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture). The model continues to price the underlying Azure OpenAI embedding usage with the same deployment-type and regional-rate assumptions. It does not add Foundry IQ, Agent Service or an answer-generation model. [Foundry IQ](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/foundry-iq-faq) is an optional retrieval layer built on Search with its own usage charges and optional model costs. Document Intelligence is an optional Foundry Tools service, priced separately by pages below.

The application embeds the query once, submits text plus vector queries to the applicable regional index or indexes, and merges results when needed. [Hybrid search](https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview) combines lexical and vector retrieval. Semantic reranking is optional. Trusted tenant and document filters must be derived from identity; recheck current authorization before returning snippets, results or content. An identity-managed private connection alone does not enforce end-user permissions. See [security trimming](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search).

The ingestion workflow is:

1. Source-specific change data capture (CDC), a transactional outbox or a publisher emits versioned work references into Service Bus. Include deletions and access-control changes.
2. Azure-hosted Container Apps workers extract, normalize and chunk changed content. Document Intelligence Read or Layout is optional for documents that need it.
3. Workers generate changed embeddings once. Store canonical chunks, full vectors, source versions, hashes and access-control metadata in Blob so both regions can reuse them.
4. Copy originals and canonical artifacts to the other region. A regional publisher validates object/version availability and queues local indexing work. Regional workers push idempotent upserts and deletes into Search, then advance a freshness watermark.
5. Use reconciliation, retry budgets, dead-letter queues and source-version checks to repair missing or out-of-order changes. Give permission revocations priority. Fail closed when authorization freshness cannot be established.

This uses flat-namespace Blob Storage. [Blob object replication](https://learn.microsoft.com/en-us/azure/storage/blobs/object-replication-overview) needs source change feed and versioning in both accounts; the same mechanism does not support hierarchical-namespace ADLS Gen2 accounts. Copy and validate deletion/permission manifests explicitly rather than treating a blob deletion as a search-delete command. Replication is asynchronous and is not a backup.

Search indexes in the two regions are populated independently from the same canonical artifacts. They do not replicate themselves. Keep one active index version per region during routine updates; reserve extra capacity temporarily for schema/model migrations or a full rebuild. [Search reliability guidance](https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search) treats the index as recoverable derived data. A running standby also needs a current authorization path, sufficient preapproved AI quota and a rehearsed source-database failover procedure.

## Application telemetry and dashboards

Instrument the API and workers with OpenTelemetry and workspace-based Application Insights. Keep an Application Insights resource and Log Analytics workspace in each region. Requests, dependencies, exceptions and traces are stored in the associated workspace; do not charge a second ingestion copy merely because both product names appear in the diagram. The existing logging line is the combined ingestion budget, with a single shared 5 GB allowance. Retention beyond the included period, exports and optional paid telemetry features require additional sizing.

Azure Managed Grafana queries Azure Monitor logs, traces and platform metrics. The design includes one Standard X1 workspace per region, each with optional zone redundancy, and five billable active identities total in the same subscription. Each X1 is two Standard Units; its zone option adds one Zone Redundancy Unit. Unique active users, service accounts and API keys are billed once per subscription even when accessing both workspaces. Extra automation identities may increase the five-user allowance. See [Grafana pricing](https://azure.microsoft.com/en-us/pricing/details/managed-grafana/).

Use private inbound dashboard endpoints and Entra ID access. Grafana managed private endpoints query supported log sources through an Azure Monitor Private Link Scope (AMPLS). Use a single scope for networks sharing DNS and link the regional Application Insights resources and workspaces. Native Azure Monitor metric APIs use their appropriate Azure endpoints; AMPLS does not privatize every management or metric API. Entra sign-in remains an Azure-managed public endpoint. See [private data sources](https://learn.microsoft.com/en-us/azure/managed-grafana/how-to-connect-to-data-source-privately), [private dashboard access](https://learn.microsoft.com/en-us/azure/managed-grafana/how-to-set-up-private-access) and [AMPLS topology guidance](https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/private-link-security).

The networking increment includes two Grafana inbound private endpoints and two application-network endpoints to AMPLS, plus five extra private DNS zones, reusing the existing Blob zone. Its traffic allowance is twice the modeled telemetry GB plus 20 GB/month for monitoring queries, allowing for ingestion and query/export traffic rather than claiming a measured volume. Grafana managed private endpoints themselves have no separate fee; related source-side Private Link charges still apply. Existing private operator connectivity is assumed. New VPN/ExpressRoute links, operator desktops and associated transfer are excluded.

Publish dashboard definitions and data-source configuration to both regions through Azure DevOps. Grafana is regional and does not automatically replicate that configuration; select regions that support the requested [zone redundancy](https://learn.microsoft.com/en-us/azure/reliability/reliability-managed-grafana). Azure Monitor alerts for availability, latency, throttling, queue/dead-letter counts and content/permission lag remain independent of Grafana. Redact content and credentials, sample high-volume traces, and test observability during failover. No Prometheus, Loki or Tempo service is required by this baseline.

The actual small deployment instead uses free Azure Monitor dashboards with Grafana in the Azure portal. That is a distinct service choice: its dashboards have no separate fee, while telemetry collection and retention remain billable. See [the Azure comparison](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/visualize-grafana-overview).

## Workload assumptions

The user-selected scenarios are 100 GB, 1 TB and 10 TB of source content; 100,000, 1 million and 5 million search requests/month; and 1% content replacement per day. Source sizes use decimal GB/TB. All other conversion factors below are explicit modeling assumptions to replace with a sample measurement.

| Input | Baseline |
| --- | --- |
| Time and resilience | 730 billed hours, 30 update days; two regions; three Search replicas in each |
| Searchable text | 10% of original source bytes; 4 bytes/token |
| Chunking | 800 tokens with 160-token overlap, approximated as a 640-token stride |
| Embedding | text-embedding-3-small, 512 dimensions; $0.022 per million tokens |
| Index disk | 8 KiB/chunk total, including text, metadata, inverted indexes and vector copies |
| Resident vector index | 512 int8 bytes + 128 graph overhead bytes/chunk, multiplied by 1.2 for update overhead |
| Canonical artifacts | 6 KiB/chunk, separate from original content; full vectors retained |
| Blob retention | Two regions × 1.5 × (original source + canonical artifacts); Hot ZRS rate proxy |
| Headroom | At most 70% of modeled disk, vector and applicable single-index limits; one active version |
| Updates | 1% of source replaced daily = 30% processed/month; no net corpus growth |
| Worker allowance | 1 worker-hour per changed source GB + 20 background hours/month; 1 vCPU/2 GiB |
| Batching for storage transactions | 1 MB source objects; 256 canonical chunks/blob |
| Request | One 100-token query embedding, 20 KB response, a content-read allowance; no generated answer |
| Index fan-out | One index per request at 100 GB/1 TB; two indexes at 10 TB; one regional stack serves |
| Logs | 20 GB/month background + 10 KB/request + 2 KB/extra index call + 0.01 GB/changed source GB |
| Grafana | Two Standard X1 workspaces; one zone unit each; five active users total in one subscription |
| Private monitoring | Four extra private endpoints; five additional DNS zones; traffic = 2 × log GB + 20 GB |
| Exchange and contingency | CAD = USD × 1.40375, illustrative; optional 20% contingency |

Worker-hours are aggregate processing and dual-region indexing effort, not hours promised to finish a job. The cost model assumes regional workers reuse vectors and that sufficient parallelism/quota can be obtained. Storage versions, tombstones, retries and metadata can exceed these allowances. The text fraction can exceed 100% for compressed source formats; the examples below are not bounds.

## Capacity candidates

| Original source | Estimated chunks | Live index disk | Resident vector estimate | Per-region Search candidate | Live indexes/region |
| --- | --- | --- | --- | --- | --- |
| 100 GB | 3,906,250 | 32 GB | 3 GB | S1: 1 partition(s) × 3 replicas | 1 |
| 1 TB | 39,062,500 | 320 GB | 30 GB | S2: 1 partition(s) × 3 replicas | 1 |
| 10 TB | 390,625,000 | 3,200 GB | 300 GB | S3: 6 partition(s) × 3 replicas | 2 |

The modeled current partition limits are S1: 160 GB disk/35 GB vectors; S2: 512/150; S3: 1,024/300. Region and service creation/upgrade status matter. S2 and S3 also have single-index limits of 1.88 TB and 2.34 TB. See [current limits](https://learn.microsoft.com/en-us/azure/search/search-limits-quotas-capacity). These are storage-fit candidates, not tested throughput guarantees or cheapest-SKU claims. Partitions are internal Search storage/compute units; logical indexes are application-visible boundaries.

At 10 TB, the estimated 3.2 TB live index is divided into two roughly 1.6 TB indexes to stay below the S3 single-index limit with headroom. [A normal Search query targets one index](https://learn.microsoft.com/en-us/azure/search/search-faq-frequently-asked-questions). Route by tenant/domain where possible; otherwise query both, merge ranked lists and evaluate relevance. Raw BM25 scores from separate indexes are not globally comparable. The main estimate conservatively uses two-index fan-out for every 10 TB request.

The vector configuration assumes scalar int8 quantization with original full-precision vectors retained for rescoring. Measure recall against full precision before accepting it. [Quantization](https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-quantization) changes memory use and retrieval behavior; [vector sizing](https://learn.microsoft.com/en-us/azure/search/vector-search-index-size) must be measured on the real schema.

The disk estimate assumes removal of the optional source-vector copy using stored:false. This does not remove originals retained for scalar rescoring. With that setting, every update must resend the vector; partial updates that omit it can silently lose vector data. Use canonical cached vectors for full-document upserts, including permission-only updates, or keep stored:true and resize. See [vector storage options](https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-storage-options).

## Monthly platform estimate, USD

| Source content | 100K requests | 1M requests | 5M 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 |

At 1M requests, 20% contingency produces planning amounts of $10,088, $15,791, $97,552 respectively. Contingency does not cover a missing business database, unknown page count or arbitrary peak-scale requirements.

| Source content | 100K requests, CAD | 1M requests, CAD | 5M requests, CAD |
| --- | --- | --- | --- |
| 100 GB | $11,758 | $11,801 | $11,994 |
| 1 TB | $18,429 | $18,472 | $18,665 |
| 10 TB | $114,065 | $114,115 | $114,342 |

The small public-site deployment remains a separate scenario: approximately $5.90 at 1K searches, $5.97 at 10K, $6.65 at 100K and $22.83 at 1M. It does not process these enterprise corpora or provide their controls. Adding a compact full-text/vector database to it would require a fresh resource estimate.

### Detailed breakdown at 1M requests/month

| Component, both regions | 100 GB | 1 TB | 10 TB |
| --- | --- | --- | --- |
| API Management Standard v2, four units | $2,399.99 | $2,399.99 | $2,399.99 |
| Azure Firewall Standard, two deployments | $1,825.00 | $1,825.00 | $1,825.00 |
| Service Bus Premium, two messaging units | $1,354.15 | $1,354.15 | $1,354.15 |
| Container Apps, six warm replicas | $323.57 | $323.57 | $323.57 |
| Front Door Premium + WAF base | $330.00 | $330.00 | $330.00 |
| ACR Premium + regional replica | $101.38 | $101.38 | $101.38 |
| 12 private endpoints | $87.60 | $87.60 | $87.60 |
| Azure DevOps, private agents and artifacts | $50.60 | $50.60 | $50.60 |
| Provisional security allowance | $100.00 | $100.00 | $100.00 |
| Provisional alerts allowance | $10.00 | $10.00 | $10.00 |
| Two firewall public IP addresses | $7.30 | $7.30 | $7.30 |
| Key Vault operations | $0.06 | $0.06 | $0.06 |
| Azure AI Search, both regions | $1,471.68 | $5,886.72 | $70,640.64 |
| Azure Managed Grafana, two Standard X1 workspaces | $99.86 | $99.86 | $99.86 |
| Grafana zone redundancy, one unit per workspace | $60.01 | $60.01 | $60.01 |
| Grafana, five active users across one subscription | $30.00 | $30.00 | $30.00 |
| Monitoring: four extra endpoints, five DNS zones and traffic | $32.51 | $32.56 | $33.14 |
| Azure DNS and Private DNS | $5.34 | $5.34 | $5.34 |
| Blob originals, canonical artifacts and versions | $9.30 | $93.00 | $930.00 |
| Blob read/write operations | $1.07 | $5.51 | $49.88 |
| Extraction and indexing workers | $7.56 | $48.38 | $456.62 |
| Changed-content embeddings, generated once | $20.63 | $206.25 | $2,062.50 |
| Query embeddings | $2.20 | $2.20 | $2.20 |
| Regional content/artifact/image transfer | $1.34 | $8.04 | $75.00 |
| Log ingestion | $69.83 | $77.28 | $157.32 |
| Front Door traffic and requests | $3.19 | $3.19 | $3.19 |
| Private Link data processing | $1.56 | $10.20 | $97.00 |
| Firewall data processing | $0.83 | $0.83 | $0.83 |
| Container Apps request meter | $0.00 | $0.00 | $0.00 |
| Total | $8,406.56 | $13,159.03 | $81,293.19 |

The machine-readable companion contains the same line items for all nine traffic/corpus combinations. The gateways, firewall, Service Bus and six warm app replicas remain fixed across scenarios. Search is charged by provisioned search units, not an ordinary per-query fee. Three replicas are included in each region for concurrent querying and indexing; capacity and end-to-end recovery still need testing.

### Auditable unit rates and equations

Public Azure pay-as-you-go rate records were retrieved on 6 November 2026, using North American regional proxies, with the same infrastructure rate applied to both regions and a separately sourced regional embedding proxy. Final regions remain unselected. These are not the account's negotiated rates. Exact retail meter records are retained with the private research material. The source is the [Azure Retail Prices API](https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices).

| Meter | USD rate |
| --- | --- |
| Search S1 / unit-hour | $0.336 |
| Search S2 / unit-hour | $1.344 |
| Search S3 / unit-hour | $2.688 |
| Search L1 / unit-hour | $3.839 |
| Search L2 / unit-hour | $7.677 |
| Container Apps active vCPU / second | $0.00003400 |
| Container Apps GiB / second | $0.00000400 |
| Blob Hot ZRS / GB-month | $0.02500 |
| Blob writes / 10,000 | $0.0688 |
| Blob reads / 10,000 | $0.0044 |
| Log Analytics / ingested GB | $2.760 |
| Cross-region transfer / GB allowance | $0.020 |
| Grafana / Standard Unit-hour | $0.0342 |
| Grafana / Zone Redundancy Unit-hour | $0.0411 |
| Grafana / active user-month | $6.00 |
| Private endpoint / hour | $0.010 |
| Private DNS zone / month | $0.50 |
| Private Link / processed GB | $0.010 |
| Semantic ranker / 1,000 index calls | $1.00 |

- Chunks = ceil(source GB × 10^9 × extracted-text fraction ÷ 4 ÷ 640). Initial embedding tokens = chunks × 800. This includes 25% overlap overhead under the stride approximation.
- Search cost = regions × services/region × partitions/service × replicas × 730 × hourly SKU rate. For 10 TB: 2 × 1 × 6 × 3 × 730 × $2.688 = $70,640.64/month.
- Changed-content embedding cost = initial tokens × daily change fraction × 30 × $0.022 / 1,000,000. Query embeddings = requests × 100 × $0.022 / 1,000,000, independent of fan-out.
- Worker cost = (20 + changed GB × 1) × 3,600 × (active vCPU-second rate + 2 × GiB-second rate).
- Blob capacity = 2 × 1.5 × (source GB + chunks × 6,144 / 10^9) × GB-month rate. Both regions hold canonical artifacts and source copies.
- Log cost = max(20 + 0.01 × changed GB + request logs in GB - 5, 0) × ingestion rate. The 5 GB allowance is shared, not repeated per region.
- Grafana compute = 2 workspaces × 2 SU × 730 × $0.0342 = $99.86/month; zone redundancy = 2 × 1 ZRU × 730 × $0.0411 = $60.01; active users = 5 × $6 = $30. Total = $189.87/month, with no trial discount or Enterprise plugin license.
- Extra private monitoring = 4 × 730 × endpoint-hour rate + 5 × private-zone rate + (2 × log GB + 20) × Private Link GB rate. At 1M requests this is $32.51, $32.56, $33.14 for the three corpora. With Grafana, the increment is $222.38, $222.43, $223.01.

The fixed platform also includes four APIM units, two firewalls, two Service Bus messaging units, six 0.5-vCPU/1-GiB app replicas, Front Door Premium, ACR Premium replication, 12 application private endpoints plus four monitoring endpoints, eight application private DNS zones plus five monitoring zones, two public IPs, 100 build-agent VM-hours, delivery/artifact allowances, $100 security and $10 alerts allowances. App free grants are allocated once at subscription level; worker rates receive no second free grant. APIM request allowances cover the modeled counts but do not guarantee sufficient gateway throughput.

## Update-rate sensitivity

At 1M requests/month, keeping the same Search and app capacity:

| Source changed/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 |

At 10% per day the model processes three corpus-equivalents per month. Higher sustained change can require extra Search replicas, faster workers, greater AI quota and more storage for versions; those effects are not captured by holding capacity fixed. The baseline's 1% on 10 TB already needs about 2.17 million embedding tokens/minute on average. Quota, burst behavior and indexing contention are material constraints.

## Source size is not index size

At 1M requests/month and 1% daily replacement, recalculating Search capacity for the searchable-text fraction gives:

| Original bytes becoming searchable text | 100 GB source | 1 TB source | 10 TB source |
| --- | --- | --- | --- |
| 5% | $8,395 | $13,044 | $44,817 |
| 10% | $8,407 | $13,159 | $81,293 |
| 50% | $9,970 | $43,518 | $302,461 |

This range is a scenario comparison, not a confidence interval. A sample of actual documents, extracted text, metadata, access lists and embeddings is needed before approving a budget. Extra languages, embeddings per item, long access lists, field attributes and deleted-vector overhead can materially change size.

## Cheaper Search capacity alternatives to benchmark

| Source | Tier | Services/region | Partitions/service | Live indexes/region | Search only/month, both regions |
| --- | --- | --- | --- | --- | --- |
| 1 TB | S1 | 1 | 3 | 1 | $4,415 |
| 1 TB | S2 | 1 | 1 | 1 | $5,887 |
| 10 TB | S1 | 3 | 12 | 3 | $52,980 |
| 10 TB | S2 | 1 | 12 | 3 | $70,641 |
| 10 TB | S3 | 1 | 6 | 2 | $70,641 |
| 10 TB | L1 | 1 | 3 | 1 | $50,444 |
| 10 TB | L2 | 1 | 2 | 1 | $67,251 |

All candidates include three replicas/service and both regions. The 1 TB S1 option saves about $1,472/month against the modeled S2 selection; S2 has fewer partitions and different hardware, but this review has not measured a performance advantage for this application. At 10 TB, the S1 fleet and L1 alternative are cheaper in provisioned storage terms. S1 introduces more service management and cross-index routing. [Storage Optimized tiers](https://learn.microsoft.com/en-us/azure/search/search-sku-tier) target large, less frequently updated indexes and typically higher query latency, so L1/L2 need workload testing before replacing Standard here. There is no measured winner in this comparison. Serverless Developer remains preview without an SLA and is outside this production baseline.

## First load and full rebuilds

| Source | Initial embedding tokens | Embedding cost | Other variable first-load costs | Initial variable total | Average TPM for a 7-day load |
| --- | --- | --- | --- | --- | --- |
| 100 GB | 3.125 billion | $68.75 | $22.44 | $91.19 | 310,020 |
| 1 TB | 31.25 billion | $687.50 | $224.43 | $911.93 | 3,100,198 |
| 10 TB | 312.5 billion | $6,875.00 | $2,244.34 | $9,119.34 | 31,001,984 |

Initial variable totals cover embeddings, the assumed worker-hours, copying data once, private-link processing and Blob operations. Add the running platform for the elapsed ingestion period; first-load logging, OCR/Layout, engineering and extra throughput capacity are excluded. Seven days is a quota-planning example, not a completion-time commitment. The 10 TB example requires around 31 million embedding TPM to finish within it, which has not been secured or verified available.

To hold two full index versions for a seven-day blue/green rebuild, estimated additional Search capacity is 100 GB: $0; 1 TB: $1,355; 10 TB: $16,257. The 100 GB case fits both versions within existing modeled capacity, but a rebuild still consumes throughput and worker resources. New embedding models/chunking can require regeneration; unchanged vectors can be replayed from Blob. Allow for scale-up/down lead time and billing granularity. Rollback from routine updates relies on retained canonical versions and replay; an immediately switchable previous full index is not always running.

## Optional semantic ranking and OCR

| Source | Semantic at 100K requests | At 1M | At 5M |
| --- | --- | --- | --- |
| 100 GB | $100 | $1,000 | $5,000 |
| 1 TB | $100 | $1,000 | $5,000 |
| 10 TB | $200 | $2,000 | $10,000 |

These additions enable semantic ranking on every index call, conservatively ignoring the small free allowance. The 10 TB two-index plan doubles calls. They are extra to the base retrieval totals and are unrelated to generating an answer. See [Search pricing](https://azure.microsoft.com/en-us/pricing/details/search/).

| New or changed pages processed | Read OCR | Prebuilt/Layout |
| --- | --- | --- |
| 100,000 | $150 | $1,000 |
| 1,000,000 | $1,500 | $10,000 |
| 10,000,000 | $6,900 | $100,000 |

[Document Intelligence pricing](https://azure.microsoft.com/en-us/pricing/details/document-intelligence/) uses pages, not source GB. Read costs $1.50/1,000 for the first million pages and $0.60/1,000 above that; Prebuilt/Layout is $10/1,000 in the selected standard-tier meter. Choose the operation required and do not add a second Read charge when Layout already extracts the text. These are separate first-load or monthly changed-page examples; the corpus byte-size does not establish page count. Other extraction features and models can have different meters.

## Validation and exclusions

Before committing to capacity, index a representative sample with the final schema, dimensions, compression and permission model. Measure disk and resident-vector sizes, recall, tail latency, peak concurrency, simultaneous update throughput and queue lag. Test source deletes, permission revocations, stale events, partial failures, index fan-out and regional failover under the expected load. Use [capacity-planning guidance](https://learn.microsoft.com/en-us/azure/search/search-capacity-planning) and [push-indexing limits and error handling](https://learn.microsoft.com/en-us/azure/search/search-how-to-load-search-index).

Five million requests/month averages about 1.9 requests/second, or 3.8 index calls/second with two-index fan-out. Neither average predicts peak traffic or guarantees performance on a large index. The running standby contains the same modeled Search capacity, but regional infrastructure availability, model quota and the source authorization path must be validated. Recovery objectives remain design targets, not observed service levels.

Excluded: source transactional databases and CDC/export infrastructure, generated-answer models/output tokens, OCR/Layout and semantic ranking unless selected, extra extraction services, application engineering, taxes, support, nonproduction, applicable Entra licenses, negotiated discounts, cross-region failover-write operations, unspecified backup/long-retention storage and capacity beyond the stated assumptions. The security/alerts figures are provisional allowances. Extra private endpoints for optional OCR or source systems also need pricing. The model charges a full duplicate source-content allowance in Blob even when some original business records remain in their database; replace it with actual exported-document volume when known.