Cloud VPN

Cloud VPN allows you to connect to your Virtual Private Cloud (VPC) network from your existing network, such as your on-premises network, another VPC network, or another cloud provider’s network, through an IPsec connection using (i) Classic VPN, which supports dynamic (BGP) routing or static routing (route-based or policy-based), or (ii) HA (high-availability) VPN, which supports dynamic routing with a simplified redundancy setup, separate failure domains for the gateway interfaces, and a higher service level objective.

Google Cloud Hybrid Connectivity – IC, VPN & NCC

~ Last updated on : ~ jayendrapatil

Google Cloud Hybrid Connectivity

Google Cloud provides various network connectivity options to meet the needs, using either public networks, peering, or interconnect technologies.

🆕 Updated June 2026: This post covers major updates including Cross-Cloud Interconnect (multicloud connectivity), Cross-Site Interconnect (L2 site-to-site), Network Connectivity Center (hub-spoke orchestration), 400 Gbps Dedicated Interconnect circuits, Classic VPN BGP deprecation, HA VPN over Cloud Interconnect, MACsec encryption, and customizable VPN ciphers.

Google Cloud Hybrid Connectivity Options

Public Network Connectivity

Standard internet connection can be used to connect Google Cloud with the on-premises environment if it meets the bandwidth needs.

Cloud VPN

  • provides secure, private connectivity using IPSec
  • connects on-premises networks to VPC or two VPCs in GCP
  • traffic flows via the VPN tunnel but is still routed over the public internet
  • traffic is encrypted by one gateway and decrypted by the other
  • allows users to access private RFC1918 addresses on resources in the VPC from on-prem computers also using private RFC1918 addresses.
  • can be used with Private Google Access for on-premises hosts
  • provides guaranteed uptime of 99.99% using High Availability (HA) VPN
  • supports only site-to-site VPN
  • supports up to 3Gbps per tunnel with a maximum of 8 tunnels
  • supports static as well as dynamic routing using Cloud Router
  • supports IKEv1 or IKEv2 using a shared secret
  • supports IPv6 traffic exchange with dual-stack (IPv4/IPv6) HA VPN gateways
  • supports customizable cipher options allowing you to configure specific ciphers per your security requirements (GA)

Classic VPN vs HA VPN

  • Classic VPN provides a single external IP address and tunnels with 99.9% SLA
  • HA VPN uses redundant interfaces and provides 99.99% SLA
  • HA VPN supports IPv6/dual-stack; Classic VPN does not
  • HA VPN supports dynamic routing (BGP) and is the only VPN option for BGP
⚠️ Classic VPN BGP Deprecation (August 1, 2025): Dynamic routing (BGP) for Classic VPN tunnels is deprecated. You cannot create new Classic VPN tunnels using BGP. Existing BGP tunnels continue to function but without SLA. For workloads requiring BGP, you must migrate to HA VPN. Classic VPN with static routing remains supported.

Peering

  • Peering provides better connectivity to Google Cloud as compared to the public connection. However, the connectivity is still not RFC1918-to-RFC1918 private address connectivity.
  • Peering gets your network as close as possible to Google Cloud public IP addresses.
  • Google does not offer an SLA with Direct Peering or Carrier Peering. For customers requiring SLA, Google recommends Cloud Interconnect.
  • Google recommends using a Verified Peering Provider instead of Direct Peering.

Direct Peering

  • requires you to lease co-lo space and install and support routing equipment in a Google Point Of Presence (PoP).
  • supports BGP over a link to exchange network routes.
  • All traffic destined to Google rides over this new link, while traffic to other sites on the internet rides your regular internet connection.

Carrier Peering

  • preferred if installing equipment isn’t an option or would prefer to work with a service provider partner as an intermediary to peer with Google
  • connection to Google is via a new link connection installed to a partner carrier that is already connected to the Google network itself.
  • supports BGP or uses static routing over that link.
  • All traffic destined to Google rides over this new link.
  • Traffic to other sites on the internet rides your regular internet connection.

Interconnect

  • Interconnects are similar to peering in that the connections get your network as close as possible to the Google network.
  • Interconnects differ from peering as they provide connectivity using private address space into the Google VPC.
  • For RFC1918-to-RFC1918 private address connectivity, either a dedicated or partner interconnect is required.
  • Cloud Interconnect now offers four types: Dedicated Interconnect, Partner Interconnect, Cross-Cloud Interconnect, and Cross-Site Interconnect.
  • Traffic doesn’t traverse the public internet, resulting in fewer hops and points of failure.
  • Supports MACsec for link-layer encryption between your on-premises router and Google’s edge routers.
  • Supports HA VPN over Cloud Interconnect for IPsec encryption of VLAN attachment traffic.

Dedicated Interconnect

  • provides private, high-performance connectivity to Google Cloud
  • requires you to lease co-lo space and install and support routing equipment in a Google Point Of Presence (PoP).
  • supports 10 Gbps, 100 Gbps, and 400 Gbps circuits with up to 8 circuits per connection (max 3200 Gbps with 400G circuits)
  • gives the RFC1918-to-RFC1918 private address connectivity.
  • All traffic destined to the Google Cloud VPC rides over this new link.
  • Traffic to other sites on the internet rides the regular internet connection.
  • Single Interconnect connection does not offer HA and GCP recommends redundancy using 2 (99.9%) or 4 (99.99%) interconnect connections so that if one connection fails, the other connection can continue to serve traffic
  • supports IPv6 traffic with dual-stack (IPv4 and IPv6) VLAN attachments
  • supports VLAN attachment MTU of 1440, 1460, 1500, or 8896 bytes (jumbo frames)
  • supports MACsec encryption for securing traffic between on-premises router and Google’s edge routers
  • supports connection groups (Interconnect groups and Attachment groups) for reliability monitoring and SLA eligibility tracking
  • supports application awareness for traffic differentiation using DSCP for prioritizing business-critical traffic
  • offers fixed port pricing for predictable monthly billing of outbound data transfers

Partner Interconnect

  • provides private, high-performance connectivity to Google Cloud
  • preferred if bandwidth requirements are below 10 Gbps or installing equipment isn’t an option or would prefer to work with a service provider partner as an intermediary
  • similar to carrier peering in that you connect to a partner service provider that is directly connected to Google.
  • supports BGP or use static routing over that link.
  • requires provisioning a VLAN attachment over the physical link
  • gives the RFC1918-to-RFC1918 private address connectivity.
  • supports VLAN attachment capacities from 50 Mbps to 50 Gbps
  • All traffic destined to your Google VPC rides over this new link.
  • Traffic to other sites on the internet rides your regular internet connection.
  • supports IPv6 traffic with dual-stack VLAN attachments
  • supports HA VPN over Cloud Interconnect for encrypting traffic

Cross-Cloud Interconnect

  • provides dedicated, private connectivity between Google Cloud and another cloud service provider (multicloud connectivity)
  • establishes a direct physical connection between Google’s network and another cloud provider’s network
  • supports connectivity to AWS, Microsoft Azure, Oracle Cloud Infrastructure (OCI), and Alibaba Cloud
  • available in 10 Gbps and 100 Gbps circuit sizes
  • provides private RFC1918-to-RFC1918 connectivity across clouds
  • backed by Google Cloud SLA (99.9% or 99.99% depending on redundancy)
  • Partner Cross-Cloud Interconnect is available for AWS and OCI for on-demand, managed cross-cloud connectivity without provisioning dedicated physical connections
  • supports application awareness for traffic differentiation
  • supports HA VPN over Cloud Interconnect for encryption
  • Google and AWS announced a managed, private, on-demand cross-cloud connectivity collaboration in 2026

Cross-Site Interconnect (GA 2025)

  • provides transparent, on-demand Layer 2 connectivity between your on-premises network sites using Google’s global infrastructure
  • simplifies, augments, and improves reliability for WAN connectivity between your data centers
  • leverages Google’s global network for high-performance and high-bandwidth site-to-site connectivity
  • requires colocation in Google-supported facilities
  • supports cross-site network MTU of 9,000 bytes
  • ideal for disaster recovery, data replication, and site-to-site backup use cases

HA VPN over Cloud Interconnect

  • allows deploying HA VPN tunnels over Dedicated Interconnect or Partner Interconnect VLAN attachments
  • encrypts traffic that traverses Cloud Interconnect connections using IPsec
  • helps meet regulatory and security requirements for data encryption in transit
  • supported for both Dedicated Interconnect and Partner Interconnect
  • provides both the private connectivity of Cloud Interconnect and the encryption of VPN

MACsec for Cloud Interconnect

  • provides link-layer encryption (IEEE 802.1AE) between your on-premises router and Google’s edge routers
  • secures traffic on the physical connection without the overhead of IPsec tunneling
  • supported on Dedicated Interconnect circuits
  • provides configurable fail-open behavior (traffic passes unencrypted if MACsec fails) or fail-close (traffic is blocked)
  • requires MACsec-capable on-premises router

Network Connectivity Center (NCC)

  • a hub-and-spoke orchestration framework that simplifies network connectivity
  • provides centralized management of connectivity between VPC networks, on-premises networks, and other clouds
  • supports VPC spokes for inter-VPC connectivity (up to 250 VPC spokes per hub)
  • supports hybrid spokes using Cloud VPN, Cloud Interconnect, or Router appliance
  • enables site-to-site data transfer using Google’s global network as part of your WAN
  • provides full mesh transitivity between all spokes connected to a hub
  • supports spoke groups for preset connectivity topologies (mesh, star, etc.)
  • integrates with Cross-Cloud Interconnect for multicloud hub-spoke architectures

Google Cloud Hybrid Connectivity Decision Tree

Google Cloud Hybrid Connectivity Decision Tree

Google Cloud Hybrid Connectivity

Google Cloud Hybrid Connectivity Comparison

Option Connectivity Bandwidth SLA Private RFC1918
Cloud VPN (HA) Over public internet (encrypted) Up to 3 Gbps/tunnel 99.99% Yes
Direct Peering Direct to Google PoP 10 Gbps per link No SLA No
Carrier Peering Via partner to Google Varies by partner No SLA No
Dedicated Interconnect Direct physical to Google 10/100/400 Gbps (up to 3200 Gbps) 99.9%/99.99% Yes
Partner Interconnect Via partner to Google 50 Mbps–50 Gbps 99.9%/99.99% Yes
Cross-Cloud Interconnect Google to other cloud provider 10/100 Gbps 99.9%/99.99% Yes
Cross-Site Interconnect Between on-prem sites via Google 10/100 Gbps Yes L2 transparent

Google Cloud Hybrid Connectivity Certification Tips

  • HA VPN is the recommended option for encrypted connectivity over public internet; Classic VPN BGP is deprecated
  • For private RFC1918 connectivity, Dedicated or Partner Interconnect is required (peering does NOT provide private addressing)
  • Cross-Cloud Interconnect is the recommended option for multicloud private connectivity (Google ↔ AWS/Azure/OCI)
  • Network Connectivity Center enables hub-spoke topologies and site-to-site data transfer across Google’s backbone
  • MACsec provides link-layer encryption; HA VPN over Interconnect provides IPsec encryption for Interconnect traffic
  • Dedicated Interconnect requires colocation in Google PoP; Partner Interconnect does not
  • Minimum 2 connections in different edge availability domains for 99.9%; 4 connections for 99.99% SLA

See also: Google Cloud Networking Services Cheat Sheet

Google Cloud Data Transfer Services Overview

~ Last updated on : ~ jayendrapatil

Google Cloud Data Transfer Services

Google Cloud Data Transfer services provide various options in terms of network and transfer tools to help transfer data from on-premises to Google Cloud network.

📋 Last Updated: June 2026 — Updated with gcloud storage CLI (gsutil replacement), Storage Transfer Service event-driven transfers, Cross-Cloud Interconnect, Transfer Appliance data export, BigQuery Data Transfer Service new sources, Classic VPN dynamic routing deprecation, and Network Connectivity Center.

Network Services

