What Cloud CDN Does
Cloud CDN uses Google's globally distributed edge caching infrastructure, the same network that serves YouTube and Search, to cache content close to end users so that repeat requests for the same object, like a product image or a JavaScript bundle, are served from a nearby edge point-of-presence instead of traveling all the way back to your origin server. It works by attaching directly to a Global external Application Load Balancer's backend service or bucket, meaning enabling it is a configuration flag rather than deploying separate infrastructure, and cached responses can cut both latency for users and egress load on your origin.
Cricket analogy: This is like a cricket highlights clip being cached on regional broadcast servers near fans, so someone in Melbourne doesn't have to stream it all the way from a server in Mumbai every single time.
Cache Keys, Cache Modes, and Cache-Control
Cloud CDN decides whether to serve a cached copy using a cache key, which by default includes the full URL, and can be customized to include or exclude specific query parameters, headers, or the protocol, which matters because two URLs that only differ by a tracking parameter like ?utm_source=twitter would otherwise be cached as separate objects and waste cache space. Cache modes control caching behavior: CACHE_ALL_STATIC automatically caches common static file extensions and any response with valid caching headers, USE_ORIGIN_HEADERS respects only the origin's Cache-Control and Expires headers, and FORCE_CACHE_ALL caches everything regardless of headers, overriding no-cache directives, which is powerful but risky for dynamic or personalized content.
Cricket analogy: This is like a scorer deciding whether two nearly identical scorecards from the same match, one with a minor typo in a fielder's name, should be treated as the same official record or two separate ones.
Cache Invalidation and Signed URLs
When origin content changes before a cached object's TTL expires, you can force Cloud CDN to drop the stale copy using a cache invalidation request targeting a specific path or wildcard pattern, which propagates across Google's edge network typically within minutes, though invalidations are rate-limited and best reserved for genuine emergencies rather than routine deploys, where versioned file names (like app.a1b2c3.js) are the more scalable practice. For content that shouldn't be publicly cacheable by just anyone, Cloud CDN supports signed URLs and signed cookies, which use a cryptographic signature and expiration timestamp to grant time-limited access to specific cached objects, useful for paid video content or private downloads.
Cricket analogy: This is like a team urgently correcting a wrongly published scorecard mid-match, versus the standard practice of simply publishing a freshly dated new scorecard for each innings instead of editing the old one.
# Enable Cloud CDN on a backend service (via gcloud, shown as equivalent config)
# gcloud compute backend-services update web-backend-service \
# --enable-cdn \
# --cache-mode=CACHE_ALL_STATIC \
# --default-ttl=3600 \
# --max-ttl=86400 \
# --global
cdnPolicy:
cacheMode: CACHE_ALL_STATIC
defaultTtl: 3600
maxTtl: 86400
clientTtl: 3600
negativeCaching: true
cacheKeyPolicy:
includeQueryString: falseNegative caching lets Cloud CDN briefly cache error responses, like a 404 or 500, for a short configurable TTL, which protects an overloaded or failing origin from being hammered with repeated requests for a known-broken resource while it recovers.
Enabling FORCE_CACHE_ALL or misconfiguring the cache key to exclude a query parameter that actually differentiates content, such as a locale or user-specific parameter, can cause Cloud CDN to serve the wrong cached response to the wrong user. Always test cache key configuration carefully for any endpoint that returns personalized or region-specific content.
- Cloud CDN caches content at Google's global edge locations, attaching to a load balancer's backend service or bucket as a configuration flag.
- The cache key determines what counts as a distinct cached object, and can be customized to include or exclude query parameters and headers.
- Cache modes range from respecting only origin headers (USE_ORIGIN_HEADERS) to caching everything regardless of headers (FORCE_CACHE_ALL).
- Cache invalidation forcibly drops stale cached content but is rate-limited; versioned file names scale better for routine deploys.
- Signed URLs and signed cookies grant cryptographically time-limited access to specific cached objects for paid or private content.
- Negative caching briefly caches error responses to protect a struggling origin from repeated requests for a broken resource.
- Misconfigured cache keys that ignore a content-differentiating parameter can cause the wrong cached response to be served to users.
Practice what you learned
1. How is Cloud CDN enabled for a website served through GCP load balancing?
2. Why does the cache key configuration matter for URLs that differ only by a tracking query parameter?
3. What is the risk of enabling FORCE_CACHE_ALL as the cache mode?
4. What is the recommended practice for routine deploys instead of relying on frequent cache invalidation requests?
5. What do Cloud CDN signed URLs provide?
Was this page helpful?
You May Also Like
Cloud Load Balancing Basics
Learn how GCP's fully managed, globally distributed load balancers route traffic to healthy backends, and the key differences between global, regional, external, and internal load balancer types.
Cloud DNS Basics
Understand how Google Cloud DNS serves authoritative public and private zones from a global anycast network, the core record types you'll configure, and how DNSSEC and delegation establish trust.
VPC Networks in GCP
Understand how Google Cloud's Virtual Private Cloud works as a global, software-defined network spanning regional subnets, and how VPC Peering and Shared VPC connect and centralize networks across projects.