Cloud Storage vs Filestore in GCP: Differences, Use Cases, Costs, and When to Use Each

Simple explanation

Cloud Storage is object storage. You interact with it over HTTPS. Your application calls an API to upload a file, download a file, or list files in a bucket. There is no mounted directory, no file locking, and no way to append to or partially overwrite a file. Every write replaces the entire object.

Filestore is a managed NFS (Network File System) server. You create an instance and it appears as a network share. You mount it on a Compute Engine VM or GKE node just like a local disk. Applications use standard filesystem calls (open(), read(), write(), seek(), flock()) without any code changes.

The core difference is the access model. Cloud Storage uses API calls over HTTPS. Filestore uses filesystem operations over NFS. Everything else (cost, scale, performance, GKE behavior) follows from this distinction.

What is the difference between Cloud Storage and Filestore?

Cloud Storage stores objects. Each file is a blob with a key (its path within a bucket). You read and write entire objects over HTTPS. There is no directory tree, no file locking, and no partial writes. This works perfectly for most cloud-native applications: web assets, backups, data pipelines, and ML training data.

Filestore provides a POSIX-compliant filesystem over NFS. Applications see a real directory tree with files and folders. They can open a file, seek to a position, write a few bytes, lock a file, or append to a log. These are all standard operations that local filesystems support. Multiple clients can mount the same share and access the same files simultaneously.

This matters because many existing applications assume a filesystem. A CMS that stores uploads in /var/www/uploads, an HPC job that reads input files from a shared directory, or a legacy app that uses flock() for coordination: none of these can use Cloud Storage without rewriting their I/O layer. Filestore lets them run unmodified.

The trade-off is cost and scale. Cloud Storage charges only for what you store, scales to petabytes, and has no minimum. Filestore charges for provisioned capacity (whether used or not), has minimum size requirements that vary by tier, and tops out at 100 TB per instance.

How Cloud Storage works

Cloud Storage is GCP’s default storage layer for unstructured data. Objects live in buckets. You interact with them using the gcloud CLI, client libraries, or the REST API. Each object has a name (key), metadata, and content. There are no directories. The forward slashes in a key like reports/2026/march.pdf are just part of the name.

Cloud Storage offers four storage classes (Standard, Nearline, Coldline, and Archive) with different cost and retrieval trade-offs. Lifecycle rules can automatically transition objects between classes or delete them after a set period. This is one of the easiest ways to reduce storage costs.

Durability is 99.999999999% (11 nines). Availability depends on the storage class and location type (regional, dual-region, or multi-region). Cloud Storage integrates natively with BigQuery, Dataflow, Cloud Build, Cloud Run, and most other GCP services.

Common use cases

• Application assets: images, videos, documents, PDFs
• Data lake storage for analytics and ML pipelines
• Static website hosting and CDN origin
• Backups, exports, and long-term archival
• CI/CD artifact storage

Limits and trade-offs

• No filesystem semantics: cannot mount, seek, append, or lock
• Writes replace the entire object (no partial updates)
• Higher latency for small random reads compared to local disk or NFS
• Per-operation charges (Class A and Class B operations) can add up with very high request volumes on small objects

# Upload a file to Cloud Storage
gcloud storage cp ./report.pdf gs://my-bucket/reports/2026/report.pdf

# Download a file
gcloud storage cp gs://my-bucket/reports/2026/report.pdf ./report.pdf

# List objects in a bucket
gcloud storage ls gs://my-bucket/reports/

How Filestore works

Filestore is a managed NFS server. You create an instance with a specified capacity and tier, and GCP provisions a file share. You mount it on Compute Engine VMs or GKE nodes using standard NFS mount commands. Once mounted, it behaves like a local directory.

Multiple clients can mount the same Filestore share simultaneously. All clients see the same files, with NFS handling consistency and locking. This makes Filestore the natural choice for shared filesystem workloads: content management systems, shared configuration directories, HPC scratch space, and GKE pods that need ReadWriteMany volumes.

