A star topology, also called hub-and-spoke, uses one central VPC network as the hub that connects to multiple spoke VPC networks or on-premises networks. The Network Connectivity Center (NCC) hub acts as the central connection point, allowing spokes to communicate without needing direct links between each other. This design lets organizations consolidate external connectivity through a single point, avoiding the need for separate connections for each VPC. The hub can also host shared services like firewalls or authentication systems that all spokes use. You choose this topology when you want to reduce the complexity and cost of managing many point-to-point connections, though it creates a single point of failure at the hub.
A mesh topology provides direct, any-to-any connectivity between all VPC networks. In a full mesh, every VPC connects directly to every other VPC using VPC Network Peering, which offers low latency because traffic flows directly between workloads without passing through a central hub. However, a full mesh becomes expensive and complex as the number of VPCs grows, since each new VPC requires connections to all existing ones. A partial mesh reduces this burden by connecting only selected VPCs directly. You select a mesh topology when high performance and direct communication between specific workloads are your primary requirements and you can manage the administrative overhead.
Network Connectivity Center is Google's service for implementing hub-and-spoke topologies. A hub administrator creates the hub and grants spoke proposal access, then spoke administrators attach their VPC networks as VPC spokes or connect on-premises networks as hybrid spokes using Cloud Interconnect or VPN. The hub's dynamic routing automatically exchanges routes between all attached spokes. For the hub to advertise VPC subnet routes to hybrid spokes, administrators must configure the hybrid spoke to include all IPv4 ranges or configure custom address ranges on the connected Cloud Routers. This service scales well because adding new spokes does not require changes to existing spoke configurations.
When traffic inspection is required, network virtual appliances (NVAs) such as next-generation firewalls sit in the hub VPC to inspect all traffic flowing between spokes, on-premises networks, and the internet. Spoke VPCs connect to the hub using VPC Network Peering, and traffic between spokes routes through the appliances via an internal passthrough Network Load Balancer that serves as the next hop. This design is mandatory when Layer 7 inspection between workloads is required or when corporate security policy demands a specific appliance vendor for all traffic. Traffic from one spoke cannot reach another spoke directly; all inter-spoke communication passes through the appliances for inspection.
The hub-and-spoke topology without appliances uses a hub VPC to provide shared connectivity to on-premises networks while giving teams autonomy over their own firewall and routing rules in spoke VPCs. Spoke networks connect to the hub using VPC Network Peering, and because peering is non-transitive, spokes cannot communicate with each other directly unless you configure direct peering between them. This design works when workloads do not need to communicate using internal IP addresses but must share on-premises connectivity. This architecture has limits because VPC Network Peering has a maximum number of connections from a single VPC, and scaling beyond those limits requires using Cloud VPN instead.
A VPC spoke connects a VPC network to a Network Connectivity Center hub, exporting the VPC's subnet routes to the hub and importing routes from other spokes. You can configure VPC spokes to export only IPv4 ranges, only IPv6 ranges, or both, and you can filter which subnet ranges are advertised using include or exclude filters. A hybrid spoke represents connectivity resources such as Cloud Interconnect VLAN attachments, HA VPN tunnels, or Router appliance VMs that connect the hub to external networks including on-premises data centers. When you create a VPC spoke, all local subnet routes are exported to the hub by default unless you use the exclude-export-ranges flag to filter specific ranges.
When implementing hub-and-spoke, you choose between VPC Network Peering, Cloud VPN, and Cloud Interconnect based on your requirements. VPC Network Peering adds minimum complexity and works well for connecting hub and spoke VPCs, but it is non-transitive and limited by quota constraints on the number of peering connections from a single VPC. Cloud VPN lets you exceed peering limits and provides transitivity between spokes when using custom advertised routes, but each tunnel has a bandwidth limit of 250,000 packets per second and adds cost. Cloud Interconnect provides the highest bandwidth and lowest latency for hybrid connectivity, with Dedicated Interconnect supporting up to 200 Gbps per attachment.
Transitive routing lets traffic pass through an intermediary network to reach a destination. Network Connectivity Center provides centralized connectivity management by connecting VPC networks and hybrid networks as spokes to a central hub. When dynamic routing is set to regional, routes learned from hybrid spokes are programmed only into the same region as each hybrid spoke. When dynamic routing is set to global, dynamic routes from hybrid spokes are programmed across all regions within the attached VPC spokes. The hub route table automatically updates when subnet lifecycle activities occur, such as adding or deleting subnets, or when spokes are added or removed.
Route propagation across Network Connectivity Center spokes uses automated route tables and specific advertisement configurations. The hub maintains a read-only hub route table containing all dynamic routes learned from on-premises systems and subnet routes from attached spokes. To advertise VPC subnet routes to on-premises networks, administrators configure the includeImportRanges field set to ALL_IPV4_RANGES on the hybrid spoke resource. For overlapping subnets across VPC spokes, Private NAT resolves communication issues by translating traffic to a dedicated subnet that does not conflict with existing subnets attached to the hub.
High Availability VPN (HA VPN) gateways connect multiple VPC networks through a central hub using transit routing. A 99.99% availability SLA requires both HA VPN gateways to reside in the same Google Cloud region with two tunnels configured across matching gateway interfaces. Deploying HA VPN gateways in different regions reduces the availability SLA to 99.9%. Organizations can achieve high availability across multi-region resources by keeping both HA VPN gateways in the same region while routing to remote subnets. Administrators use active-active routing for maximum throughput or active-passive configuration with base priority adjustments on Cloud Router to maintain deterministic failover capacity.
Network policies and firewalls enforce security across multi-VPC and hybrid paths at multiple layers. When traffic crosses trust boundaries, a multi-NIC virtual appliance can bridge an untrusted transit VPC to internal trusted VPCs for stateful Layer 7 packet inspection. Within Google Cloud, security policies are evaluated hierarchically: first hierarchical firewall policies at the organization or folder level, then VPC firewall rules at the network level, and finally Kubernetes network policies at the namespace and Pod layer for Layer 4 filtering inside clusters. VPC Service Controls establish security perimeters around Google-managed resources to block data exfiltration attempts across external boundaries.
Connectivity Tests in Network Intelligence Center validate reachability across interconnected VPCs and Network Connectivity Center hubs using configuration analysis and active data plane probing. The configuration analysis simulates a packet trace through sequential checkpoints to determine whether the path reaches a final state of deliver or is dropped. The trace verifies source VM egress IP assignment, evaluates hierarchical firewall policies followed by local VPC egress firewall rules, matches destination routes according to VPC routing order, and evaluates destination ingress policies. When analyzing connectivity across a Network Connectivity Center hub or peered networks in different projects, Connectivity Tests displays intermediate hops such as Cloud VPN tunnels and load balancer forwarding rules, identifying whether failures are caused by missing dynamic routes or specific hierarchical firewall policies.
Hub-and-spoke uses a central hub that all spokes connect to, simplifying management and reducing costs as you add more VPCs, but it can create bottlenecks and increases latency for traffic between spokes. Mesh topologies provide direct any-to-any connectivity with lower latency but become complex and expensive to scale as more VPCs are added.
Use Private NAT when you have overlapping subnet ranges across different VPC spokes that need to communicate through the hub. The Private NAT gateway translates traffic to IP addresses in a dedicated subnet that does not conflict with any existing subnets attached to the hub, allowing communication between spokes that would otherwise have IP address conflicts.
Choose VPC Network Peering when you need simple connectivity between hub and spoke VPCs within Google Cloud and you are within the peering quota limits. Choose Cloud VPN when you need to exceed peering limits, require transitivity between spokes without direct peering, or need to connect to on-premises networks through the hub.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts