Before the details, let us understand the problem that Cloud CDN solves, using a simple story.

The problem: distance makes things slow

Imagine you run an online shop from a data center in one city. Your customers live all over the world. When a customer far away opens your home page, their request must cross oceans and many networks to reach your server, and the answer must come all the way back. Even at the speed of light in a cable, long distances add delay. A page is not one file, either. It may need dozens or hundreds of files, such as pictures, fonts and scripts, and each needs its own trip.

There is a second problem. If a thousand customers ask for the same big picture at the same moment, your server must send the same picture a thousand times. It works hard doing the same job again and again, and your network bill grows. In a big sale, the server may simply give up under the load.

The Cloud CDN answer: keep copies near the users

A CDN keeps copies of your content in many places around the world. Each place is a small data center that is close to where people live. When someone asks for a file, the CDN tries to answer from the nearest copy. This is called caching, which means keeping a copy of something so that the next request can be answered faster. If the CDN does not have a copy, it fetches the file from your server, answers the user, and keeps a copy for the next person.

Cloud CDN uses Google’s own worldwide network, the same kind of infrastructure that serves Search and YouTube. It works together with Google Cloud’s load balancing, so it feels like a built-in feature of your web front door rather than a separate system to run.

What a CDN gives you

A short history

The first commercial CDNs appeared in the late 1990s, when websites began to carry images and video and the internet struggled with the load. Over time CDNs became a standard part of nearly every large website. Google Cloud introduced Cloud CDN in the mid 2010s, built on top of its global load balancers, and has added features such as signed access, custom cache keys, serving stale content and support for outside origins. Google also offers a separate product, Media CDN, aimed at very large video and download delivery.

Where Cloud CDN sits among Google Cloud services

To understand a CDN, you first need a simple picture of what happens when you open a web page.

Clients and servers

A client is the program asking for something, such as your web browser or a mobile app. A server is the computer that answers. The client sends a request, such as “give me the picture at this address”. The server sends a response, which contains the file and some extra information called headers.

URLs and domain names

Every file on the web has an address, called a URL. A URL names the site, such as shop.example.com, and the path to the file, such as /images/shoes.jpg. People use names, but computers use numbers called IP addresses. A system called DNS, the Domain Name System, is like the phone book that turns a name into an IP address.

The trip and its delays

Before any content flows, the client and server must do some setup. First, DNS finds the address. Then they open a connection, which takes a short exchange of messages. If the site uses HTTPS, which is the secure version, they also agree on encryption, which takes a few more messages. Only then does the request for the file go out. Each of these steps takes at least one round trip across the network, and a round trip across a continent can take over a hundred milliseconds. These small delays add up.

Latency and bandwidth

Latency is the time one message takes to travel and be answered. It depends mostly on distance and the number of hops between networks. Bandwidth is how much data can flow per second, like the width of a pipe. A CDN mainly reduces latency, by shortening the distance, and it also relieves bandwidth pressure on your servers.

Static and dynamic content

Static content is the same for everyone and does not change often. Examples include logos, product photos, style sheets, scripts, fonts, videos and software downloads. Dynamic content is made fresh for each request or each person, such as a shopping cart, a bank balance or a search result. Static content is perfect for caching. Dynamic content is harder, because a copy made for one person would be wrong for another.

What caching is

A cache is a place that keeps copies of things that were recently used, so they can be found quickly the next time. Your browser has a cache. Your computer has caches. A CDN is a very large, shared cache spread across the world. The big question for any cache is: when is a stored copy still good? That question leads to the idea of a lifetime.

Lifetime, or TTL

Every cached copy has a TTL, which stands for Time To Live. It is the number of seconds the copy may be used before it is considered old. Within its TTL, a copy is fresh, and the cache may serve it without asking the original server. After the TTL ends, the copy is stale, and the cache must check with the origin before using it again.

Cache hit and cache miss

When the cache has a fresh copy and uses it, that is a cache hit. When it has no usable copy and must go to the origin, that is a cache miss. The share of requests that are hits is the cache hit ratio. A higher ratio means more speed and more savings, so much of CDN tuning is about raising it safely.

Headers that guide caching

Servers use headers to tell caches what to do. The most important is Cache-Control. It can say how long to keep something, for example “keep for one hour”, or forbid keeping it, for example “private” for data meant for one person only, or “no-store” for data that must never be saved. Other headers help a cache check whether a copy is still valid, such as ETag, a label for a version of a file, and Last-Modified, the time the file last changed.

Cloud CDN has its own small vocabulary. Learn these words once, and the rest of the guide will feel familiar.

Origin

The origin is the place where the real, original content lives. It may be a group of virtual machines, a Kubernetes service, a Cloud Run service, a Cloud Storage bucket, or even a server outside Google Cloud. The CDN fetches from the origin when it has no copy.

Edge and point of presence

The edge is the part of the network closest to users. A point of presence, often written PoP, is one location at the edge where Google has network equipment and caches. When people say “the edge cache”, they mean the cache at one of these locations.

External Application Load Balancer

A load balancer receives incoming traffic and spreads it across backends. The external Application Load Balancer is Google’s load balancer for public web traffic. Cloud CDN is switched on for it, so the load balancer is the “front door” that also checks the cache.

Backend service and backend bucket

A backend service describes a group of servers that handle requests, together with health checks and settings. A backend bucket connects the load balancer to a Cloud Storage bucket. You enable Cloud CDN on a backend service or a backend bucket, one at a time.

Network endpoint group

A network endpoint group, or NEG, is a way to name a set of targets for the load balancer. A serverless NEG points to a serverless service such as Cloud Run. An internet NEG points to an outside server by its name or address, which lets Cloud CDN work with origins that are not inside Google Cloud.

