Azure AI Search Index
Does ZopNight manage Azure AI Search Index?
Search indexes hold the documents and vector fields inside an Azure AI Search service, and their count and size decide how many billable search units the service needs. ZopNight enumerates every index through the data plane with document counts and storage size, the utilization evidence behind rightsizing a service's tier.
Rules that fire on Azure AI Search Index
No active rule family targets Azure AI Search Index today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery only. |
Search indexes hold the searchable documents and vector fields within an AI Search service. Index count and size determine how many billable search units the service needs.
Indexes drive the unit count without billing directly
An index has no meter of its own; the parent service bills for search units regardless of what its indexes contain. The causal arrow runs the other way: index storage is what forces partition counts up, and partitions multiply against replicas to set the bill. A service’s tier also caps how many indexes it may hold, so index proliferation pushes tier upgrades even when total storage is modest. Vector fields sharpen both effects, since embedding data is large relative to the text it represents.
Document counts as rightsizing evidence
Discovered via the search enricher with document counts and storage size per index. Indexes are data-plane objects, enumerated with the service’s admin key because they are invisible to Resource Graph. This is the utilization evidence behind service rightsizing: a Standard service whose indexes total a few thousand documents is a tier mismatch stated in numbers rather than suspicion. Indexes are discovery-only rows; the levers are deleting dead indexes, trimming unused fields, and letting the service drop to a smaller shape.
Dead indexes and vector bloat
Two patterns account for most index-level waste. Abandoned indexes (the RAG experiment’s document set, the schema-v1 index kept after a v2 migration) hold storage that keeps partition pressure high. And over-vectorized schemas, where every text field got an embedding during prototyping and the index is several times the size the application’s queries actually exercise. Neither shows on the invoice as a line item; both show in the index inventory.
Inspecting indexes on the service blade
Azure portal → AI Search → select the service → Search management → Indexes lists each index with its document count and storage consumed. The same list, with schema detail, is available in the Search explorer, useful when deciding which fields a slimmer index could drop.