In the era of cloud-native architectures, data is rarely confined to a single environment. As organizations scale their Google Cloud footprint, the demand for centralized, high-performance file storage grows. Google Cloud Filestore, a fully managed NFS (Network File System) offering, is the go-to solution for many. However, as infrastructure grows more complex—spanning multiple Virtual Private Clouds (VPCs) for production, staging, and shared services—connecting these isolated islands to a single storage resource becomes a significant architectural hurdle.
This post explores how to leverage the Network Connectivity Center (NCC) to bridge these gaps, specifically focusing on the “Producer VPC spoke” to enable seamless, multi-network access to Filestore.
1. The need: Why centralized storage matters
Modern enterprise environments rarely consist of a single, monolithic network. Most organizations adopt a multi-VPC strategy to enforce security boundaries, manage quotas, or separate environments by lifecycle (e.g., Production vs. Non-Production). Despite this separation, the need for shared data remains constant.
Production and Non-Production Parity
Consider a media processing pipeline. Your Production VPC contains the high-availability engines that render video, while your Non-Production VPC contains the staging environment where developers test new algorithms. Both environments need access to the same multi-terabyte library of raw assets stored on a Filestore instance. Duplicating this data is not only non-cost-efficient but introduces data consistency nightmares.
Active Directory and NFSv4 Authentication
The complexity increases when security requirements mandate identity-based access. For Filestore instances using NFSv4.1, integration with an Active Directory (AD) server is often required for Kerberos authentication.
In many architectures, the AD domain controllers reside in a “Shared Services” or “Identity” VPC. If your Filestore instance is deployed in a “Data” VPC, the storage must be able to reach the AD server to authenticate users. Without a transitive networking solution, the Filestore service—which lives in a Google-managed producer network—remains isolated from the identity services it needs to function.
2. The hurdle: The VPC transitivity challenge
To understand why this is difficult, we must look at how Google Cloud handles network interconnections. Traditionally, Filestore is deployed using Private Services Access (PSA). This creates a VPC Network Peering connection between your VPC (the consumer) and a Google-owned VPC (the producer) where the Filestore hardware actually resides.
While VPC Network Peering is efficient and low-latency, it has a fundamental constraint: Peering is not transitive.
If VPC-A is peered with VPC-B, and VPC-B is peered with VPC-C, VPC-A cannot communicate with VPC-C. In the context of Filestore:
-
Your Production VPC is peered with the Filestore Producer VPC.
-
Your Non-Production VPC might be peered with the Production VPC (or connected via VPN).
-
Result: The Non-Production VPC cannot “see” the Filestore instance because the route to the Filestore producer network cannot jump across the second peering hop.
Historically, architects bypassed this using complex workarounds:
-
Proxy VMs: Deploying a fleet of VMs to act as NAT gateways or NFS proxies. This adds latency, cost, and a significant management burden.
-
Cloud VPN Tunnels: Creating redundant VPN loops between VPCs to exchange routes, which limits throughput.
Neither of these solutions is “cloud-native” or scalable for high-performance file workloads. This is where the Network Connectivity Center changes the game.
3. The solution: Configuring NCC with Producer VPC Spokes
Google Cloud Network Connectivity Center (NCC) provides a hub-and-spoke model for network management. While originally designed to connect on-premises sites via VPN and Interconnect, NCC now supports VPC-to-VPC connectivity and, crucially, Producer VPC spokes.
By making the Filestore producer network a member of the NCC Hub, its routes can be propagated across the hub to every other connected VPC spoke, effectively bypassing the transitivity limits of standard peering.
The example used for this post is having the below solution:
- One Filestore instance in the production project.
- One GCE VM in the production project.
- One GCE VM in the non-production project.
- The goal is to create a NCC architecture to allow the GCE VM in the non-production project mounting the Filestore instance attached to the production project.
Step-by-step configuration
Step 1: Create the NCC Hub
The Hub is the central administrative resource. It acts as the “glue” that links your various networks.
-
In the Google Cloud Console, navigate to Network Connectivity Center.
-
Create a new Hub. This Hub will serve as the central router for your cross-VPC traffic.
Step 2: Attach the VPC Spokes
Next, you need to bring your standard networks into the fold.
-
Create a Spoke for your Production VPC.
-
Create a Spoke for your Non-Production VPC.
-
During this process, NCC will ask you to select the VPC network. Once attached, these VPCs can now share routes through the Hub (provided you enable the “Export” and “Import” of routes).
Step 3: The “magic” link - The Producer VPC Spoke
This is the critical step for Filestore access. You must connect the Google-managed network where Filestore lives to your Hub.
-
When creating a new spoke, choose the type Producer VPC.
-
Select your Production VPC as the “Consumer VPC.”
-
Specify the Service Networking connection (servicenetworking-googleapis-com).
-
This action tells Google Cloud to take the routes associated with the Filestore peering in your Production VPC and advertise them to the entire NCC Hub.
Step 4: Routing and firewall rules
Once the spokes are active:
-
Route propagation: The Hub will see the Filestore IP range coming from the Producer Spoke. It will then push this route into the Non-Production VPC.
-
Firewalling: You must ensure that the Non-Production VPC has egress firewall rules allowing traffic to the Filestore IP range on standard NFS ports.
After the spokes are active, the GCE VM running in the non-production project can mount successfully the Filestore instance attached to the production project.
root@dev:/# mount -t nfs 10.98.96.2:/instance /mnt/filestore/
root@dev:/# df -h | grep filestore
10.98.96.2:/instance 1.0T 0 1.0T 0% /mnt/filestore
4. Summary and key takeaways
By implementing Network Connectivity Center with Producer VPC spokes, you transform Filestore from a siloed resource into a global asset. This architecture provides a robust, high-performance path for multi-VPC storage access without the overhead of manual proxy management.
Key takeaways:
-
Overcoming transitivity: NCC is the definitive answer to the “no-transitivity” rule of VPC peering, allowing Filestore to be reached from networks multiple hops away.
-
Security & identity: This solution is essential for NFSv4.1 deployments that require a central Active Directory for authentication, as it allows the Filestore instance to communicate with AD servers in different VPCs.
-
Operational efficiency: You no longer need to manage proxy VMs or complex VPN configurations. NCC handles route advertisements dynamically.
-
Performance: Traffic stays on Google’s private backbone, ensuring the high throughput and low latency that Filestore is known for.
Centralizing your storage with NCC doesn’t just save money on data duplication; it simplifies your entire cloud architecture, allowing your teams to focus on building applications rather than managing complex network tunnels. Whether you are synchronizing production data to a test environment or securing files with enterprise-grade identity, NCC and Filestore are a powerful combination for the modern enterprise.