Google Cloud CDN Setup 2026: The Production Playbook

The most expensive line in a Google Cloud CDN bill is rarely the one teams budget for. It is cache fill — the origin-to-edge traffic that a 72% hit ratio silently doubles. A Google Cloud CDN setup that looks correct in the console can still push 28% of every gigabyte through internet egress at full rate, and because cache fill bills separately from cache egress, the invoice splits across two SKUs that never appear side by side on a dashboard. This playbook covers the full path: backend bucket versus backend service, the four cache modes and exactly which TTL wins when headers disagree, signed URLs and key rotation, the invalidation rate limits nobody documents loudly enough, and a worked monthly bill at 200 TB so you can see where the money actually goes.

Google Cloud CDN setup: backend bucket vs backend service

Cloud CDN is not a standalone product you point a hostname at. It is a flag on a backend attached to a global external Application Load Balancer. That single architectural fact drives every decision that follows. Regional external ALBs still do not support Cloud CDN as of 2026, so if your forwarding rule is regional, the checkbox does not exist.

Two backend types matter:

• Backend bucket — wraps a Cloud Storage bucket. No health checks, no NEGs, no capacity scaler. Best for immutable static assets, HLS/DASH segments, installer binaries, game patch files. Use uniform bucket-level access and Standard storage class; Nearline and Coldline add per-GB retrieval charges on every cache miss, which quietly taxes your long-tail content.
• Backend service — wraps instance groups, serverless NEGs (Cloud Run, App Engine), internet NEGs (external origins), or GKE NEGs. This is where you get health checks, outlier detection, connection draining, and Cloud Armor policies. Required for API, SSR, and anything that needs origin logic.

Split them in the URL map rather than forcing one backend to do both jobs. A typical 2026 layout: static path prefixes to a CDN-enabled backend bucket, media manifests to a second bucket with shorter TTLs, and everything else to a serverless NEG backend service with Cloud CDN either off or set to cache-by-origin-headers only. Mixing SSR HTML and hashed assets behind one backend is the single most common reason hit ratios stall in the 60s.

Multi-region buckets and cache fill in 2026

A multi-region bucket removes the single-region tail latency on misses but introduces a subtlety: cache fill from Cloud Storage into Cloud CDN is billed by the origin-to-edge region pair. As of 2026, dual-region and multi-region Cloud Storage origins carry lower cache-fill rates than they did in 2024, while intercontinental internet egress rates moved up. The net effect is that keeping your origin inside Google's network is now materially cheaper than fronting an external origin over an internet NEG. If you are still using an internet NEG pointed at a non-Google origin, re-run the numbers.

Verify the plumbing before touching cache policy: HTTPS target proxy on the forwarding rule, certificate in ACTIVE state, and for backend services, health checks returning 200. Google-managed certificates typically provision in minutes but the documented ceiling is 24 hours, and the failure mode is a FAILED_NOT_VISIBLE state that means your DNS A/AAAA records are not yet pointing at the anycast IP. Provision the IP, set DNS, then create the certificate.

GCP CDN caching: the four cache modes and TTL precedence

This is where most configurations go wrong, because the console presents cache modes as a simple dropdown and hides the precedence rules.

Precedence, in order: with USE_ORIGIN_HEADERS, the origin's max-age or s-maxage wins and your configured default TTL is ignored for responses that carry directives. Your maximum TTL clamps origin values downward. Your default TTL only applies to responses that have no directives — and under USE_ORIGIN_HEADERS, those responses are not cached at all. Under CACHE_ALL_STATIC and FORCE_CACHE_ALL, default TTL fills the gap; under FORCE_CACHE_ALL, client TTL also overrides what the browser sees. Client TTL cannot exceed max TTL.

Practical settings for immutable hashed assets in 2026: origin emits public with a one-year max-age and the immutable directive, max TTL matching, client TTL matching. For HTML or manifests: short origin s-maxage in the tens of seconds, stale-while-revalidate configured through serve-stale so a slow origin does not become a user-visible outage.

Cache keys are where hit ratio is won

