Azure AI Search services with extra replicas or partitions serving under 0.1 queries per second

Search units bill whether anyone searches or not

For provisioned tiers, Microsoft’s capacity planning guide says you pay an hourly rate measured in search units regardless of usage, and that the unit count is replicas multiplied by partitions. Two replicas and two partitions is four units, so doubling both more than doubles the bill. Capacity added for a load test or a big reindex is easy to forget once the traffic settles down.

Checking query load against capacity

az search service list --resource-group <rg> \
  --query "[].{name:name, sku:sku.name, replicas:replicaCount, partitions:partitionCount}" -o table

az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Search/searchServices/<service> \
  --metric SearchQueriesPerSecond ThrottledSearchQueriesPercentage \
  --aggregation Average --interval PT1H --offset 30d

The availability floor ZopNight respects

Microsoft’s reliability guidance ties the SLA to replicas: at least two for read-only workloads and at least three for read-write workloads. You can tell ZopNight which one you need with the tag zopnight:search-read-sla on the service:

• read (or true, 1, yes) keeps 2 units.
• read-write keeps 3 units.
• No tag keeps the minimum of 1 replica by 1 partition.

Conditions for a scale-down finding

1. The service has more units than its floor.
2. SearchQueriesPerSecond data exists and its 30-day average is below 0.1.
3. That metric has at least 7 days of real coverage, so a service created last week is not judged.
4. ThrottledSearchQueriesPercentage is absent or averages below 1%. Any real throttling means the capacity is being used.
5. The service has a positive monthly price.

Services that are left as they are

A service already at its floor, including every single-unit service, gets no finding. Without a query metric, or with too little history, nothing is raised. The rule never guesses a saving: if the cost is unknown, there is no finding at all.

Splitting the bill by search unit

Every unit in a service bills at the same rate, so the per-unit cost is the service’s own cost divided by its unit count:

per-unit cost = monthly cost / (replicas x partitions)
saving        = per-unit cost x (current units - floor units), capped at monthly cost

Scaling the service down

1. Review query volume, latency and indexing schedules in the service’s Monitoring blade before changing anything.
2. Reduce replicas, partitions or both: az search service update --resource-group <rg> --name <service> --replica-count <n> --partition-count <n>.
3. Keep at least two replicas for a read SLA and three for a read-write SLA.