# Filestore Instance

> Filestore bills for the full provisioned NFS share capacity every month whether the share holds 10 files or millions. Consumed bytes never enter the meter. ZopNight discovers each instance via Cloud Asset Inventory, compares provisioned against used capacity, and surfaces downsizing opportunities where tiers or sizes outrun actual need.

Source: https://zop.dev/integrations/gcp/filestore
Updated: 2026-08-19

---

Filestore provides managed NFS file shares billed for the full provisioned capacity per month, regardless of how much data is stored. High-tier instances start at large minimum capacities, so tier and size choices dominate cost.

## Provisioned capacity is the entire Filestore meter

A Filestore share bills per GB of provisioned capacity, per month, at a rate set by its service tier. Only provisioned capacity counts. Stored bytes, throughput actually used, client count: none of it appears on the bill. The tier decision carries hidden weight because higher-performance tiers impose large minimum capacities; choosing a premium tier for a modest dataset can force provisioning many times the storage the workload will ever write, and that floor bills in full from day one.

## Measuring the gap between provisioned and stored

ZopDev discovers Filestore instances via Cloud Asset Inventory, compares provisioned versus used capacity, and surfaces downsizing opportunities in recommendations. That provisioned-to-used ratio is the single most useful number for this type: an 80 percent-empty share is not a performance buffer, it is a standing charge for absent data.

## NFS shares that outgrew their purpose

Filestore waste has a distinctive shape. Shares provisioned at a performance tier's minimum for workloads that needed only basic throughput. Shared home directories or CI caches whose contents were migrated to GCS, leaving the mount serving nothing while its capacity bills on. And capacity increased during a crunch (provisioned size can grow) with no follow-up, because shrinking requires creating a smaller instance and copying data across, which nobody schedules voluntarily.

## The asymmetry between growing and shrinking

Growth is a live operation; reduction is a migration. That one-way ratchet means every temporary capacity bump becomes permanent by default, and it is why catching oversized tiers at creation time is worth more here than on resizable resource types. For an existing oversized share, the honest options are a copy-down migration or accepting the charge knowingly.

## Filestore's place in the console

Google Cloud console → Filestore → Instances lists each share with its tier, provisioned capacity, and location. Set those columns beside measured usage and the downsizing candidates identify themselves.