GCP

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 Peering – Direct & Carrier Peering

~ Last updated on : ~ jayendrapatil

Google Cloud Peering

📌 Important Updates (2025-2026):

  • Verified Peering Provider (VPP) — Google now recommends VPP over Direct Peering for most customers (launched 2024).
  • Google Peering Policy Change — Google moved from an “Open” to a “Selective” peering policy in early 2025, preferring 100G PNIs.
  • Pricing Changes — Effective May 1, 2026, pricing adjustments apply to Direct Peering, Carrier Peering, and CDN Interconnect data transfer out.
  • Cloud WAN — Announced at Google Cloud Next ’25 as a fully managed enterprise WAN solution leveraging Google’s global network.

Direct Peering

  • Direct Peering establishes a direct peering connection between the on-premises network and Google’s edge network and exchanges high-throughput cloud traffic.
  • Direct Peering provides a direct path from the on-premises network to Google services, including Google Cloud products that can be exposed through one or more public IP addresses.
  • Traffic from Google’s network to the on-premises network also takes that direct path, including traffic from VPC networks in the projects.
  • Google Cloud customers must request that direct egress pricing be enabled for each of the projects after they have established Direct Peering with Google.
  • Direct Peering exists outside of Google Cloud.
  • Unless you need to access Google Workspace applications, the recommended methods of access to Google Cloud are Dedicated Interconnect or Partner Interconnect.
  • Direct Peering doesn’t produce any custom routes in a VPC network.
  • Direct Peering does not provide any SLA. For customers who need an SLA, Google recommends Cloud Interconnect.
  • Direct Peering helps reduce Internet egress rates to on-premises network from GCP resources.
  • Google now recommends using a Verified Peering Provider (VPP) instead of Direct Peering for most Google Cloud customers.
  • Google recommends customers who do not use a VPP to privately peer with Google using a private network interconnect (PNI), requiring physical redundancy with at least two separate connections in a single metropolitan area.
  • Direct Peering is available at more than 100 locations in 33 countries.

Carrier Peering

  • Carrier Peering helps access Google applications, such as Google Workspace, by using a service provider to obtain enterprise-grade network services that connect your infrastructure to Google.
  • Carrier Peering exists outside of Google Cloud.
  • Carrier Peering doesn’t produce any custom routes in a VPC network.
  • Carrier Peering does not provide any SLA.
  • Google recommends using Cloud Interconnect instead of Direct Peering, Carrier Peering, and Verified Peering Provider for accessing Google Cloud (these are used only in certain circumstances).

Verified Peering Provider (VPP)

  • Verified Peering Provider (VPP) is a program launched in 2024 that identifies ISPs with demonstrated diverse and reliable connectivity to Google.
  • VPP is a simpler alternative to Direct Peering — the provider manages all aspects of the peering arrangements with Google.
  • Google recommends connecting through a Verified Peering Provider to reach publicly available Google Cloud resources.
  • Customers using a VPP do not need to meet Google’s Direct Peering requirements (no need for ASN, /24 address space, etc.).
  • VPP has two badge tiers based on technical criteria:
    • Silver — Points of Presence (PoPs) redundancy
    • Gold — Metropolitan-level redundancy (connectivity to Google in multiple distinct metros)
  • VPPs must maintain redundant and physically diverse connectivity to Google’s network.
  • Google periodically validates enrolled providers against program requirements.
  • Google does not offer an SLA for VPP, but the provider may offer an SLA on their network prior to traffic handoff to Google.
  • VPP provides access to all Google services reachable over the internet, including Google Workspace, Cloud APIs, Cloud VPN, public IP addresses, and Network Service Tiers.
  • VPPs can be viewed at the Google Edge Network.

Google Cloud Peering Policy Change (2025)

  • In early 2025 (between Feb-Mar 2025), Google changed from an “Open peering policy” to a “Selective peering policy.”
  • Google no longer does bilateral peering over an Internet Exchange Point (IXP) with new networks.
  • Google now prefers 100G Private Network Interconnects (PNIs) with networks having at least 10 Gbps peak traffic flow (Google → other network direction).
  • This makes Direct Peering harder to establish for smaller networks, further pushing customers toward VPP or Cloud Interconnect.

Cloud WAN (Announced 2025)

  • Cloud WAN was announced at Google Cloud Next ’25 (April 2025) as part of Cross-Cloud Network.
  • Cloud WAN is a fully managed, reliable, and secure enterprise backbone solution to transform enterprise WAN architectures.
  • Provides up to 40% faster performance compared to the public internet.
  • Offers up to 40% savings in total cost of ownership (TCO) over customer-managed WAN solutions.
  • Leverages Google’s global network spanning 2 million miles of lit fiber, 33 subsea cables, and 202 network edge locations.
  • Components include:
    • Network Connectivity Center (NCC) — Hub for managing hybrid connectivity
    • NCC Gateway — Regionally managed spoke that integrates cloud-native security services (e.g., third-party SSE solutions)
    • Cloud Interconnect — Direct, low-latency links from on-premises to Google Cloud
    • Cross-Cloud Interconnect — Multicloud connections (AWS, Azure, Oracle)
    • Cross-Site Interconnect — Layer 2 connectivity between on-premises sites (GA in 2025)
    • Verified Peering Providers — Simplified internet connectivity to Google

Peering Requirements (Direct Peering)

  • Publicly routable ASN
  • Publicly routable address space (at least one /24 of IPv4 and/or one /48 of IPv6 space)
  • ASN record completed in PeeringDB
  • 24×7 NOC contact
  • Presence at one or more internet exchanges or private peering interconnection facilities listed for Google in PeeringDB
  • Up to date Maintainer, ASN, AS-SET, and Route/Route6 objects in an internet routing registry (IRR) used by Google
  • New (2025): Google now prefers 100G PNIs with at least 10 Gbps traffic flow; physical redundancy with at least two connections in a metro area is required for private peering.

Network Connectivity Comparison

Feature Direct Peering Carrier Peering Verified Peering Provider Dedicated Interconnect
Connection type Direct to Google Edge Via service provider Via verified ISP Direct physical link
Scope Outside Google Cloud Outside Google Cloud Outside Google Cloud Google Cloud product
SLA No No No (provider may offer) Yes (99.9%/99.99%)
VPC routes No custom routes No custom routes No custom routes Yes
Requirements ASN, /24 IPv4, NOC, PeeringDB Service provider contract ISP contract only Colocation facility
Google recommendation Use VPP instead Use Cloud Interconnect Recommended for public access Recommended for Google Cloud

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. You want to establish a dedicated connection to Google that can access Cloud SQL via a public IP address and that does not require a third-party service provider. Which connection type should you choose?
    1. Carrier Peering
    2. Direct Peering
    3. Dedicated Interconnect
    4. Partner Interconnect
  2. A company wants to access Google Cloud services over the internet but does not have the technical capability to manage Direct Peering with Google. What does Google recommend?
    1. Carrier Peering
    2. Partner Interconnect
    3. Verified Peering Provider
    4. Cloud VPN
  3. Which of the following are requirements for establishing Direct Peering with Google? (Choose 3)
    1. Publicly routable ASN
    2. 24×7 NOC contact
    3. Cloud Interconnect VLAN attachment
    4. At least one /24 of IPv4 address space
    5. Google Cloud project with billing enabled
  4. What is the key advantage of using a Verified Peering Provider (VPP) over Direct Peering?
    1. VPP provides an SLA backed by Google
    2. VPP removes the need to meet Google’s Direct Peering requirements
    3. VPP provides private IP connectivity to VPC networks
    4. VPP creates custom routes in VPC networks
  5. A company needs a connection to Google Cloud with an SLA guarantee. Which option should they choose?
    1. Direct Peering
    2. Carrier Peering
    3. Verified Peering Provider
    4. Cloud Interconnect (Dedicated or Partner)
  6. Which of the following statements about Google’s peering options is correct? (Choose 2)
    1. Direct Peering, Carrier Peering, and VPP all exist outside of Google Cloud
    2. Carrier Peering produces custom routes in a VPC network
    3. None of the peering options (Direct, Carrier, VPP) provide an SLA from Google
    4. Direct Peering requires a service provider contract

References

Cloud Interconnect – Dedicated vs Partner, Setup & Pricing

~ Last updated on : ~ jayendrapatil

Google Cloud Interconnect

  • Google Cloud Interconnect provides low-latency, high-availability connections that enable reliable data transfer between networks.
  • Cloud Interconnect offers the following options for extending the network:
    • Dedicated Interconnect – provides a direct physical connection between the on-premises network and Google’s network.
    • Partner Interconnect – provides connectivity between the on-premises and VPC networks through a supported service provider.
    • Cross-Cloud Interconnect – provides dedicated connectivity between Google Cloud and another cloud service provider (AWS, Azure, OCI, Alibaba Cloud).
    • Cross-Site Interconnect – provides Layer 2 connectivity between on-premises network sites using Google’s global network.
  • Cloud Interconnect provides access to all Google Cloud products and services from the 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.
  • Traffic between networks doesn’t traverse the public internet, reducing points of failure and improving latency.
  • VPC network’s internal IP addresses are directly accessible from on-premises without NAT or VPN tunnels.

Dedicated Interconnect

  • Dedicated Interconnect provides direct physical connections between the on-premises network and Google’s network.
  • Dedicated Interconnect enables the transfer of large amounts of data between networks, which can be more cost-effective than purchasing additional bandwidth over the public internet.
  • Dedicated Interconnect requires your network to physically meet Google’s network in a colocation facility with your own routing equipment.
  • Dedicated Interconnect supports only dynamic routing.
  • Dedicated Interconnect supports the following link types:
    • 10 Gbps circuits (single mode fiber, 10GBASE-LR)
    • 100 Gbps circuits (single mode fiber, 100GBASE-LR4)
    • 400 Gbps circuits (single mode fiber, 400GBASE-LR4) – GA March 2026
  • VLAN attachments support maximum bandwidths up to 400 Gbps (GA March 2026).
  • VLAN attachment should be associated with a Cloud Router.
  • Cloud Router creates a BGP session for the VLAN attachment and its corresponding on-premises peer router.
  • Cloud Router receives the routes that the on-premises router advertises. These routes are added as custom dynamic routes in the VPC network.
  • Cloud Router also advertises routes for Google Cloud resources to the on-premises peer router.
  • Supports IPv6 traffic exchange between IPv6-enabled VPC network and on-premises network.

Google Cloud Dedicated Interconnect

Dedicated Interconnect Provisioning

  • Find a collocation facility with GCP Point of Presence (PoP) which offers Direct Interconnect connections.
  • Order an Interconnect connection so that Google can allocate the necessary resources and send a Letter of Authorization and Connecting Facility Assignment (LOA-CFA).
  • LOA-CFA is sent via email to NOC (technical contact) or can be downloaded from the Google Cloud console.
  • Submit the LOA-CFA to the vendor so that they can provision the Interconnect connections between Google’s network and your network.
  • Configure and test the connections with Google before you can use them.
  • Create VLAN attachments to allocate a VLAN on the connection.
  • Configure the on-premises router to establish a BGP session with the Cloud Router.

Dedicated Interconnect Redundancy

  • Single Dedicated Interconnect connection does not offer redundancy or high availability.
  • Google 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.
  • Redundant Interconnect connection with 2 connections must be created in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
  • Redundant Interconnect connection with 4 connections must be created with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone).
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.
  • A single-region Critical production SLA (99.99%) topology is now available (GA June 2026), allowing 99.99% availability within a single region.

Google Cloud Dedicated Interconnect Redundancy

Partner Interconnect

  • Partner Interconnect provides connectivity between the on-premises network and the VPC network through a supported service provider.
  • A Partner Interconnect connection is useful if the data center is in a physical location that can’t reach a Dedicated Interconnect colocation facility, or the data needs don’t warrant an entire 10-Gbps connection.
  • Partner Interconnect supports bandwidth from 50 Mbps minimum to 50 Gbps maximum per VLAN attachment.
  • Service providers have existing physical connections to Google’s network that they make available for their customers to use.
  • After the connectivity with a service provider is established, a Partner Interconnect connection from the service provider can be requested.
  • After the service provider provisions the connection, you can start passing traffic between your networks by using the service provider’s network.
  • Partner Interconnect 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.
      • BGP configuration information is provided by the VLAN attachment after your service provider has configured it.
    • For Layer 3 connections:
      • The service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
      • You don’t need to configure BGP on the on-premises router. Google and the service provider automatically set the correct configuration.
  • Supports IPv6 traffic exchange between IPv6-enabled VPC network and on-premises network.

Google Cloud Partner Interconnect

Partner Interconnect Provisioning

  • Connect the on-premises network to a supported service provider.
  • Create a VLAN attachment for a Partner Interconnect connection in the Google Cloud project, which generates a unique pairing key that must be used to request a connection from the service provider.
  • Activate the connection.
  • Depending on the connection, either you or your service provider then establishes a Border Gateway Protocol (BGP) session.
  • Partner Interconnect provisioning does not require LOA-CFA.

Partner Interconnect Redundancy

  • Single Partner Interconnect connection does not offer redundancy or high availability.
  • 99.9% availability requires:
    • At least two VLAN attachments in a single Google Cloud region, in separate edge availability domains (metro availability zones).
    • At least one Cloud Router, connected to both VLAN attachments.
  • 99.99% availability requires:
    • At least four VLAN attachments across two metros, one in each edge availability domain (metro availability zone).
    • Two Cloud Routers (one in each Google Cloud region of a VPC network).
    • Associate one Cloud Router with each pair of VLAN attachments.
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.

Google Cloud Dedicated Interconnect Redundancy - Layer 2

Cross-Cloud Interconnect

  • Cross-Cloud Interconnect provides high-bandwidth dedicated connectivity between Google Cloud and another cloud service provider.
  • Supported cloud providers include Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud Infrastructure (OCI), and Alibaba Cloud.
  • Provides private, SLA-backed connectivity without traversing the public internet.
  • Available connection capacities: 10 Gbps, 100 Gbps, and 400 Gbps (GA March 2026).
  • Google provisions and manages the physical connections from Google to the remote cloud provider.
  • Supports traffic differentiation through application awareness (GA September 2025).
  • Use cases:
    • Multicloud deployments requiring private connectivity between clouds.
    • Data replication and disaster recovery across cloud providers.
    • Distributed applications spanning multiple clouds.

Partner Cross-Cloud Interconnect

  • Partner Cross-Cloud Interconnect for AWS (GA April 2026) provides an on-demand, reliable method for establishing cross-cloud transport without manually setting up networking components.
  • Provides region-to-region transport with SLA-protected, coordinated underlay built with AWS.
  • Can be set up on-demand and sized up or down based on needs.
  • Supports both VPC Network Peering and Network Connectivity Center (NCC) connectivity models.
  • Partner Cross-Cloud Interconnect for OCI provides on-demand connections with variable speed options (1 Gbps to 50 Gbps).

Cross-Site Interconnect

  • Cross-Site Interconnect (Preview, April 2025) provides reliable, high-bandwidth Layer 2 connectivity between on-premises network sites using Google’s global network.
  • A transparent, on-demand, Layer 2 connectivity solution that leverages Google’s global infrastructure.
  • Supports 10 Gbps and 100 Gbps connections.
  • Supports an MTU size of 9,000 bytes for cross-site networks.
  • Use cases:
    • Site-to-site connectivity between on-premises locations.
    • Simplifying WAN infrastructure for high-performance and high-bandwidth connectivity.
    • Improving reliability posture across the WAN.
  • Provisioning requires LOA-CFA similar to Dedicated Interconnect.
  • Available in multiple colocation facilities globally (Singapore, Dallas, Miami, Melbourne, Taipei, Stockholm, etc.).

Cloud Interconnect Security

  • Cloud Interconnect does not encrypt the connection between your network and Google’s network by default.
  • Multiple encryption options are now available:
    • HA VPN over Cloud Interconnect – Deploys IPsec-encrypted HA VPN tunnels over VLAN attachments. Supported for both Dedicated Interconnect and Partner Interconnect. Each HA VPN tunnel provides up to 3 Gbps bandwidth.
    • MACsec for Cloud Interconnect – Uses IEEE 802.1AE MACsec standard to encrypt traffic between your on-premises router and Google’s edge routers. Available for 100 Gbps and 400 Gbps links regardless of location; for 10 Gbps links, availability varies by location.
    • Application-level encryption or your own VPN for additional security.
  • HA VPN over Cloud Interconnect helps maintain compliance with industry regulations requiring encryption of outgoing traffic or data in transit.

MACsec for Cloud Interconnect

  • MACsec encrypts traffic at the Layer 2 (data link) level between your on-premises router and Google’s edge routers.
  • MACsec doesn’t provide encryption in transit within Google’s network. For stronger security, combine with IPsec or TLS.
  • Supports two security modes:
    • Fail open (must-secure) – If MACsec session can’t be established, link operates without encryption.
    • Fail closed – If MACsec session can’t be established, the link fails (drops all traffic).
  • Available for 100 Gbps and 400 Gbps links regardless of location.
  • Uses pre-shared keys to encrypt traffic transiting between routers.

HA VPN over Cloud Interconnect

  • Establishes encrypted HA VPN tunnels over Cloud Interconnect VLAN attachments.
  • Supported for both Dedicated Interconnect and Partner Interconnect.
  • Each HA VPN tunnel provides up to 3 Gbps bandwidth.
  • Provides IPsec encryption at the IP layer (Layer 3).
  • Requires a Cloud Router with encrypted_interconnect_router = true.
  • Can reserve regional internal IP ranges for HA VPN gateway interfaces.

Traffic Differentiation (Application Awareness)

  • Dedicated Interconnect and Cross-Cloud Interconnect support network traffic differentiation through application awareness (GA September 2025).
  • Lets you map outbound traffic to different traffic classes.
  • Supports bandwidth percentage policy or strict priority policy for traffic prioritization.
  • Uses Differentiated Services Field Codepoint (DSCP) in IP headers for traffic differentiation.
  • Managed traffic classification (Preview April 2026) automates DSCP bit assignment in outgoing packets.
  • Contact your account team to enable application awareness.

Dedicated Interconnect vs Partner Interconnect

  • Choosing between Dedicated Interconnect vs Partner Interconnect, consider the connection requirements, such as the connection location and capacity:
    • If you can’t physically meet Google’s network in a colocation facility to reach your VPC networks, use Partner Interconnect to connect through service providers.
    • If you have high bandwidth needs (up to 400 Gbps per link), Dedicated Interconnect can be a cost-effective solution.
    • If you require lower bandwidth (50 Mbps to 50 Gbps), Partner Interconnect provides flexible options through service providers.
    • If you need connectivity to another cloud provider, use Cross-Cloud Interconnect or Partner Cross-Cloud Interconnect.

Cloud Interconnect MTU

  • Cloud Interconnect VLAN attachments support the following MTU sizes:
    • 1,440 bytes
    • 1,460 bytes
    • 1,500 bytes
    • 8,896 bytes
  • Cross-site networks support an MTU size of 9,000 bytes.

Connection Groups and SLA

  • Interconnect connection groups and VLAN attachment groups (GA June 2025) help communicate intended reliability levels.
  • Reliability options:
    • Critical production – 99.99% uptime SLA for maximum resiliency.
    • Non-critical production – 99.9% uptime SLA for non-critical workloads.
    • No SLA – No uptime guarantee (not recommended for production).
  • Resource groups provide feedback on how Cloud Interconnect resources meet the intended level of reliability.

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 has decided to build a backup replica of their on-premises user authentication PostgreSQL database on Google
    Cloud Platform. The database is 4 TB, and large updates are frequent. Replication requires private address space communication.
    Which networking approach should you use?

    1. Google Cloud Dedicated Interconnect
    2. Google Cloud VPN connected to the data center network
    3. A NAT and TLS translation gateway installed on-premises
    4. A Google Compute Engine instance with a VPN server installed connected to the data center network
  2. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 20 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
  3. 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
  4. A company needs to establish private connectivity between their Google Cloud environment and their AWS environment for a multicloud application. They require high bandwidth and an SLA. Which connectivity option should they use?
    1. Cloud VPN with AWS Site-to-Site VPN
    2. Partner Interconnect through a shared service provider
    3. Cross-Cloud Interconnect
    4. Dedicated Interconnect with VPN tunnels to AWS
  5. An organization requires encrypted traffic over their Dedicated Interconnect connection to meet regulatory compliance requirements. What is the recommended approach?
    1. Use a third-party VPN appliance on a Compute Engine instance
    2. Deploy HA VPN over Cloud Interconnect
    3. Enable Cloud Armor on the Interconnect
    4. Use application-level TLS only
  6. A company wants to connect two of their on-premises data centers using Google’s global network for high-bandwidth, low-latency Layer 2 connectivity. Which Google Cloud service should they use?
    1. Cloud VPN
    2. Dedicated Interconnect
    3. Network Connectivity Center
    4. Cross-Site Interconnect
  7. Which encryption options are available for Cloud Interconnect traffic? (Choose TWO)
    1. MACsec for Cloud Interconnect
    2. Cloud Armor DDoS protection
    3. HA VPN over Cloud Interconnect
    4. Cloud KMS envelope encryption
    5. Identity-Aware Proxy
  8. A company needs an on-demand, managed connection between Google Cloud and AWS without setting up physical infrastructure or colocation facilities. Which service should they use?
    1. Cross-Cloud Interconnect
    2. Dedicated Interconnect with AWS Direct Connect
    3. Partner Cross-Cloud Interconnect for AWS
    4. Cloud VPN with AWS Site-to-Site VPN

Google Cloud DNS – Managed Authoritative DNS

~ Last updated on : ~ jayendrapatil

Google Cloud DNS

  • Cloud DNS is a high-performance, resilient, reliable, low-latency, global Domain Name System (DNS) service that publishes the domain names to the global DNS in a cost-effective way.
  • Cloud DNS helps to publish the zones and records in DNS without the burden of managing your own DNS servers and software.
  • Cloud DNS offers both public zones and private managed DNS zones.
    • A public zone is visible to the public internet
    • A private zone is visible only from one or more specified VPC networks
    • Google Cloud also creates internal DNS names for VMs automatically, even if you do not use Cloud DNS
  • Cloud DNS also supports zonal DNS zones (GA since Dec 2022) that are scoped to a specific Google Cloud zone, providing higher availability for zonal resources.
  • With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
  • Google Cloud offers inbound and outbound DNS forwarding for private zones
  • Cloud DNS offers DNS forwarding zones and DNS server policies to allow lookups of DNS names between the on-premises and Google Cloud environment
  • Cloud DNS supports per-resource IAM permissions (GA since Dec 2022) allowing fine-grained read, write, or administrator permissions for different managed zones under the same project.
  • Cloud DNS supports Cloud Logging for both private and public zones (GA since Nov 2021) to monitor DNS queries, including query name, type, response code, and source IP address.

DNS Server Policies

  • DNS Server Policies can specify inbound DNS forwarding, outbound DNS forwarding, or both.
  • Inbound server policy refers to a policy that permits inbound DNS forwarding i.e. On-premises to VPC
  • Outbound server policy refers to one possible method for implementing outbound DNS forwarding i.e. VPC to On-premises
  • It is possible for a policy to be both an inbound server policy and an outbound server policy if it implements the features of both.
  • DNS Server Policies is similar to DNS Forwarding zones, except that it applies to all the traffic and not a single specific domain
  • DNS Outbound Policy disables internal DNS for the selected networks
  • DNS Server Policies also support DNS64 configuration to enable IPv6-only VM instances to communicate with IPv4-only destinations (see DNS64 section below).

DNS Forwarding Zones

  • Cloud DNS forwarding zones help configure target name servers for specific private zones.
  • Using a forwarding zone is one way to implement outbound DNS forwarding from the VPC network.
  • A Cloud DNS forwarding zone is a special type of Cloud DNS private zone. Instead of creating records within the zone, you specify a set of forwarding targets.
  • Each forwarding target is an IP address of a DNS server, located in the VPC network, or in an on-premises network connected to the VPC network by Cloud VPN or Cloud Interconnect.
  • Forwarding targets can also be specified as a fully qualified domain name (FQDN) (GA since June 2025), which allows outbound DNS forwarding without requiring a fixed IP address for the target name server.
  • Cloud DNS caches responses for queries sent to Cloud DNS forwarding zones
  • DNS forwarding does not work between two Google Cloud environments

DNS Peering

  • DNS peering allows sending requests for records that come from one zone’s namespace to another VPC network for e.g., a SaaS provider can give a SaaS customer access to DNS records it manages.
  • To provide DNS peering,
    • Cloud DNS peering zone must be created and configured to perform DNS lookups in a VPC network where the records for that zone’s namespace are available.
    • The VPC network where the DNS peering zone performs lookups is called the DNS producer network.
  • To use DNS peering,
    • A network must be authorized to use a peering zone.
    • The VPC network authorized to use the peering zone is called the DNS consumer network.
  • DNS peering and VPC Network Peering are different services. DNS peering can be used with VPC Network Peering, but VPC Network Peering is NOT required for DNS peering. VPC peering does not enable DNS peering and must be setup explicitly.

Cloud DNS Forwarding and Peering

DNS Routing Policies

  • Cloud DNS supports DNS routing policies (GA since Jan 2022) to steer traffic based on specific criteria for resource record sets in both private and public zones.
  • Cloud DNS supports the following routing policy types:
    • Weighted Round Robin (WRR) – assign different weights to each resource record set for a DNS name to distribute traffic according to configured weights. Supports manual active-active or active-passive configurations.
    • Geolocation – map traffic originating from source geographies (Google Cloud regions) to specific DNS targets. Applies nearest match when source doesn’t exactly match a policy item.
    • Geolocation with Geofence – restricts traffic to a specific geolocation even if all endpoints in that region are unhealthy (prevents automatic failover to next closest region).
    • Failover – active/backup configurations for high availability. Returns IP addresses from the active set normally; switches to backup set when all active endpoints are unhealthy.
  • DNS routing policies cannot be configured for forwarding zones, peering zones, managed reverse lookup zones, or Service Directory zones.
  • Cloud DNS supports health checks with routing policies for:
    • Internal Application Load Balancers (regional and cross-region)
    • Internal passthrough Network Load Balancers
    • Internal proxy Network Load Balancers (Preview)
    • External endpoints (GA since Feb 2025) – health checks for any public IP address including global/regional external load balancers and on-premises endpoints
  • Cloud DNS enables automatic failover when endpoints fail their health checks, dynamically adjusting traffic split among remaining healthy endpoints.
  • For external endpoint health checks, probes originate from three user-specified Google Cloud source regions with three prober instances per region (nine total probers per endpoint).
  • If all endpoints are unhealthy, Cloud DNS returns all endpoints as a result (fail-open behavior).

