Use this topic to learn about Cloud Filestore architectural choices that affect your Cloud Filestore instances.
A Cloud Filestore instance consists of a single NFS fileshare with fixed export settings and default Unix permissions. For more information about these settings and how they affect access, see Access Control.
Cloud 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. 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.
You must create a Cloud Filestore instance in the same GCP project and VPC network as any clients that connect to it, unless you're using shared VPC. All internal IP addresses in the selected VPC network can connect to the Cloud Filestore instance.
In shared VPC, the Network Admin of the host project can create Cloud 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 Cloud Filestore instances on the shared VPC network. For details, see Known issues.
If you are using a VPC network other than the default network, you might need to create firewall rules to enable communication with Cloud Filestore instances. For more information, see Configuring Firewall Rules.
IP address range
Each Cloud Filestore instance must have an IP address range associated
with it. The IP address range must be from within the internal IP address ranges
192.168.0.0/16) and have a block size of 29.
Examples of valid Cloud Filestore instance IP address ranges are
You can assign the IP address range if there's a specific one you want to use, otherwise Cloud Filestore picks a random 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 Cloud Filestore instance uses, or with the IP address ranges assigned to any other existing Cloud Filestore instances in that network.
Cloud Filestore network peering
The first time you create a Cloud Filestore instance,
Cloud Filestore also creates a peered network
to enable network connectivity between clients in your project and the
Cloud Filestore instance. The peered network has a machine-generated name
filestore-peer-123456789012 and appears in the VPC Network Peering page.
Note that if you created a Cloud Filestore instance either during the Alpha
period or early in the Beta period, the peered network name has a different
format, similar to
Don't delete the peered network, because this will cause you to lose connectivity with your Cloud Filestore instances. If you accidentally delete the peered network, the easiest thing to do to re-create it is to create another Cloud Filestore instance. Cloud Filestore will recognize that there is no connectivity between your project and the new instance, and will re-create the peered network. You can delete the new Cloud Filestore instance after that if you don't need it for anything else.
Cloud Filestore has built-in zonal storage redundancy to protect your data against equipment failure and to ensure data availability during data center maintenance.
Storage size units
Cloud Filestore defines 1 gigabyte (
GB) as 10243 bytes, a
unit also known as a gibibyte (
Cloud Filestore defines 1 terabyte (
TB) as 10244 bytes, a
unit also known as a tebibyte (