Default cache keys include protocol, host, and the full query string. Every analytics parameter appended by a marketing team fragments your cache. Use the included-query-parameters allowlist rather than the exclusion list — allowlists fail closed. Strip host from the key when multiple hostnames serve identical content. Add named headers or cookies to the key only when the response genuinely varies on them, and never add a session cookie to a key unless you enjoy a hit ratio of zero.

Broad Vary headers do the same damage from the origin side. Vary on Accept-Encoding is fine. Vary on User-Agent multiplies your object count by the size of the UA space and is almost never what you want in 2026 — negotiate on Accept or Client Hints and keep the variant count in single digits.

Negative caching deserves an explicit policy rather than defaults. Cache 404 and 410 for a few minutes, 301 and 308 for longer, and 500/502/503/504 for a handful of seconds. That last one is the difference between an origin hiccup and an origin stampede.

Signed URLs, signed cookies, and SSL

Signed URLs work at the backend level. Create a signing key on the backend bucket or backend service, then construct URLs carrying the key name, an expiration timestamp, and the signature. Cloud CDN validates at the edge, so unauthorized requests never reach the origin — that is the whole point, and it is why signed URLs beat origin-side token checks for high-fanout media.

Signed cookies are the better fit for HLS and DASH, where a single manifest pulls hundreds of segment URLs. One cookie covers a path prefix; per-URL signing multiplies your manifest rewriting work and breaks player-side range requests in awkward ways.

Key rotation is additive-then-subtractive: add the new key, wait out the longest signature lifetime you issue, then remove the old key. Keys are limited per backend, so keep the count at two during rotation and one at rest. Signed URL requests bypass some cache-key normalization, so verify hit ratio after enabling signing — teams regularly discover their signature parameters are landing in the cache key.

On TLS: use Google-managed certificates with up to 100 domains per certificate map entry, or Certificate Manager for larger fleets. As of 2026 the modern TLS policy profile disables TLS 1.0 and 1.1 by default; if you have embedded clients or set-top boxes, test before you tighten. QUIC is on by default on global external ALBs, and for segment-heavy video delivery the difference on lossy mobile networks is worth measuring rather than assuming.

Invalidation limits and why you should avoid needing them

The invalidation API takes a path pattern against a URL map and propagates globally. Three constraints shape how you use it:

• Propagation is eventually consistent. Budget minutes, not seconds, and never gate a deploy on completion.
• Operations are rate-limited per project. A CI pipeline that invalidates on every merge will hit the ceiling and start failing builds.
• Wildcard invalidations are coarse. Invalidating a broad prefix dumps warm objects and converts the next traffic wave into cache fill you pay for twice.

The correct answer is content-hashed filenames for assets and short s-maxage plus serve-stale for HTML. Reserve invalidation for genuine mistakes: a leaked pre-release asset, a wrong price on a cached page. If your CMS demands purge-on-publish, scope patterns to individual paths and measure your monthly invalidation count as an operational metric. Above a few hundred per month, your cache strategy is doing the work that versioning should.

Cloud CDN pricing: a worked 200 TB bill

Cloud CDN bills three things: cache egress to clients (tiered by destination region and volume), cache fill from origin to edge (tiered by region pair), and HTTP/HTTPS cache lookup requests. The global external ALB itself bills forwarding rules and processed data separately. Cloud Storage adds its own class-A and class-B operation charges on misses.

Assume 200 TB monthly egress, 85% hit ratio, North America and Europe heavy, using published list rates as of 2026. Cache egress in NA/EU sits around $0.08/GB for the first 10 TB, stepping down through roughly $0.055–$0.02/GB as volume grows past 150 TB. Asia-Pacific and South America run materially higher. Cache fill in-network runs in the $0.01–$0.04/GB range depending on region pair. Requests bill around $0.0075 per 10,000 lookups.

Call it roughly $8,000–$10,000 for 200 TB. Now drop the hit ratio to 70%: cache fill triples to 60 TB and you add $600–$1,800 for zero user benefit. Hit ratio is a cost lever, not just a latency lever. Note also that request-count pricing punishes small-object workloads hardest — two billion lookups on 200 TB implies a 100 KB average object, and web-font-and-icon-heavy sites land well below that.

