Legacy Vertex AI featurestores whose online serving nodes sat near 0% CPU for 30 days

Online serving nodes run whether or not anyone reads features

A legacy featurestore serves low-latency reads from provisioned online serving nodes. Google’s featurestore management guide says these nodes “are always running even when they aren’t serving data” and that you are charged for each node hour. A store created for an experiment and then forgotten keeps its fixed node count, and the bill, indefinitely.

The product itself is on its way out. The Feature Store (Legacy) overview states it is deprecated: from May 17, 2026 only critical patches ship, and on February 17, 2027 the service is sunset and its APIs stop working. An idle legacy store is a cleanup candidate twice over.

Checking node counts and traffic yourself

There is no gcloud command group for legacy featurestores, so list them through the REST API. Each entry shows onlineServingConfig, with either a fixedNodeCount or a scaling range:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://us-central1-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/us-central1/featurestores"

Then open Metrics Explorer and chart aiplatform.googleapis.com/featurestore/cpu_load and featurestore/online_serving/request_count for the store over the past month.

What proves a featurestore is idle

ZopNight anchors the decision on the CPU load gauge, which Cloud Monitoring reports even when nothing is being read. The store must have that series, and its CPU load must stay under 1% on average and at peak over whatever metric history ZopNight holds, up to 42 days. There is no minimum history, so a store with only a few days of data can be flagged; the finding’s evidence shows the last 7 days.

The request counter works the other way. Serving count is a delta metric, and a delta metric writes no points while there is no traffic, so a missing request series is consistent with an idle store rather than a reason to hold back. A request series that exists and shows real reads is a veto: a store answering a trickle of queries on fixed nodes can sit below 1% CPU and still be in use, which makes it a sizing question, not a deletion.

When a quiet store is still left alone

No CPU load series means no finding, because silence from the gauge says nothing about use. Any genuine request traffic in the window also stops the rule. Finally, ZopNight will not guess the node-hour cost: when it has no priced figure for the store, it raises nothing rather than reporting a zero or an estimate.

The node-hours behind the saving

saving = billed monthly cost ZopNight holds for the featurestore (never estimated)
cost after fix = 0

The figure comes from billing data attributed to the store. When no such figure exists, the rule stays silent rather than inventing a node-hour rate.

Turning off online serving or deleting the store

1. Confirm no application calls ReadFeatureValues or StreamingReadFeatureValues on the store.
2. Export any feature data you need; Google warns that setting the node count to 0 deletes the whole online store, including its data, and a later scale-up does not bring it back.
3. To keep offline use, remove any scaling settings and PATCH online_serving_config.fixed_node_count to 0.
4. To remove it entirely, send a DELETE to the featurestore URL with ?force=true; the console cannot delete featurestores.
5. For new work, use Feature Store (V2), whose idle online stores are covered by GCP Vertex AI Feature Online Store Idle.