This page describes the architectural choices that affect your Filestore instances.


A Filestore instance consists of a single NFS file share with configurable export settings and default Unix permissions. For more information about these settings and how they affect access, see Access Control.


Filestore automatically encrypts your data before it travels outside of the instance to the underlying durable storage layer. The durable storage behind each Filestore instance is encrypted with system-defined keys that users cannot control. Additionally, Google distributes Filestore data across multiple physical disks in a manner that users do not control.

When you delete a Filestore instance, Google discards the cipher keys, rendering the data irretrievable as per the description in Data deletion on Google Cloud Platform. Once the data is deleted, this process is irreversible.

For more information on encryption, see the following white papers:


You must create a Filestore instance in the same Google Cloud project and VPC network as any clients that connect to it, unless you're using shared VPC or have a VPN connection between the client and Filestore instance networks. All internal IP addresses in the selected VPC network can connect to the Filestore instance.

In shared VPC, the Network Admin of the host project can create Filestore instances on the shared VPC network. Once created, these instances can be mounted on service project clients from any attached service projects. However, service projects cannot directly create Filestore instances on the shared VPC network. For details, see Known issues.

In scenarios where service project clients are on a different VPC network than the Filestore instance and VPC network peering is enabled, you can mount the Filestore instance by following the instructions on Mounting file shares on remote clients.

If you are using a VPC network other than the default network, you might need to create firewall rules to enable communication with Filestore instances. For more information, see Configuring Firewall Rules.

You can't use a legacy network with Filestore instances. If necessary, create a new VPC network to use by following the instructions at Creating a new VPC network with custom subnets.

IP address range

Each Filestore instance must have an IP address range associated with it. The IP address range must be from within the internal IP address ranges (,, and and have a block size of 29 for Basic tier instances and a block size of 23 for High Scale tier instances. Examples of valid Filestore instance IP address ranges are and

You can assign the IP address range if there's a specific one you want to use. However, we recommend letting Filestore automatically pick an available range to use from within the internal IP address ranges. If the range is already in use, the service tries again until it finds one that is free. If you assign an IP address range, make sure it doesn't overlap with any existing subnets in the VPC network that the Filestore instance uses, or with the IP address ranges assigned to any other existing Filestore instances in that network.

Filestore network peering

The first time you create a Filestore instance, Filestore also creates an internal network that is peered with the specified VPC network from your Google Cloud project. This network peering enables connectivity between clients in your project and the Filestore instance. The network peering has a machine-generated name similar to filestore-peer-123456789012 and appears in the VPC Network Peering page.

Don't delete or modify the network peering, because this will cause you to lose connectivity with your Filestore instances. If the network peering is accidentally deleted, the easiest way to recreate it is to create another Filestore instance on the same VPC network. Filestore will recognize that there is no connectivity between your project and the new instance, and will re-create the network peering. You can delete the new Filestore instance after that if you don't need it for anything else.


Filestore instances are zonal resources that feature in-zone storage redundancy to protect your data against equipment failure. However, if a zone goes down due to an outage or data center maintenance, the instances that reside in that zone become unavailable for the duration that the zone is down.