Cloud HA VPN provides secure, encrypted site-to-site connectivity between Google Cloud Virtual Private Cloud (VPC) networks, on-premises data centers, and external clouds over public networks. A complete deployment pairs a regional Cloud HA VPN gateway with dynamic Border Gateway Protocol (BGP) routing managed by a Cloud Router and an external peer VPN gateway resource. This architecture establishes redundant IPsec tunnels across distinct interfaces to deliver an automated failover path and a 99.99% service level agreement (SLA).
A Cloud HA VPN gateway uses dual physical interfaces to eliminate single points of failure across public IPsec connections. To qualify for the 99.99% SLA, network administrators must configure two active VPN tunnels so that interface 0 and interface 1 on the Cloud HA VPN gateway connect to matching peer gateway interfaces. When provisioning the gateway, the stackType attribute is configured as either IPV4_ONLY by default or IPV4_IPV6. Internet Key Exchange version 2 (IKEv2) is the standard negotiation protocol and is mandatory when routing IPv6 traffic over the tunnels.
An external peer VPN gateway resource represents the physical routers, firewalls, or third-party cloud gateways residing outside Google Cloud. The configuration assigns a specific redundancyType based on how many public IP addresses the external peer system presents:
StudyCerts
StudyCertsSINGLE_IP_INTERNALLY_REDUNDANT applies to a single peer device that uses one external IP address on interface 0.TWO_IPS_REDUNDANCY applies to a dual-interface peer device or two separate single-interface peer devices mapped to interfaces 0 and 1.FOUR_IPS_REDUNDANCY applies to configurations requiring four external IP interfaces (assigned to interface IDs 0, 1, 2, and 3), such as connections terminating on Amazon Web Services (AWS).All interface IDs and public IP addresses must match precisely between the Cloud HA VPN gateway and the external peer VPN gateway. If the interface mapping or peer IP assignments do not align, the IPsec tunnels fail to establish.
A Cloud Router automates the dynamic exchange of network routes between a VPC network and external peer networks over IPsec VPN tunnels. Each regional Cloud Router uses an autonomous system number (Google ASN) chosen from private ranges 64512 to 65534 or 4200000000 to 4294967294. Once set, the Google ASN applies to every BGP session on that router and cannot be changed later. Each VPN tunnel maps to a dedicated Cloud Router interface with a link-local /30 subnet, and traffic priority is tuned by adjusting the advertised_route_priority attribute to define primary and backup paths.
Network Virtual Appliances (NVAs) provide centralized security inspection and traffic filtering for packets moving between branch offices, data centers, and VPC networks. In a transit architecture, NVAs operating in single-network interface (single-NIC mode) deploy inside a central transit VPC that connects to spoke VPCs using VPC Network Peering or Cloud HA VPN. Internal TCP/UDP Load Balancers sit in front of the NVAs to provide health checking, automatic scaling, and symmetric flow hashing for stateful traffic inspection. Policy-based routing directs traffic into the NVA security layer by evaluating packet metadata such as source and destination IP ranges.
Cloud Interconnect delivers enterprise-grade private connectivity between on-premises networks and Google Cloud without traversing the public internet. Dedicated Interconnect provides physical fiber connections directly into Google colocation facilities, while Partner Interconnect routes traffic through a certified service provider's network. Organizations select Dedicated Interconnect for high-bandwidth private circuits or Partner Interconnect when they cannot physically colocate with Google or require smaller bandwidth allocations.
A Cloud Interconnect link connects to a VPC network through a VLAN attachment, also known as an interconnect attachment. The attachment provisions a dedicated VLAN and a pair of link-local IP addresses shared between a Cloud Router interface and the on-premises router subinterface. The Cloud Router and on-premises router establish a BGP session across these link-local addresses. On-premises route advertisements become custom dynamic routes inside the VPC, while the Cloud Router advertises VPC subnet ranges back to the on-premises network.
VLAN attachments support configurable maximum transmission unit (MTU) sizes of 1440, 1460, 1500, or 8896 bytes. The 8896-byte jumbo frame setting is available only on unencrypted IPv4 and IPv6 attachments. For reliable packet delivery, all VLAN attachments associated with a VPC network must share the same MTU, and the VPC network MTU should match this value. Google API Client Library requests always enforce a 1440-byte MTU regardless of the attachment configuration.
Provisioning Dedicated Interconnect begins by ordering physical ports, receiving a Letter of Authorization (LOA), and coordinating circuit cross-connects with the colocation vendor. Once Google tests and verifies the physical circuit, administrators create VLAN attachments to begin routing production traffic. Dedicated Interconnect uses a fixed monthly port fee for outbound data transfers. Pricing differentiates between local connections, where the attachment metropolitan area matches the destination Google Cloud region, and remote connections, where the metro area and destination region differ.
Achieving an official availability SLA requires deploying redundant Interconnect connections across distinct failure domains. A 99.9% SLA requires two connections deployed across two separate edge availability domains within a single metropolitan area. A mission-critical 99.99% SLA requires four connections deployed across two distinct Google Cloud regions, with each regional pair using separate edge availability domains in separate metropolitan areas. Organizations can use Cloud Interconnect groups to organize resources and automatically validate their topology against 99.9% or 99.99% architectural standards.
Cloud Interconnect traffic is unencrypted by default, requiring additional security configurations for regulated or sensitive workloads. Organizations can enable MACsec for Cloud Interconnect to provide line-rate, Layer 2 hardware encryption between the on-premises router and Google's edge router. Alternatively, teams can deploy HA VPN over Cloud Interconnect, which establishes an encrypted IPsec tunnel over the private VLAN attachments and uses a dedicated Cloud Router for the encrypted routing tier. Organization policies can also restrict which VPC networks are authorized to attach to Cloud Interconnect connections.
Cross-Cloud Interconnect provisions direct, high-bandwidth physical connections between Google Cloud and other cloud providers such as AWS, Microsoft Azure, Oracle Cloud Infrastructure, or Alibaba Cloud. Google manages the physical cabling between cloud edge ports, while customers provision and pay for the ports on both sides under a shared responsibility model. Google's SLA covers network availability up to the provider hand-off point. High availability designs mirror standard Interconnect requirements, using redundant links across distinct metropolitan areas and edge domains to achieve 99.9% or 99.99% reliability.
Network Connectivity Center (NCC) manages global wide-area network routing by linking VPC networks, branch offices, and external clouds through a centralized hub-and-spoke model. The service supports VPC spokes, hybrid spokes, and Router appliance spokes to integrate third-party Software-Defined WAN (SD-WAN) virtual appliances directly into Google Cloud's network fabric. This hub architecture simplifies complex multi-cloud topologies while supporting centralized traffic inspection and consistent route propagation.
Router appliances are third-party NVAs running on Compute Engine virtual machines that exchange dynamic BGP routes with a regional Cloud Router. Network Connectivity Center uses Router appliance instances to connect a VPC network to external networks or to connect two distinct VPC networks using dynamic routing. The Cloud Router manages the BGP peering sessions with the Router appliance instances, automatically learning and advertising network prefixes. To join the transit architecture, Router appliance virtual machines are assigned directly to an NCC hybrid spoke.
A hybrid spoke in Network Connectivity Center connects external on-premises or branch networks to an NCC hub using Router appliances, Cloud Interconnect VLAN attachments, or Cloud HA VPN tunnels. Multiple hybrid and VPC spokes can attach to a single hub, allowing organizations to scale multi-site branch topologies across regions. VPC spokes can access on-premises networks through hybrid spokes residing in separate routing VPC networks. When a hybrid spoke has site-to-site data transfer enabled, the Cloud Router re-advertises learned prefixes to all other hybrid spokes attached to that hub.
An SD-WAN NVA can use up to 8 virtual network interfaces (multi-NIC mode) to connect multiple network segments while preventing overlapping IP addresses between subnets. Deploying a multi-NIC appliance across distinct VPC networks requires valid Identity and Access Management (IAM) permissions in every target network. This multi-NIC design allows an NVA to sit directly in the traffic path between VPC networks and private branch environments, enforcing centralized security inspection on cross-boundary traffic flows.
Network Connectivity Center relies on Cloud Router to establish External BGP (eBGP) sessions with peer routing devices. All non-Google routers belonging to a single spoke must use the same Autonomous System Number (ASN) when advertising prefixes to Cloud Router. Different spokes attached to the same hub must use distinct ASNs to prevent routing conflicts and route dropping. Network Connectivity Center does not support BGP communities, and all routes introduced by hybrid spokes are installed as dynamic routes that follow standard VPC routing precedence.
Site-to-site data transfer enables external branch offices and data centers to exchange IPv4 traffic with each other across Google's private backbone network. When data transfer is enabled on multiple hybrid spokes associated with the same hub, Cloud Router re-advertises BGP prefixes learned from one branch spoke to all other hybrid spokes on that hub. All hybrid spokes participating in data transfer must reference Router appliances, VPN tunnels, or VLAN attachments residing in a single VPC network. This capability creates a global mesh between remote sites, such as offices in New York, Sydney, and Tokyo, and supports IPv4 traffic exclusively.
Network Connectivity Center enforces strict IP version rules depending on the spoke configuration:
When data transfer is enabled on hybrid spokes, all participating resources and data paths are restricted to IPv4.
Cloud Router operates purely in the control plane to install dynamic routes in the software-defined network, never carrying data plane traffic directly. When configured for regional dynamic routing, the Cloud Router advertises and learns subnets located only in its local region. When configured for global dynamic routing, the Cloud Router advertises subnets across all regions in the VPC network, but applies a distance penalty (200 plus the inter-region round-trip time in milliseconds) to prioritize local interconnects and maintain symmetric regional routing paths.
Designing secure and resilient hybrid topologies means choosing the right connectivity options, security controls, and redundancy mechanisms to link on-premises environments with Google Cloud and to connect multiple cloud providers. The architecture must balance performance, cost, and operational complexity while protecting data and ensuring high availability.
Google Cloud provides several connectivity options for hybrid and multicloud architectures, each suited to different requirements. Cloud VPN offers IPsec-encrypted tunnels over the public internet, with HA VPN providing active/active configurations for higher availability. Cloud Interconnect extends your external network to Google's network through dedicated physical connections—Dedicated Interconnect provides direct connections at colocation facilities, while Partner Interconnect uses service providers for more points of connectivity. Cross-Cloud Interconnect specifically enables private, high-bandwidth connections between Google Cloud and other supported cloud service providers like AWS, Azure, Oracle Cloud Infrastructure, and Alibaba Cloud, with throughput rates up to 100 Gbps per link and optional MACsec encryption.
To achieve 99.99% availability for production workloads, you must architect redundant connectivity paths that connect to two different Google Cloud regions from distinct metros across two separate zones. The recommended approach uses a transit VPC as a centralized hub that connects to external networks through HA VPN, Dedicated Interconnect, Partner Interconnect, or Router appliances. Workload VPCs then connect to the transit VPC through VPC Network Peering or Network Connectivity Center spokes. For Cross-Cloud Interconnect specifically, you must purchase two connections—a primary and a redundant pair—to satisfy the SLA requirements, with each pair dedicated to a single cloud provider.
Cloud Router provides Border Gateway Protocol (BGP) speaker and responder functionality for dynamic routing between your networks and Google Cloud. BGP enables automatic route learning and failover—when you configure BGP sessions on Cloud Routers, you can use metrics like Multi-Exit Discriminator (MED) values to influence path preference. For example, you might assign MED 100 to routes from the primary region and MED 200 to routes from a secondary region, allowing Google Cloud to use Equal-Cost Multi-Path (ECMP) load balancing across multiple tunnels when they announce the same MED. Cloud Router supports both global dynamic routing, which advertises routes across all regions, and regional routing for more granular control.
Protecting data across provider boundaries requires multiple layers of encryption and access control. For application-layer security, use Transport Layer Security (TLS) encryption for all sensitive traffic. At the network connectivity layer, you can deploy HA VPN over Cloud Interconnect to encrypt traffic between your network and Google's network, or enable MACsec for Cross-Cloud Interconnect and Dedicated/Partner Interconnect for Layer 2 encryption. Private Service Connect allows workloads to access Google APIs or published services using internal IP addresses without exposing traffic to the public internet. Additionally, VPC Service Controls define service perimeters around VPC resources to control data movement across perimeter boundaries.
Network Connectivity Center provides a hub-and-spoke model that simplifies connectivity management across multiple VPCs, on-premises networks, and other cloud environments. The hub serves as a centralized management resource, while spokes attach supported resources like VLAN attachments, VPN tunnels, and Router appliances. You can choose between a full-mesh topology, which permits traffic between any VPC networks, or a star topology, which restricts traffic to a core group of spokes. Network Connectivity Center also supports site-to-site data transfer, letting you use Google's network as a wide-area network (WAN) to move data between on-premises sites and multiple cloud providers.
Hybrid and multicloud architectures require integrated DNS resolution to enable seamless communication between environments. DNS forwarding zones forward queries to on-premises DNS servers, while DNS peering allows forwarding DNS requests within Google Cloud environments. DNS server policies enable inbound queries from on-premises environments to resolve Google Cloud internal DNS names. This integration ensures that services and applications can discover each other across environment boundaries using private IP addresses.
When designing hybrid topologies, select connectivity options based on your specific requirements—use Cloud VPN for lower bandwidth needs or experimentation, Dedicated or Partner Interconnect for enterprise-grade connections with higher throughput, and Cross-Cloud Interconnect for multicloud scenarios requiring dedicated bandwidth. Always design for end-to-end high availability by distributing workloads across regions and using redundant connectivity paths. Minimize synchronous dependencies between systems running in different environments, as these can degrade performance and reduce availability. Use defense-in-depth principles by combining multiple security controls, and ensure consistent logging and monitoring across all environments using tools like VPC Flow Logs and Network Intelligence Center.
Multicloud network design involves balancing traffic performance, financial expenditures, and administrative overhead across disparate cloud service providers (CSPs). Organizations interconnect Google Cloud with external platforms—such as Amazon Web Services (AWS), Microsoft Azure, and Oracle Cloud Infrastructure (OCI)—to prevent vendor lock-in, meet regulatory residency requirements, and deploy disaster recovery (DR) sites. Selecting an appropriate architecture requires evaluating distinct connectivity pricing structures, provisioning requirements, and unified operational frameworks across independent administrative domains.
Multicloud network connectivity pricing combines fixed infrastructure fees with variable data transfer charges based on the selected transport method. Transferring data over the public internet incurs standard internet egress charges on outbound traffic from Google Cloud, though the Standard Network Service Tier offers a lower pricing tier when latency tolerance is high. Setting up Cloud VPN introduces an hourly gateway charge per tunnel alongside standard internet egress rates, which often exceed the fixed service costs during sustained transfers.
Private connectivity alternatives alter the cost model by replacing high public internet rates with discounted egress pricing. Cross-Cloud Interconnect requires an hourly fee for each dedicated 10-Gbps or 100-Gbps physical connection alongside an hourly charge for each virtual local area network (VLAN) attachment. Egress traffic routed through Cross-Cloud Interconnect or Dedicated Interconnect is billed at reduced rates compared to standard internet transfers, lowering total cost of ownership (TCO) for high-volume workloads. When deploying Partner Interconnect, Google bills for the VLAN attachment capacity and egress bandwidth, while the third-party provider bills separately for Layer 2 or Layer 3 transport across their network fabric.
The operational complexity and provisioning timelines for multicloud links depend on physical infrastructure dependencies and vendor boundaries. Internet-based transit and Cloud VPN provide the fastest provisioning with minimal complexity, as engineers configure software endpoints in each cloud console without procuring physical circuits. However, managing multiple IPsec tunnels across regions introduces configuration overhead and lacks end-to-end performance or latency guarantees across the unmanaged public internet.
Colocation models using Dedicated Interconnect require the highest operational effort and longest lead times because the organization must procure, house, and manage physical routers within a common point of presence (PoP). In contrast, Cross-Cloud Interconnect provides a fully managed private transport where Google provisions physical cross-connects directly to the remote CSP edge, eliminating customer-managed colocation hardware. Partner Interconnect offers an intermediate option where supported partners manage intermediate BGP routing hardware, enabling flexible VLAN attachment bandwidths from 50 Mbps to 50 Gbps without requiring multi-Gbps port commitments.
Cross-cloud routing integrates disjoint network domains by establishing dynamic routing sessions over shared boundaries. Cloud Router uses Border Gateway Protocol (BGP) to exchange routes dynamically between Google Cloud Virtual Private Cloud (VPC) networks and remote cloud routers. By configuring Cloud Router in global dynamic routing mode, a single set of cross-cloud attachments or VPN tunnels in one region can propagate routes to all subnets across the entire global VPC network.
To streamline multi-network transit, organizations can deploy a transit VPC as a centralized hub to terminate external connections and house network virtual appliances (NVAs) for security inspection. Traffic flowing between Google Cloud and another CSP requires careful IP address management within private RFC 1918 allocations to prevent overlapping ranges across clouds. When IP spaces overlap between cloud environments, Hybrid NAT must be enabled on the hybrid connection to translate addresses and ensure bidirectional reachability.
Monitoring and troubleshooting multicloud architectures requires unified diagnostic tools that span disparate administrative domains. Network Intelligence Center serves as a centralized console within Google Cloud to visualize network topologies, monitor performance metrics, and troubleshoot transit paths. When performance degradations or packet drops occur, engineers analyze metrics across three primary segments: internal Google Cloud routing, the physical cross-connect interconnecting both cloud edges, and the internal network of the remote CSP.
Administrative boundaries dictate specific operational troubleshooting responsibilities between providers. Under the Cross-Cloud Interconnect service level agreement (SLA), Google maintains and monitors the physical cabling up to the demarcation point at the remote cloud's edge router. For end-to-end issues, customers must maintain active support contracts with all involved CSPs and open tickets with each provider to resolve intermediate faults. Security teams should aggregate telemetry into a centralized security information and event management (SIEM) solution, such as Google Security Operations SIEM, and employ Cloud DNS peering and forwarding policies to ensure consistent domain name resolution across clouds.
Operating a multicloud architecture introduces distinct billing metrics and discount structures that necessitate unified financial governance. Redundant deployments across providers often incur extra infrastructure costs due to duplicate data storage and underutilized idle compute resources in disaster recovery environments. To mitigate these expenses, organizations can maintain stopped Compute Engine instances that incur only storage costs, or dynamically scale compute infrastructure using automated deployment pipelines.
Establishing a centralized visibility framework is critical for tracking and optimizing cross-cloud resource expenditures. Teams can aggregate raw billing exports from multiple cloud providers into a unified reporting interface using the Looker Cloud Cost Management Block. Under a structured FinOps framework, a central team standardizes cost allocation, budget alerting, and optimization processes while delegating operational remediation to specific resource owners across cloud platforms.
Multicloud connectivity technologies are the services that create secure, high-performance links between Google Cloud VPC networks and networks in other public clouds. The choice between technologies like Cloud VPN, Cloud Interconnect, and Cross-Cloud Interconnect is a critical architectural decision based on bandwidth, latency, availability, and cost requirements.
Cloud VPN establishes an encrypted IPsec tunnel over the public internet to connect your Google Cloud VPC to another cloud or on-premises network. Data flows from a source network, through a Cloud VPN Gateway in a Google Cloud region, across the internet via the encrypted tunnel, and terminates at a peer VPN gateway in the destination network. This service is best for moderate bandwidth needs and where a physical private connection is not feasible. For high availability, you configure High Availability (HA) VPN with two tunnels and dynamic Border Gateway Protocol (BGP) routing, which allows for active/active or active/passive failover between tunnels if one fails.
Cloud Interconnect provides private, physical connectivity that bypasses the public internet, offering lower latency and higher reliability. It has two main types for external connectivity: Dedicated Interconnect, where you provision a direct physical link between your on-premises router and Google's network at a colocation facility, and Partner Interconnect, where you connect through a supported service provider's existing infrastructure. You create a logical VLAN attachment that links the physical connection to a specific VPC network region via a Cloud Router, which establishes a BGP session to exchange routes. Dedicated Interconnect supports high bandwidth (10 Gbps or 100 Gbps links, up to 200 Gbps total per connection) and is ideal for high-volume, consistent data transfer.
Cross-Cloud Interconnect is a specific type of Dedicated Interconnect designed for multicloud scenarios. Google provisions a direct physical connection between Google's network and the network of another supported cloud provider, such as AWS, Azure, or Oracle Cloud Infrastructure (OCI). As with Dedicated Interconnect, you then create VLAN attachments to connect this physical link to your Google Cloud VPC. This service is optimal for high-bandwidth, low-latency data transfer between clouds, which can also help reduce outbound data transfer costs compared to routing traffic over the internet.
The decision between these technologies hinges on evaluating performance, cost, and operational needs. Choose Cross-Cloud Interconnect or Dedicated Interconnect when you require high bandwidth (over 3 Gbps), consistent low latency, high availability with an SLA, and predictable pricing for high data volumes. Choose Cloud VPN for lower bandwidth requirements, initial proof-of-concept work, or when the cost and lead time of provisioning a physical connection are prohibitive. For all interconnect options, you must design for redundancy by provisioning connections in separate edge availability domains within a metro area to protect against planned maintenance or single points of failure.
Accessing Google services and interconnecting enterprise environments requires selecting network paths, peering architectures, and endpoint configurations that match specific routing and security requirements. Google Cloud provides mechanisms to route traffic to public Google Application Programming Interfaces (APIs), Software as a Service (SaaS) offerings, and managed workloads across the public internet, dedicated private endpoints, and peered connections. Network boundary design requires organizations to balance IP address allocations, routing transitivity, traffic isolation, and network inspection topology across hybrid and multi-cloud environments.
Public and private access paths determine whether network traffic to Google APIs and services traverses the public internet or remains isolated within Google's private network infrastructure. Public access routes traffic to external, publicly routable IP addresses, such as regional service endpoints or outbound traffic from private compute instances using a Cloud NAT gateway over the public internet. Conversely, Private Google Access (PGA) allows virtual machine (VM) instances with internal RFC 1918 addresses to reach Google APIs privately over Google's internal network using virtual IP addresses such as private.googleapis.com. Private Service Connect (PSC) provides granular private connectivity by deploying a private IP endpoint directly inside a customer Virtual Private Cloud (VPC) network, mapping incoming requests directly to target services without exposing packets to the public internet.
VPC Network Peering and Private Services Access (PSA) establish direct network connectivity between two VPC networks to allow bidirectional communication and internal route exchange. When establishing a PSA connection to a service producer, the consumer network must allocate a dedicated, non-overlapping internal IP address range—such as a /22 or /28 Classless Inter-Domain Routing (CIDR) block—that the producer uses to provision isolated workload instances. Peered connections synchronize routing tables between connected networks but do not support transitive routing across multiple network hops. Deploying Private Service Connect endpoints eliminates the requirement to allocate large consumer subnet ranges, avoids routing table exhaustion, and natively supports transitive connectivity across multi-tier topologies.
Hybrid and multi-cloud architectures link on-premises data centers and external cloud networks to Google Cloud environments using Cloud Interconnect attachments or Cloud VPN tunnels. When on-premises hosts connect across hybrid links, custom route advertisements managed by Cloud Router enable traffic to reach internal resources, peered service subnets, and Private Service Connect endpoints hosted within customer VPC networks. Enterprises requiring perimeter traffic inspection can route inbound hybrid traffic through a dedicated transit VPC containing virtual firewalls before directing requests toward internal application endpoints. In distributed deployments, management plane integrations such as the Apigee Adapter for Envoy allow edge proxies deployed in remote data centers to enforce local authentication, rate limiting, and security policies while synchronizing asynchronously with Google Cloud.
Evaluating technical prerequisites and operational requirements involves assessing the foundational infrastructure and administrative capabilities needed to establish an enterprise-grade connection to Google's public edge network. The decision between using Direct Peering and a Verified Peering Provider depends on an organization's ability to satisfy physical, routing, and operational criteria versus choosing a partner-managed service.
Direct Peering requires an enterprise to deploy and manage its own physical routing hardware at a Google edge point of presence (PoP). The enterprise must possess a registered public Autonomous System Number (ASN) and allocate publicly routable IP address blocks. These resources are necessary to establish Border Gateway Protocol (BGP) sessions with Google and advertise public network routes. Without a public ASN and routable public IP space, an enterprise cannot establish a direct peering relationship with Google's edge.
Direct Peering demands ongoing operational management and infrastructure monitoring from the enterprise network team. The enterprise must maintain a 24/7 Network Operations Center (NOC) capable of monitoring the peering link, troubleshooting connectivity disruptions, and responding to incidents immediately. Operational duties include managing active BGP sessions, ensuring route health, and coordinating maintenance events directly with Google's NOC. The enterprise retains complete operational responsibility for the availability and performance of its physical peering connections.
A Verified Peering Provider delivers an alternative peering model where an authorized Internet Service Provider (ISP) manages physical interconnect hardware, BGP routing sessions, and operational support on behalf of the customer. In this deployment, the enterprise connects directly to the provider's network, and the provider routes traffic to Google over its established peering infrastructure. This model shifts the responsibility of satisfying technical peering prerequisites and staffing a 24/7 NOC to the provider. While routing through a third-party provider adds an intermediary network hop, it eliminates the requirement for in-house public peering infrastructure.
Traffic engineering in Google Cloud involves choosing the optimal connection method to Google's edge network based on performance, service level agreements (SLAs), and internal VPC routing requirements. The available mechanisms for connecting to Google public services include Direct Peering, Verified Peering Provider, Carrier Peering, and Cloud Interconnect. Understanding the boundaries between public peering paths and private interconnect paths ensures that both internal VPC resources and public Google services receive appropriate network routing.
Direct Peering establishes a direct BGP connection between an enterprise network and Google's edge network across more than 100 locations worldwide to exchange high-throughput public traffic. Direct Peering provides a direct path to Google services that operate on public IP addresses, including Google Workspace and public Google Cloud APIs. Traffic flowing from Google Cloud VPC networks to the customer's on-premises network also uses this path if public routes are advertised. Direct Peering operates entirely outside Google Cloud, does not inject custom dynamic routes into VPC networks, and requires physical redundancy across at least two separate links within a metropolitan area without providing a Google SLA.
A Verified Peering Provider enables an organization to reach publicly available Google Cloud resources through a certified ISP without establishing a direct physical connection to Google. Verified Peering Providers manage the technical complexity of peering arrangements with Google while providing customers with reliable, low-latency internet connectivity. Google evaluates participating ISPs based on technical criteria and awards badges:
Organizations should choose a Verified Peering Provider when they require redundant connectivity to Google public services without the overhead of satisfying Google's Direct Peering physical prerequisites.
Verified Peering Provider and Cloud Interconnect serve fundamentally different architectural roles based on network boundaries and resource targets:
Carrier Peering provides enterprise-grade connectivity to Google public applications like Google Workspace through a network service provider over dedicated or shared partner links. Carrier Peering enables an organization to connect an isolated perimeter subnetwork to Google's edge over the public internet rather than exposing its entire enterprise network. Similar to Direct Peering, Carrier Peering exists outside of Google Cloud and does not insert routes into VPC networks. Google does not offer an SLA for Carrier Peering, so organizations requiring private access to internal VPC resources or a Google SLA should use Partner Interconnect instead.
Architecting hybrid connectivity requires enforcing strict boundaries between public peering paths and private VPC paths to ensure predictable traffic engineering. Traffic destined for public Google services traverses public peering paths over Direct Peering or a Verified Peering Provider, while traffic destined for RFC 1918 internal VM addresses must traverse Cloud Interconnect or Cloud VPN. BGP sessions configured on peering links advertise public prefixes to Google's edge, whereas Cloud Routers advertise internal VPC subnets and custom ranges to on-premises routers. Because peering connections do not import routes into VPC routing tables, organizations cannot use Direct Peering or Verified Peering Providers to route transit traffic directly into private VPC workloads.
A primary risk in multi-region designs is application unavailability if multiple regions fail simultaneously. When an application is deployed across two regions and both experience outages, the global load balancer remains available but has no healthy backends to distribute traffic to, which renders the service down. To mitigate this, critical applications must be deployed across more than two regions, and proper capacity planning must be performed to ensure either sufficient reserved capacity exists in all regions or the risks of emergency autoscaling are acceptable. Operational practices for disaster recovery testing, incident management, and post-incident verification are also essential to ensure rapid recovery.
When designing connectivity between regions and external networks, you must account for differences in how cloud providers handle routing. A Google Cloud VPC network supports global cross-region routing, while other cloud service providers might use regional VPCs with different Border Gateway Protocol scopes. The Cloud Router service automatically advertises routes with path preferences based on regional proximity, but this behavior depends on the VPC's configured dynamic routing mode. You may need to override these default preferences to achieve desired routing behavior, such as controlling which network path carries inter-regional traffic.
To manage latency and ensure flow symmetry where request and response traffic follow the same path, you should designate a preferred network for inter-regional communications using hot-potato and cold-potato routing strategies. Cold-potato routing in one domain paired with hot-potato routing in the peer domain keeps traffic on the originating network as long as possible, reducing latency and preventing issues with stateful security functions that asymmetric flows can cause.
For high availability within a single region, use active/active designs for intra-regional links. This design uses Equal Cost Multi-Path routing to aggregate the bandwidth of multiple paths, such as Cloud Interconnect connections, and use them simultaneously. Cloud Interconnect also supports LACP-aggregated links to achieve up to 200 Gbps of aggregate bandwidth per path. An active/passive design, where one link is a standby, is only necessary when on-premises network topologies combined with stateful security functions require it.
To increase availability to 99.99% for connections to on-premises networks, you must peer in multiple geographical regions. This involves connecting on-premises routers in different locations redundantly to the managed Cloud Router services in two different Google Cloud regions. This multi-region design provides backup connectivity in case one region fails.
You must configure external routers to control traffic paths and avoid site-to-site data transfer failures. Site-to-site data transfer via Network Connectivity Center is only supported in specific locations. If you maintain a connectivity resource in an unsupported location, you must influence BGP route selection to ensure traffic uses paths associated with Network Connectivity Center spokes.
To optimize for site-to-site data transfer, configure your external router to advertise prefixes with a lower Multi-Exit Discriminator value to the supported region and a higher MED to the unsupported region. This forces the Cloud Router to prefer and readvertise the route from the supported region, enabling site-to-site connectivity. To optimize for site-to-cloud traffic, advertise prefixes with the same MED to both regions, and the Cloud Router will choose the geographically closer path.
A Virtual Private Cloud network dynamic routing mode defines the operational scope for all Cloud Router instances deployed within that network. In regional dynamic routing mode, dynamic routes learned from external networks over Cloud Interconnect or Cloud VPN are only shared with subnets in the local Google Cloud region where the BGP session terminates. Conversely, global dynamic routing mode enables cross-region routing, allowing Cloud Routers in any region to advertise all VPC subnets to external networks and propagate learned on-premises prefixes to every subnet throughout the global VPC network.
Organizations implement regional dynamic routing when workloads require strict geographic boundaries or jurisdictional isolation where inter-regional traffic should not flow automatically. Global dynamic routing is selected when workloads span multiple regions and require simplified VPC-wide communication to external data centers without requiring manual route management.
Route propagation and path selection rely on Cloud Router advertising routes with predetermined path preferences calculated from regional proximity. When global dynamic routing is enabled, Cloud Router automatically assigns higher preference to local regional paths and lower preference to cross-region paths. Network engineers can override these default preferences using Multi-Exit Discriminator values or Cloud Router custom route advertisements to control ingress and egress
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills