Foundry IQ / AI Search

Naming note: Azure AI Search has been rebranded as Foundry IQ on the Azure pricing page as of mid-2026. The underlying resource type (Microsoft.Search/searchServices) and billing service family (Search) remain unchanged. Both names refer to the same service.

Azure AI Search / Foundry IQ is significant enough to warrant its own top-level resource in Azure, but it is closely integrated with the Azure AI Services family through AI enrichment pipelines.

What it does (in the AI Services context)

When combined with Azure AI Services, Azure AI Search / Foundry IQ gains AI enrichment — a pipeline that runs Cognitive Skills (Vision, Language, Document Intelligence) over raw content during indexing to extract and store enriched metadata alongside the original content.

When you'd use it

• You have a corpus of unstructured documents (PDFs, images, emails) and want to make their content searchable, not just their filenames.

• You are building a RAG (Retrieval-Augmented Generation) solution where a chatbot needs to retrieve relevant chunks of private documents before passing them to an LLM.

Sample use case

A law firm has 10 years of case files in SharePoint — PDFs, scanned documents, and emails. Azure AI Search with AI enrichment indexes the entire corpus: OCR extracts text from scans, NER tags legal entities (parties, courts, dates), and embeddings from Azure OpenAI enable semantic search. Lawyers search in natural language and retrieve the most relevant precedents in seconds.

Example reference architecture

Pricing & How Costs Work

Foundry IQ (Azure AI Search) offers two billing models: Dedicated (traditional always-on, tier-based) and Serverless (preview, scale-to-zero). Costs also come from separately billed add-on features.

1. Dedicated tiers — Search Units (SUs)

A Search Unit (SU) is the fundamental billing unit for dedicated tiers:

Azure AI Search uses a tier-based, always-on pricing model. Unlike consumption-based services, you pay for provisioned capacity per hour regardless of query traffic. Costs come from three independent sources:

Search Units (SU) = Replicas * Partitions

You pay a fixed monthly rate per SU, with the rate determined by the tier:

• Replicas add query throughput and availability.

• Partitions add storage capacity and indexing throughput.

• The service runs 24×7 on dedicated tiers; there is no pause or stop capability — the service bills continuously once provisioned.

• Prices above are per SU per month (billed hourly). A Basic service with 1 replica and 1 partition = 1 SU = ~$73.73/month.

2. Serverless tier (preview)

A new billing model that scales to zero when idle — no always-on compute cost:

Note: Billing for Serverless is expected to begin in late 2026. Customers using Serverless are not charged before billing is enabled.

Serverless is suited to infrequent or variable traffic workloads where dedicated always-on capacity would be significantly underutilised.

3. Add-on features — billed per use

These are charged on top of the base tier cost:

4. AI Enrichment — billed via linked AI Services resource

When you attach an Azure AI Services multi-service resource to the search indexer enrichment pipeline, skills (OCR, NER, key phrases, embeddings) are billed through that AI Services resource at the respective service rates. The search service itself does not charge for enrichment calls.

What Drives Costs

Azure Cost Data — Meters & Meter Subcategories

Azure AI Search / Foundry IQ appears under the Search service family (not Cognitive Services) in Cost Management. Resource type: Microsoft.Search/searchServices.

Meter subcategory notes:

• The meter subcategory for Search Units reflects the tier (e.g. Standard S1). If you change tier mid-month, two separate SU meter rows appear in that billing period.

• Quantity for Search Unit meters = cumulative SU-hours. Divide by 720 (hours/month) to get the average SU count provisioned; divide by 24 to get daily SU-hours.

• Agentic Retrieval meters are new with the Foundry IQ positioning. These appear as consumption-based rows and will grow as agentic RAG pipelines scale, independently of the SU tier cost.

• AI enrichment costs (OCR, NER, embeddings run via the skillset) appear under Cognitive Services meters against the linked AI Services resource — not under the Search service family. This split is the most common source of incomplete cost attribution for search-based RAG architectures.

