Azure AI Search Service
Does ZopNight manage Azure AI Search Service?
Azure AI Search bills per search unit (replicas multiplied by partitions) continuously at the service tier, whether 0 queries or millions arrive. ZopNight discovers each service with SKU, replica, and partition detail, expands its data plane into indexes, indexers, skillsets, and data sources, and reads 60 days of query metrics.
Rules that fire on Azure AI Search Service
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Azure AI Search provides full-text and vector search for applications and RAG pipelines, billed per search unit (replicas x partitions) continuously. Services scaled up for an experiment and never scaled back are a growing AI-era cost pattern.
Search units: replicas times partitions, around the clock
The unit of billing is the search unit, and a service consumes replicas multiplied by partitions of them at its tier’s hourly rate. Scale from one replica to three for a load test and the service bills three times as much until someone scales it back. There is no pause, no serverless mode, and query volume has no effect on the meter. Vector workloads push this further: embeddings inflate index storage, storage pressure drives partition counts up, and every added partition multiplies against the replica count.
Full-service discovery down to the data plane
Discovered via Azure Resource Graph with SKU, replica, and partition detail. The interesting objects, though, are not ARM resources at all: indexes, indexers, skillsets, and data sources live in the service’s data plane and never appear in Resource Graph. ZopNight’s search enricher (running with the Search Service Contributor role) fetches the service’s primary admin key, because query keys cannot list definitions, and enumerates each collection, including index aliases, into child rows. Azure Monitor metrics over a 60-day lookback show query volume, Cost Management billing attributes spend, and rightsizing surfaces in review.
The experiment that never scaled back
The signature waste on this type is capacity ratcheting: replicas added for a launch or a load test that stay forever, and partitions grown for an ingest spike that never recur. Second is the RAG prototype pattern: a Standard-tier service created for a demo, holding one small index, billing its full tier month after month. Third is environment mismatch, where dev and staging run the same tier as production because the service was cloned rather than sized.
Service tiers in the Azure portal
Azure portal → AI Search lists every service with its tier; a service’s Scale blade shows current replica and partition counts, the two numbers whose product is the bill.