At sustained multi-hundred-TB volume, per-GB list pricing is where flat-rate CDNs pull ahead. BlazingCDN's volume pricing starts at $100/month for 25 TB and steps to $1,500 for 500 TB and $2,500 for 1,000 TB, with overage at $0.003 and $0.0025 per GB respectively — roughly $2–$3 per TB against Google's blended $30–$40 per TB at comparable volume. It delivers stability and fault tolerance comparable to Amazon CloudFront with 100% uptime and NVMe SSD edge storage, which matters for the same segment-heavy media and software-distribution workloads that drive Cloud CDN bills up. Bunny.net and CDN77 compete in that same cost-at-scale league and both have real strengths, and Fastly's edge compute and log streaming remain ahead for teams doing request-time logic. The honest framing: keep Cloud CDN where Cloud Armor, IAP, and VPC Service Controls integration is load-bearing, and move raw bulk delivery to a flat-rate provider.

Diagnostics and rollback

When hit ratio disappoints, work the chain in this order. Check the cache status field in load balancer logs — it distinguishes HIT, MISS, DISABLED, and the revalidation states, and DISABLED means your cache mode or origin headers are refusing the object outright. Then compare the request URL against your cache-key policy: a single unallowed query parameter explains most mysteries. Then inspect Vary. Then check object size against your max cacheable size.

Instrument four Cloud Monitoring series: cache hit count, cache miss count, total latencies, and backend latencies. The gap between total and backend latency is your edge contribution. If backend latency is flat while total latency spikes, you have a client-side or routing issue, not an origin issue.

The rollback math is the part teams forget. At a 90% hit ratio, disabling Cloud CDN or failing over DNS away from the ALB multiplies origin request rate by ten, instantly. Before any cutover, confirm the origin's autoscaler can reach that ceiling, that connection limits and database pools tolerate it, and that a warm-up ramp exists. Run the drill in staging with mirrored production traffic, compare hit ratio and p50/p99 against the live baseline, and only then move the record.

FAQ

Can I use Google Cloud CDN without a load balancer?

No. Cloud CDN is enabled as a property of a backend bucket or backend service attached to a global external Application Load Balancer. Regional external ALBs and network load balancers do not support it as of 2026, so a global anycast IP and HTTPS target proxy are prerequisites.

Which cache mode should a GCP CDN caching setup use by default?

USE_ORIGIN_HEADERS, with explicit Cache-Control emitted at the origin. It keeps caching decisions in version control alongside your application rather than in console state, and it prevents FORCE_CACHE_ALL from ever caching an authenticated response. Reserve CACHE_ALL_STATIC for origins you genuinely cannot change.

How fast is Cloud CDN cache invalidation?

Propagation is eventually consistent and typically completes in minutes, not seconds, and the API is rate-limited per project. Do not block deployments on invalidation completion. Use content-hashed filenames so you rarely need it at all.

Why is my Cloud CDN hit ratio below 80%?

In order of likelihood: query parameters in the cache key, a broad Vary header such as Vary on User-Agent, Cache-Control private or no-store from the origin, objects exceeding the maximum cacheable size, or a long-tail catalog where low request density per object per PoP prevents warm caches. Load balancer logs with the cache status field will tell you which.

Do signed URLs still get cached at the edge?

Yes, provided the signature components are excluded from the cache key, which Cloud CDN handles for its own signing parameters. Signed cookies are usually the better choice for HLS and DASH because one cookie authorizes an entire path prefix rather than requiring per-segment signing.

Is cache fill billed separately from cache egress?

Yes, and it is the line item most teams miss. Cache fill covers origin-to-edge traffic and is priced by region pair, so a hit ratio drop from 85% to 70% doubles that spend. In-network Cloud Storage origins are cheaper to fill from than external origins reached through internet NEGs.

Run this benchmark this week

Pull thirty days of load balancer logs, group by cache status, and compute hit ratio per path prefix rather than in aggregate. Then take the ten paths with the worst ratios and diff their request URLs against your cache-key allowlist. Most teams find one analytics parameter accounting for several percentage points of hit ratio and several hundred dollars of monthly cache fill.

Second exercise: export your last full month of Cloud CDN egress by region, apply flat-rate per-TB pricing to the same volume, and put both numbers next to your origin's peak request capacity. If the delta is larger than an engineer-month, the migration conversation is worth having. What is your current hit ratio, and do you know it per path prefix or only as a project-wide average?