Cloud VPN

  • Provides network connectivity with Google Cloud between on-premises network and Google Cloud, or from Google Cloud to another cloud provider.
  • Cloud VPN still routes the traffic through the Internet.
  • Cloud VPN is quick to set up (as compared to Interconnect)
  • Each Cloud VPN tunnel can support up to 3 Gbps total for ingress and egress, but available bandwidth depends on the connectivity. Bandwidth can be increased by adding more tunnels.
  • Choose Cloud VPN to encrypt traffic to Google Cloud, or with lower throughput solution, or experimenting with migrating the workloads to Google Cloud
  • HA VPN is the recommended VPN configuration offering a 99.99% SLA when configured with tunnels on both interfaces per Google best practices.
  • Classic VPN provides a 99.9% SLA. Note: Classic VPN dynamic routing (BGP) was deprecated on August 1, 2025. HA VPN must be used for BGP-based VPN connectivity.
  • HA VPN over Cloud Interconnect allows encrypting traffic traversing Dedicated or Partner Interconnect connections for additional security and compliance.
  • Cloud VPN supports customizable cipher options (Public Preview as of June 2025) allowing configuration of ciphers per security requirements.
  • Cloud Interconnect offers a direct connection to Google Cloud through Google or one of the Cloud Interconnect service providers.
  • Cloud Interconnect service prevents data from going on the public internet and can provide a more consistent throughput for large data transfers
  • For enterprise-grade connection to Google Cloud that has higher throughput requirements, choose Dedicated Interconnect (10 Gbps to 100 Gbps) or Partner Interconnect (50 Mbps to 50 Gbps)
  • Cloud Interconnect provides access to all Google Cloud products and services from your on-premises network except Google Workspace.
  • Cloud Interconnect also allows access to supported APIs and services by using Private Google Access from on-premises hosts.
  • Cross-Cloud Interconnect enables dedicated, private connectivity between Google Cloud and another cloud service provider (AWS, Azure, Oracle Cloud Infrastructure, Alibaba Cloud). This eliminates the need for traffic to traverse the public internet for multicloud architectures.
  • Partner Cross-Cloud Interconnect (available for AWS) provides an on-demand method for cross-cloud transport without manually setting up networking components.
  • Cross-Site Interconnect (GA 2025) is a transparent, on-demand Layer 2 connectivity solution leveraging Google’s global infrastructure for high-bandwidth connectivity between on-premises sites.
  • Direct Peering provides access to the Google network with fewer network hops than with a public internet connection
  • By using Direct Peering, internet traffic is exchanged between the customer network and Google’s Edge Points of Presence (PoPs), which means the data does not use the public internet.
  • Google does not offer a Service Level Agreement (SLA) with Direct Peering.
  • For SLA-backed connectivity, Cloud Interconnect (Dedicated or Partner) is recommended over Direct Peering.

Network Connectivity Center

  • Network Connectivity Center (NCC) is an orchestration framework that simplifies network connectivity using a hub-and-spoke model.
  • Supports three types of spokes: VPC spokes, Producer VPC spokes, and Hybrid spokes (HA VPN tunnels, Cloud Interconnect VLAN attachments, Router appliance VMs).
  • Enables site-to-cloud connectivity (external networks to Google Cloud) and site-to-site connectivity (using Google Cloud as enterprise WAN).
  • Supports up to 250 VPC spokes per hub and provides transitivity between workload VPCs.
  • Useful for managing complex multicloud and hybrid network topologies centrally.

Google Cloud Networking Services Decision Tree

Google Cloud Hybrid Connectivity

Transfer Services

gcloud storage (formerly gsutil)

⚠️ gsutil Deprecation Notice: gsutil is no longer the recommended CLI for Cloud Storage. Google recommends using gcloud storage commands in the Google Cloud CLI instead. gsutil does not support newer Cloud Storage features such as soft delete and managed folders. gcloud storage commands require less manual optimization and provide faster transfer rates.
  • gcloud storage (replacement for gsutil) is the standard tool for small- to medium-sized transfers (less than 1 TB) over a typical enterprise-scale network, from a private data center to Google Cloud.
  • gcloud storage provides all the basic features needed to manage Cloud Storage instances, including copying data to and from the local file system and Cloud Storage.
  • gcloud storage can also move, rename, and remove objects and perform real-time incremental syncs (similar to rsync) to a Cloud Storage bucket.
  • gcloud storage is especially useful in the following scenarios:
    • As-needed transfers or during command-line sessions by your users.
    • Transferring only a few files or very large files, or both.
    • Consuming the output of a program (streaming output to Cloud Storage).
    • Watching a directory with a moderate number of files and syncing any updates with very low latencies.
  • gcloud storage provides the following features:
    • Parallel multi-threaded transfers for increased transfer speeds.
    • Composite transfers for a single large file, breaking them into smaller chunks to increase transfer speed. Chunks are transferred and validated in parallel. Once the chunks arrive at Google, they are combined (composited) to form a single object.
    • Uses faster CRC32C hashing algorithm for data integrity checking (improved over gsutil’s crcmod).
  • Migration: Replace gsutil commands with equivalent gcloud storage commands. For example: gsutil cp → gcloud storage cp, gsutil rsync → gcloud storage rsync.
  • Storage Transfer Service is a fully managed, highly scalable service to automate transfers into Cloud Storage from multiple sources.
  • Supported Sources:
    • Amazon S3
    • S3-compatible storage (requires agents)
    • Microsoft Azure Blob Storage and Azure Data Lake Storage Gen2
    • Cloud Storage (bucket-to-bucket)
    • Publicly accessible HTTP/HTTPS URLs
    • On-premises file systems (POSIX-compliant, requires agents)
    • Hadoop Distributed File System (HDFS, requires agents)
  • Storage Transfer Service for Cloud-to-Cloud transfers:
    • Supports transfers from S3, Azure Blob Storage, and Cloud Storage without agents.
    • Supports daily copies of any modified objects.
  • Storage Transfer Service for on-premises data:
    • Is designed for large-scale transfers (up to petabytes of data, billions of files).
    • Supports full copies or incremental copies.
    • Can be set up by installing on-premises software (known as agents) onto computers in the data center.
  • Has a simple, managed graphical user interface; even non-technically savvy users (after setup) can use it to move data.
  • Provides robust error-reporting and a record of all files and objects that are moved.
  • Supports executing recurring transfers on a schedule.
  • Event-Driven Transfers (2025-2026):
    • Listens to event notifications to automatically transfer new or updated objects.
    • Supported for AWS S3 (via S3 Event Notifications to Amazon SQS).
    • Supported for Azure Blob Storage and Data Lake Storage Gen2 (via Azure Event Grid to Azure Storage Queues) — available since January 2026.
    • Supported for Cloud Storage (via Pub/Sub notifications).
  • Private Network Transfers (December 2025): Transfer data from AWS S3 or Azure Blob Storage to Cloud Storage over a private network connection using Cross-Cloud Interconnect or Partner Interconnect, optimizing costs and compliance.
  • Google-Managed Private Network for S3: Transfer from S3 over a Google-managed private network, eliminating AWS egress fees with a flat per-GiB rate.
  • AWS GovCloud Support (2026): Supports transfers from S3 buckets in us-gov-east-1 and us-gov-west-1 regions.
  • Organization Policy Constraints (February 2026): Custom organization policy constraints to control Storage Transfer Service usage (e.g., restrict sources or destinations).
  • Encrypts data in transit, supports VPC Service Controls, and uses checksums for data integrity.

Transfer Appliance

  • Transfer Appliance is an excellent option for performing large-scale transfers, especially when a fast network connection is unavailable, it’s too costly to acquire more bandwidth, or it’s a one-time transfer.
  • Expected turnaround time for a network appliance to be shipped, loaded with the data, shipped back, and rehydrated on Google Cloud is approximately 50 days.
  • Consider Transfer Appliance if the online transfer timeframe is calculated to be substantially more than this timeframe.
  • Transfer Appliance requires the ability to receive and ship back the Google-owned hardware.
  • Transfer Appliance is available only in certain countries.
  • Data Export (GA in US): Transfer Appliance now supports exporting data from Cloud Storage to the appliance, which is then shipped to you. This enables large-scale data egress from Google Cloud when network transfer is impractical.
  • gcloud CLI Support (Alpha): gcloud alpha transfer appliances commands allow viewing in-progress results, working with draft orders, and cloning existing orders.
  • Data is encrypted during upload, transit, after upload to Cloud Storage, and during download for data export.

BigQuery Data Transfer Service

  • BigQuery Data Transfer Service automates data movement into BigQuery on a scheduled, managed basis.
  • After a data transfer is configured, the BigQuery Data Transfer Service automatically loads data into BigQuery on a regular basis.
  • BigQuery Data Transfer Service can also initiate data backfills to recover from any outages or gaps.
  • BigQuery Data Transfer Service can only sink data to BigQuery and cannot be used to transfer data out of BigQuery.
  • Also supports dataset copies and scheduled queries within BigQuery.
  • BigQuery Data Transfer Service supports loading data from the following data sources:
    • Google SaaS Applications:
      • Google Ads
      • Google Ad Manager
      • Campaign Manager
      • Search Ads 360
      • Google Merchant Center
      • Google Play
      • YouTube Channel reports
      • YouTube Content Owner reports
      • Google Analytics 4 (GA4) — provides 12 daily partitioned tables reflecting UI reports
    • Cloud Storage — supports incremental and truncated write preferences
    • External cloud storage providers:
      • Amazon S3 (supports cross-cloud transfer)
    • Data warehouses:
      • Teradata
      • Amazon Redshift
    • Third-party connectors (2025):
      • Salesforce Sales Cloud
      • Salesforce Marketing Cloud (SFMC)
      • Facebook Ads
      • Adobe Analytics

Transfer Data vs Speed Comparison

Data Migration Speeds

Choosing the Right Transfer Method

Method Best For Data Size Network Requirement
gcloud storage Ad-hoc, small transfers < 1 TB Standard internet
Storage Transfer Service Recurring, large cloud-to-cloud or on-premises transfers TB to PB scale Available network (supports private network)
Transfer Appliance One-time massive transfers, limited bandwidth Hundreds of TB to PB Minimal (physical shipping)
BigQuery Data Transfer Service SaaS data ingestion into BigQuery Varies Standard internet

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 9 Gbps of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?
    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect
  2. An organization wishes to automate data movement from Software as a Service (SaaS) applications such as Google Ads and Google Ad Manager on a scheduled, managed basis. This data is further needed for analytics and generate reports. How can the process be automated?
    1. Use Storage Transfer Service to move the data to Cloud Storage
    2. Use Storage Transfer Service to move the data to BigQuery
    3. Use BigQuery Data Transfer Service to move the data to BigQuery
    4. Use Transfer Appliance to move the data to Cloud Storage
  3. Your company’s migration team needs to transfer 1PB of data to Google Cloud. The network speed between the on-premises data center and Google Cloud is 100Mbps. The migration activity has a timeframe of 6 months. What is the efficient way to transfer the data?
    1. Use BigQuery Data Transfer Service to transfer the data to Cloud Storage
    2. Expose the data as a public URL and Storage Transfer Service to transfer it
    3. Use Transfer Appliance to transfer the data to Cloud Storage
    4. Use gcloud storage command to transfer the data to Cloud Storage
  4. Your company uses Google Analytics for tracking. You need to export the session and hit data from a Google Analytics 360 reporting view on a scheduled basis into BigQuery for analysis. How can the data be exported?
    1. Configure a scheduler in Google Analytics to convert the Google Analytics data to JSON format, then import directly into BigQuery using bq command line.
    2. Use gcloud storage to export the Google Analytics data to Cloud Storage, then import into BigQuery and schedule it using Cron.
    3. Import data to BigQuery directly from Google Analytics using Cron
    4. Use BigQuery Data Transfer Service to import the data from Google Analytics
  5. A company needs to automatically transfer new files from an AWS S3 bucket to Cloud Storage as soon as they are created, with minimal latency. What is the most efficient approach?
    1. Schedule Storage Transfer Service to run every 15 minutes
    2. Use a Lambda function to call the Cloud Storage API on each new object
    3. Configure Storage Transfer Service event-driven transfers using S3 Event Notifications and Amazon SQS
    4. Use gsutil rsync with a cron job
  6. An organization wants to establish private, high-bandwidth connectivity between their Google Cloud environment and their AWS infrastructure for a multicloud application. Which service should they use?
    1. Cloud VPN with HA configuration
    2. Partner Interconnect
    3. Cross-Cloud Interconnect
    4. Direct Peering
  7. A company needs to transfer 500 TB of data from Azure Blob Storage to Cloud Storage while keeping all traffic off the public internet and maintaining dedicated bandwidth. What combination should they use?
    1. Storage Transfer Service over public internet
    2. Storage Transfer Service with private network transfer over Cross-Cloud Interconnect
    3. Transfer Appliance
    4. gcloud storage cp command
  8. Your organization wants to centrally manage connectivity between multiple VPC networks, on-premises sites, and other cloud providers using a hub-and-spoke model. Which Google Cloud service should you use?
    1. Cloud Router
    2. VPC Network Peering
    3. Shared VPC
    4. Network Connectivity Center

References

 

Google Cloud VPN – HA VPN & Classic VPN

~ Last updated on : ~ jayendrapatil

Google Cloud VPN

  • Cloud VPN securely extends the peer network to the Virtual Private Cloud (VPC) network through an IPsec VPN connection.
  • Traffic traveling between the two networks is encrypted by one VPN gateway and then decrypted by the other VPN gateway.
  • Cloud VPN protects the data as it travels over the internet.
  • Two instances of Cloud VPN can also be connected to each other.
  • Cloud VPN cannot be used to route traffic to the public internet; it is designed for secure communication between private networks.

Cloud VPN Types

  • Google Cloud offers two types of Cloud VPN gateways:
    • HA VPN – Recommended, high-availability with 99.99% SLA
    • Classic VPN – Legacy, 99.9% SLA, limited functionality

Cloud VPN Specifications

  • Each Cloud VPN gateway is a regional resource.
  • Only supports site-to-site IPsec VPN connectivity.
  • Does not support client-to-gateway scenarios i.e., Cloud VPN doesn’t support use cases where client computers need to “dial in” to a VPN by using client VPN software.
  • Only supports IPsec. Other VPN technologies (such as SSL VPN) are not supported.
  • Can be used with Private Google Access for on-premises hosts.
  • Each Cloud VPN gateway must be connected to another Cloud VPN gateway or a peer VPN gateway.
  • Peer VPN gateway must have a static external (internet routable) IPv4 address, needed to configure Cloud VPN.
  • Requires that the peer VPN gateway be configured to support prefragmentation. Packets must be fragmented before being encapsulated.
  • Each Cloud VPN tunnel supports up to 250,000 packets per second (pps) for the sum of ingress and egress traffic, equivalent to between 1 Gbps and 3 Gbps of bandwidth depending on average packet size.
  • Supports IKEv1 and IKEv2 by using an IKE pre-shared key (shared secret) and IKE ciphers. Only pre-shared key authentication is supported.
  • Supports generic routing encapsulation (GRE) traffic (GA since May 2021), enabling services like SASE and SD-WAN.
  • Uses replay detection with a window of 4096 packets (cannot be disabled).
  • Cloud VPN uses ESP in tunnel mode with authentication; does not support AH or ESP in transport mode.
  • Only ESP, UDP 500, and UDP 4500 traffic is permitted to Cloud VPN gateway addresses.

Cloud VPN Components

Google Cloud VPN Components

  • Cloud VPN gateway
    • A virtual VPN gateway running in Google Cloud managed by Google, using a specified configuration in the project, and used only by you.
    • Each Cloud VPN gateway is a regional resource that uses one or more regional external IP addresses.
    • A Cloud VPN gateway can connect to a peer VPN gateway.
  • Peer VPN gateway
    • A gateway that is connected to a Cloud VPN gateway.
    • A peer VPN gateway can be one of the following:
      • Another Cloud VPN gateway
      • A VPN gateway hosted by another cloud provider such as AWS or Microsoft Azure
      • An on-premises VPN device or VPN service
  • External VPN gateway
    • A gateway resource configured for HA VPN that provides information to Google Cloud about the peer VPN gateway or gateways.
  • Remote peer IP address
    • For an HA VPN gateway interface that connects to an external VPN gateway, the remote peer IP address is the IP address of the interface on the external VPN gateway that is used for the tunnel.
  • VPN tunnel
    • A VPN tunnel connects two VPN gateways and serves as a virtual medium through which encrypted traffic is passed.
  • Internet Key Exchange (IKE)
    • IKE is the protocol used for authentication and to negotiate a session key for encrypting traffic.

Classic VPN

⚠️ Classic VPN Dynamic Routing (BGP) Deprecated – August 1, 2025

Dynamic routing (BGP) for Classic VPN tunnels was deprecated on August 1, 2025.

Existing Classic VPN tunnels using BGP will continue to function but operate without an availability SLA and are no longer supported.

What remains supported:

  • Classic VPN tunnels using static routing from Classic VPN gateways to on-premises VPN gateways
  • Classic VPN tunnels using static routing from a Classic VPN gateway to a Compute Engine VM acting as a VPN gateway

Recommendation: Migrate to HA VPN for all production traffic requiring dynamic routing (BGP). HA VPN provides 99.99% SLA, IPv6 support, and is the only path for BGP functionality in Cloud VPN.

  • Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use static routing (policy-based or route-based) only.
  • Classic VPN provides an SLA of 99.9% service availability.
  • Classic VPN gateways don’t support IPv6.
  • Classic VPNs are referred to as target VPN gateways in the API documentation.

HA VPN (High Availability VPN)

  • HA VPN is the recommended Cloud VPN solution that securely connects the on-premises network to the VPC network through an IPsec VPN connection.
  • HA VPN provides an SLA of 99.99% service availability when configured with two interfaces and two external IP addresses.
  • When you create an HA VPN gateway, Google Cloud automatically chooses two external IP addresses, one for each of its interfaces. Each IP address is automatically chosen from a unique address pool to support high availability.
  • Each HA VPN gateway interface supports multiple tunnels. You can also create multiple HA VPN gateways.
  • Peer VPN gateway device must support dynamic (BGP) routing.
  • HA VPN supports only dynamic routing (BGP). Static routing is not supported with HA VPN.
  • HA VPN can connect two VPC networks in different regions (inter-region support added June 2024).
  • To achieve high availability when both VPN gateways are in VPC networks, two HA VPN gateways must be used, and both must be in the same region.
  • If the VPC network uses global dynamic routing mode, routes shared through the gateways can be in any region.
  • HA VPN supports connecting to Compute Engine VM instances with external IP addresses (GA Jan 2024).
  • Known as the vpn-gateway resource in the API (vs. target-vpn-gateway for Classic).
  • No forwarding rules required for HA VPN gateways; external IP addresses are created from a pool.

Google Cloud VPN HA

IPv6 Support in HA VPN

  • HA VPN supports dual-stack (IPv4 and IPv6) and IPv6-only gateways (GA since June 2024).
  • Classic VPN does not support IPv6.
  • HA VPN gateway stack types:
    • IPV4_ONLY – Supports only IPv4 traffic (default). Gateway gets IPv4 external addresses.
    • IPV4_IPV6 (Dual-stack) – Supports both IPv4 and IPv6 traffic. Gateway gets both IPv4 and IPv6 external addresses.
    • IPV6_ONLY – Supports only IPv6 traffic. Gateway gets IPv6 external addresses.
  • IKEv2 must be used to enable IPv6 traffic in HA VPN.
  • Dual-stack HA VPN uses Multiprotocol BGP (MP-BGP) sessions in Cloud Router to exchange both IPv4 and IPv6 routes.
  • Once created, the stack type of an HA VPN gateway cannot be modified; must delete and recreate.
  • When connecting two HA VPN gateways, both must use identical IP stack types.

Customizable Cipher Options

  • Cloud VPN supports customizable cipher options for VPN tunnels (GA since September 2025).
  • Cipher selection allows configuring ciphers for IKE SA negotiation (phase 1) and IPsec SA negotiation (phase 2).
  • Cipher selection is available only with IKEv2, not IKEv1.
  • Once configured, cipher options cannot be modified; the tunnel must be deleted and recreated.
  • If AEAD ciphers are specified for encryption, separate integrity ciphers cannot be specified.
  • Note: DH algorithm group 22 has been deprecated. Google is rolling out changes to prefer more secure cipher algorithms first.

Active/Active vs Active/Passive Routing Options

  • If a Cloud VPN tunnel goes down, it restarts automatically.
  • If an entire virtual VPN device fails, Cloud VPN automatically instantiates a new one with the same configuration.
  • The new gateway and tunnel connect automatically.
  • Active/Active
    • Effective aggregate throughput is the combined throughput of both tunnels.
    • Peer gateway advertises the peer network’s routes with identical MED values for each tunnel.
    • Egress traffic sent to the peer network uses equal-cost multipath (ECMP) routing.
    • If one tunnel becomes unavailable, Cloud Router withdraws the learned custom dynamic routes whose next hops are the unavailable tunnel, which can take ~40 seconds.
  • Active/Passive
    • Effective aggregate throughput is the individual throughput of each tunnel.
    • Peer gateway advertises the peer network’s routes with different MED values for each tunnel.
    • Egress traffic sent to the peer network uses the route with the highest priority, as long as the associated tunnel is available.
    • Peer gateway can only use the tunnel with the highest priority to send traffic to Google Cloud.
    • If one tunnel becomes unavailable, Cloud Router withdraws the learned custom dynamic routes whose next hops are the unavailable tunnel, which can take ~40 seconds.
  • Google Cloud recommends:
    • Using Active/Passive configuration with a single HA VPN Gateway as the observed bandwidth capacity at the time of normal tunnel operation matches the bandwidth capacity observed during failover.
    • Using Active/Active configuration with multiple HA VPN Gateways as the observed bandwidth capacity at the time of normal tunnel operation is twice that of the guaranteed bandwidth capacity.

HA VPN over Cloud Interconnect

  • HA VPN over Cloud Interconnect lets you encrypt the traffic that traverses Dedicated Interconnect or Partner Interconnect connections (GA since February 2023).
  • Deploys HA VPN tunnels over VLAN attachments to provide IPsec encryption alongside the increased capacity of Cloud Interconnect.
  • Network traffic never traverses the public internet since it uses Cloud Interconnect infrastructure.
  • Particularly valuable for Partner Interconnect where traffic passes through third-party providers, requiring IPsec encryption for data security and compliance.
  • Each HA VPN tunnel over Cloud Interconnect has a bandwidth of 3 Gbps.
  • HA VPN gateways associated with VLAN attachments can be assigned regional internal IP addresses.

Network Connectivity Center (NCC) Integration

  • Using Network Connectivity Center, HA VPN tunnels can connect on-premises networks together, passing traffic between them as a data transfer network.
  • Connect networks by attaching a pair of tunnels to an NCC spoke for each on-premises location, then connect each spoke to an NCC hub.

Classic VPN vs HA VPN

Google Cloud Classic VPN vs HA VPN

Feature HA VPN Classic VPN
SLA 99.99% (most topologies) 99.9%
Routing Dynamic (BGP) only Static only (BGP deprecated Aug 2025)
External IPs Auto-assigned from pool; no forwarding rules Must create external IPs and forwarding rules
Interfaces Two interfaces Single interface
IPv6 Supported (dual-stack and IPv6-only) Not supported
Two tunnels to same peer Supported Not supported
Connect to Compute Engine VMs Supported (recommended) Supported
API resource vpn-gateway target-vpn-gateway

Cloud VPN Monitoring

  • Cloud VPN provides predefined monitoring dashboards in the Google Cloud console for quick insight into system health and tunnel performance (GA since December 2025).
  • Displays key metrics for project-wide health and tunnel-specific diagnosis without manual configuration.
  • Cloud VPN supports Dead Peer Detection (DPD) per RFC 3706 to verify peer is alive. DPD interval is not configurable.
  • Network Topology visualization shows Cloud VPN gateways and VPN tunnels as entities.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company’s infrastructure is on-premises, but all machines are running at maximum capacity. You want to burst to Google Cloud. The workloads on Google Cloud must be able to directly communicate to the workloads on-premises using a private IP range. What should you do?
    1. In Google Cloud, configure the VPC as a host for Shared VPC.
    2. In Google Cloud, configure the VPC for VPC Network Peering.
    3. Create bastion hosts both in your on-premises environment and on Google Cloud. Configure both as proxy servers using their public IP addresses.
    4. Set up Cloud VPN between the infrastructure on-premises and Google Cloud.
  2. Your organization requires encryption for traffic between your on-premises data center and Google Cloud, and you already have a Dedicated Interconnect connection. Which solution should you implement?
    1. Create a Classic VPN tunnel over the Dedicated Interconnect.
    2. Deploy HA VPN over Cloud Interconnect to encrypt traffic on the VLAN attachments.
    3. Set up a separate VPN connection over the public internet.
    4. Use application-level TLS encryption only.
  3. You need to connect your on-premises network to Google Cloud VPC with a 99.99% availability SLA. Your on-premises VPN device supports BGP. What Cloud VPN type should you use?
    1. Classic VPN with dynamic routing
    2. Classic VPN with static routing
    3. HA VPN
    4. Classic VPN with policy-based routing
  4. Your company needs to support both IPv4 and IPv6 traffic over a VPN connection to Google Cloud. Which configuration should you choose?
    1. Classic VPN with IPv6 enabled
    2. HA VPN with dual-stack (IPV4_IPV6) stack type
    3. HA VPN with IPV4_ONLY stack type and MP-BGP
    4. Classic VPN with IKEv2
  5. You are configuring HA VPN tunnels for high availability. The peer gateway advertises routes with different MED values for each tunnel. What routing configuration is this?
    1. Active/Active with ECMP
    2. Active/Passive
    3. Static routing with priority
    4. Policy-based routing
  6. Which of the following statements about Classic VPN is TRUE as of August 2025? (Choose two)
    1. Classic VPN tunnels using static routing to on-premises gateways are still supported.
    2. Classic VPN supports dynamic routing (BGP) with full SLA.
    3. Classic VPN tunnels using BGP continue to function but without an availability SLA.
    4. Classic VPN supports IPv6 traffic.
    5. New Classic VPN tunnels with BGP can still be created.

Related Reads

References

Google Cloud Networking Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Virtual Private Cloud

  • Virtual Private Cloud (VPC) provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
  • VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
  • Subnets are regional resources and each subnet defines a range of IP addresses
  • IPv6 Support
    • VPC networks support dual-stack (IPv4 and IPv6) subnets in custom-mode VPC networks.
    • IPv6 functionality is available only in Premium Tier.
    • Supports both external (GUA – Globally Unique Addresses) and internal (ULA – Unique Local Addresses) IPv6 ranges.
    • VMs can have IPv4-only, dual-stack, or IPv6-only interfaces.
  • Cloud NGFW (Next Generation Firewall)
    • replaces legacy VPC firewall rules with network firewall policies.
    • protects workloads by applying controls at Layer 3, Layer 4, and Layer 7 of the network stack.
    • available in three tiers:
      • Essentials – rules based on IP ranges, ports, and protocols
      • Standard – adds FQDN objects, geo-location objects, and threat intelligence
      • Enterprise – adds Intrusion Detection and Prevention Service (IPS) powered by Palo Alto Networks, TLS inspection
    • Google recommends migrating from legacy VPC firewall rules to Cloud NGFW network firewall policies.
    • Network firewall policies can be attached to a single VPC or group of VPCs (unlike legacy VPC firewall rules which apply to a single VPC only).
  • Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
  • Private access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
  • Private Service Connect (PSC)
    • allows consumers to access managed services privately from inside their VPC network.
    • allows managed service producers to host services in their own separate VPC networks and offer a private connection to consumers.
    • creates service endpoints in consumer VPCs that provide private connectivity and policy enforcement.
  • Shared VPC to keep a VPC network in a common host project shared with service projects. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network
  • VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
  • VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
  • Primary and Secondary IP address cannot overlap with the on-premises CIDR
  • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Cloud Load Balancing

  • Cloud Load Balancing is a fully distributed, software-defined managed load balancing service
  • distributes user traffic across multiple instances of the applications and reduces the risk of performance issues by spreading the load
  • provides health checking mechanisms that determine if backends, such as instance groups and zonal network endpoint groups (NEGs), are healthy and properly respond to traffic.
  • supports IPv6 clients with Application Load Balancers and proxy Network Load Balancers.
  • Note: Google Cloud has renamed load balancer types. HTTP(S) Load Balancing is now Application Load Balancer, TCP/UDP Load Balancing is now passthrough Network Load Balancer, and SSL Proxy/TCP Proxy are now proxy Network Load Balancer.
  • supports multiple Cloud Load Balancing types
    • Internal Application Load Balancer (formerly Internal HTTP(S) Load Balancing)
      • is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
      • also available as a cross-region internal Application Load Balancer for multi-region backends with automatic failover.
      • supports a regional backend service, which distributes HTTP and HTTPS requests to healthy backends (either instance groups containing CE VMs or NEGs containing GKE containers).
      • supports path based routing
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
      • supports a regional health check that periodically monitors the readiness of the backends.
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
    • External Application Load Balancer (formerly External HTTP(S) Load Balancing)
      • is a global, proxy-based Layer 7 load balancer that enables running and scaling the services worldwide behind a single external IP address
      • distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
      • offers global (cross-regional) and regional load balancing
      • supports content-based load balancing using URL maps
      • preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
      • supports connection draining on backend services
      • has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
      • supports mutual TLS (mTLS) authentication for client certificate-based authentication.
    • Internal passthrough Network Load Balancer (formerly Internal TCP/UDP Load Balancing)
      • is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address
      • distributes traffic among VM instances in the same region in a Virtual Private Cloud (VPC) network by using an internal IP address.
      • provides high-performance, pass-through Layer 4 load balancer for TCP or UDP traffic.
      • routes original connections directly from clients to the healthy backends, without any interruption.
      • does not terminate SSL traffic and SSL traffic can be terminated by the backends instead of by the load balancer
      • provides access through VPC Network Peering, Cloud VPN or Cloud Interconnect
      • supports health check that periodically monitors the readiness of the backends.
    • External passthrough Network Load Balancer (formerly External TCP/UDP Network Load Balancing)
      • is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic originating from the internet to among VM instances in the same region
      • Load-balanced packets are received by backend VMs with their source IP unchanged.
      • Load-balanced connections are terminated by the backend VMs. Responses from the backend VMs go directly to the clients, not back through the load balancer (direct server return).
      • scope of a network load balancer is regional, not global. A network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
      • supports connection tracking table and a configurable consistent hashing algorithm to determine how traffic is distributed to backend VMs.
      • supports additional protocols like UDP, ESP, GRE, ICMP, and ICMPv6.
    • External proxy Network Load Balancer (formerly External SSL Proxy and TCP Proxy Load Balancing)
      • is a reverse proxy load balancer that distributes SSL or TCP traffic coming from the internet to VM instances in the VPC network.
      • with SSL traffic, user SSL (TLS) connections are terminated at the load balancing layer, and then proxied to the closest available backend instances by using either SSL (recommended) or TCP.
      • supports global load balancing service with the Premium Tier and regional load balancing service with the Standard Tier
      • is intended for non-HTTP(S) traffic. For HTTP(S) traffic, use Application Load Balancers.
      • supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer

Cloud CDN

  • Cloud CDN is Google Cloud’s web acceleration solution that caches website and application content closer to the user.
  • uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
  • works with the global external Application Load Balancer or the classic Application Load Balancer to deliver content to users
  • Cloud CDN content can be sourced from various types of backends
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
  • supports content targeting (GA) — enables device characterization and geo-targeting for responsive websites, language customization, and currency settings.
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
  • recommends
    • using versioning instead of cache invalidation
    • using custom keys to improve cache hit ratio
    • cache static content
  • Media CDN
    • is Google Cloud’s media delivery solution, complementing Cloud CDN.
    • optimized for high-throughput egress workloads, such as streaming video and large file downloads.
    • uses YouTube’s infrastructure to bring video streams (VoD and live) and large file downloads closer to users.
    • supports Cloud Armor edge security policies for DDoS protection.

Cloud VPN

  • securely connects the peer network to the VPC network or two VPCs through an IPsec VPN connection.
  • encrypts the data as it travels over the internet.
  • only supports site-to-site IPsec VPN connectivity and not client-to-gateway scenarios. Cannot be used to route traffic to the public internet.
  • allows users to access private RFC1918 addresses on resources in the VPC from on-prem computers also using private RFC1918 addresses.
  • can be used with Private Google Access for on-premises hosts
  • HA VPN
    • provides a high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
    • provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.
    • supports IPv6 (dual-stack) tunnels for both inner and outer IP addresses.
    • supports customizable cipher options for VPN tunnels.
  • Classic VPN
    • provides a 99.9% SLA.
    • Classic VPN dynamic routing (BGP) was deprecated on August 1, 2025. HA VPN is now the only option for BGP connectivity in Cloud VPN. Existing tunnels continue to function but without an availability SLA. If deleted, they cannot be recreated.
    • Does not support IPv6 traffic.
  • HA VPN over Cloud Interconnect
    • allows encrypting traffic traversing Dedicated or Partner Interconnect connections.
    • deploys HA VPN tunnels over VLAN attachments for additional security and compliance.
    • Each HA VPN tunnel has a bandwidth of 3 Gbps.
  • supports up to 3Gbps per tunnel with a maximum of 8 tunnels
  • supports static as well as dynamic routing using Cloud Router
  • supports IKEv1 or IKEv2 using a shared secret

Cloud Interconnect

  • Cloud Interconnect provides options for extending the on-premises network to the VPC networks in Google Cloud.
  • Dedicated Interconnect (Dedicated connection)
    • provides a direct physical connection between the on-premises network and Google’s network
    • requires your network to physically meet Google’s network in a colocation facility with your own routing equipment
    • supports only dynamic routing
    • supports 10 Gbps, 100 Gbps, and 400 Gbps circuits.
  • Partner Interconnect (Use a service provider)
    • provides connectivity between the on-premises and VPC networks through a supported service provider.
    • supports bandwidth from 50 Mbps minimum to 50 Gbps maximum.
    • provides Layer 2 and Layer 3 connectivity
      • For Layer 2 connections, you must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment
      • For Layer 3 connections, the service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
  • Cross-Cloud Interconnect
    • provides dedicated, private connectivity between Google Cloud and another cloud provider (AWS, Azure, OCI, Alibaba Cloud).
    • offers 10 Gbps or 100 Gbps managed, encrypted links.
    • supports security options such as IPsec VPN or MACsec.
    • Partner Cross-Cloud Interconnect (for AWS) provides an on-demand method for establishing cross-cloud transport without manually setting up networking components.
  • Cross-Site Interconnect
    • is a transparent, on-demand, Layer 2 connectivity solution between on-premises network sites.
    • leverages Google’s global infrastructure for high-performance and high-bandwidth connectivity.
  • Single Interconnect connection does not offer redundancy or high availability and its recommended to
    • use 2 in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
    • use 4 with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone)
    • Cloud Routers are required one in each Google Cloud region
  • Cloud Interconnect does not encrypt the connection between your network and Google’s network. For additional security, use HA VPN over Cloud Interconnect or application-level encryption.

Cloud Router

  • is a fully distributed, managed service that provides dynamic routing and scales with the network traffic.
  • works with both legacy networks and VPC networks.
  • isn’t supported for Direct Peering or Carrier Peering connections.
  • helps dynamically exchange routes between the Google Cloud networks and the on-premises network.
  • peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
  • Google Cloud recommends creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
  • supports following dynamic routing mode
    • Regional routing mode – provides visibility to resources only in the defined region.
    • Global routing mode – provides visibility to resources in all regions
  • is part of the Network Connectivity Center, which provides a hub-and-spoke model for managing connectivity across VPC networks, on-premises, and other clouds.

Network Connectivity Center

  • provides a hub-and-spoke model for managing network connectivity at scale.
  • enables site-to-site data transfer between on-premises locations through Google’s network.
  • supports VPC spokes, hybrid spokes (VPN/Interconnect), and router appliance spokes.
  • solves transitivity challenges through features like producer VPC spoke integration supporting Private Service Access (PSA) and Private Service Connect (PSC) propagation.
  • uses ECMP routing and BGP for route distribution between networks.

Cloud DNS

  • is a high-performance, resilient, reliable, low-latency, global DNS service that publishes the domain names to the global DNS in a cost-effective way.
  • With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
  • provides Private Zone which supports DNS services for a GCP project. VPCs in the same project can use the same name servers
  • supports DNS Forwarding for Private Zones, which overrides normal DNS resolution for the specified zones. Queries for the specified zones are forwarded to the listed forwarding targets.
  • supports DNS Peering, which allows sending requests for records that come from one zone’s namespace to another VPC network within GCP
  • supports DNS Outbound Policy, which forwards all DNS requests for a VPC network to the specified server targets. It disables internal DNS for the selected networks.
  • DNS Routing Policies
    • supports weighted round robin, geolocation, and failover routing policies.
    • can be configured with health checks for automatic failover.
    • supports internal passthrough Network Load Balancers and internal proxy Network Load Balancers as health checked targets.
  • Cloud DNS VPC Name Resolution Order
    • DNS Outbound Server Policy
    • DNS Forwarding Zone
    • DNS Peering
    • Compute Engine internal DNS
    • Public Zones
  • supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks

Related Posts