Filestore Study Notes
Filestore is Google Cloud's managed file storage service that provides fully managed NFS file shares for Compute Engine and Google Kubernetes Engine workloads. It delivers a traditional directory hierarchy, file locking, and POSIX-like semantics that legacy applications expect. Filestore is the answer when an application cannot be rewritten for object storage or block devices alone.
Key facts
- Filestore instances expose an NFSv3 or NFSv4.1 file share that multiple clients can mount simultaneously, enabling shared read and write access across many VMs or containers.
- Service tiers range from Basic HDD and Basic SSD to higher performance zonal, regional, and enterprise options, differing in capacity scaling, throughput, IOPS, and availability guarantees.
- Filestore shares are created inside a VPC network and are accessed using private IP addresses, so client VMs must be in the same VPC or a peered network with correct firewall rules.
- Capacity and performance are linked in several tiers, meaning provisioning a larger share can increase maximum throughput and IOPS even before you fill the additional space.
- Backups can be scheduled or taken on demand and stored separately from the instance, allowing restoration to a new Filestore instance for recovery or cloning purposes.
- Snapshots, on tiers that support them, provide point-in-time copies within the instance for quick rollback, which is distinct from backups intended for disaster recovery.
- Filestore supports IAM for administrative control and uses NFS export options and IP-based access controls to restrict which clients can mount a share and with what permissions.
- Integration with GKE is through the Filestore CSI driver, which dynamically provisions persistent volumes backed by Filestore shares for stateful workloads needing ReadWriteMany access.
- Unlike Cloud Storage, Filestore is regional or zonal in scope and is designed for low-latency file operations inside a VPC rather than global HTTP object delivery.
What the exam expects you to know
- Choose Filestore for lift-and-shift applications that require a shared file system, NFS mounts, file locking, or a hierarchical directory structure without code changes.
- Recognize ReadWriteMany as the GKE access mode that Filestore provides, in contrast to Persistent Disk which is primarily ReadWriteOnce for a single pod.
- Know that Filestore connectivity is private and VPC-based, so scenarios mentioning authorized networks, peering, or firewall rules for NFS traffic point to this service.
- Understand the difference between backups for recovery to a new instance and snapshots for quick in-place rollback, and when the exam expects each mechanism.
- Select a tier based on availability and performance needs, for example enterprise or regional tiers for high availability rather than basic zonal tiers.
- Eliminate Cloud Storage when the scenario explicitly requires mounting a file system, POSIX permissions, or concurrent writes from many compute clients.
Filestore vs Cloud Storage: when to use which
Use Filestore when applications need to mount a shared file system over NFS, preserve directory hierarchies, and perform standard file operations without refactoring, such as content management systems or legacy enterprise apps. Use Cloud Storage when you store unstructured objects accessed via API or HTTP, need global scale, lifecycle tiering, or serve media and backups cheaply. The exam signal is interface: mount, NFS, and shared POSIX access mean Filestore, while buckets, objects, and signed URLs mean Cloud Storage. Filestore costs more per gigabyte but saves the engineering cost of rewriting file-based applications. See also the Cloud Storage notes.
Useful gcloud commands
gcloud filestore instances create my-instance --zone=us-central1-a --tier=BASIC_SSD --file-share=name=share1,capacity=1TB --network=name=default
gcloud filestore instances list --zone=us-central1-a
gcloud filestore backups create my-backup --instance=my-instance --zone=us-central1-a --file-share=share1Common exam traps
- Filestore is not object storage and does not use buckets or signed URLs; applying Cloud Storage concepts to Filestore questions leads to incorrect answers.
- A Filestore share cannot be accessed publicly over the internet like a bucket; clients need VPC connectivity and the correct private network path.
- Persistent Disk cannot natively provide ReadWriteMany shared access for many pods or VMs, which is precisely the gap Filestore fills in GKE scenarios.
- Basic tiers are zonal and do not provide the same high availability as regional or enterprise tiers, so assuming every Filestore instance is highly available is a trap.
Frequently asked questions
Why use Filestore instead of a self-managed NFS server?
Filestore removes the operational burden of building, patching, scaling, and protecting your own NFS server on a VM. Google manages availability, backups integration, and performance tiers while you simply create a share and mount it from clients. For the exam, managed Filestore is preferred over a do-it-yourself NFS VM unless a scenario requires custom control.
How do GKE workloads use Filestore?
GKE uses the Filestore CSI driver to provision persistent volumes backed by Filestore shares, allowing multiple pods to read and write the same files concurrently. This supports the ReadWriteMany access mode that standard persistent disks cannot provide for a single volume. It suits shared content, uploads, and legacy stateful applications running in Kubernetes.
Are Filestore backups and snapshots the same?
No, backups are independent copies stored for recovery and can be restored to a new Filestore instance in another location. Snapshots are point-in-time copies kept with the instance for fast rollback of recent changes. The exam expects backups for disaster recovery scenarios and snapshots for quick operational recovery from accidental file changes.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.