Feedback on Google Network Connectivity Center ( VPC Spoke)
Theses last days, I had the opportunity to test the last features on Google Network Connectivity Center with VPC spokes mode. I give you my feedback.
Introduction
What is Network Connectivity Center
Network Connectivity Center limitations
Create your own ncc hub
Review
Introduction
Actually, we have two approaches to interconnect VPCs in GCP. A centralized approach with a shared VPC or a decentralized model with a VPC peering or VPN.
In a large-scale deployment with the constraints of large organizations, the centralized model is limiting due to the complexity of implementation and the limitations of VPC peering to 25 peering per VPC. With a large number of GCP projects, we can imagine the limitations and complexity of implementation.
The decentralized model with the implementation of the shared VPC is limiting with a centralized team that manages the IP addressing plan, firewall filtering rules, and routing rules for an entire organization.
Often, organization wants a more flexible model with a decentralization of network tasks to project teams such as create custom firewall rules. Not possible in shared vpc model.
For this reason, the GCP community was eagerly awaiting the release of a hub service capable of interconnecting many VPCs in a simple way with routing rules or filtrering rules between subnets similar to AWS Transit Gateway.
Whats is Network Connectivity Center?
Network Connectivity Center is GCP service that provides network connectivity among spoke resources: VPC, Cloud VPN or Vlan attachment.
On paper, the service looks great. Let’s take a closer look at the features.
Network Connectivity Center is composed of a central management called hub and spoke resources which are connected to the Hub. Spoke ressources can attached to hub project or a hub from another GCP project. VPC spoke filter can be configured to exclude Ip ranges.
Pay attention to NCC limitations:
1.A hub can only have either VPC spokes or hybrid spokes. You can not connect VPN/ Vlan spokes with VPC spokes. We have to create two hubs if needed,
2.You can not connect to VPC spokes with overlapping issues. You have to exclude ip ranges by filters. No private NAT configuration possible
3.Two hubs can not be connected natively
4.Hub does not provide transitive connectivity,
5.No dynamic or static routing configuration in your hub. You can not configuration custom routes between subnet in your hub and enable segregation between vpc.
Implementation
Create your hub:
Add your VPC Spoke attached to your NCC Hub.
Select your vpc spoke and filter ip ranges if needed
Review:
In this initial version, Network Connectivity Center vpc spoke is limited for hybrid use cases and cannot address complex networking challenges. Some work around with private service connect can deployed to by pass NCC limitations but the gain will be low.
NCC could be a good alternative solution for VPC spokes only configuration with decentralized model. Do not use it for hybrid architecture, wait for the next release.