Filestore is regional. The instance and all clients must be in the same VPC and region. You cannot access a Filestore share from another region or over the public internet without additional networking (like VPN or Interconnect).

Common use cases

• Legacy applications that use filesystem I/O and cannot be rewritten
• Multiple VMs or pods sharing a data directory (CMS uploads, web assets, shared configs)
• GKE workloads requiring ReadWriteMany persistent volumes
• HPC and batch processing with shared scratch storage
• Shared home directories across a fleet of VMs

Limits and trade-offs

• Provisioned capacity: you pay for the full size whether you use it or not
• Minimum capacity varies by tier (e.g. 1 TB for Basic HDD, lower minimums available on some tiers for GKE)
• Regional only, with no cross-region access without VPN or Interconnect
• Maximum 100 TB per instance
• No native integration with GCP analytics services (BigQuery, Dataflow, etc.)

# Create a Filestore instance (Basic HDD tier)
gcloud filestore instances create my-nfs \
  --zone us-central1-a \
  --tier BASIC_HDD \
  --file-share name=vol1,capacity=1TB \
  --network name=default

# Mount the share on a Compute Engine VM
sudo mount -t nfs 10.0.0.2:/vol1 /mnt/data

Cloud Storage vs Filestore: side-by-side comparison

When to use Cloud Storage

Cloud Storage is the right default for most storage needs in GCP. Use it when:

• Your application reads and writes whole files. Web apps uploading user images, pipelines exporting CSV reports, services storing PDF invoices. These are all object storage workloads.
• You are building a data lake. BigQuery, Dataflow, Dataproc, and Vertex AI all read natively from Cloud Storage. It is the standard staging layer for analytics in GCP.
• You need long-term archival. Coldline and Archive storage classes cost a fraction of Standard, and lifecycle rules automate the transition. No minimum capacity to provision.
• You serve static content. Cloud Storage can host static websites directly and works as a CDN origin with Cloud CDN.
• You need global access. Cloud Storage buckets are accessible from any region. Filestore is confined to one region and VPC.
• You want to minimise cost. Cloud Storage Standard tier is roughly 10x cheaper per GB than Filestore Basic HDD, with no minimum provisioning.

When to use Filestore

Filestore is the right choice when your workload genuinely requires NFS semantics. Use it when:

• Your application uses filesystem I/O and cannot be modified. Legacy software that reads from directories, writes to log files, or uses file locking will not work with object storage without a rewrite.
• Multiple VMs or pods need shared read-write access. A CMS cluster where all nodes write to the same uploads directory, or an HPC workload with shared scratch storage. These need a shared filesystem, not object storage.
• GKE pods need ReadWriteMany volumes. Persistent Disks in GKE are ReadWriteOnce. If multiple pods need to write to the same volume, Filestore via the Filestore CSI driver is the standard solution.
• You need low-latency random I/O on shared data. Filestore SSD tiers provide low-latency read and write performance for workloads with random access patterns. Cloud Storage and FUSE cannot match this.
• You need file locking for coordination. Applications that use flock() or advisory locks to coordinate between processes need a real filesystem. Cloud Storage does not support locking.

Cloud Storage vs Filestore vs Persistent Disk

These three are often confused because they are all “storage,” but they serve different purposes:

• Persistent Disk is block storage. It attaches to a single VM (or a single pod in GKE). Think of it as a virtual hard drive. It is the best choice for databases, boot disks, and any workload where one compute instance owns the storage. In GKE, Persistent Disk volumes are ReadWriteOnce, so only one pod can mount them at a time.
• Filestore is a shared network filesystem. Multiple VMs or pods mount the same share and read-write simultaneously. Use it when you need shared access across compute instances.
• Cloud Storage is object storage. It is not attached to any compute instance. Applications access it over the network via API. It scales without provisioning, costs the least per GB, and integrates with GCP analytics services. Use it for everything that does not require a mounted filesystem.

The decision usually comes down to two questions. Does more than one client need to write to it? If not, Persistent Disk is simpler and cheaper than Filestore. Does the application need filesystem semantics? If not, Cloud Storage is simpler and cheaper than both. For a broader comparison including databases and other services, see choosing the right GCP storage service.

