In the landscape of enterprise storage, Google Cloud NetApp Volumes (GCNV) stands as a powerhouse, bringing the legendary performance and management capabilities of ONTAP to the cloud. However, as organizations move beyond simple proof-of-concepts into multi-project architectures, they often hit a wall: the “Networking Silo.”
When you have a high-performance Flex storage pool, you don’t want it trapped in a single VPC. You want it accessible from your production environment, your staging projects, and even your on-premises data centers for identity management.
This post breaks down how Network Connectivity Center (NCC) serves as the ultimate bridge for NetApp Volumes Flex, ensuring you get every cent of value out of your storage investment.
1. The multi-project need: Efficiency and identity
Enterprise IT is rarely a “single bucket” operation. To maintain security and budget hygiene, organizations split workloads into separate Google Cloud projects and VPCs. Yet, storage requirements often demand a unified approach for two primary reasons:
Multi-project connectivity
Instead of being restricted to a single network or project, GCNV Flex allows you to connect the same volumes across different environments, such as Production and Development. This architecture provides the flexibility to centralize storage access, ensuring that resources can be shared securely across your entire Google Cloud organization without being isolated by VPC boundaries.
The on-premise identity anchor
Security-conscious organizations don’t usually recreate the wheel in the cloud; they extend their existing Active Directory (AD). For GCNV volumes using SMB or dual-protocol access, the storage must be able to “talk” to AD Domain Controllers.
In a hybrid setup, these AD servers often sit on-premises, connected to Google Cloud via Cloud Interconnect or VPN. If your GCNV instance is tucked away in a peered producer network, it effectively has no “map” to find your on-prem servers.
2. The challenge: The transitivity trap
To deploy GCNV Flex, Google uses Private Services Access (PSA). This sets up a hidden “Producer VPC” managed by Google and peers it to your VPC. While this makes deployment easy, it introduces the VPC Peering Transitivity Limit.
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 NetApp Volumes:
-
Your Production VPC is peered with the NetApp Volumes 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 NetApp Volumes instance because the route to the NetApp Volumes 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 NetApp Volumes 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 GCNV Flex volume 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 NetApp Volumes volume 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.
Step 3: The “magic” link - The Producer VPC Spoke
This is the critical step for NetApp Volumes access. You must connect the Google-managed network where NetApp Volumes 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 (sn-netapp-prod).
-
This action tells Google Cloud to take the routes associated with the NetApp Volumes 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 NetApp Volumes 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 NetApp Volumes IP range on standard SMB & NFS ports.
After the spokes are active, the GCE VM running in the non-production project can successfully mount the NetApp Volumes instance attached to the production project.
root@dev:/# mount -t nfs 10.128.128.6:/share /mnt/netapp/
root@dev:/# df -h | grep netapp
10.128.128.6:/share 1.0T 256K 1.0T 1% /mnt/netapp
4. Summary and key takeaways
Using NCC with GCNV Flex isn’t just about “making things talk”—it’s about architectural maturity and fiscal responsibility. By breaking the transitivity barrier, you unlock a much more flexible cloud data strategy.
Key takeaways:
-
Overcoming Transitivity: NCC is the definitive answer to the “no-transitivity” rule of VPC peering, allowing NetApp Volumes to be reached from networks multiple hops away.
-
Hybrid Identity: Seamlessly connect GCNV volumes to on-premises Active Directory for enterprise-grade authentication without complex proxy servers.
-
Flex is the Key: Remember that this specific “Producer VPC Spoke” architecture is designed for the Flex service level.
-
Simplified Routing: NCC eliminates the need for manual static route management or “Next Hop” VM hacks, providing a native, high-performance path for storage traffic.
By integrating GCNV Flex with Network Connectivity Center, you transform your storage from a project-specific silo into a true enterprise resource, accessible from anywhere your business operates.