Skip to main content
idle · gcp

Vector Search index endpoints holding replicas at zero queries

resource types
1
rule IDs covered
1
severity
medium

What does ZopNight detect here?

Deployed Vector Search indexes keep replica nodes billing per node-hour whether queries arrive or not. ZopNight anchors on the continuous request-utilization CPU gauge staying under 1% and vetoes on any real query traffic. The query counter itself emits no datapoints while idle, so requiring it would blind the rule.

Signal and threshold

How ZopNight evaluates Vector Search index endpoints holding replicas at zero queries.
Field Value
Rule IDsRC-1217
Categoryidle
Severitymedium
Metricnone — pure configuration read
Sourcevertex_idle.go

Replicas bill while deployed

Deploying a Vector Search index to an IndexEndpoint allocates replica nodes that bill per node-hour continuously. Retrieval-augmented prototypes are the classic source, built in a sprint and left serving an application that was retired. The charge belongs to the deployment, not the queries, so a zero-query endpoint costs the same as a busy one.

The idle-blind counter problem

VertexIndexEndpointQueryCount is a delta counter: Cloud Monitoring writes datapoints for it only when queries actually happen. An idle endpoint therefore has no query series at all, and a rule that required the counter to be present-and-zero could never fire; that defect existed here once and is why the current design anchors elsewhere. The anchor is VertexIndexEndpointCPU, the request-utilization gauge that is continuously present for any deployed endpoint: the rule fires when its average and peak both stay under 1%. A query series that does exist and carries traffic vetoes the recommendation outright.

Undeploy is the lever

There is no pause for a deployed index. Recovering the node-hours means undeploying the index from the endpoint, which keeps the built index intact and redeployable; delete the IndexEndpoint as well once nothing will be redeployed. Rebuilding later costs per-GiB build fees, so undeploy-and-keep is usually the right first step.

See which indexes are deployed

Terminal window
gcloud ai index-endpoints describe INDEX_ENDPOINT_ID --region us-central1 \
--format="table(deployedIndexes.id,deployedIndexes.createTime)"

Metric reads behind this rule use monitoring.timeSeries.list from roles/monitoring.viewer.

Cost attribution and abstains

Vertex serving carries no rack rate in the calculated cost path (ZopNight declines to invent a per-replica rate), so the rule fires only where GCP billing export ties real spend to the endpoint’s UID, and the recoverable figure is that attributed cost in full. Silence is guaranteed when the CPU gauge is absent, when utilization reaches 1% on average or peak, when a present query series shows any traffic, or when no positive cost is known.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·