Cache key

A cache key is the label a CDN uses to decide whether two requests are asking for the same thing. By default, it includes the protocol, the host name and the full URL with its query string. Two requests with the same key share one cached copy. Changing what goes into the key changes how many separate copies exist.

Cache mode

The cache mode decides what Cloud CDN is allowed to cache. In one mode it follows the headers sent by the origin. In another it caches common static file types automatically. In the strongest mode it caches nearly every successful response regardless of headers. We study these in detail later.

Invalidation

Invalidation means telling the CDN to forget cached copies before their lifetime ends, for example because you published a fix and cannot wait.

Signed URL and signed cookie

A signed URL is a web address with a secret signature and an expiry time. Only people who hold such an address can fetch the content, and only until it expires. A signed cookie does the same job for many files at once. They protect paid or private content while still using the CDN.

Now let us zoom out and see how Cloud CDN fits between your users and your servers.

A typical setup has four groups of parts. First, the users, with browsers and apps all over the world. Second, the Google edge, which includes the points of presence, the global front-end network and the load balancer with Cloud CDN. Third, the origins: your servers or buckets. Fourth, the supporting services: security rules, certificates, monitoring and logs.

flowchart TD
  U1["User in Asia"] --> E1["Google Edge PoP Asia"]
  U2["User in Europe"] --> E2["Google Edge PoP Europe"]
  U3["User in Americas"] --> E3["Google Edge PoP Americas"]
  subgraph GFE["Google Global Front End"]
    E1 --> LB["External Application Load Balancer"]
    E2 --> LB
    E3 --> LB
    LB --> ARMOR["Cloud Armor Security Policy"]
    ARMOR --> CDN["Cloud CDN Cache Lookup"]
  end
  CDN -->|"cache hit - answer from cache"| E1
  CDN -->|"cache miss"| BS["Backend Service"]
  CDN -->|"cache miss"| BB["Backend Bucket"]
  BS --> MIG["VM Instance Group or GKE"]
  BS --> RUN["Cloud Run via Serverless NEG"]
  BS --> EXT["External Origin via Internet NEG"]
  BB --> GCS["Cloud Storage Bucket"]
  MON["Cloud Monitoring and Logging"] -.-> LB
  CERT["Managed TLS Certificates"] -.-> LB

Walking through the picture

At the top are users in different parts of the world. Each user’s request is sent to a nearby Google edge location. Google uses a technique called anycast, which lets one public IP address be announced from many places, so the network automatically delivers each user’s traffic to the closest one. The user does not choose and does not need to know.

From the edge, the request flows into Google’s global front end and reaches the external Application Load Balancer. The load balancer ends the secure connection, reads the request, and applies a Cloud Armor security policy if you have one. Then Cloud CDN performs a cache lookup. If a fresh copy exists, the answer goes straight back to the user. That path is the hit path, and it is the fastest and cheapest.

If there is no usable copy, Cloud CDN passes the request to the backend. A backend can be a backend service, which points to virtual machines, Kubernetes pods, Cloud Run or even an outside server, or a backend bucket that points to Cloud Storage. The origin answers, and Cloud CDN keeps a copy of the response, if the rules allow, for the next requester.

Around everything are supporting services: managed certificates for HTTPS, and monitoring and logging that record each request and whether it was a hit or a miss.

Why this design works

The cache sits at the same place as the load balancer, so there is no extra hop and no separate product to connect. The same front door that routes traffic, terminates encryption and applies security rules also serves cached content. This keeps the system simple, and it lets you add or change origins, rules and security without redesigning the delivery path.

This is the part many tutorials skip. Knowing it explains why Cloud CDN behaves the way it does.

Step 1: finding the nearest edge

When a user types your address, DNS returns one IP address belonging to your load balancer. That address is announced from many Google locations at once through anycast. The user’s request follows the internet’s normal routing to the closest location that announces it. From there, Google carries the traffic over its own private backbone, which is faster and steadier than the open internet for the long part of the trip.

Step 2: terminating the connection early

Setting up an encrypted connection takes several round trips. If these trips went all the way to your origin, the user would wait a long time. Instead, the connection ends at the nearby edge, so the setup round trips are short. Google’s front end also supports modern protocols, such as HTTP/2 and HTTP/3, which send many files over one connection and handle poor networks better. Good news for users on mobile networks, even before any caching happens.

Step 3: computing the cache key

Next, the request is turned into a cache key. By default, this is made of the protocol, host and full URL including the query string. You may customize it, for example to ignore tracking parameters in the address or to include a certain header. The key decides which stored copy, if any, answers this request.

Step 4: the cache lookup

Cloud CDN looks in the edge cache for an entry with that key. Three outcomes are possible.

Step 5: cache fill and tiered caching

On a miss, Cloud CDN does a cache fill: it requests the file from the origin, returns it to the user and, if the rules allow, stores it. Google caches in more than one layer. If the nearest edge does not have the file, it may first ask a larger cache elsewhere in Google’s network before bothering your origin. This arrangement is sometimes called tiered caching, and it means the origin sees fewer requests than a simple one-layer design would produce. The exact arrangement is managed by Google and may change.

Step 6: request collapsing

Imagine a popular new video is released and a thousand people ask for it in the same second, before any copy exists. A naive system would send a thousand identical requests to the origin. Cloud CDN can collapse these requests, which means it sends one request to the origin and makes the others wait for that one answer. This protects the origin from stampedes and is one reason CDNs help during sudden crowds.

Step 7: revalidation

When a cached copy goes stale, asking the origin to resend the whole file would waste bandwidth. Instead Cloud CDN can send a small conditional request that says, “I have the version labeled with this ETag. Has it changed?” If it has not, the origin replies with a tiny “not modified” message, and the copy becomes fresh again for another lifetime. This is cheap and fast, and it is a good reason to make your origin send proper ETag or Last-Modified headers.

Step 8: eviction

Caches have limited space. When room runs out, or when content has not been requested for a long time, old entries are removed to make space for newer ones. This is called eviction. It means that unpopular files may be dropped before their lifetime ends, so a rarely used file may need to be fetched from the origin again even when its TTL is long. Popular files tend to stay.

Why different users may see different results

Because there are many edge locations, and each keeps its own copies, a file may be cached in Mumbai but not yet in Frankfurt. The first person in each region to ask for a file after it is published is likely to get a miss, and later people get hits. This is why a CDN’s benefit grows with the number of repeat requests in each region.

Two stories matter in a CDN: the story of one request, and the story of one cached file as time passes.

The story of one request

Let us follow two requests for the same picture. The first arrives when no copy exists. The second arrives soon after.

sequenceDiagram
  participant B as Browser
  participant E as Google Edge and Load Balancer
  participant C as Cloud CDN Cache
  participant O as Origin
  B->>E: Request logo picture
  E->>C: Look up cache key
  C-->>E: Miss - no copy
  E->>O: Fetch logo picture
  O-->>E: Picture with Cache-Control one day
  E->>C: Store copy for one day
  E-->>B: Picture delivered - first visitor
  B->>E: Second visitor requests same picture
  E->>C: Look up cache key
  C-->>E: Hit - fresh copy found
  E-->>B: Picture delivered from cache

What the picture shows

The first browser asks for the logo. The edge computes the cache key and checks the cache. It finds nothing, so it fetches the logo from the origin. The origin sends the file along with a header saying it may be kept for one day. The edge stores a copy and also delivers the picture to the first visitor. When the second visitor asks, the cache finds the fresh copy and the origin is not involved at all. The second visitor’s answer comes from a place that may be a few kilometers away instead of thousands.

The story of a cached object

A cached copy lives through several stages.

Two clocks: the CDN and the browser

There are two caches between the origin and a person. The CDN keeps copies at the edge. The user’s own browser also keeps copies. Each has its own lifetime. Cloud CDN lets you set a client TTL, which controls how long browsers may keep the file, separately from the lifetime in the CDN. This matters a lot: you can invalidate the CDN copy, but you cannot reach into every person’s browser to erase theirs. A file that browsers keep for a year cannot be corrected quickly for people who already have it.

Different responses are treated differently

Cloud CDN mostly caches successful responses, such as “OK”, but it can also cache certain error and redirect responses for a short time, which is called negative caching. For example, caching a “not found” answer for a few minutes prevents a flood of requests for a missing file from reaching the origin repeatedly. You can set how long each kind of status code is cached. Check the current list of cacheable status codes in the documentation.

Partial requests and large files

Many large downloads and videos are fetched in pieces using byte range requests, where the client asks for only part of a file. Cloud CDN supports these, which makes it a good fit for large downloads, video and resuming interrupted downloads. Very large files may be stored in the cache in chunks.

A CDN is only as good as the origin behind it. Cloud CDN supports several kinds of origins, each suited to different content.

Origin type 1: Cloud Storage buckets

The simplest origin is a Cloud Storage bucket holding static files such as images, videos, documents and whole static websites. You connect it through a backend bucket, and enable Cloud CDN on it. Because storage is durable and cheap, this is an excellent place for large files that rarely change. Access to the bucket must be arranged so that the CDN can read it. Google provides options for this, including making objects publicly readable or using more controlled access, and the details can change, so check the current documentation.

Origin type 2: Compute Engine virtual machines and GKE

Dynamic web applications often run on groups of virtual machines or on Kubernetes pods. These sit behind a backend service. Cloud CDN can cache the public, repeatable parts of their responses, such as product pages and API results that do not depend on the user, while private parts bypass the cache.

Origin type 3: Cloud Run and other serverless services

Serverless services connect to the load balancer through a serverless NEG. Cloud CDN can cache their responses too. This is a good combination, since cached responses mean fewer serverless invocations and a lower bill, as well as faster pages.

Origin type 4: external origins

Your content might live outside Google Cloud, such as in another cloud, in your own data center or on a partner’s server. An internet NEG lets the load balancer treat that server as a backend, identified by a name or address. Cloud CDN can then cache its responses. This is useful for gradual migrations, where you want a CDN in front of old servers before you move them.

flowchart LR
  USERS["Users"] --> LB["External Application Load Balancer with URL Map"]
  LB -->|"path: /static/*"| BB["Backend Bucket - CDN on"]
  LB -->|"path: /media/*"| BB2["Backend Bucket for large files - CDN on"]
  LB -->|"path: /api/public/*"| BS1["Backend Service - CDN on with short TTL"]
  LB -->|"path: /account/*"| BS2["Backend Service - CDN off"]
  LB -->|"path: /legacy/*"| NEG["Internet NEG - CDN on"]
  BB --> GCS1["Cloud Storage Bucket A"]
  BB2 --> GCS2["Cloud Storage Bucket B"]
  BS1 --> GKE["GKE Service"]
  BS2 --> VM["Compute Engine VMs"]
  NEG --> OLD["Server in Another Data Center"]

URL maps: routing by path and host

The load balancer uses a URL map to decide where each request goes. It can send requests by host name, such as images.example.com, or by path, such as /static/. This allows one domain to mix origins. Because Cloud CDN is enabled per backend, URL maps are how you apply the right caching rules to the right content.

Choosing the origin for each kind of content

Origin health and location

Backends in a backend service are checked by health checks, small repeated tests that ask, “Are you working?” Unhealthy backends receive no traffic. The placement of the origin matters too. When there is a cache miss, the fill travels from the origin to Google’s network. An origin in a region close to your main audience will fill caches faster, and a well-chosen region reduces cost.

Origin capacity

A CDN reduces origin load, but it does not remove it. Cache misses, revalidations and uncacheable requests still arrive. Size your origin for the miss traffic, plus the worst case of a cache that has been emptied or a sudden burst of requests for new content. Also plan for the cold start of a new region, where every first request is a miss.

The cache mode is the most important single setting in Cloud CDN. It decides what gets cached, and for how long.

The three cache modes

The lifetime settings

Cloud CDN has several TTL settings. Names may vary slightly in tools, but the ideas are these.

• Default TTL: the lifetime used when the origin gives no lifetime of its own. A typical default is one hour.
• Maximum TTL: an upper limit. Even if the origin asks for a very long lifetime, Cloud CDN will not keep a copy longer than this. A typical default is one day.
• Client TTL: the lifetime that browsers are told to use. It cannot be longer than the maximum TTL.

In some modes, you can also override the origin’s lifetime with your own value. That is useful if you cannot change the origin’s headers.

Serve stale content

Cloud CDN can be allowed to serve stale content. When a copy has just expired, instead of making the user wait while the cache fetches a fresh copy, Cloud CDN can serve the old copy straight away and refresh it in the background. It can also serve a stale copy if the origin is down or returns errors, for a limited extra time. This improves both speed and resilience, at the cost of occasionally showing slightly old content.

Negative caching

You can choose to cache certain error and not-found responses for a short time, such as a few minutes. This protects the origin from repeated requests for something that does not exist. Keep these lifetimes short, so that when the content is later published, users are not told “not found” for long.

Choosing lifetimes in practice

A cache key decides how many separate copies of a file exist. Getting it right is one of the most effective ways to raise your hit ratio.

The default cache key

By default, the cache key includes the protocol (HTTP or HTTPS), the host name and the full path with its query string. So a request for one address with one set of options is a different cache entry from the same address with different options. This is safe, but it can create many near-duplicate copies.

Query strings

A query string is the part of an address after a question mark, such as options for a search or tracking tags from an advertisement. Suppose a marketing link adds a different tracking code for every campaign and every user. The page is the same, but each address is different, so each request creates its own cache entry and nearly all are misses. The cure is to exclude parameters that do not change the content from the cache key, or to include only the parameters that do.

Headers and cookies in the key

Sometimes the response really does vary with a header or cookie. For example, a site may send a different page to mobile and desktop devices, or in different languages. You can include such a header in the cache key, so each version gets its own cached copy. Be careful: including a header with many different values, such as a user-agent string, creates an enormous number of separate copies and ruins the hit ratio. It is much better to include a small, clean value, such as “mobile” or “desktop”, prepared by a rule.

The Vary header

Servers can send a Vary header, which says that the response depends on certain request headers. Caches must then keep separate copies for each combination. Cloud CDN handles Vary in a limited way and gives you cache key controls as the main tool, so check the current documentation for which headers it supports and how.

Protocol and host in the key

You can choose whether the protocol and host name are part of the key. If your site serves the same files on several names, such as a main name and a regional name, and you want them to share cached copies, you may remove the host from the key. Do this only when the content is truly identical.

A cache key checklist

Personalization and caching

Many pages are mostly the same for everyone, with one small personal part, such as “Hello, Maya”. If the whole page is made on the server, you cannot cache it for everyone. A common solution is to cache the shared page and load the personal part separately, using a small request that bypasses the cache, or code that runs in the browser. This keeps the big, heavy part cached while the private part stays private.

Not every response may be cached. This chapter explains the headers and rules that decide it.

The Cache-Control header

The Cache-Control header is the main tool the origin uses to talk to caches. It contains directives, which are small instructions. The most useful are these.

Other headers

• Expires: an older way to give a date after which the copy is stale.
• ETag: a label that identifies a version of the file, used for revalidation.
• Last-Modified: the time the file last changed, also used for revalidation.
• Vary: lists request headers that change the response.
• Set-Cookie: sets a cookie in the browser. Responses that set cookies are normally not shared between users, so caches treat them with care, and you should avoid cookies on static content.

Using s-maxage for the CDN and max-age for browsers

A useful pattern is to give the CDN a long lifetime using s-maxage, and browsers a short one using max-age. Then you can keep content at the edge for an hour, while browsers check back every minute. When you change the content and invalidate the CDN, users see the update within a minute, instead of waiting for a long browser lifetime to end.

What Cloud CDN will usually cache

In general, Cloud CDN caches successful responses to simple read requests, which are the GET requests for files and pages. It does not cache requests that change things, such as POST requests used for forms and payments. It does not cache responses that the origin marks as private or no-store, unless you choose the force mode. It also has limits on object size and on the lifetimes it will keep, so check the current limits for large files.

Compression

Compressing text files, such as pages, scripts and style sheets, makes them much smaller and faster to send. Typically the origin compresses and sends the compressed version, and the CDN keeps and serves it. The client says which compression it can handle through a header, and the cache may keep separate copies for different compression types. Cloud CDN has features related to compression, and the details have changed over time, so check the current documentation. Do not compress files that are already compressed, such as most images and videos.

Protocols at the edge

