Professional Cloud Network Engineer
A Virtual Private Cloud (VPC) network in Google Cloud is a global, isolated software-defined network that spans all regions. You can create a VPC in auto mode, which automatically creates subnets in each region, or in custom mode, which gives you full control over the subnet IP ranges. Auto mode VPCs are convenient for getting started but have a fixed set of subnets, while custom mode VPCs are required for production environments where you need to define your own IP address space. You can also create a VPC network that is shared across multiple projects using Shared VPC, which allows a central host project to share its subnets with service projects.
VPC routing in Google Cloud is handled by the implicit VPC router, which is a fully managed, distributed service that routes traffic between subnets and to the internet. Each VPC network has a set of system-generated routes for its subnets and a default route for internet access, and you can add custom static routes or use dynamic routes learned through Cloud Router. The routing table is evaluated based on the most specific route prefix match, and if multiple routes have the same prefix, the route with the lowest priority value wins. You can also configure custom route advertisements on Cloud Router to advertise specific IP ranges to on-premises networks, and you can use policy-based routing to direct traffic based on source IP, destination IP, and protocol.
Network Connectivity Center (NCC) spokes are attachment resources that connect different network types to an NCC hub, enabling site-to-site connectivity among on-premises and other cloud networks through Google's backbone. Spokes can be created using VPC networks, VPN tunnels, VLAN attachments (for Cloud Interconnect), or third-party router appliance virtual machines. They serve as the fundamental building blocks for hybrid and multi-cloud connectivity patterns.
VPC spokes allow Network Connectivity Center to create either a mesh or star topology among multiple VPC networks, providing full interconnectivity between workloads in different VPC networks. When you attach a VPC network as a spoke, the hub learns the subnet routes from that VPC and can redistribute them to other spokes connected to the same hub, enabling transitive routing between spoke VPC networks. VPC spokes support both static route exchange and dynamic route exchange through Cloud Router, giving administrators flexibility in how routes are propagated across the network architecture.
Hybrid spokes connect on-premises networks or other cloud environments to an NCC hub using Cloud VPN, Cloud Interconnect (Dedicated or Partner), or router appliance solutions. When using hybrid spokes for site-to-site data transfer between non-Google Cloud networks, you must enable the site-to-site data transfer field on the spoke configuration to allow traffic to flow through Google's backbone network. The hybrid spoke type requires that the underlying connectivity resource (such as a VPN tunnel or VLAN attachment) is properly configured with BGP peering through Cloud Router to enable dynamic route exchange.
When data transfer traffic fails to flow between two non-Google Cloud networks connected through NCC, first verify that HA VPN tunnels or VLAN attachments are functional and that routes are properly programmed between the two locations. Confirm that ASN assignments meet the requirements for site-to-site data transfer and that each spoke has the site-to-site data transfer field set to true. If routes are not distributing properly between regions, check that the VPC network's dynamic routing mode is set to global rather than regional, because regional mode limits route propagation to the local region only.
Duplicate route advertisements can occur when some BGP sessions participate in data transfer while others do not, causing traffic to use equal-cost multi-path (ECMP) distribution across all available next hops regardless of their participation in data transfer. When troubleshooting interconnect connections to unsupported locations, you may need to configure external router advertisements to avoid advertising routes from locations that NCC cannot support. Always specify the location parameter when updating spoke configurations, as this is a common source of command syntax errors.
Connectivity Tests in Network Intelligence Center can analyze network configurations by simulating the expected forwarding path of packets through VPC networks, Cloud VPN tunnels, and VLAN attachments. The tool supports testing connectivity from a non-Google Cloud network to a VPC network connected through NCC, as well as testing between VM instances through an NCC hub. However, because Connectivity Tests cannot access on-premises network configurations, they can only verify Google Cloud-side configurations and will consider traffic from on-premises networks to VPC networks as valid without validating on-premises route and firewall rules.
Hybrid and multi-cloud network integration connects Google Cloud VPC networks to on-premises data centers and external cloud providers such as AWS and Azure. Google Cloud delivers this integration through Cloud Interconnect, Cloud VPN, Cloud Router, and Network Connectivity Center (NCC). These services establish private, high-bandwidth data paths and dynamic BGP routing to enable reliable data transfer without traversing the public internet.
Cloud Interconnect extends on-premises local area networks directly to a Google Cloud VPC network through private, enterprise-grade physical links. Organizations select Dedicated Interconnect to connect directly to Google routing equipment in a colocation facility using 10-Gbps or 100-Gbps circuits, scaling up to 8 x 10-Gbps (80 Gbps) or 2 x 100-Gbps (200 Gbps) per connection. When physical colocation is unavailable or lower capacity is required, organizations choose Partner Interconnect to reach Google through a supported service provider, provisioning VLAN attachments ranging from 50 Mbps to 50 Gbps. To achieve a 99.99% availability SLA, architectures deploy four interconnect connections across two distinct metropolitan areas and two edge availability domains per metro, terminating on redundant Cloud Routers configured with global dynamic routing. For scenarios where compliance requires encryption over private circuits, administrators deploy HA VPN over Cloud Interconnect or configure MACsec encryption.
Cross-Cloud Interconnect provisions direct, dedicated physical connectivity between Google Cloud edge facilities and supported cloud providers, including AWS, Azure, Oracle Cloud Infrastructure, and Alibaba Cloud. Google manages the physical interconnect up to the demarcation point of the external provider, eliminating the need for customers to deploy hardware in third-party colocation facilities. To satisfy the 99.99% availability SLA, the architecture requires a primary connection pair and a redundant connection pair configured in separate facilities, while a single pair provides a 99.9% SLA. Bandwidth is delivered over 10-Gbps or 100-Gbps links, with optional MACsec encryption for transport security. If overlapping IP address schemes exist between Google Cloud and external cloud environments, administrators configure Hybrid NAT on the connection to preserve routability.
Cloud Router is a distributed, fully managed control plane service that provides BGP speaker and responder functionality to exchange dynamic routes between Google Cloud VPC networks and external routers. When Cloud Router operates in global dynamic routing mode, it learns dynamic routes from on-premises or multi-cloud peers and programs them across all subnets in the VPC network, regardless of region. Cloud Router advertises local subnet prefixes with a higher priority and remote subnet prefixes with a lower priority based on multi-exit discriminator (MED) metrics; administrators can override these defaults using custom route advertisements. When connecting redundant links across locations, external routers advertise local subnets with a base MED (such as 100) and remote subnets with a higher MED (such as 200), enabling equal-cost multi-path (ECMP) routing across identical metrics while ensuring deterministic failover. Cloud Router also advertises specific non-subnet ranges to external networks, including the DNS egress proxy range (35.199.192.0/19) and Google health-checking ranges (35.191.0.0/16 and 130.211.0.0/22).
Network Connectivity Center (NCC) provides a centralized management model that uses Google's global backbone network as a WAN to interconnect external sites and VPC networks. A central NCC hub resource manages connectivity across multiple spoke attachments, allowing branch offices, data centers, and other clouds to exchange traffic directly through Google infrastructure. Supported spoke resources include Cloud Interconnect VLAN attachments, HA VPN tunnels, VPC networks, and Router appliance VM instances. Router appliance instances run third-party SD-WAN or next-generation firewall software in a transit VPC, establishing BGP peering sessions with Cloud Router over internal IP interfaces to exchange routes across distributed branches. Traffic entering an NCC spoke routes through Google's private network close to the source site and exits near the destination site, isolating inter-site data transfer from the public internet.
Google Cloud load balancers distribute ingress traffic to on-premises and multi-cloud workloads by using hybrid connectivity Network Endpoint Groups (hybrid NEGs). A hybrid NEG defines external backends using IP:port combinations (NON_GCP_PRIVATE_IP_PORT) that are reachable across Cloud Interconnect, HA VPN, or Router appliance paths. When configuring Envoy-based load balancers—such as regional or cross-region internal Application Load Balancers—administrators must create a proxy-only subnet within the VPC network to allocate proxy IP addresses. Cloud Router must advertise the proxy-only subnet range to the on-premises or external cloud routers so that backends can accept proxied client traffic and distributed Envoy health checks. Remote firewalls must be configured with ingress rules that permit traffic from the regional proxy-only subnet range as well as the standard Google health check probe ranges (35.191.0.0/16 and 130.211.0.0/22).
Network Connectivity Center (NCC) is the orchestration framework for architecting hub-and-spoke topologies in Google Cloud. A hub is a central management resource that connects to various spokes, which are attachments representing your VPC networks, on-premises sites via Cloud Interconnect or Cloud VPN, or other cloud networks. This topology centralizes connectivity management and enables dynamic route exchange between connected environments.
The hub-and-spoke topology uses an NCC hub as the central point to interconnect multiple VPC spokes and hybrid spokes. You must make an irreversible decision at hub creation between a full-mesh topology, where all spokes can communicate with each other, and a star topology, where spokes can only communicate with the hub and a designated core group. Choose a full-mesh if traffic is permitted between all your VPC networks; choose a star topology if traffic between certain VPC spokes is not permitted but they can all connect to a core group. This central design contrasts with conventional hybrid connectivity, which places VPN tunnels or VLAN attachments directly in each individual VPC network.
Routing policies control how traffic flows between the hub, spokes, and external networks. For hybrid connectivity (on-premises or other clouds), you configure BGP sessions on Cloud Routers attached to your hybrid spokes (Cloud Interconnect VLAN attachments or Cloud VPN tunnels). To influence path selection, you use the Multi-Exit Discriminator (MED) BGP attribute. For example, to prefer a local region, an on-premises router announces its local subnets with a lower MED (like 100) and remote subnets with a higher MED (like 200). Cloud Router then uses these MED values to choose the optimal path, enabling efficient cross-region traffic flow and failover.
Dynamic route exchange through the hub allows routes learned from one hybrid spoke to be advertised to other spokes. To enable site-to-site data transfer directly between two non-Google Cloud networks (like two branch offices) over Google's backbone, you must enable the site-to-site data transfer field on the relevant hybrid spokes and ensure proper ASN assignments. This configuration allows traffic to bypass the hub VPC, taking an optimal path across Google's network.
To scale a hub-and-spoke architecture with many VPC networks, you centralize hybrid connectivity into one or more dedicated transit VPC networks. You then add these hybrid connections and all your VPC spokes to a single NCC hub. You must enable dynamic route exchange with VPC spokes on the hub. This configuration allows static or dynamically learned routes from the hybrid connections to be exported to the VPC spokes, providing centralized configuration and scale. An alternative, if you will not exceed resource limits and require Network Virtual Appliances (NVAs), is to use VPC Network Peering with custom advertised routes to provide access to shared hybrid connections.
Within a hub-and-spoke design, security is enforced at multiple layers. You apply firewall rules within each VPC network to control traffic. For sensitive data, define VPC Service Controls service perimeters. You can deploy Cloud Next Generation Firewall (Cloud NGFW) in a services-access VPC to inspect traffic entering or leaving workload VPCs. For observability and troubleshooting, use Connectivity Tests to validate paths between endpoints through the NCC hub and VPC Flow Logs with Flow Analyzer to gain insights into traffic patterns. Network Intelligence Center provides a single console for monitoring and managing network visibility across the entire topology.
Google Kubernetes Engine (GKE) clusters are managed Kubernetes environments that run on Google Cloud VPC networks. When you create a GKE cluster, you choose between a zonal cluster, which runs in a single zone, and a regional cluster, which runs across multiple zones for higher availability. The cluster's nodes are Compute Engine VM instances that are part of a managed instance group, and they are connected to a VPC subnet that you specify. GKE supports two networking modes: VPC-native clusters, which use alias IP ranges and are the recommended option, and routes-based clusters, which use the VPC's route table. VPC-native clusters provide better scalability and integration with VPC features like firewall rules and Cloud Router. You can also configure private clusters, where nodes have internal IP addresses only and the control plane is accessed through a VPC peering connection or a Private Service Connect endpoint.
In a full-mesh topology, all spokes connected to the hub can communicate with each other. In a star topology, spokes can only communicate with the hub and a designated core group; traffic between non-core spokes is not permitted. Choose full-mesh when all VPC networks need to exchange traffic, and star when you need to isolate certain spokes.
Use Dedicated Interconnect when you need high bandwidth (10 Gbps or 100 Gbps) and can colocate directly in a Google Cloud facility. Use Partner Interconnect when you need lower bandwidth (50 Mbps to 50 Gbps) or cannot colocate, because you connect through a supported service provider.
You must enable the site-to-site data transfer field on each hybrid spoke that represents the branch offices (connected via VPN or Interconnect) and ensure proper ASN assignments. This allows traffic to flow directly between the branches over Google's backbone, bypassing the hub VPC.
When using Envoy-based load balancers (internal Application Load Balancers) with hybrid NEGs, you must create a proxy-only subnet in the VPC. Cloud Router must advertise this subnet range to on-premises routers so that proxy IP addresses are reachable, and remote firewalls must allow traffic from this subnet and Google health check ranges.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts