Google Cloud CDN Guide: Backends & Cache Modes

Google Cloud CDN Guide: Backends & Cache Modes

What Is Cloud CDN

Google Cloud CDN uses Google's global edge network (GFE) to serve content closer to users, speeding up websites and applications. It is not a standalone gateway; it works with the external Application Load Balancer: the load balancer provides the frontend IP and port, while Cloud CDN handles caching and delivery. So the prerequisite is a load balancer, then you enable caching on the backend service.

Step 1: Configure a Backend Service

Cloud CDN content can come from several backends:

• VM instance groups: run web server software, good for mixed dynamic/static workloads.
• Cloud Storage buckets (backend buckets): ideal for pure static assets, images, and packages.
• Managed instance groups and NEGs (network endpoint groups), among others.

Tick Enable Cloud CDN on the load balancer backend service to start caching all cacheable content. Pair it with Cloud Armor security policies: edge policies apply to all traffic before the CDN, while backend policies only apply to dynamic origin requests.

Teams that live in the CLI or write infrastructure as code can enable the CDN directly on an existing backend service with gcloud:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
  --global \
  --enable-cdn \
  --cache-mode=CACHE_ALL_STATIC \
  --default-ttl=3600

Here --cache-mode and --default-ttl are the CLI equivalents of the cache mode and default TTL in the console — the flags you reach for almost every day when writing Terraform or deployment scripts.

Step 2: Choose a Cache Mode

The origin uses HTTP response headers (such as Cache-Control) to indicate what can be cached, and you can override behavior with a cache mode in the console:

• USE_ORIGIN_HEADERS: fully honor origin response headers; flexible but requires correct origin setup.
• CACHE_ALL_STATIC: cache all static content, ignoring origin headers.
• FORCE_CACHE_ALL: force caching of everything, including dynamic responses, for known-safe endpoints.

The trade-offs between the three are easier to see side by side:

For a static site that needs quick wins, start with CACHE_ALL_STATIC; only move to FORCE_CACHE_ALL for endpoints you have confirmed are side-effect-free.

You can also set custom cache keys (ignore query parameters, group by header), TTL overrides, and negative caching (short caching of 404s and similar). Key granularity decides the balance between hit ratio and freshness — for example, ignoring the query string while grouping by Accept-Language:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
  --global --enable-cdn \
  --cache-key-policy-include-query-string=false \
  --cache-key-policy-include-http-header=Accept-Language

Requests to the same URL now share the cache, while users of different languages still get their own version. For hit-ratio tuning see CDN cache hit ratio optimization, and for broader strategy see CDN cache strategy.

Step 3: Manage the Cache and Invalidations

• Cache hit/miss: on a hit, GFE returns cached content directly; on a miss, it fetches from the origin and fills the cache.
• Invalidation: after updates, invalidate in the console, either by prefix or per URL.
• Expiration vs eviction: expiration decides when content is "stale," while eviction is driven by cache-space pressure; they are independent, and popular content tends to stay cached longer.

Step 4: Set Up Signed URLs and Signed Cookies

To protect private content, use signed URLs or signed cookies:

• Signed URLs: append an expiry and signature to the URL, suitable for temporary sharing and download sites.
• Signed cookies: better when you need to protect a whole site for logged-in users.
• Both support custom URL prefixes, IP ranges, and start/expiry time constraints, and combine with private Cloud Storage access.

Step 5: Understand Quotas and Pricing

Cloud CDN bills by cache egress, cache fill, and cache lookup; higher hit ratios mean lower cost. Accounts have quotas on backend services, invalidations, and more, which can be raised in the IAM and Quotas page. For cost tuning see CDN cost optimization guide.

A Real Scenario: Speeding Up a Static Product Site

Say your product site lives in a Cloud Storage bucket, roughly 40 MB of assets, with about 60% of visitors in Europe and the US. Before enabling Cloud CDN, users in Tokyo or Frankfurt hit the origin every time — a single region — and hero images often took two to three seconds to render. After enabling it, the edge serves cache hits without going to origin, TTFB typically drops to 100-200 ms, and egress shifts from "full origin fetch" to "edge egress." With a high hit ratio, the bandwidth bill can easily fall by more than half.

The whole payoff depends on the hit ratio. If frequently parameterized URLs fragment your above-the-fold assets, the ratio never rises; see the hit-ratio article above for the fix. One point that is easy to overlook: if origin requests queue at the source, the CDN just concentrates pressure into the cache-miss moment, so cache warming and origin scaling matter just as much.

When to Choose It

Cloud CDN suits teams already on Google Cloud that want load balancing, Cloud Armor, and GKE integrated; GKE clusters can enable Cloud CDN through the Ingress BackendConfig with near-zero extra operations. The downside is that you must first build a load balancer architecture, which feels heavy for a pure static small site. For selection see our CDN provider selection guide.

16IDC Take

Cloud CDN is essentially "caching built into the load balancer": entry, routing, caching, and security (Cloud Armor) live in one Google network, ideal for cloud-native teams. If your site runs on a plain VPS and you only want static acceleration, a standalone CDN is lighter to adopt. More content in the CDN acceleration category.

Reference: Cloud CDN overview https://cloud.google.com/cdn/docs/overview · Cache keys https://cloud.google.com/cdn/docs/caching · Signed URLs https://cloud.google.com/cdn/docs/using-signed-urls
Source: https://cloud.google.com/cdn/docs/overview