The load balancer at the edge supports modern web protocols. HTTP/2 allows many files to travel on one connection at once. HTTP/3, built on a protocol called QUIC, is even better on poor and mobile networks, because a lost packet does not stall every file. These benefits apply even to responses that are not cached, since the connection to the user ends at the edge.

A short checklist for cacheable responses

This chapter walks through the setup in plain terms. The exact buttons and commands change over time, so follow the current documentation for the details, and use this chapter for the order of thinking.

What you need before you start

• A Google Cloud project with billing enabled.
• Content to serve, in a Cloud Storage bucket, on servers, on Cloud Run, or on an outside server.
• A domain name that you control, so that you can point it at the load balancer, and a certificate for HTTPS. Google can create and renew a managed certificate for you.
• Permissions to create load balancers and backends in the project.

The setup path

How to test that caching works

Request the same file twice from the same place, using a browser’s developer tools or a command line tool that shows response headers. On the second request, look for signs of a hit, such as an Age header, which tells you how many seconds the copy has been in the cache, and a faster response time. In the load balancer logs, each request records whether the cache was looked up and whether it was a hit. Also test from different regions or with a different network, because each edge location has its own cache.

Turning on logging

Enable request logging on the backend, with a sampling rate you can afford. A full record of every request is the most useful in the beginning, since it shows exactly which requests are hits or misses and why. After tuning, you may reduce the sampling to save on cost.

Custom response headers

At the backend, you can add custom headers to responses, such as headers showing the cache status for debugging, or security headers that tell browsers how to behave. You can also add custom request headers sent to the origin, for example to tell it the location of the user. Check the documentation for the variables that can be used in headers.

Safe rollout

• Start with one low-risk path, such as pictures, and enable Cloud CDN there only.
• Watch the logs and the hit ratio for a few days.
• Extend to other static paths, then to public pages with short lifetimes.
• Keep private paths uncached from the first day.
• Keep a way back: you can disable Cloud CDN on a backend at any time, and traffic will simply flow to the origin.

A CDN can make a site feel dramatically faster, but only when it is set up with care. This chapter shows what to measure and how to improve it.

The measures that matter

• Cache hit ratio: the share of requests answered from the cache. Higher is better, but remember to watch the ratio by kind of content, since a high overall ratio can hide a low ratio on the important pages.
• Byte hit ratio: the share of data, in bytes, served from the cache. This matters most for cost, since big files dominate the bill.
• Time to first byte, often written TTFB: the time from the request until the first part of the answer arrives. A good CDN greatly reduces this for cached content.
• Page load time and the user-focused measures built on it, such as how soon the main content appears.
• Origin load: how many requests and how many bytes still reach your servers.

Ways to raise the hit ratio

Ways to make cache hits faster and lighter

• Compress text content such as pages, scripts and styles.
• Use modern image formats and the right sizes for each device, so that users do not download a huge picture to show a small thumbnail.
• Combine and minify scripts and styles where this makes sense, to reduce the number and size of files.
• Use HTTP/2 and HTTP/3, which the load balancer supports, to send many files over one connection.
• Use byte range requests for large files and video, so that players can jump and resume.

Ways to make misses faster

Misses cannot be avoided entirely, so make them cheap. Place the origin in a region close to most of your users and well connected to Google’s network. Make sure the origin responds quickly, with its own caches and an efficient database. Use serve-stale so that expired copies are refreshed in the background rather than making users wait. Warm the cache before a big event by requesting key files from several regions, so that the first real visitors get hits.

Cache warming and pre-positioning

Before a launch, you may warm the cache by requesting the most important files. Since each edge location has its own cache, warming covers only those you reach, so it helps most in the regions you can test from, and less elsewhere. For very large events, plan capacity assuming that the first requests in each region will be misses.

Large files and video

Large downloads and video put the most load on bandwidth. Cloud CDN supports byte ranges and caches large objects, subject to size limits. For video streaming, splitting the video into small segments, as in common streaming formats, makes caching efficient, because each segment is a small, shared file. For massive media workloads, Google offers Media CDN, which is designed for very high throughput and long-tail media libraries. Compare Cloud CDN and Media CDN against your needs before you decide.

Measuring from the real world

Synthetic tests from a few locations are useful, but real users see more varied conditions. Collect real user measurements, using tools built into browsers or analytics services, and compare regions and devices. Compare pages before and after changes, and watch the slowest group of users, since averages hide the people who suffer most.

A tuning routine

Caching makes things fast, but it risks showing old content. This chapter explains how to keep content fresh without giving up the speed.

Why freshness is a problem

Once a copy is in the cache, the origin no longer controls it until the lifetime ends. If you publish a correction, fix a mistake or remove a sensitive file, the cache may keep serving the old one. You need tools to change this.

Strategy 1: short lifetimes

The simplest approach is to give changeable content short lifetimes, such as minutes. The cost is more trips to the origin, and the benefit is that stale content disappears by itself soon. Combined with serve-stale and revalidation, short lifetimes keep both speed and reasonable freshness.

Strategy 2: versioned addresses

The best approach for static files is to change the address whenever the content changes, by putting a version or a content fingerprint in the file name. The old and new versions are then different cache entries. You never need to invalidate anything, because the page now points to the new address. This is the most reliable method, and it works for browsers as well as the CDN.

Strategy 3: invalidation

Cache invalidation is the command to remove cached copies. In Cloud CDN, you can invalidate by a path, such as one file, or by a pattern with a wildcard at the end, such as everything under a folder. You can also limit the invalidation to a host. Invalidation is not instant everywhere. It may take some minutes to take effect across the world. There are also limits on how often you may invalidate, so check the current limits.

