Cloud CDN

Cloud CDN uses Google’s globally distributed edge points of presence to cache HTTP(S) load balanced content close to your users.

Google Cloud CDN – Content Delivery Network

~ 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

    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

    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

    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

    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

    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

    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

    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

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

References

Google Cloud Networking Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Virtual Private Cloud

  • Virtual Private Cloud (VPC) provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
  • VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
  • Subnets are regional resources and each subnet defines a range of IP addresses
  • Network firewall rules
    • control the Traffic to and from instances.
    • Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
    • Firewall rules are defined to allow or deny traffic and are executed within order with a defined priority
    • Highest priority (lower integer) rule applicable to a target for a given type of traffic takes precedence
  • Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
  • Private access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
  • Shared VPC to keep a VPC network in a common host project shared with service projects. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network
  • VPC Network Peering allow VPC networks to be connected with other VPC networks in different projects or organizations.
  • VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
  • Primary and Secondary IP address cannot overlap with the on-premises CIDR
  • VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network; VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources.
  • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Cloud Load Balancing

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

Cloud CDN

  • caches website and application content closer to the user
  • uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
  • works with external HTTP(S) Load Balancing to deliver content to the users
  • Cloud CDN content can be sourced from various types of backends
    • Instance groups
    • Zonal network endpoint groups (NEGs)
    • Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
    • Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
    • Buckets in Cloud Storage
  • Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
  • recommends
    • using versioning instead of cache invalidation
    • using custom keys to improve cache hit ration
    • cache static content

Cloud VPN

  • securely connects the peer network to the VPC network or two VPCs in GCP through an IPsec VPN connection.
  • encrypts the data as it travels over the internet.
  • only supports site-to-site IPsec VPN connectivity and not client-to-gateway scenarios
  • 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
  • Cloud VPN HA
    • provides a high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
    • provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.
  • supports up to 3Gbps per tunnel with a maximum of 8 tunnels
  • supports static as well as dynamic routing using Cloud Router
  • supports IKEv1 or IKEv2 using a shared secret

Cloud Interconnect

  • Cloud Interconnect provides two options for extending the on-premises network to the VPC networks in Google Cloud.
  • Dedicated Interconnect (Dedicated connection)
    • provides a direct physical connection between the on-premises network and Google’s network
    • requires your network to physically meet Google’s network in a colocation facility with your own routing equipment
    • supports only dynamic routing
    • supports bandwidth to 10 Gbps minimum to 200 Gbps maximum.
  • Partner Interconnect (Use a service provider)
    • provides connectivity between the on-premises and VPC networks through a supported service provider.
    • supports bandwidth to 50 Mbps minimum to 10 Gbps maximum.
    • provides Layer 2 and Layer 3 connectivity
      • For Layer 2 connections, you must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment
      • For Layer 3 connections, the service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
  • Single Interconnect connection does not offer redundancy or high availability and its recommended to
    • use 2 in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
    • use 4 with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone)
    • Cloud Routers are required one in each Google Cloud region
  • Cloud Interconnect does not encrypt the connection between your network and Google’s network. For additional security, use application-level encryption or your own VPN.
  • Currently, Cloud VPN can’t be used with Dedicated Interconnect.

Cloud Router

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

Cloud DNS

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