Cloud Storage vs Filestore in GKE

Storage in GKE is provisioned through persistent volumes. The access mode determines how many pods can use the volume:

• ReadWriteOnce (RWO) means one pod at a time can mount and write. This is what Persistent Disk provides. It works for databases, caches, and any workload where a single pod owns the data.
• ReadWriteMany (RWX) means multiple pods can mount and write simultaneously. This is what Filestore provides via the Filestore CSI driver. Use it for shared config directories, CMS uploads, or any workload where pods need concurrent filesystem access.

When to use the Filestore CSI driver

Use Filestore in GKE when your pods need ReadWriteMany access with real filesystem semantics: shared writes, file locking, or low-latency random I/O. The Filestore CSI driver provisions and manages Filestore instances automatically from your PersistentVolumeClaim. On GKE Autopilot, Filestore Multishares can provision smaller shares (starting at 128 GiB on Enterprise tier), which reduces the minimum cost compared to standalone Filestore instances.

Cloud Storage FUSE is not the same as NFS

The Cloud Storage FUSE CSI driver lets you mount a Cloud Storage bucket as a volume in GKE pods. This is useful for reading large files sequentially, for example loading ML training datasets from a bucket. But FUSE is a translation layer, not a native filesystem:

• Latency for small random reads is significantly higher than Filestore or Persistent Disk
• Write operations replace entire objects, with no partial writes or appends
• File locking is not supported
• Metadata operations (listing directories with many files) can be slow

Cost, performance, and scalability considerations

The cost structures of Cloud Storage and Filestore are fundamentally different. Understanding the patterns matters more than memorising specific prices, which change over time and vary by region and tier.

Cloud Storage cost pattern

• Pay for what you store. No minimum. You are charged per GB stored per month, with rates that decrease as you move from Standard to Nearline to Coldline to Archive.
• Per-operation charges. Every API call (list, get, create) incurs a small charge. High-volume workloads with millions of operations on small objects should factor this in.
• Egress charges. Data leaving a region or leaving GCP is charged per GB. Cross-region access costs more than same-region access.
• No infrastructure to manage. No server running, no capacity to plan.

As a rough reference, Cloud Storage Standard tier is in the range of $0.020 to $0.026 per GB per month depending on region. The key point is that you pay from the first byte with no minimum commitment.

Filestore cost pattern

• Pay for provisioned capacity. You choose a size when you create the instance. You pay for the full provisioned amount whether you use 1% or 100% of it.
• Minimum capacity varies by tier. Basic HDD requires at least 1 TB. Basic SSD requires at least 2.5 TB. Enterprise and Zonal tiers have different minimums. GKE Multishares on Enterprise tier can start at 1 TB with 128 GiB shares.
• Per-GB rate is roughly 10x Cloud Storage Standard. The exact rate varies by tier and region, but as a general pattern Filestore is an order of magnitude more expensive per GB.
• Minimum monthly cost floor. Because of the minimum capacity and higher per-GB rate, even the cheapest Filestore configuration has a meaningful monthly minimum (roughly $150 to $250/month for Basic HDD, depending on region).

For current pricing, check the storage cost optimisation guide and Google’s pricing pages. Pricing changes, and regional differences are significant.

Performance

• Throughput: Cloud Storage delivers high throughput for large sequential reads, well-suited for data pipelines and ML training. Filestore throughput scales with provisioned capacity and tier.
• Latency: Filestore (especially SSD tiers) provides sub-millisecond latency for small I/O operations. Cloud Storage latency is higher per operation due to the HTTPS round-trip.
• IOPS: Filestore SSD tiers support high IOPS for random read/write patterns. Cloud Storage is not designed for high-IOPS random access.

Scalability

• Cloud Storage scales to petabytes with no provisioning. Add objects at any rate. Google manages the infrastructure.
• Filestore scales to 100 TB per instance. Growing beyond that requires additional instances. Resizing an existing instance is possible but requires planning.