DNS Response Policies

  • Response policies (GA since Nov 2021) let you customize DNS management within a private zone by using rules instead of records.
  • If a rule in the response policy affects the incoming query, it is processed; otherwise, the lookup proceeds normally.
  • Response policy rules are selectors that apply behavior to queries matching the selector (DNS names via wildcards or exact matches).
  • Use cases include:
    • Setting up private connectivity to Google APIs from within a VPC Service Controls perimeter
    • Overriding DNS resolution for specific domains within a VPC network
    • Blocking access to specific domains by returning NXDOMAIN
    • Redirecting traffic to alternative endpoints for specific DNS names
  • Response policies can be bound to VPC networks and GKE clusters.

Alias Records

  • Alias records (GA since Sept 2025) provide CNAME-like functionality at the zone apex.
  • This custom record type maps the apex domain name to a canonical target, solving the limitation that CNAME records cannot coexist with other record types (like SOA) required at the zone apex.
  • Useful when you need to point a naked/apex domain (e.g., example.com) to a load balancer or CDN hostname without using a CNAME.
  • Similar in concept to AWS Route 53 Alias records.

DNS64

  • DNS64 (GA since Aug 2025) provides synthesized IPv6 addresses for IPv4 destinations, enabling IPv6-only VM instances to communicate with IPv4-only services.
  • DNS64 is configured as part of a DNS server policy and applies to VPC networks bound to the policy.
  • When an IPv6-only client queries for a domain that only has A records (IPv4), Cloud DNS synthesizes AAAA records (IPv6) using the 64:ff9b::/96 well-known prefix.
  • Works together with Cloud NAT’s NAT64 to provide end-to-end IPv6-to-IPv4 connectivity.
  • Useful for IPv6-only environments that need to reach legacy IPv4 applications on the internet.

DNS Armor – Advanced Threat Detection

  • DNS Armor (GA since Jan 2026), powered by Infoblox, is a fully-managed DNS-layer security service for Google Cloud workloads.
  • Monitors internet-bound DNS queries for malicious activity at the earliest point in the attack chain—the DNS query—without adding operational complexity or performance overhead.
  • Detects threats including:
    • Requests to malicious command and control (C2) servers
    • DNS tunneling for sensitive data exfiltration
    • Malware using DNS queries for communication
  • Complements existing cloud-first network security products (Cloud Armor, Cloud NGFW) by offering a foundational DNS-based security layer.
  • Threat findings are reported in Cloud Logging for integration with security operations workflows.

VPC Name Resolution Order

  • Each VPC network provides DNS name resolution services to the VM instances that use it.
  • When VMs use their metadata server 169.254.169.254 as their name server, Google Cloud searches for DNS records in the following order:
    • If the VPC network has an outbound server policy, Google Cloud forwards all DNS queries to those alternative servers. The VPC name resolution order consists only of this step.
    • If the VPC network does not have an outbound server policy:
      • Google Cloud tries to find a private zone that matches as much of the requested record as possible (longest suffix matching).
        • Searching records that you created in private zones.
        • Querying the forwarding targets for forwarding zones.
        • Querying the name resolution order of another VPC network by using peering zones.
      • Searches the automatically created Compute Engine internal DNS records for the project.
      • Queries publicly available zones

DNSSEC

  • DNSSEC is a feature of DNS that authenticates responses to domain name lookups
  • DNSSEC protects the domains from spoofing and cache poisoning attacks
  • DNSSEC provides strong authentication for domain lookups, but it does not provide encryption
  • Both the registrar and registry must support DNSSEC for the Top Level Domain (TLD) used
  • For Enabling DNSSEC
    • Enable DNSSEC on the domain. DNS zone for the domain must serve special DNSSEC records for public keys (DNSKEY), signatures (RRSIG), and non-existence (NSEC, or NSEC3 and NSEC3PARAM) to authenticate the zone’s contents.
    • DS record must be added to the TLD at the registrar
    • DNS resolver that validates signatures for DNSSEC-signed domains must be used
  • Note: When DNSSEC is enabled with DNS routing policies, only a single IP address can be used within each policy item.

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.

Questions on DNS Routing Policies and New Features

  1. A company needs to distribute DNS traffic across multiple regions with automatic failover when a region becomes unhealthy. Which Cloud DNS routing policy should they use?
    1. Weighted Round Robin (WRR) routing policy
    2. Geolocation routing policy
    3. Failover routing policy
    4. DNS forwarding policy
    Show Answer

    Answer: b. Geolocation routing policy – Geolocation routing with health checks automatically fails over to the next closest region when endpoints are unhealthy. Failover routing policy (c) provides active/backup, not multi-region distribution.

  1. A company wants to point their apex domain (example.com) to a load balancer hostname without using an A record with a static IP. What Cloud DNS feature should they use?
    1. CNAME record at the apex
    2. DNS peering zone
    3. Alias record
    4. DNS forwarding zone
    Show Answer

    Answer: c. Alias record – Alias records (GA Sept 2025) provide CNAME-like functionality at the zone apex. CNAME records cannot be placed at the apex because they cannot coexist with SOA records.

  1. An organization has IPv6-only VM instances that need to access legacy IPv4-only services on the internet. Which combination of features should they configure?
    1. Cloud NAT with DNS forwarding
    2. DNS64 with NAT64
    3. DNS peering with Cloud VPN
    4. DNSSEC with IPv6 forwarding
    Show Answer

    Answer: b. DNS64 with NAT64 – DNS64 synthesizes AAAA records from A records using the 64:ff9b::/96 prefix, and NAT64 handles the actual packet translation, enabling IPv6-only VMs to reach IPv4 destinations.

  1. A security team wants to detect DNS-based command and control (C2) communication and data exfiltration from their Google Cloud workloads. Which service should they enable?
    1. DNSSEC
    2. Cloud Armor
    3. DNS Armor
    4. DNS Response Policies
    Show Answer

    Answer: c. DNS Armor – DNS Armor (GA Jan 2026), powered by Infoblox, provides DNS-layer threat detection for C2 communications, DNS tunneling, and malware DNS queries.

  1. Which of the following routing policy types restricts DNS traffic to a specific geolocation even when all endpoints in that region are unhealthy?
    1. Weighted Round Robin (WRR)
    2. Geolocation routing policy
    3. Geolocation routing policy with geofence
    4. Failover routing policy
    Show Answer

    Answer: c. Geolocation routing policy with geofence – With geofencing enabled, automatic failover to the next closest region does not occur, even if all endpoints in a geolocation fail health checks.

  1. An organization wants to override DNS resolution for specific Google API domains within their VPC to route to VPC Service Controls restricted endpoints. What Cloud DNS feature should they use?
    1. DNS forwarding zone
    2. DNS server policy
    3. DNS response policy
    4. DNS peering zone
    Show Answer

    Answer: c. DNS response policy – Response policies allow custom DNS resolution within VPCs, making it easy to route specific API domains to restricted VIPs for VPC Service Controls compliance.

  1. Cloud DNS health checks for external endpoints (GA Feb 2025) support which of the following? (Choose 2)
    1. Health checking endpoints behind Cloud VPN
    2. TCP, HTTP, and HTTPS protocols
    3. Health check probes from three user-specified regions
    4. gRPC protocol health checks
    5. Probes from fixed IP address ranges
    Show Answer

    Answer: b, c – External endpoint health checks support TCP/HTTP/HTTPS protocols and originate from three user-specified source regions. gRPC, SSL, and HTTP/2 are not supported. Probe source IP ranges are not fixed.

References

Google Cloud Network Endpoint Groups – NEG

~ Last updated on : ~ jayendrapatil

Google Cloud Network Endpoint Groups – NEG

  • Network Endpoint Groups (NEG) is a configuration object that specifies a group of backend endpoints or services.
  • Network Endpoint Groups provides a logical grouping of IP addresses and ports for software services instead of entire VMs.
  • NEGs let you distribute traffic to your load balancer’s backends at a more granular level (for example, load balancing traffic at the Pod level instead of at the VM-level for GKE workloads).
  • NEGs can be used as backends for Application Load Balancers (HTTP/HTTPS), Proxy Network Load Balancers (TCP/SSL), Passthrough Network Load Balancers, and with Cloud Service Mesh (formerly Traffic Director).
  • Google Cloud supports six types of NEGs: Zonal, Internet, Serverless, Hybrid connectivity, Private Service Connect, and Port mapping.

Zonal NEG

  • contains one or more endpoints that can be Compute Engine VMs or services running on the VMs.
  • are zonal resources that represent collections of either IP addresses or IP address/port combinations for Google Cloud resources within a single subnet.
  • Supports two endpoint types:
    • GCE_VM_IP – IP only: resolves to the primary internal IPv4 address of a VM’s network interface.
    • GCE_VM_IP_PORT – IP:Port: resolves to either the primary internal IPv4 address or an internal IPv4 address from an alias IP range (e.g., Pod IPv4 addresses in VPC-native GKE clusters).
  • Only GCE_VM_IP_PORT type endpoints support IPv4 and IPv6 (dual-stack) zonal NEGs.
  • All other backends in that backend service must also be zonal NEGs.
  • Zonal NEG can be used as a backend for more than one backend service.
  • Backend services using zonal NEGs for backends only support balancing modes of RATE or CONNECTION. UTILIZATION is not supported.
  • Supports centralized health checks for NEGs with GCE_VM_IP_PORT and GCE_VM_IP endpoints.
  • Supported by:
    • Internal and External Passthrough Network Load Balancers (GCE_VM_IP endpoints)
    • Regional/Cross-region Internal and External Proxy Network Load Balancers (GCE_VM_IP_PORT endpoints)
    • Internal, External, and Classic Application Load Balancers (GCE_VM_IP_PORT endpoints)
    • Global external Proxy Network Load Balancer (GCE_VM_IP_PORT endpoints)
    • Cloud Service Mesh (GCE_VM_IP_PORT endpoints)

Internet NEG

  • contains endpoints that are hosted outside of Google Cloud, specified by hostname FQDN:port or IP:port.
  • Supports two endpoint types:
    • INTERNET_IP_PORT – IP:Port, where IP must not be an RFC 1918 address.
    • INTERNET_FQDN_PORT – FQDN:Port.
  • Can be global or regional in scope:
    • Global internet NEGs – contain a single endpoint; health checks not supported.
    • Regional internet NEGs – support up to 256 endpoints; use distributed Envoy health checks.
  • Ideal to serve content from an origin hosted outside of Google Cloud that needs to be fronted by an external Application Load Balancer.
  • Allows you to:
    • Use Google Edge infrastructure for terminating the user connection.
    • Direct the connections to your custom origin.
    • Use Cloud CDN for your custom origin.
    • Deliver traffic to the public endpoint across Google’s private backbone, improving reliability and decreasing latency.
  • Supported by:
    • Global internet NEGs: Cloud CDN, Global/Classic external Application Load Balancer, Cloud Service Mesh
    • Regional internet NEGs: Regional external/internal Application Load Balancer, Regional external/internal Proxy Network Load Balancer

Serverless NEG

  • points to Cloud Run, App Engine, Cloud Run functions (formerly Cloud Functions), or API Gateway services residing in the same region as the NEG.
  • Endpoint type is SERVERLESS.
  • Serverless NEGs don’t contain traditional endpoints – they reference FQDN belonging to the serverless resource.
  • Contains a single endpoint and is regional in scope.
  • Health checks are not applicable (managed by the serverless platform).
  • Supported by:
    • Global/Classic/Regional external Application Load Balancers
    • Regional/Cross-region internal Application Load Balancers (Cloud Run and Cloud Run functions 2nd gen only)

Hybrid Connectivity NEG

  • contains one or more endpoints that resolve to on-premises services, server applications in another cloud, or other internet-reachable services outside Google Cloud.
  • Endpoint type is NON_GCP_PRIVATE_IP_PORT – IP:Port belonging to a VM that is not in Compute Engine and must be routable using hybrid connectivity (Cloud Interconnect, Cloud VPN, or Router appliance).
  • Zonal in scope with one or more endpoints.
  • Health checks:
    • Centralized health checks – when used with Global/Classic external Application Load Balancer, Global external/Classic Proxy Network Load Balancer.
    • Distributed Envoy health checks – when used with Regional external/internal Application Load Balancer, Regional external/internal Proxy Network Load Balancer, Cross-region internal Application/Proxy Network Load Balancer.
  • Supported by:
    • External Application Load Balancers (Global, Classic, Regional)
    • Internal Application Load Balancers (Regional, Cross-region)
    • External Proxy Network Load Balancers (Global, Classic, Regional)
    • Internal Proxy Network Load Balancers (Regional, Cross-region)
    • Cloud Service Mesh

Private Service Connect NEG

  • resolves to a Google-managed regional or global API endpoint, or a managed service published using Private Service Connect.
  • Endpoint type is PRIVATE_SERVICE_CONNECT.
  • Contains a single endpoint and is regional in scope.
  • Health checks are not applicable.
  • Enables consumers to access managed services privately from inside their VPC network through a load balancer.
  • Supported by:
    • Global external Application Load Balancer (not supported by Classic Application Load Balancer)
    • Regional external Application Load Balancer
    • Regional/Cross-region internal Application Load Balancer
    • Global external Proxy Network Load Balancer (not supported by Classic Proxy Network Load Balancer)
    • Regional external/internal Proxy Network Load Balancer
    • Cross-region internal Proxy Network Load Balancer

Port Mapping NEG

  • provides a mapping from a client port of a Private Service Connect endpoint to a combination of service port and service producer VM.
  • Endpoint type is GCE_VM_IP_PORTMAP.
  • Contains one or more endpoints and is regional in scope.
  • Health checks are not applicable.
  • Routes traffic to a service producer VPC network through a connection between a Private Service Connect endpoint and a service attachment.
  • Used with Private Service Connect port mapping services.

NEG Comparison Summary

  • Zonal and Internet NEGs define how endpoints should be reached, whether they are reachable, and where they are located.
  • Serverless and Private Service Connect NEGs don’t contain traditional IP endpoints.
  • Hybrid connectivity NEGs point to services running outside Google Cloud, reachable via Cloud Interconnect or Cloud VPN.
  • Port Mapping NEGs are specifically for Private Service Connect port mapping use cases.

Google Cloud Network Endpoint Groups

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 needs to route traffic from their external HTTP(S) load balancer to an application running on-premises, connected via Cloud Interconnect. Which type of NEG should they use?
    1. Zonal NEG
    2. Internet NEG
    3. Hybrid connectivity NEG
    4. Private Service Connect NEG
    Show Answer

    Answer: c. Hybrid connectivity NEG – Hybrid connectivity NEGs use NON_GCP_PRIVATE_IP_PORT endpoints for on-premises or multi-cloud backends reachable via Cloud Interconnect or Cloud VPN.

  2. Which NEG type allows you to access a managed service published via Private Service Connect through a load balancer?
    1. Serverless NEG
    2. Internet NEG
    3. Private Service Connect NEG
    4. Zonal NEG
    Show Answer

    Answer: c. Private Service Connect NEG – PSC NEGs resolve to Google-managed API endpoints or managed services published using Private Service Connect.

  3. A team wants to load balance traffic to their Cloud Run service using an external Application Load Balancer. Which NEG type should they configure?
    1. Zonal NEG with GCE_VM_IP_PORT
    2. Serverless NEG
    3. Internet NEG
    4. Hybrid connectivity NEG
    Show Answer

    Answer: b. Serverless NEG – Serverless NEGs point to Cloud Run, App Engine, Cloud Run functions, or API Gateway services.

  4. Which balancing modes are supported by backend services that use zonal NEGs? (Choose 2)
    1. UTILIZATION
    2. RATE
    3. CONNECTION
    4. BANDWIDTH
    Show Answer

    Answer: b, c – Backend services using zonal NEGs only support RATE or CONNECTION balancing modes. UTILIZATION is not supported.

  5. Which of the following NEG types supports distributed Envoy health checks for regional load balancers? (Choose 2)
    1. Serverless NEG
    2. Regional Internet NEG
    3. Hybrid connectivity NEG
    4. Private Service Connect NEG
    Show Answer

    Answer: b, c – Regional Internet NEGs and Hybrid connectivity NEGs (when used with regional load balancers) support distributed Envoy health checks.

References

Google Kubernetes Engine – GKE

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – GKE

  • Google Kubernetes Engine – GKE provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
  • GKE is available in two editions:
    • GKE Standard edition – core GKE functionality including cluster management, autoscaling, release channels, fleet management, Config Management, and Policy Controller at no additional cost.
    • GKE Enterprise edition – adds advanced security, compliance insights, Binary Authorization, service mesh, multi-cluster management, and richer networking features for enterprise-scale operations.

Standard vs Autopilot Cluster

  • Autopilot (Recommended – Default mode since 2023)
    • Provides a fully provisioned and managed cluster configuration.
    • Cluster configuration options are made for you.
    • Autopilot clusters are pre-configured with an optimized cluster configuration that is ready for production workloads.
    • GKE manages the entire underlying infrastructure of the clusters, including the control plane, nodes, and all system components.
    • Applies security best practices by default including hardened node configuration, automatic security patching, and default seccomp profiles.
    • Billing is based on Pod resource requests (CPU, memory, ephemeral storage) rather than node-level resources.
    • Uses a container-optimized compute platform (introduced 2025) that delivers up to 85% faster provisioning speed and improved autoscaling performance.
    • Supports ComputeClasses (Balanced, Scale-Out, custom) to let workloads specify hardware requirements like GPUs, high-memory, or accelerator-optimized nodes.
    • In 2024, 30% of all active GKE clusters were created in Autopilot mode.
  • Standard
    • Provides advanced configuration flexibility over the cluster’s underlying infrastructure.
    • Cluster configurations needed for the production workloads are determined by you.
    • You manage node pools, machine types, scaling policies, and node-level security.
    • Supports Autopilot mode workloads in Standard clusters – allows deploying ComputeClasses and letting GKE auto-create/manage node pools for specific workloads while retaining Standard cluster control for others.

GKE - Autopilot vs Standard Clusters

Zonal vs Regional Cluster

  • Zonal clusters
    • Zonal clusters have a single control plane in a single zone.
    • Depending on the availability requirements, nodes for the zonal cluster can be distributed in a single zone or in multiple zones.
    • Single-zone clusters
      • Control Plane -> Single Zone & Workers -> Single Zone
      • A single-zone cluster has a single control plane running in one zone.
      • Control plane manages workloads on nodes running in the same zone.
    • Multi-zonal clusters
      • Control Plane -> Single Zone & Workers -> Multi-Zone
      • A multi-zonal cluster has a single replica of the control plane running in a single zone and has nodes running in multiple zones.
      • During an upgrade of the cluster or an outage of the zone where the control plane runs, workloads still run. However, the cluster, its nodes, and its workloads cannot be configured until the control plane is available.
      • Multi-zonal clusters balance availability and cost for consistent workloads.
  • Regional clusters
    • Control Plane -> Multi Zone & Workers -> Multi-Zone
    • A regional cluster has multiple replicas of the control plane, running in multiple zones within a given region.
    • Nodes also run in each zone where a replica of the control plane runs.
    • Because a regional cluster replicates the control plane and nodes, it consumes more Compute Engine resources than a similar single-zone or multi-zonal cluster.

GKE Zonal vs Regional Cluster

Route-Based Cluster vs VPC-Native Cluster

  • VPC-native clusters (using Alias IPs) are the default and recommended networking mode.
  • VPC-native mode is always on for Autopilot clusters and cannot be turned off.
  • Route-based clusters require explicitly disabling the VPC-native option and are not recommended for new deployments.
  • VPC-native clusters offer better scalability (not subject to route quotas), native integration with VPC features, and support for Private Google Access.

Refer blog post @ Google Kubernetes Engine Networking

Private Cluster

  • Private clusters help isolate nodes from having inbound and outbound connectivity to the public internet by providing nodes with internal IP addresses only.
  • External clients can still reach the services exposed as a load balancer by calling the external IP address of the HTTP(S) load balancer.
  • Cloud NAT or self-managed NAT gateway can provide outbound internet access for certain private nodes.
  • By default, Private Google Access is enabled, which provides private nodes and their workloads with limited outbound access to Google Cloud APIs and services over Google’s private network.
  • The defined VPC network contains the cluster nodes, and a separate Google Cloud VPC network contains the cluster’s control plane.
  • The control plane’s VPC network is located in a project controlled by Google. The control plane’s VPC network is connected to the cluster’s VPC network with VPC Network Peering. Traffic between nodes and the control plane is routed entirely using internal IP addresses.
  • Control plane for a private cluster has a private endpoint in addition to a public endpoint.
  • Control plane public endpoint access level can be controlled:
    • Public endpoint access disabled
      • Most secure option as it prevents all internet access to the control plane.
      • Cluster can be accessed using Bastion host/Jump server or if Cloud Interconnect and Cloud VPN have been configured from the on-premises network to connect to Google Cloud.
      • Authorized networks must be configured for the private endpoint, which must be internal IP addresses.
    • Public endpoint access enabled, authorized networks enabled:
      • Provides restricted access to the control plane from defined source IP addresses.
    • Public endpoint access enabled, authorized networks disabled
      • Default and least restrictive option.
      • Publicly accessible from any source IP address as long as you authenticate.
  • Nodes always contact the control plane using the private endpoint.

Shared VPC Clusters

  • Shared VPC supports both zonal and regional clusters.
  • Shared VPC supports VPC-native clusters and must have Alias IPs enabled. Legacy networks are not supported.

Node Pools

  • A node pool is a group of nodes within a cluster that all have the same configuration and are identical to one another.
  • Node pools use a NodeConfig specification.
  • Each node in the pool has a cloud.google.com/gke-nodepool Kubernetes node label, which has the node pool’s name as its value.
  • Number of nodes and type of nodes specified during cluster creation becomes the default node pool. Additional custom node pools of different sizes and types can be added to the cluster for e.g. local SSDs, GPUs, Spot VMs, or different machine types.
  • Node pools can be created, upgraded, and deleted individually without affecting the whole cluster. However, a single node in a node pool cannot be configured; any configuration changes affect all nodes in the node pool.
  • You can resize node pools in a cluster by adding or removing nodes using gcloud container clusters resize CLUSTER_NAME --node-pool POOL_NAME --num-nodes NUM_NODES
  • Existing node pools can be manually upgraded or automatically upgraded.
  • For a multi-zonal or regional cluster, all of the node pools are replicated to those zones automatically. Any new node pool is automatically created or deleted in those zones.
  • GKE drains all the nodes in the node pool when a node pool is deleted.
  • Spot VMs (replacement for Preemptible VMs) can be used in node pools for fault-tolerant workloads with up to 60-91% cost savings.
  • Node pool auto-creation (formerly Node Auto-Provisioning/NAP) allows GKE to automatically create and delete node pools based on workload requirements and ComputeClass specifications.

Cluster Autoscaler

  • GKE’s cluster autoscaler automatically resizes the number of nodes in a given node pool, based on the demands of the workloads.
  • Cluster autoscaler is automatic by specifying the minimum and maximum size of the node pool and does not require manual intervention.
  • Cluster autoscaler increases or decreases the size of the node pool automatically, based on the resource requests (rather than actual resource utilization) of Pods running on that node pool’s nodes.
    • If Pods are unschedulable because there are not enough nodes in the node pool, cluster autoscaler adds nodes, up to the maximum size of the node pool.
    • If nodes are under-utilized, and all Pods could be scheduled even with fewer nodes in the node pool, cluster autoscaler removes nodes, down to the minimum size of the node pool. If the node cannot be drained gracefully after a timeout period (currently 10 minutes – not configurable), the node is forcibly terminated.
  • Before enabling cluster autoscaler, design the workloads to tolerate potential disruption or ensure that critical Pods are not interrupted.
  • Workloads might experience transient disruption with autoscaling, esp. with workloads running with a single replica.
  • With Autopilot clusters, you don’t need to configure cluster autoscaler because node pools are automatically provisioned and scaled to meet workload requirements.

ComputeClasses

  • A ComputeClass is a Kubernetes custom resource that defines a list of node configurations (machine types, feature settings, hardware requirements) for GKE to follow when provisioning nodes.
  • Built-in ComputeClasses (Autopilot):
    • General-Purpose (default) – standard compute for most workloads.
    • Balanced – optimized balance of compute, memory, and networking.
    • Scale-Out – cost-efficient for horizontally scalable workloads.
    • Accelerator – for GPU/TPU workloads (AI/ML).
  • Custom ComputeClasses let you define prioritized lists of node configurations for autoscaling, including machine families, Spot VM fallback, specific zones, and hardware constraints.
  • ComputeClasses work in both Autopilot and Standard clusters (with Autopilot mode enabled for the workload).
  • Pods select a ComputeClass using the cloud.google.com/compute-class node selector or nodeAffinity.

Release Channels & Extended Support

  • GKE release channels provide automatic version management:
    • Rapid – latest Kubernetes release; access new GKE features as soon as they go GA.
    • Regular – 1-2 months after Rapid; balance of feature access and stability.
    • Stable – 2-3 months after Regular; priority on stability.
    • Extended – for clusters needing longer support on a specific minor version.
  • Extended Support (since GKE 1.27): clusters can remain on a specific minor version for up to 24 months – 14 months of standard support plus ~10 months of extended support with continued security patches.
  • Clusters enrolled in release channels receive automatic upgrades within their channel’s schedule.

Auto-upgrading Nodes

  • Node auto-upgrades help keep the nodes in the GKE cluster up-to-date with the cluster control plane version when the control plane is updated on your behalf.
  • Node auto-upgrade is enabled by default when a new cluster or node pool is created with Google Cloud Console or the gcloud command.
  • Node auto-upgrades provide several benefits:
    • Lower management overhead – no need to manually track and update the nodes when the control plane is upgraded on your behalf.
    • Better security – GKE automatically ensures that security updates are applied and kept up to date.
    • Ease of use – provides a simple way to keep the nodes up to date with the latest Kubernetes features.
  • Node pools with auto-upgrades enabled are scheduled for upgrades when they meet the selection criteria. Rollouts are phased across multiple weeks to ensure cluster and fleet stability.
  • During the upgrade, nodes are drained and re-created to match the current control plane version. Modifications on the boot disk of a node VM do not persist across node re-creations. To preserve modifications across node re-creation, use a DaemonSet.
  • Enabling auto-upgrades does not cause the nodes to upgrade immediately.

Workload Identity Federation

  • Workload Identity Federation for GKE (previously known as Workload Identity) is the recommended way for workloads running on GKE to authenticate to Google Cloud APIs.
  • Eliminates the need for service account keys, which are a security risk due to being long-lived credentials.
  • Allows Kubernetes service accounts to act as IAM principals, directly referencing them in IAM policies without an intermediate Google service account.
  • Provides per-Pod identity using the principle of least privilege, unlike node-level service accounts that are shared by all workloads on a node.
  • Enabled by default on Autopilot clusters.
  • Supports fleet-level Workload Identity Federation for multi-cluster environments.

Fleet Management

  • A Fleet is a logical grouping of GKE clusters that enables multi-cluster management and governance.
  • Fleets allow you to manage features like Config Management, Policy Controller, and service mesh across multiple clusters simultaneously.
  • Fleet-level features include:
    • Teams – define team scopes across clusters for multi-tenancy.
    • Config Sync – apply consistent configuration across fleet members.
    • Policy Controller – enforce governance policies fleet-wide.
    • Service Mesh – unified service mesh across clusters (Cloud Service Mesh).
    • Multi-cluster Services (MCS) – discover and route to services across clusters.
    • Multi-cluster Gateway – global load balancing across clusters using Gateway API.
  • Fleet management features are available in GKE Standard edition at no additional cost (since 2024).

GKE Security

https://jayendrapatil.com/google-kubernetes-engine-gke-security/

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 existing application running in Google Kubernetes Engine (GKE) consists of multiple pods running on four GKE n1-standard-2 nodes. You need to deploy additional pods requiring n2-highmem-16 nodes without any downtime. What should you do?
    1. Use gcloud container clusters upgrade. Deploy the new services.
    2. Create a new Node Pool and specify machine type n2-highmem-16. Deploy the new pods.
    3. Create a new cluster with n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
    4. Create a new cluster with both n1-standard-2 and n2-highmem-16 nodes. Redeploy the pods and delete the old cluster.
  2. A company is running a production GKE cluster and wants to minimize operational overhead while ensuring nodes are always patched and running the latest supported Kubernetes version. What should they configure?
    1. Manually upgrade nodes each quarter using gcloud container clusters upgrade.
    2. Use GKE Autopilot mode with release channels enabled.
    3. Disable auto-upgrade and use a custom CI/CD pipeline for upgrades.
    4. Use preemptible VMs so nodes are recycled frequently.
  3. Your organization runs multiple GKE clusters across different regions. You need a way to apply consistent security policies and deploy services accessible across all clusters. Which features should you use?
    1. Create separate IAM policies for each cluster and use external load balancers.
    2. Register clusters in a Fleet and use Policy Controller with Multi-cluster Services.
    3. Deploy identical configurations manually to each cluster.
    4. Use a single regional cluster spanning all regions.
  4. A team wants their GKE workloads to securely access Google Cloud Storage and BigQuery APIs without managing service account keys. What is the recommended approach?
    1. Mount service account JSON keys as Kubernetes secrets.
    2. Use the node’s default service account for all Pods.
    3. Enable Workload Identity Federation and bind Kubernetes service accounts to IAM principals.
    4. Store service account keys in Secret Manager and inject at runtime.
  5. You are deploying an AI/ML training workload on GKE that requires GPU nodes. You want GKE to automatically provision the right node type without manual node pool creation. What should you use?
    1. Manually create a GPU node pool and set taints/tolerations.
    2. Use cluster autoscaler with a pre-created GPU node pool.
    3. Use GKE Autopilot with the Accelerator ComputeClass.
    4. Deploy the workload on CPU nodes and use software-based GPU emulation.
  6. You want your GKE cluster to remain on Kubernetes version 1.29 for 24 months to minimize disruption to production workloads. What should you configure?
    1. Disable auto-upgrades and manually manage the cluster version.
    2. Use the Rapid release channel for the latest patches.
    3. Enroll the cluster in the Extended release channel for extended support.
    4. Create a new cluster every 14 months on the desired version.

References

GKE Networking – VPC, Gateway API & Dataplane V2

~ Last updated on : ~ jayendrapatil

Google Kubernetes Engine – Networking

📅 Last Updated: June 2026 — Added GKE Dataplane V2, Gateway API, Network Isolation simplification, Multi-Pod CIDR, Multi-Network support, IPv6 Dual-Stack, and GKE Inference Gateway sections.

IP allocation

Kubernetes uses various IP ranges to assign IP addresses to Nodes, Pods, and Services.

  • Node IP
    • Each node has an IP address assigned from the cluster’s VPC network.
    • Node IP provides connectivity from control components like kube-proxy and kubelet to the Kubernetes API server.
    • Node IP is the node’s connection to the rest of the cluster.
  • Pod CIDR or Address Range
    • Each node has a pool of IP addresses that GKE assigns the Pods running on that node (a /24 CIDR block by default).
    • With Multi-Pod CIDR (GKE 1.29+), additional Pod IP address ranges can be added to an existing cluster without recreating it.
  • Pod Address
    • Each Pod has a single IP address assigned from the Pod CIDR range of its node.
    • Pod IP address is shared by all containers running within the Pod and connects them to other Pods running in the cluster.
  • Service Address Range
    • Each Service has an IP address, called the ClusterIP, assigned from the cluster’s VPC network.
  • For Standard clusters
    • a maximum of 110 Pods can run on a node with a /24 range, not 256 as you might expect. This provides a buffer so that Pods don’t become unschedulable due to a transient lack of IP addresses in the Pod IP range for a given node.
    • For ranges smaller than /24, roughly half as many Pods can be scheduled as IP addresses in the range.
  • Autopilot clusters can run a maximum of 32 Pods per node.

GKE Cluster Networking Types

  • GKE, clusters can be distinguished according to the way they route traffic from one Pod to another Pod.
    • VPC-native cluster: A cluster that uses alias IP address ranges (recommended and default)
    • Routes-based cluster: A cluster that uses custom static routes in a VPC network (legacy, not recommended for new clusters)
  • GKE clusters can also be distinguished by their dataplane:
    • GKE Dataplane V2 (default for Autopilot): Uses eBPF/Cilium for packet processing, replacing iptables and kube-proxy
    • Legacy Dataplane: Uses iptables and kube-proxy with Calico for network policy

VPC-Native Clusters

  • VPC-native cluster uses alias IP address ranges
  • VPC-native is the default and recommended network mode for all new clusters
  • VPC-native clusters have several benefits:
    • Pod IP addresses are natively routable within the cluster’s VPC network and other VPC networks connected to it by VPC Network Peering.
    • Pod IP address ranges, and subnet secondary IP address ranges in general, are accessible from on-premises networks connected with Cloud VPN or Cloud Interconnect using Cloud Routers.
    • Pod IP addresses are reserved in the VPC network before the Pods are created in the cluster. This prevents conflict with other resources in the VPC network and allows you to better plan IP address allocations.
    • Pod IP address ranges do not depend on custom static routes and do not consume the system-generated and custom static routes quota. Instead, automatically generated subnet routes handle routing for VPC-native clusters.
    • Firewall rules can be created that apply to just Pod IP address ranges instead of any IP address on the cluster’s nodes.
    • Supports GKE Dataplane V2 with eBPF-based networking
    • Required for multi-network support for Pods (multi-NIC)

VPC-Native Clusters IP Allocation

Google Kubernetes Engine Networking VPC-Native Cluster IP Management

  • VPC-native cluster uses three unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are assigned from the primary IP address range of the subnet associated with the cluster.
      • Both node IP addresses and the size of the subnet’s secondary IP address range for Pods limit the number of nodes that a cluster can support
    • One secondary IP address range for all Pod IP addresses.
      • Pod IP addresses are taken from the cluster subnet’s secondary IP address range for Pods.
      • By default, GKE allocates a /24 alias IP range (256 addresses) to each node for the Pods running on it.
      • On each node, those 256 alias IP addresses support up to 110 Pods.
      • Pod Address Range previously could not be changed once created. However, with Multi-Pod CIDR (available since GKE 1.29), additional Pod IP address ranges can now be added to an existing cluster.
        • Allows adding discontiguous secondary ranges for Pod IPs without recreating the cluster.
        • If the original range is exhausted, add a new Pod CIDR range using gcloud container clusters update.
        • Alternatively, node pools can be recreated with decreased --max-pods-per-node settings.
    • Another secondary IP address range for all Service (cluster IP) addresses.
      • Service (cluster IP) addresses are taken from the cluster’s subnet’s secondary IP address range for Services.
      • Service address range should be large enough to provide addresses for all the Kubernetes Services hosted in the cluster.
  • Node, Pod, and Services IP address ranges must all be unique and subnets with overlapping primary and secondary IP addresses cannot be created.

Routes-based Cluster

⚠️ Note: Routes-based clusters are legacy and not recommended for new clusters. VPC-native clusters are the default and recommended mode. To create a routes-based cluster, you must explicitly disable the VPC-native option.
  • Routes-based cluster that uses custom static routes in a VPC network i.e. it uses Google Cloud Routes to route traffic between nodes
  • In a routes-based cluster,
    • each node is allocated a /24 range of IP addresses for Pods.
    • With a /24 range, there are 256 addresses, but the maximum number of Pods per node is 110.
    • With approximately twice as many available IP addresses as possible Pods, Kubernetes is able to mitigate IP address reuse as Pods are added to and removed from a node.
  • Routes-based cluster uses two unique subnet IP address ranges
    • Subnet’s primary IP address range for all node IP addresses.
      • Node IP addresses are taken from the primary range of the cluster subnet
      • Cluster subnet must be large enough to hold the total number of nodes in your cluster.
    • Pod address range
      • A routes-based cluster has a range of IP addresses that are used for Pods and Services
      • Last /20 (4096 addresses) of the Pod address range is used for Services and the rest of the range is used for Pods
      • Pod address range size cannot be changed after cluster creation. So ensure that a large enough Pod address range is chosen to accommodate the cluster’s anticipated growth during cluster creation
  • Maximum number of nodes, Pods, and Services for a given GKE cluster is determined by the size of the cluster subnet and the size of the Pod address range.
  • Routes-based clusters do not support GKE Dataplane V2, multi-network Pods, or many newer GKE networking features.

GKE Dataplane V2

  • GKE Dataplane V2 is a modern dataplane optimized for Kubernetes networking, powered by eBPF and Cilium.
  • Enabled by default for all new Autopilot clusters.
  • Replaces iptables and kube-proxy with eBPF programs for packet processing, routing, load balancing, and network policy enforcement.
  • Key benefits:
    • Scalability: Removes iptables bottlenecks; supports up to 260,000 endpoints across all services via eBPF maps.
    • Security: Kubernetes NetworkPolicy is always enabled without needing third-party add-ons like Calico.
    • Observability: Built-in network policy logging and Hubble integration for real-time traffic visibility.
    • Consistency: Unified networking behavior across GKE environments.
    • SCTP Support: Supports Stream Control Transmission Protocol workloads.
  • Implementation:
    • Deploys a DaemonSet named anetd in the kube-system namespace on each node.
    • anetd interprets Kubernetes objects and programs network topologies using eBPF.
    • Does not use kube-proxy or iptables for service routing.
  • Cluster scale with Dataplane V2:
    • Up to 15,000 nodes per regional cluster (65,000 with scale-optimized mode that disables network policy enforcement).
    • Up to 400,000 Pods per cluster.
    • Up to 10,000 ClusterIP Services.
  • Limitations:
    • Can only be enabled at cluster creation time; existing clusters cannot be upgraded.
    • Custom eBPF programs are not supported on Dataplane V2 nodes.
    • Third-party eBPF tools may interfere with Dataplane V2 programs.
  • Supports Cilium Cluster-wide Network Policies for centralized network rule enforcement across all namespaces.
  • Refer GKE Dataplane V2

GKE Network Isolation (Control Plane & Node Access)

  • As of January 2025, GKE has simplified cluster networking by decoupling control-plane access from node-pool IP configuration.
    • The terms “public cluster” and “private cluster” are being replaced with flexible network isolation settings.
    • Control plane access and node configuration can now be changed at any time without recreating the cluster.
  • Control Plane Access Methods:
    • DNS-based endpoint (new, recommended): Uses IAM and authentication-based policies for dynamic, flexible access. Works with VPC Service Controls for multi-layer security.
    • Public IP-based endpoint: Traditional external access with authorized networks.
    • Private IP-based endpoint: Access restricted to private networks (VPC Peering or Private Service Connect-based clusters). Can now be locked down to specific RFC-1918 addresses.
  • All three endpoints can be enabled simultaneously or in any combination.
  • Node Pool Flexibility:
    • Each node pool has its own network configuration (public/private IP).
    • Public IPs can be attached or detached from node pools independently at any time.
    • Traffic between nodes and the control plane is always private regardless of configuration.
  • Private Service Connect (PSC): Newer clusters use PSC instead of VPC Peering for control-plane connectivity, eliminating VPC peering complexity.
  • Refer GKE Network Isolation

Gateway API (Recommended for Service Networking)

  • The Gateway API is the recommended evolution of Kubernetes service networking, replacing traditional Ingress resources.
  • Key advantages over Ingress:
    • Role-oriented: Separate API resources for cluster operators (Gateway), developers (HTTPRoute), and infrastructure providers (GatewayClass).
    • Expressive: Built-in support for header-based matching, traffic weighting, and traffic splitting without custom annotations.
    • Portable: Consistent concepts across environments with a core conformance model.
    • Multi-namespace: A single Gateway can serve routes across multiple namespaces.
  • GKE Gateway supports:
    • External and Internal Application Load Balancers
    • Frontend mTLS (client certificate validation) — 2025
    • Cloud CDN integration
    • Multi-cluster Gateways for cross-cluster load balancing
  • All Ingress resources are directly convertible to Gateway and HTTPRoute resources.
  • Refer GKE Gateway API

GKE Inference Gateway

  • GKE Inference Gateway is a specialized networking layer for AI/ML inference workloads, announced in 2025.
  • Extends the GKE Gateway to optimize serving of generative AI applications.
  • Key features:
    • Model-aware routing: Routes traffic to inference pools of model replicas based on model name.
    • Predicted latency-based routing: Routes requests to the model server with the lowest predicted latency.
    • Body-based routing: Routes based on request body content.
    • Prefix caching: Accelerates inference by caching common prompt prefixes.
    • Multi-cluster support: Scale AI workloads across clusters and regions.
  • Benchmarks show 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency vs. competing solutions.
  • Refer GKE Inference Gateway

Multi-Network Support for Pods

  • GKE supports attaching multiple network interfaces (multi-NIC) to Pods, removing the single-interface limitation.
  • Requires GKE Dataplane V2 and VPC-native clusters.
  • Use cases:
    • Separating control plane traffic from data plane traffic.
    • Network isolation between different workload types.
    • Multicast capability for Pods.
    • High-performance RDMA networking for AI/GPU workloads (via DRANET).
  • Pods can connect to up to 8 networks (default + 7 additional).
  • DRANET (Dynamic Resource Allocation for Networking): Specifically designed for AI workloads running across multiple GPUs, enabling RDMA network interface allocation for high-throughput inter-GPU communication.
  • Supports multi-network network policies for per-interface traffic control.
  • Refer Multi-Network Support for Pods

IPv6 Dual-Stack Networking

  • GKE supports dual-stack (IPv4 and IPv6) networking for clusters.
  • Available for Standard clusters (GKE 1.24+) and Autopilot clusters (GKE 1.25+).
  • Dual-stack clusters assign both IPv4 and IPv6 addresses to Pods and Services.
  • Requirements:
    • VPC-native clusters only.
    • Dual-stack subnets with both IPv4 and IPv6 ranges.
    • For internal IPv6, VPC must be custom mode with ULA internal IPv6 enabled.
  • Enables applications to serve both IPv4 and IPv6 clients without separate infrastructure.

Related Reads

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.

Questions on GKE Networking Updates:

  1. Your organization runs a GKE cluster that is running out of Pod IP addresses. What is the best approach to address this without downtime?
    1. Recreate the cluster with a larger Pod CIDR range
    2. Use Multi-Pod CIDR to add additional Pod IP address ranges to the existing cluster
    3. Migrate to a routes-based cluster with more IP space
    4. Reduce the number of Pods per node
    Show Answer

    Answer: b – Multi-Pod CIDR (GKE 1.29+) allows adding discontiguous Pod IP ranges to existing VPC-native clusters without recreation.

  2. Which of the following are advantages of GKE Dataplane V2 over the legacy dataplane? (Choose THREE)
    1. Uses eBPF instead of iptables for packet processing
    2. Built-in Kubernetes NetworkPolicy enforcement without third-party add-ons
    3. Can be enabled on existing clusters via an upgrade
    4. Provides real-time network observability via Hubble
    5. Requires manual installation of Calico for network policies
    Show Answer

    Answer: a, b, d – Dataplane V2 uses eBPF/Cilium replacing iptables/kube-proxy, has built-in NetworkPolicy (no Calico needed), and integrates Hubble for observability. It can only be enabled at cluster creation.

  3. A company wants to change their GKE cluster from publicly accessible to private without recreating it. Which GKE networking feature enables this?
    1. VPC Peering-based private clusters
    2. Routes-based cluster configuration
    3. GKE flexible network isolation with DNS-based endpoints
    4. Cloud NAT configuration
    Show Answer

    Answer: c – Since January 2025, GKE allows changing control-plane access and node-pool configuration at any time without cluster recreation. DNS-based endpoints provide IAM-based dynamic security.

  4. Your team needs to expose multiple HTTP services across different namespaces using a single load balancer with traffic splitting capabilities. Which GKE networking resource should you use?
    1. Kubernetes Ingress with annotations
    2. GKE Gateway with HTTPRoute resources
    3. LoadBalancer Service per application
    4. Cloud DNS with round-robin
    Show Answer

    Answer: b – Gateway API is the recommended approach for HTTP service networking in GKE. A single Gateway can serve routes across namespaces with built-in traffic splitting.

  5. An AI team needs high-throughput RDMA networking between GPU pods in their GKE cluster. Which feature should they use?
    1. Standard Pod networking with increased MTU
    2. Multi-network support for Pods with DRANET
    3. Routes-based cluster with custom routes
    4. GKE Inference Gateway
    Show Answer

    Answer: b – DRANET (Dynamic Resource Allocation for Networking) enables allocation of RDMA network interfaces for high-throughput inter-GPU communication in AI workloads.

  6. What is the maximum number of nodes supported in a GKE regional cluster with Dataplane V2?
    1. 5,000 nodes
    2. 15,000 nodes
    3. 65,000 nodes with scale-optimized mode
    4. 1,000 nodes
    Show Answer

    Answer: c – GKE supports up to 65,000 nodes in regional clusters with Dataplane V2 scale-optimized mode (which disables network policy enforcement). Standard regional clusters support up to 15,000 nodes.

 

Google Cloud NAT – Public, Private & NAT64

~ Last updated on : ~ jayendrapatil

Google Cloud NAT

  • Cloud NAT provides network address translation (NAT) for outbound traffic to the internet, Virtual Private Cloud (VPC) networks, on-premises networks, and other cloud provider networks.
  • Cloud NAT is a distributed, software-defined managed service. It’s not based on proxy VMs or appliances. Cloud NAT configures the Andromeda software that powers your VPC network.
  • Cloud NAT supports two types: Public NAT (outbound internet access) and Private NAT (private-to-private NAT between networks).
  • Cloud NAT translates addresses for the following resources:
    • Compute Engine virtual machine (VM) instances
    • Google Kubernetes Engine (GKE) clusters
    • Cloud Run instances (services and jobs)
    • Cloud Run functions instances
    • App Engine standard environment instances
    • Regional internet network endpoint groups (NEGs)
  • Cloud NAT provides source network address translation (SNAT) for outbound traffic and destination network address translation (DNAT) for established inbound response packets.
  • Cloud NAT does not implement unsolicited inbound connections from the internet. DNAT is only performed for packets that arrive as responses to outbound packets.
  • Cloud NAT works only for the VM’s network interface’s primary IP address and alias IP address provided that the network interface doesn’t have an external IP address assigned to it, in which case traffic is routed through the internet gateway.
  • Cloud NAT gateway is associated with a single VPC network, region, and Cloud Router
  • Cloud NAT provides the following benefits:
    • Security
      • Reduce the need for individual VMs to each have external IP addresses. Subject to egress firewall rules, VMs without external IP addresses can access destinations on the internet.
      • With manual NAT IP address assignment, whitelisting can be performed by the destination service to allow connections from known external IP addresses.
      • Private NAT enables private-to-private NAT between VPC networks or between VPC and on-premises/other cloud provider networks using Private NAT subnet IP addresses.
    • Availability
      • is a distributed, software-defined managed service that doesn’t depend on any VMs in your project or a single physical gateway device.
      • Can be configured on a Cloud Router, which provides the control plane for NAT, holding specified configuration parameters.
    • Scalability
      • can be configured to automatically scale the number of NAT IP addresses that it uses, and it supports VMs that belong to managed instance groups, including those with autoscaling enabled.
    • Performance
      • does not reduce the network bandwidth per VM. It is implemented by Google’s Andromeda software-defined networking.
    • Logging
      • For Cloud NAT traffic, you can trace the connections and bandwidth for compliance, debugging, analytics, and accounting purposes.
    • Monitoring
      • Cloud NAT exposes key metrics to Cloud Monitoring that give insight into your fleet’s use of NAT gateways. Network Analyzer automatically publishes Cloud NAT insights.

Traditional NAT versus Cloud NAT (click to enlarge).

Types of Cloud NAT

  • A single Cloud NAT gateway provides either Public NAT or Private NAT.
  • By creating two separate gateways, you can use both NAT types to serve the same subnet.
  • Both Public NAT and Private NAT translate addresses from IPv4 to IPv4.
  • Public NAT also provides translation from IPv6 to IPv4 (NAT64).

Public NAT

  • Public NAT lets Google Cloud resources that don’t have external IPv4 addresses communicate with IPv4 destinations on the internet.
  • VMs use a set of shared external IP addresses to connect to the internet.
  • A Cloud NAT gateway allocates a set of external IP addresses and source ports to each VM that uses the gateway to create outbound connections to the internet.
  • Traffic sent to Google APIs and services is routed through Private Google Access even if the VM instance uses Public NAT.
  • Public NAT supports both Premium Tier (default) and Standard Tier network service tiers.
  • Public NAT supports NAT64 (IPv6 to IPv4 translation) for IPv6-only Compute Engine VM instances, allowing them to reach IPv4 internet destinations.
  • Public NAT supports source-based NAT rules for IPv4 addresses, allowing NAT address selection based on source address in addition to destination address.

Private NAT

  • Private NAT enables private-to-private network address translation between networks.
  • Private NAT for Network Connectivity Center (NCC) spokes – enables private-to-private NAT for VPC networks connected to an NCC hub, including traffic between VPC spokes and between VPC spokes and hybrid spokes.
  • Hybrid NAT – enables private-to-private NAT between VPC networks and on-premises or other cloud provider networks connected over Cloud Interconnect or Cloud VPN.
  • Private NAT is useful when source and destination networks have overlapping subnet IP addresses.
  • Private NAT supports Compute Engine VMs, GKE clusters, and Cloud Run instances.
  • Private NAT does not support auto mode VPC networks.
  • Private NAT supports only TCP and UDP. ICMP and other protocols aren’t supported.
  • Private NAT supports a maximum of 64,000 simultaneous connections per endpoint.
  • Private NAT uses IP addresses from a dedicated Private NAT subnet range.
  • Private NAT is a port restricted cone NAT as defined in RFC 3489.

Cloud NAT Specifications

  • Cloud NAT gateway provides NAT services for packets sent from a VM’s network interface as long as that network interface doesn’t have an external IP address assigned to it
  • Cloud NAT gateway can be configured to provide NAT for the VM network interface’s primary internal IP address, alias IP ranges, or both
  • Cloud NAT gateway does not change the amount of outbound or inbound bandwidth that a VM can use, as it depends on VM’s machine type
  • Cloud NAT gateway can only apply to a single network interface of a VM.
  • Cloud NAT gateway can only use routes whose next hops are the default internet gateway (for Public NAT) or dynamic/subnet routes (for Private NAT)
  • Cloud NAT never performs NAT for traffic sent to the select external IP addresses for Google APIs and services
  • Cloud NAT gateways are associated with subnet IP address ranges in a single region and a single VPC network.
  • Cloud NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.
  • A Cloud NAT configuration is tied to a VPC network. You can’t choose specific VMs to be served by a Cloud NAT gateway; the configuration applies to all resources belonging to the specified subnets.

Dynamic Port Allocation

  • Dynamic Port Allocation (DPA) allows Cloud NAT to dynamically scale up/down port allocations for instances depending on demand.
  • DPA is configured with minimum and maximum port limits so that it never scales down ports below the minimum, or scales up beyond the maximum.
  • Without DPA, Cloud NAT divides available source ports per external IP equally across all in-scope instances (static port allocation).
  • DPA helps avoid port exhaustion for high-connection VMs while optimizing IP address usage across the fleet.
  • When using DPA with any further configuration changes, established NAT connections might be broken as ports are temporarily reset to the minimum.

Cloud NAT Rules

  • NAT rules let you create access rules that define how Cloud NAT is used to connect to the internet.
  • NAT rules support source NAT based on destination address and source address (source-based NAT rules GA April 2026).
  • NAT rules allow you to assign different NAT IP addresses for specific destination or source address ranges.
  • NAT rules require Endpoint-Independent Mapping to be disabled on the gateway.
  • NAT rules apply only to Public NAT gateways.

NAT64 (IPv6 to IPv4 Translation)

  • NAT64 in Public NAT allows IPv6-only Compute Engine VMs to reach IPv4 destinations on the internet.
  • NAT64 works with DNS64 to form a mechanism that translates communication between IPv6-only environments and legacy IPv4 applications.
  • NAT64 is available only for IPv6-only Compute Engine VM instances for supported machine series (all second generation or earlier series, M3 series).
  • For GKE nodes, serverless endpoints, and regional internet NEGs, Public NAT translates only IPv4 addresses (NAT64 not supported).
  • NAT64 helps organizations transition to IPv6-only infrastructure while maintaining access to existing IPv4 services.

Supported Resources

Resource Public NAT Private NAT
Compute Engine VM instances ✓ ✓
GKE clusters ✓ ✓
Cloud Run, Cloud Run functions, App Engine ✓ ✓
Regional internet NEGs ✓ Not applicable
  • Serverless endpoints (Cloud Run, Cloud Run functions) are supported through Direct VPC egress (recommended) or Serverless VPC Access.
  • App Engine standard environment instances are supported through Serverless VPC Access.

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. You decide to set up Cloud NAT. After completing the configuration, you find that one of your instances is not using the Cloud NAT for outbound NAT. What is the most likely cause of this problem?
    1. The instance has been configured with multiple interfaces.
    2. An external IP address has been configured on the instance.
    3. You have created static routes that use RFC1918 ranges.
    4. The instance is accessible by a load balancer external IP address.
  2. Your organization has two VPC networks with overlapping IP address ranges that need to communicate. Which Cloud NAT feature should you use?
    1. Public NAT with NAT rules
    2. Private NAT for Network Connectivity Center spokes
    3. Public NAT with Dynamic Port Allocation
    4. Standard Tier Cloud NAT
  3. You have IPv6-only Compute Engine VMs that need to access an external IPv4-only API endpoint. What should you configure?
    1. Private NAT with Hybrid NAT
    2. A proxy VM to perform protocol translation
    3. Public NAT with NAT64 and DNS64
    4. Cloud Interconnect with IPv6 support
  4. Your VPC network needs to communicate with an on-premises network that has overlapping subnet ranges, connected via Cloud Interconnect. Which Cloud NAT solution should you use?
    1. Public NAT with manual IP assignment
    2. Private NAT for NCC spokes
    3. Hybrid NAT
    4. NAT64 translation
  5. Which of the following statements about Private NAT are correct? (Choose TWO)
    1. Private NAT supports only TCP and UDP protocols
    2. Private NAT supports auto mode VPC networks
    3. Private NAT supports a maximum of 64,000 simultaneous connections per endpoint
    4. Private NAT supports Endpoint-Independent Mapping
    5. Private NAT supports ICMP protocol
  6. You want different outbound NAT IP addresses to be used based on the source VM IP address. Which Cloud NAT feature supports this?
    1. Dynamic Port Allocation
    2. Private NAT rules
    3. Source-based NAT rules
    4. Standard Tier egress

References

Google Cloud CDN – Caching, Signed URLs & Media CDN

~ Last updated on : ~ jayendrapatil

Google Cloud CDN

  • Google Cloud CDN (Content Delivery Network) uses Google’s global edge network to serve content closer to users, which accelerates websites and applications.
  • Cloud CDN 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 (also referred to as origin servers):
    • 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
    • GKE Ingress and GKE Gateway backends
  • 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.
  • Google Cloud Armor supports edge security policies (applied before CDN lookup for all traffic) and backend security policies (enforced only for cache misses/dynamic content).

Cloud CDN vs Media CDN

  • Cloud CDN is Google Cloud’s web acceleration solution optimized for web content delivery (websites, APIs, and small/medium assets).
  • Media CDN (GA since 2022) is Google Cloud’s media delivery CDN optimized for high-throughput egress workloads such as streaming video (VoD and live) and large file downloads. It uses YouTube’s serving infrastructure.
  • Media CDN complements Cloud CDN — they are separate products for different use cases.
  • Choose Cloud CDN for: websites, APIs, dynamic content caching, small/medium assets.
  • Choose Media CDN for: video streaming, large file downloads, high-throughput media delivery.

Cloud CDN Flow

Google Cloud CDN Response Flow

  • When a user requests content from an external Application Load Balancer, the request arrives at a Google Front End (GFE), which is at the edge of Google’s network as close as possible to the user.
  • GFE uses Cloud CDN if the load balancer’s URL map routes traffic to a backend service or backend bucket that has Cloud CDN configured.
  • Cloud CDN doesn’t perform any URL redirection. The Cloud CDN cache is located at the GFE.
  • Caching happens automatically for all cacheable content, once Cloud CDN is enabled.
  • Cache Hits and Cache Misses
    • A cache is a group of servers that stores and manages content so that future requests for that content can be served faster.
    • Cached content is a copy of cacheable content that is stored on origin servers.
    • Cache Hit – GFE sends the cached response, if the GFE looks in the Cloud CDN cache and finds a cached response to the user’s request.
    • Partial Hit – A request is served partially from cache and partially from a backend. This can happen if only part of the requested content is stored in cache (relevant to byte range requests).
    • Cache Miss – GFE determines that it can’t fulfill the request from the cache, if the content is requested for the first time or has expired or been evicted.
  • Cache Hit Ratio
    • Cache Hit Ratio is the percentage of times that a requested object is served from the cache.
    • Cache hit ratio can be monitored from the Cloud CDN page in Google Cloud Console.
  • Cache Egress and Cache Fill
    • Cache Egress – Data transfer from a cache to the client.
    • Cache Fill – Data transfer to a cache.
  • Cache Eviction
    • Cloud CDN removes or evicts content to insert new content once the cache reaches its capacity.
    • Content evicted is usually the one that hasn’t recently been accessed, regardless of the content’s expiration time.
    • Multiple Google Cloud projects share a common pool of cache space since they are served from the same set of GFEs.
  • Cache Expiration
    • Content in HTTP(S) caches can have a configurable expiration time or Time To Live (TTL).
    • Cloud CDN supports TTL settings and overrides: client TTL, default TTL, and max TTL.
  • Cache Invalidation
    • Cache Invalidation allows one to force an object or set of objects to be ignored by the cache.
    • Invalidations don’t affect cached copies in web browser caches or caches operated by third-party internet service providers.
    • Each invalidation request takes effect in about 10 seconds.
    • Invalidation supports URL path patterns (e.g., /images/* instead of each individual file).
    • Cache Tag Invalidation (GA May 2025) allows grouping objects by arbitrary metadata tags and invalidating them at scale with faster performance and higher rate limits.
  • Cache Preloading
    • Caching is reactive in that an object is stored in a particular cache only if a request goes through that cache and if the response is cacheable.
    • Caches cannot be preloaded except by causing the individual caches to respond to requests.
  • An object stored in one cache does not automatically replicate into other caches; cache fill happens only in response to a client-initiated request.

Cloud CDN Cache Modes

  • Cloud CDN supports three cache modes that define how responses are cached:
    • CACHE_ALL_STATIC (default) – Automatically caches static content (images, CSS, JS, video, audio, web fonts) that does not have no-store, private, or no-cache directives. Responses without caching directives use the configured default TTL.
    • USE_ORIGIN_HEADERS – Requires the origin to set valid caching directives (Cache-Control and Expires headers). Responses without these headers or with no-store/private directives are not cached.
    • FORCE_CACHE_ALL – Unconditionally caches responses, overriding any cache directives set by the origin. Should NOT be used if serving private, per-user content (e.g., dynamic HTML or API responses).
  • Cache modes can be configured per backend service or backend bucket.

Cloud CDN Content Targeting

  • Content Targeting (GA May 2025) helps cache and deliver assets customized for end-user contexts.
  • Supports:
    • Device characterization – serve different content based on device type (mobile, tablet, desktop).
    • Geo-targeting – serve content customized by user’s geographic location.
  • Useful for implementing responsive websites, language customization, and currency settings.
  • Content targeting works with cache keys to serve appropriate cached content per user context.

Cloud CDN Signed URLs and Signed Cookies

  • Cloud CDN signed URLs and signed cookies help serve responses from Google Cloud’s globally distributed caches, even for authorized requests.
  • Signed URLs
    • A Signed URL provides user read access to a private resource for a limited time without needing a Google Account.
    • Anyone who knows the URL can access the resource until the expiration time is reached or the key is rotated.
    • Cryptographic keys are created on a backend service or bucket, or both.
    • The signed URL contains authorization within the request URL with selected elements hashed and cryptographically signed using a strongly generated random key.
    • Best for controlling access to individual URLs.
  • Signed Cookies
    • Signed cookies provide access to a URL prefix — all requests under that prefix are automatically authenticated.
    • Signed cookies are better suited when you need to authorize access to multiple restricted files.
    • Avoid re-signing URLs for every request or embedding custom logic in applications.

Cloud CDN Private Origin Authentication

  • Private Origin Authentication (GA September 2023) gives Cloud CDN long-term resource access to private Amazon S3 buckets or other compatible object stores.
  • Limits connections to your private origins and prevents users from directly accessing them.
  • Uses AWS Signature Version 4 to sign requests to S3-compatible backends.
  • The backend verifies that requests genuinely come from your Cloud CDN setup, allowing the bucket to remain private.
  • Configurable through both gcloud CLI and Google Cloud Console.

Cloud CDN Service Extensions (Edge Compute)

  • Service Extensions for Cloud CDN (GA November 2025) lets you add custom code to the request processing path of global external Application Load Balancers.
  • Two types of extensions:
    • Edge Extensions (pre-cache) – run before Cloud CDN evaluates the cache, allowing you to manipulate request headers to influence caching and routing decisions.
    • Traffic Extensions (post-cache) – run after content is served from cache, allowing manipulation of cached content on the response path.
  • Use cases include: custom header manipulation, A/B testing, authentication at the edge, exception handling, and custom logging.

Cloud CDN with GKE Gateway

  • GKE Gateway integration (GA April 2026) allows configuring Cloud CDN using the Gateway API for workloads running on GKE.
  • Cloud CDN caching behavior is defined using GCPHTTPFilter resources attached to HTTPRoute resources.
  • Gateway API lets you configure, manage, and fine-tune caching configurations for different segments of traffic.
  • Filters support configuration of cache policies including cache modes and TTL settings.

Cloud CDN Additional Features

  • Cache Policies in URL Maps (GA May 2026) – Configure CDN cache policies at various levels of a URL map with granular control based on hostnames, URL paths, HTTP headers, and query parameters.
  • TLS 1.3 Early Data / 0-RTT (February 2025) – External Application Load Balancer and Cloud CDN support early data for TLS 1.3, allowing clients to include HTTP request data with a TLS handshake, improving performance for resumed connections.
  • Negative Caching – Allows configuring Cloud CDN to cache certain error responses (e.g., 404, 410) to reduce origin load for requests that consistently result in errors.
  • Stale Content Serving – Cloud CDN can serve stale (expired) content while asynchronously revalidating with the origin, reducing latency for users.
  • Dynamic Compression – Cloud CDN can dynamically compress responses using gzip or Brotli when serving content to clients that support it.
  • Predefined Dashboards (GA October 2025) – Default dashboards for monitoring traffic distribution and cache effectiveness without manual configuration.
  • Custom Cache Keys – Cache keys can include or omit any combination of protocol, host, query string, and HTTP headers to improve cache hit ratio.
  • Byte Range Requests – Cloud CDN can initiate multiple cache fill requests in reaction to a single client request when the origin supports byte ranges.

Cloud CDN Best Practices

  • Cache static content using CACHE_ALL_STATIC mode for automatic caching of common static content types.
  • Use proper expiration time or TTL for time-sensitive data.
  • Use custom cache keys to improve cache hit ratio.
    • Cloud CDN, by default, uses the entire request URL to build the cache key.
    • Cache keys can be customized to include or omit any combination of protocol, host, query string, and HTTP headers.
  • Use versioning to update content instead of cache invalidation.
    • Versioning content serves a different version of the same content, effectively replacing old content before the cache entry expires.
    • Invalidation is eventually consistent and should be used as a last resort.
  • Use cache tags for surgical invalidation instead of broad pattern-based invalidation when you need to purge specific groups of objects.
  • Enable negative caching for error responses to reduce origin load.
  • Use stale content serving (stale-while-revalidate) to improve latency for users while content is refreshed.
  • Enable dynamic compression for text-based content to reduce bandwidth usage.
  • Use Google Cloud Armor edge security policies for DDoS protection applied before CDN lookup.

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 serve static website content globally with minimum latency. The content is hosted on Compute Engine instances. Which Google Cloud service should they use?
    1. Cloud DNS
    2. Cloud CDN with global external Application Load Balancer
    3. Cloud Interconnect
    4. Media CDN
    Show Answer

    Answer: b – Cloud CDN with external Application Load Balancer caches static content at Google’s edge locations for low-latency delivery.

  2. Your organization hosts video-on-demand (VoD) content and needs a CDN solution optimized for high-throughput media streaming. Which Google Cloud product is best suited?
    1. Cloud CDN
    2. Media CDN
    3. Cloud Storage with multi-region buckets
    4. Cloud Interconnect
    Show Answer

    Answer: b – Media CDN is optimized for high-throughput egress workloads like streaming video and large file downloads, using YouTube’s serving infrastructure.

  3. A company needs to cache content from a private Amazon S3 bucket using Google Cloud CDN without making the bucket public. What feature should they enable?
    1. Signed URLs
    2. Signed Cookies
    3. Private Origin Authentication
    4. Cloud Storage Transfer Service
    Show Answer

    Answer: c – Private Origin Authentication allows Cloud CDN to sign requests to S3-compatible backends using AWS Signature V4, keeping the bucket private.

  4. Which Cloud CDN cache mode should you use if you want to unconditionally cache all responses, including dynamic content, regardless of origin cache directives?
    1. USE_ORIGIN_HEADERS
    2. CACHE_ALL_STATIC
    3. FORCE_CACHE_ALL
    4. CACHE_DYNAMIC
    Show Answer

    Answer: c – FORCE_CACHE_ALL unconditionally caches responses, overriding origin cache directives. Should not be used with private, per-user content.

  5. You need to invalidate a large number of cached objects in Cloud CDN that belong to the same content group. What is the most efficient approach?
    1. Invalidate each URL individually
    2. Use URL path patterns with wildcards
    3. Use cache tag-based invalidation
    4. Wait for TTL expiration
    Show Answer

    Answer: c – Cache tag invalidation (GA May 2025) allows grouping objects by arbitrary metadata tags and invalidating them at scale with better performance and higher rate limits.

  6. Your application needs to serve different cached content based on user device type (mobile vs desktop). Which Cloud CDN feature supports this?
    1. Custom cache keys
    2. Content Targeting
    3. Signed URLs
    4. Cache Modes
    Show Answer

    Answer: b – Content Targeting (GA May 2025) supports device characterization and geo-targeting for serving customized cached content.

  7. You want to add custom authentication logic at the edge before Cloud CDN serves cached content. What feature should you use?
    1. Cloud Armor security policies
    2. Signed URLs
    3. Service Extensions edge extensions (pre-cache)
    4. Backend service IAM policies
    Show Answer

    Answer: c – Service Extensions edge extensions (GA November 2025) run before Cloud CDN evaluates the cache, allowing custom code to manipulate requests and influence caching/routing.

  8. Which of the following are valid Cloud CDN backend (origin) types? (Choose THREE)
    1. Managed instance groups
    2. Cloud SQL instances
    3. Cloud Storage buckets
    4. Internet NEGs (custom origins)
    5. Cloud Memorystore
    Show Answer

    Answer: a, c, d – Cloud CDN supports instance groups, Cloud Storage buckets, internet NEGs, zonal NEGs, serverless NEGs, and GKE backends.

References

Google Cloud Compute Engine Snapshots & Backups

~ Last updated on : ~ jayendrapatil

Compute Engine Snapshots

  • Snapshots provide periodic backup of Persistent Disk and Google Cloud Hyperdisk volumes.
  • Snapshots incrementally back up data from the disks.
  • Snapshots are global resources by default, so any snapshot is accessible by any resource within the same project. Regionally scoped snapshots (Preview) are also available for data residency requirements.
  • Snapshots can be shared across projects.
  • Storage costs for disk snapshots charge only for the total size of the snapshot.
  • Snapshots once created with the current state of the disk, can be restored as a new disk.
  • Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of the data.
  • Snapshots can be created from disks even while they are attached to running virtual machine (VM) instances.
  • Lifecycle of a snapshot created from a disk attached to a running VM instance is independent of the lifecycle of the VM instance.
  • Standard and archive snapshots can be stored in either one Cloud Storage multi-regional location, such as asia, or one Cloud Storage regional location, such as asia-south1.
  • A multi-regional storage location provides higher availability and might reduce network costs when creating or restoring a snapshot.
  • A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.

Snapshot Types

  • Compute Engine provides three types of snapshots: Standard, Archive, and Instant.
  • All three types capture the contents of a disk at a specific point in time but differ in retention behavior, recovery time, and storage location.

Standard Snapshots

  • Provide geo-redundant data backup stored in one or more regions, separate from the source disk.
  • Best for disaster recovery and regular backups.
  • Support both Persistent Disk and Hyperdisk volumes.
  • Can be created with snapshot schedules for automated backups.
  • Are NOT deleted when the source disk is deleted.
  • Offer faster data recovery times than archive snapshots.

Archive Snapshots

  • Same benefits as standard snapshots (incremental chains, compression, encryption) but at lower cost.
  • Best suited for compliance, audit, and long-term cold storage use cases.
  • Have a 90-day minimum billing period and charges for retrievals.
  • Have the longest data recovery times but offer the most cost-efficient storage.
  • Cannot be created with snapshot schedules.
  • Are NOT deleted when the source disk is deleted.
  • Stored in separate incremental snapshot chains from standard snapshots.

Instant Snapshots

  • Introduced in August 2024, instant snapshots provide near-instantaneous, high-frequency, point-in-time checkpoints of a disk.
  • Provide in-place data backup stored in the same zone or region as the source disk.
  • Offer the lowest and best recovery times — RPO of seconds and RTO in tens of seconds.
  • Created in seconds with no performance impact to the underlying disk.
  • Are incremental — only store changed data blocks since the previous instant snapshot.
  • Are deleted when the source disk is deleted (lifecycle tied to source disk).
  • Not redundant — stored only in the same zone/region as the source disk.
  • Cannot be created with snapshot schedules.
  • Can be converted to standard or archive snapshots for geo-redundant, long-term storage.
  • Support Persistent Disk and most Hyperdisk types (except Hyperdisk ML and Hyperdisk Throughput).
  • Use cases include:
    • Rapid recovery from user error, application failures, and file system corruption.
    • Backup verification workflows (create snapshot, restore, verify consistency).
    • Taking restore points before application upgrades for rapid rollback.
    • Improving developer productivity with fast restores during development cycles.

Snapshot Type Comparison

Feature Standard Archive Instant
Best for Geo-redundant DR backup Long-term cold storage, compliance In-place backup, rapid restore
Storage Location Multi-region or regional (separate from source) Multi-region or regional (separate from source) Same zone/region as source disk
Recovery Time Minutes Longest (minutes to hours) Seconds
Redundancy Geo-redundant Geo-redundant Not redundant (same zone only)
Hyperdisk Support Yes Yes Yes (except ML & Throughput)
Snapshot Schedules Yes No No
Deleted on Source Disk Deletion No No Yes

Snapshot Scopes (Preview)

  • Snapshots can be created as globally scoped (default) or regionally scoped.
  • Globally scoped snapshots can be created and restored in any region without restriction.
  • Regionally scoped snapshots ensure all snapshot data and metadata are co-located within the scoped region.
    • Restrict allowed snapshot creation and restore locations.
    • Help control network costs.
    • Enhance resiliency to global outages.
    • Provide additional data security by limiting locations where data can be created/restored.
  • Regionally scoped snapshots can only be stored in Cloud Storage regional locations (not multi-regional).
  • Cannot convert a globally scoped snapshot to a regionally scoped snapshot — must create a new one.

Snapshot Creation

  • Snapshots are incremental and automatically compressed, so that they can be regularly created on a Persistent Disk or Hyperdisk faster and at a lower cost than regularly creating a full image of the disk.
  • Incremental snapshots work as follows:
    • The first successful snapshot of a disk is a full snapshot that contains all the data on the disk.
    • The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since the first snapshot isn’t included. Instead, it contains references to the first snapshot for any unchanged data.
    • Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.
  • To ensure the reliability of snapshot history, a snapshot might occasionally capture a full image of the disk automatically.

Snapshot Chains

  • Standard snapshots can be created in distinct snapshot chains by specifying a chain name at creation time.
  • Each new snapshot with the same chain name is based incrementally on the last successful snapshot created with that chain name.
  • Useful for advanced use cases like chargeback tracking across separate incremental chains.
  • Standard and archive snapshots are stored in separate incremental chains.

Snapshot Deletion

  • Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot.
  • For unchanged data, snapshots reference the data in previous snapshots.
  • Warning: Deleting a snapshot is irreversible. You can’t recover a deleted snapshot.
  • When a snapshot is deleted:
    • If the snapshot has no dependent snapshots, it is deleted outright.
    • If the snapshot does have dependent snapshots:
      • Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
      • Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
      • The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
  • Deleting a snapshot does not necessarily delete all the data on the snapshot because subsequent snapshots might require that information.
  • To definitively delete data from the snapshots, you should delete all snapshots.
  • If a disk has a snapshot schedule, you must detach the schedule from the disk before deleting it.

Snapshot Schedules

  • Snapshot schedules create standard snapshots at specified intervals to provide automated, geo-redundant disk backups.
  • Support both Persistent Disk and Hyperdisk volumes (zonal and regional).
  • Snapshot schedules are a best practice for backing up Compute Engine workloads — available at no additional charge.
  • Configure schedules with:
    • Frequency: Hourly (1-23 hour intervals), daily, or weekly.
    • Retention policy: Maximum number of days to retain snapshots with auto-deletion of older ones.
    • Source disk deletion behavior: What happens to automatic snapshots when the source disk is deleted.
    • Storage location: Region or multi-region for snapshot storage.
  • Application consistent snapshots can be configured for:
    • Windows: VSS (Volume Shadow Copy Service) snapshots.
    • Linux: Guest-flush option with pre/post snapshot scripts (Persistent Disk only).
  • Snapshot schedules have separate frequency considerations and don’t contribute to the manual snapshot frequency limit.

Backup and DR Service

  • Google Cloud Backup and DR Service provides enhanced protection with immutable and indelible backups of Compute Engine instances.
  • Offers an out-of-the-box backup solution with seamless backup management across projects.
  • Supports backup plans that can be applied to instances during or after creation.
  • Provides features beyond snapshot schedules:
    • Immutable backups protected against deletion for a specified retention period.
    • Centralized backup management console.
    • Cross-region backup storage for disaster recovery.
    • Scheduled backups (daily, weekly, monthly, yearly).
  • Uses Persistent Disk snapshots under the hood to incrementally back up data at the instance level.

Snapshot Best Practices

  • Security: Only grant snapshot-related IAM permissions (compute.snapshots.useReadOnly, compute.instantSnapshots.useReadOnly) to trusted principals to prevent unintended privilege escalation.
  • Crash Consistent vs Application Consistent:
    • Crash consistent: Default behavior — captures disk state as if the machine crashed (may have pending writes in transit).
    • Application consistent: Pause applications and flush writes before snapshot to capture complete application state.
  • If creating a snapshot while an application is running, prepare disk for consistency:
    • Pause application/processes that write data, flush disk buffers.
    • Unmount disk completely.
    • For Windows, use VSS snapshots.
    • For Linux on Persistent Disk, use guest-flush with pre/post scripts.
    • For Linux on Hyperdisk, manually pause the application before creating the snapshot.
  • Use snapshot schedules as a best practice to back up your Compute Engine workloads.
  • Use instant snapshots or disk clones instead of standard snapshots when you need an immediate copy in the same zone.
  • Schedule snapshots during off-peak hours (avoid midnight peaks).
  • Snapshot frequency limit: You can snapshot a specific disk at most 6 times every 60 minutes. Avoid taking snapshots more often than once per hour.
  • Use multiple disks for large data volumes. Larger amounts of data create larger snapshots, which cost more and take longer.
  • Run fstrim before snapshot (Linux) or enable the discard mount option to clean up space, reducing snapshot size and creation time.
  • Create an image from an infrequently used snapshot, instead of using the snapshot itself repeatedly (saves networking costs).
  • Use journaling file systems like ext4 to reduce the risk that data is cached without being written to disk.
  • Wait for new snapshots to finish before taking subsequent snapshots from the same disk to avoid duplicate effort.

Snapshot Storage Locations

  • Standard and archive snapshots can be stored in:
    • Cloud Storage multi-regional locations (e.g., asia, us) — highest availability and resilience.
    • Cloud Storage regional locations (e.g., asia-south1, us-central1) — more control over data placement.
  • Regionally scoped snapshots can only be stored in regional locations.
  • You cannot change the storage location of an existing snapshot.
  • Snapshot settings define a default storage location for all project snapshots (configurable).
  • Network charges apply for cross-region snapshot creation or restoration.
  • To minimize costs, store snapshots in the same region as the source disk.

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. You have a workload running on Compute Engine that is critical to your business. You want to ensure that the data on the boot disk of this workload is backed up regularly. You need to be able to restore a backup as quickly as possible in case of disaster. You also want older backups to be cleaned automatically to save on cost. You want to follow Google-recommended practices. What should you do?
    1. Create a Cloud Function to create an instance template.
    2. Create a snapshot schedule for the disk using the desired interval.
    3. Create a cron job to create a new disk from the disk using gcloud.
    4. Create a Cloud Task to create an image and export it to Cloud Storage.
  2. Your application is running on Compute Engine and you need to take point-in-time backups of your Persistent Disk that allow restoration within seconds. The backup must be stored locally for fastest recovery. Which solution should you use?
    1. Create a standard snapshot and store it in the same region.
    2. Create an archive snapshot for long-term storage.
    3. Create an instant snapshot of the disk.
    4. Create a machine image of the entire VM.
  3. You need to retain disk backups for compliance purposes for 2 years, and you rarely need to access them. You want the lowest cost option. What should you do?
    1. Create standard snapshots on a schedule.
    2. Create archive snapshots of the disk.
    3. Create instant snapshots and convert them to standard snapshots.
    4. Export disk images to Cloud Storage Coldline.
  4. You are performing a software upgrade on a Compute Engine VM and want a rapid rollback option if the upgrade fails. You need to restore the disk state in seconds. What is the recommended approach?
    1. Create a standard snapshot before the upgrade.
    2. Create a machine image before the upgrade.
    3. Create an instant snapshot before the upgrade.
    4. Clone the disk before the upgrade.
  5. You delete a snapshot from an incremental chain. What happens to the data that is needed by subsequent snapshots?
    1. The data is permanently lost.
    2. The data is moved to the next snapshot in the chain.
    3. All dependent snapshots are also deleted.
    4. The source disk is updated with the snapshot data.
  6. You need to ensure your Compute Engine disk snapshots comply with data residency requirements and are restricted to a specific region. What should you do?
    1. Store globally scoped snapshots in a regional location.
    2. Use instant snapshots which are stored in the same zone.
    3. Create regionally scoped snapshots with restricted creation and restore locations.
    4. Use archive snapshots with a specific storage location.

References