• There is no separate storage meter for dedicated tiers — storage capacity is bundled into the SU price. Only the Serverless tier has an explicit storage meter.

• Semantic ranker overages appear as a distinct row, making it straightforward to isolate that cost in exports.

Common Developer Mistakes That Drive Up Costs

• Choosing too high a tier at the start and never reviewing it. Teams provision Standard S2 ($981/SU/month) or S3 ($1,962/SU/month) "for production readiness" before knowing actual index size or query volume. Because Foundry IQ / Azure AI Search bills per SU-hour continuously, an over-tiered service running for months before a review costs significantly more than a right-sized one.

• Leaving development and staging search services running 24×7. Unlike consumption-based services, a dedicated dev search service on S1 with 2 replicas bills ~$490/month whether it receives a single query or thousands. There is no pause capability on dedicated tiers — deleting and recreating the service is the only way to stop billing.

• Not considering Serverless for dev/test workloads. The new Serverless tier scales to zero when idle, making it significantly cheaper than a dedicated S1 service for development or infrequent-use scenarios. Teams that provision dedicated tiers for dev by default are paying for always-on capacity that is idle most of the time.

• Adding replicas "for availability" without measuring actual query throughput. Each replica at S1 adds $245/month. A dev or internal-facing service receiving tens of queries per day does not need 3 replicas. Replicas improve throughput and SLA, not data durability.

• Enabling semantic ranker on every query. At $1/1,000 requests (after the first 1,000/month free), a service handling 1 million queries/month with semantic ranker enabled on all of them adds $1,000/month in ranker charges on top of the SU cost. Semantic ranker should be scoped to queries where ranking quality materially affects user experience.

• Not accounting for Agentic Retrieval token costs in multi-agent architectures. Agentic retrieval uses a multi-turn self-reflective framework and is billed per million tokens. Medium-complexity retrieval at $0.10/1M tokens in a high-volume agent pipeline adds up quickly — and the first 50M free tokens per month can be exhausted faster than expected at scale.

• Not using AI enrichment selectively. Running every document through a full AI enrichment skill pipeline (OCR, NER, embeddings) regardless of document type inflates the cost of the attached AI Services resource. Documents already in clean text format that don't need OCR or entity extraction still consume AI Services calls if the skill pipeline is applied uniformly.

• Adding too many partitions without checking actual index size. Each partition doubles storage capacity and the SU count. Teams sometimes add a partition when approaching a perceived storage limit rather than profiling actual index size or applying vector quantisation to reduce storage footprint.

What Could Make Your Bill Go Up or Down Next Month

Could go UP:

• A replica is added to improve query throughput for a production workload — at S1 this adds $245/month per replica.

• The document corpus grows significantly, requiring an additional partition to accommodate index storage — doubles the SU count at the current tier.

• Semantic ranker is enabled for all queries rather than selectively, generating $1/1,000 charges on high-volume traffic beyond the 1,000/month free allocation.

• Agentic retrieval is adopted in a new multi-turn agent pipeline and token consumption scales beyond the 50M/month free tier.

• The tier is upgraded from S1 ($245/SU) to S2 ($981/SU) to accommodate a growing vector index — a 4× increase in the per-SU rate.

• A development or staging search service that was supposed to be temporary is left running through an entire sprint or quarter.

• Image extraction is enabled in the indexer for a new document type, adding image extraction charges on top of the base SU cost.

Could go DOWN:

• A development or staging search service is deleted and replaced with a Serverless tier service, eliminating always-on compute cost.

• Replica count is reduced from 3 to 2 (or 2 to 1) after profiling shows actual query throughput requirements are lower than provisioned.

• Semantic ranker is scoped to only user-facing search endpoints, removing it from internal tooling queries.

• Vector index storage is optimised (scalar quantisation, dimension reduction) to defer the need for an additional partition.

• Agentic retrieval complexity tier is reduced (medium → min/low) for query patterns that don't require deep multi-turn reasoning.

• The service tier is re-evaluated and downgraded after a workload is cancelled or moved.

Most Common Optimisation Techniques