flowchart TD
  START["Content changed at origin"] --> Q1{"Is the file name versioned?"}
  Q1 -->|"Yes"| NEWURL["Publish new URL and update pages - no invalidation needed"]
  Q1 -->|"No"| Q2{"Can users wait for TTL to expire?"}
  Q2 -->|"Yes"| WAIT["Wait for the short TTL to end"]
  Q2 -->|"No"| INV["Request cache invalidation for the path"]
  INV --> BROW{"Browsers cached it too?"}
  BROW -->|"Yes - long client TTL"| STUCK["Some users still see old copy until browser TTL ends"]
  BROW -->|"No - short client TTL"| DONE["All users see the new content within minutes"]

Strategy 4: bypass for special requests

Sometimes you want one person, such as an editor previewing a change, to see the newest version without disturbing everyone else. Preview systems can send requests to a different address or with a special value in the key, which skips the shared cache copy. Design previews so that they are never cached for the public.

Emergency removal

If sensitive or illegal content is published by mistake, remove it from the origin first, then invalidate the path. Remember browsers and other copies outside your control, and consider the lifetimes you set. This is a strong reason to keep lifetimes sensible for content where mistakes are costly, rather than leaving everything cached for a year.

Staleness, on purpose

Some freshness is a choice. A news homepage may accept being a minute old. A stock price should not be. A product description can be an hour old, but a stock count on the checkout page cannot. Decide for each kind of content how old is too old, and set lifetimes to match.

Comparing the strategies

A CDN stands at the front of your system, so it is a natural place for security. It also introduces special risks that you must understand.

The shared responsibility model

Google secures its global network, its edge locations and the load balancing service. You are responsible for deciding what is cached, who may reach private content, how your origin is protected, and how your applications handle data. A mistake in cache settings can expose private data, even on a perfectly secure platform.

HTTPS everywhere

Use HTTPS for all traffic. The load balancer ends the secure connection at the edge, using a certificate. Google can create and renew a managed certificate for you. Redirect plain HTTP requests to HTTPS and choose modern protocol versions. You should also use encrypted connections between the load balancer and your origin where possible.

Never cache private data in a shared cache

The most serious CDN mistake is caching a response meant for one person and serving it to another. Prevent this in layers. Keep private content on separate backends with caching off. Mark private responses with the private or no-store directive. Avoid the force-cache mode on any backend that might return personal data. Test by logging in as two different users and checking that each sees only their own data.

Signed URLs and signed cookies

Sometimes content must be limited to certain people, such as paying customers or members, but you still want it served from the CDN for speed. Signed URLs and signed cookies solve this. Your application decides that a user may have the content, then creates a link or a cookie containing an expiry time and a signature made with a secret key. The edge checks the signature. If it is valid and not expired, the content is served from the cache. If not, the request is refused. The origin is not even asked.

sequenceDiagram
  participant U as Paying Customer
  participant A as Your Application
  participant E as Cloud CDN Edge
  participant O as Origin Bucket
  U->>A: Log in and request video
  A->>A: Check subscription
  A-->>U: Signed URL with expiry and signature
  U->>E: Request video using signed URL
  E->>E: Verify signature and expiry
  E->>E: Check cache
  E->>O: Fetch only if not cached
  O-->>E: Video content
  E-->>U: Video delivered
  U->>E: Request again after expiry
  E-->>U: Access denied

What signed URLs protect, and what they do not

A signed URL proves that the application issued the link, until it expires. Anyone holding the link can use it, so it can be shared by the original user. Use short expiry times for valuable content, and use signed cookies or other controls for sessions where sharing is a concern. Keep the signing keys secret, store them in a safe place such as Secret Manager, rotate them regularly, and do not put them in source code.

Protecting the origin

If your origin can be reached directly from the internet, attackers can bypass the CDN and its protections, and hit the origin with floods or exploit weaknesses. Reduce this risk.

• For Google Cloud origins, use firewall rules so that only the load balancer and its health checks can reach the servers.
• For Cloud Storage origins, use the access options provided for backend buckets, rather than leaving a bucket fully open when it holds anything sensitive.
• For external origins, allow only Google’s front-end addresses where practical, or use a secret header added by the load balancer, which the origin checks, so that requests not sent by your CDN are refused.
• Do not publish the true address of your origin in public places such as DNS records.

Cloud Armor

Cloud Armor is Google’s web application firewall and protection service for attacks. It works at the same front door. It can block traffic from certain countries or addresses, apply rules against common web attacks and limit request rates. Some of its policies can also be applied at the edge, in front of the cache, so that blocked requests never use cache or origin resources. Check the current features and editions for what is available.

Protection from floods

Google’s front-end network is built to absorb large attacks, and a cache helps further, because a flood of requests for cached files is answered at the edge. Attacks that use random addresses to force cache misses are harder, because each is a unique request that goes to the origin. Rate limits, Cloud Armor rules and careful cache keys all help.

Hotlinking and abuse

Hotlinking is when another website embeds your pictures or files, and your CDN pays for the traffic. You can limit it using signed URLs, by checking where requests came from, or with Cloud Armor rules. Also be careful about hosting user-uploaded content on the same domain as your application, because uploaded files can contain harmful scripts. Use a separate domain for user content.

Security headers

You can add response headers that tell browsers to behave safely, for example to refuse to be shown inside other sites’ frames, or to always use HTTPS for your domain. These are set as custom response headers at the backend, or by the origin.

A CDN stands in front of everything. It must stay up, and it can also help your origin stay up.

What availability means

Availability is the share of time a service works. It is often written in “nines”. Ninety-nine point nine percent allows under nine hours of downtime a year, and ninety-nine point ninety-nine percent allows under an hour. Google publishes service level agreements, called SLAs, for its load balancing and Cloud CDN services. Read the current text for exact numbers and conditions.

Built-in resilience of the edge

Cloud CDN runs on Google’s global load balancing infrastructure, which is spread across many locations and does not depend on a single machine or a single site. If one location has trouble, traffic is routed to other nearby ones. You do not run or patch edge servers, and you do not manage failover between edge locations.

The CDN as a shield for the origin

The cache protects the origin in several ways. Most requests never reach it. Request collapsing prevents stampedes. And serve-stale lets the CDN continue to provide content for a limited time even if the origin is down or returns errors. For static content, this can turn an origin outage into a minor event, because users continue to receive cached files.

Making the origin reliable too

The CDN cannot serve what it has never cached, and it cannot fix a permanently broken origin. Run the origin across several zones, using instance groups with health checks and autoscaling. For Cloud Storage origins, choose a location type, such as a multi-region or dual-region, that matches the durability and availability you need. For backend services, the load balancer can distribute traffic across several regions and fail over when a region is unhealthy.

Multi-region origins and failover

The global load balancer can route to backends in several regions. It sends users to the closest healthy one and shifts traffic away automatically if a region fails, subject to your capacity settings. With Cloud CDN on top, the cache fills from whichever backend is chosen, so the entire system benefits from regional redundancy.

Planning for a cold cache

Caches can be emptied by a large invalidation, a configuration change that alters cache keys, or a launch in a new region. A cold cache means every request is briefly a miss, and the origin must handle the full load. Plan capacity for this case, avoid big invalidations at busy times, and warm the cache before major events.

Handling errors well

Decide what users should see when the origin fails and nothing is cached. A friendly static error page, served from a bucket, is better than a raw error. You can configure the load balancer or the application to return such a page. Also, cache error responses for a very short time, to protect a struggling origin from being hammered by retries.

Design habits for reliable delivery

You cannot improve what you cannot see. Monitoring turns a mysterious slow site into a clear picture.

The three kinds of signals

Metrics are numbers over time, such as requests per second. Logs are written records of events, such as each request and its result. Alerts are messages sent when something needs attention. Together they answer: Is something wrong? What went wrong? Who needs to act?

Request logs

The load balancer’s request logs, stored in Cloud Logging, record each request or a sample of requests. For Cloud CDN, they include whether the cache was consulted and whether the request was a hit, and information such as the response size, status code, latency, the address requested and the client’s region. These logs are the best tool for finding out why something is a miss.

Metrics in Cloud Monitoring

The load balancer and Cloud CDN report metrics, including request counts, bytes sent, response codes, latency and, for caching, counts and bytes of hits and misses. From these you can build charts of the cache hit ratio and the byte hit ratio, and compare them with origin traffic. Names can change, so use the metric list in the console.

What to watch

Using logs to find problems

1. Filter for requests that were misses and sort by how often each address appears.
2. Look for addresses that appear with many different query strings. This points to cache key problems.
3. Look for popular addresses with short lifetimes, and ask whether they can safely be longer.
4. Look for responses whose headers forbid caching, and ask whether that is correct.
5. Look at large responses that are often misses, because they cost the most.

Exporting logs for analysis

For deeper analysis, you can send logs to BigQuery, Google’s data warehouse, and ask questions with SQL, such as “Which ten addresses caused the most origin bytes last week?”. This is powerful for cost and performance tuning, and for security investigations.

Alerts that help

Alert on things that matter to users and that a person can act on: a sharp fall in the hit ratio, a sudden rise of server errors, an increase in latency, or a sharp rise in origin traffic. Avoid alerts that fire constantly for small variations. Attach a short runbook to each alert, listing the first checks and the people to call.

Dashboards

Build a dashboard per site, with hit ratios, origin traffic, error rates, latency and bandwidth side by side. During a launch or an incident, everyone should look at the same picture.

A CDN can lower your bill or raise it, depending on how it is used. Understanding the pricing parts is the first step to controlling it.

What you pay for

• Cache egress: data delivered from the cache to users, charged per gigabyte. The price depends on the region where the user is, and tends to be lower with higher volume.
• Cache fill: data moved from the origin into the cache on misses, charged per gigabyte, often depending on the distance between origin and cache.
• Cache lookup requests: a small charge per number of requests that check the cache, usually priced per ten thousand requests.
• Invalidation requests: after a free allowance, each invalidation may carry a charge.
• Load balancer costs: the forwarding rules and the data processed by the load balancer.
• Origin costs: compute, storage and the egress of data from the origin for misses, and for traffic that never enters the cache.
• Security and logging: Cloud Armor, logging and monitoring have their own prices.

Prices change and differ by region and volume. Always read the current Cloud CDN and load balancing pricing pages, and use the pricing calculator with your own traffic numbers.

How a CDN can reduce the bill

Without a CDN, all data leaves your origin, and you pay origin egress for every byte. With a CDN, most bytes are served from the cache, and only the smaller cache fill traffic comes from the origin. The price per gigabyte for cache egress can be lower than the normal internet egress price from a virtual machine or a bucket, and the origin itself can be smaller. For content that is requested many times, the saving can be large.

How a CDN can raise the bill

Ways to save money

1. Raise the hit ratio with clean cache keys and good lifetimes. This reduces fills and origin costs.
2. Compress text content and use efficient image and video formats to cut bytes.
3. Use versioned addresses instead of frequent invalidation.
4. Place the origin wisely, in a region that is close to your caches and users, to reduce fill costs.
5. Block abuse with Cloud Armor, signed URLs and rate limits.
6. Control log volume by sampling, since logging every request on a high-traffic site can cost a great deal.
7. Review the content mix. Large files that nobody requests twice might be better served directly.
8. Set budgets and alerts on the project so unusual traffic is noticed early.
9. Compare options such as Media CDN for very heavy media delivery, or committed spending agreements when traffic is steady and large.

A simple cost thought experiment

Suppose a site serves one hundred terabytes a month, and ninety percent of the bytes are cache hits. Only ten terabytes are filled from the origin. The origin sends ten terabytes instead of one hundred, and needs far less compute and bandwidth. If the hit ratio falls to fifty percent, the origin sends fifty terabytes, five times more, and the bill and the load grow accordingly. A few points of hit ratio change the bill a lot, which is why tuning pays for itself.

A pattern is a proven way to solve a common problem. An anti-pattern looks reasonable but causes pain later.

Patterns that work

Anti-patterns to avoid

This chapter gathers the habits of teams that run CDNs well, and the mistakes of those who learned the hard way.

Best practices: planning

• List your content by behavior: never changes, changes slowly, changes often, personal. Decide lifetimes for each group before you start.
• Check which load balancer types, origins and features Cloud CDN supports today, and confirm limits such as object sizes and invalidation rates.
• Use a separate domain or path for static content, so rules are simple and cookies do not leak onto static files.
• Choose the origin region near your largest audience.
• Define the load balancer, backends and CDN settings as code, and keep them in version control.

Best practices: caching

• Set explicit Cache-Control headers at the origin, with public, a lifetime and, for shared caches, s-maxage.
• Use fingerprinted names for static files and very long lifetimes.
• Give changeable pages short lifetimes and enable serve-stale.
• Clean the cache key of tracking tags and session values.
• Do not send cookies on static content.
• Keep private content on backends with caching off.

Best practices: security

• Use HTTPS everywhere with managed certificates.
• Use signed URLs or cookies for protected content, with short expiry, and keep keys in Secret Manager.
• Lock the origin so only the load balancer can reach it.
• Use Cloud Armor for filtering and rate limiting at the front door.
• Serve user-uploaded content from a separate domain.

Best practices: operations

• Turn on logging from the start, and review the top misses weekly.
• Alert on hit ratio drops, error spikes and origin traffic jumps.
• Warm caches before big events, and size the origin for cold-cache traffic.
• Test with a second user account to prove that private data is not shared.
• Review cost by category every month, and set budgets and alerts.

Common mistakes

Most teams do not begin with a blank slate. They have a site that already runs, sometimes behind another CDN. This chapter explains a calm way to adopt Cloud CDN.

Starting from no CDN

If your site currently serves everything from its own servers, adopting Cloud CDN is mostly a matter of putting a load balancer in front and enabling caching for the safest content first. The steps in the setup chapter apply. The key habit is to begin with static files, learn from the logs and extend step by step.

Starting from another CDN

Many companies use another CDN, for example Amazon CloudFront, Akamai, Cloudflare, Fastly or Azure Front Door, and consider Cloud CDN because they have moved to Google Cloud, want one bill, or want to use Google’s load balancing. Moving requires care, because the new service differs in details such as how cache keys, headers and rules are configured.

A safe migration path

Things that surprise teams

• Cold caches. The new CDN starts empty. When traffic moves, the origin must handle a burst of misses. Shift traffic gradually and warm important files.
• Header differences. Each CDN adds and removes headers differently. Applications that depend on special headers, such as the client’s address or country, must be checked.
• Cache key differences. Defaults differ. Test that query strings, cookies and headers are handled the way you expect.
• Signed URL formats. Different providers use different signing schemes. Links already shared may stop working, so plan a period when both are accepted, or issue new links.
• Certificates and DNS. Provision certificates before the switch, and lower the DNS lifetime in advance.
• Edge logic. If you used code running at the edge of the old CDN, you will need to move that logic to the origin, the load balancer rules or another service.
• Cost differences. Compare pricing structures using real traffic, because per-request and per-gigabyte charges differ.

Testing before and after

Keep a list of important addresses, including home pages, popular articles, large downloads, protected content and error cases. Run the list through the old and the new setup, and compare status codes, headers, sizes and timings. Repeat after each stage of the migration. Add checks for cache behavior, such as whether the second request is a hit.

After the move

Review the hit ratio, latency and origin load at the end of the first week. Compare the bill with the forecast. Tune cache keys and lifetimes. Retire the old CDN configuration only when you are sure the new one is stable, and write down the lessons learned.

Let us look at the kinds of work that content delivery networks carry every day. Companies seldom publish detailed designs, so these examples describe typical patterns in each industry.

What these stories have in common

Every example shares the same habits. Content that is the same for everyone is cached close to users, with lifetimes matched to how fast it changes. Files get versioned names, so updates are clean. Private content is kept separate or protected with signed access. The origin is shielded and sized for the misses. Logs and dashboards show hit ratios and costs. The industries differ, but the design habits are the same.

Short, direct answers to questions that beginners ask most often.

You have now seen Cloud CDN from the outside and from the inside. Here is the whole story in one place.

Cloud CDN keeps copies of your content at Google’s edge locations around the world and works through Google’s external Application Load Balancer. A user’s request reaches a nearby edge, the cache is checked with a key, and a fresh copy is returned at once, while a miss goes to your origin, fills the cache and serves the next person faster. You decide what is cached, for how long and for whom, and you protect private content, shield your origin and watch the hit ratio, the errors and the bill.