Custom origins overview

Use custom origins for Cloud CDN (Content Delivery Network) when content is hosted on-premises or in another cloud, and you want to deliver the content over Google's high performance, distributed edge caching infrastructure.

The terms custom origin, external endpoint, and internet endpoint are often used interchangeably because they have the same meaning. In CDN, origin is the industry-standard term for a backend instance that serves web content. This document uses the term custom origin.

Supported origins for Cloud CDN

Cloud CDN works with HTTP(S) Load Balancing to deliver content to your users. The external HTTP(S) load balancer provides the frontend IP addresses and ports that receive requests. Cloud CDN content can be sourced from various types of backends:

Internet NEGs are also known as custom origins. Internet NEGs can be origins hosted within an on-premises infrastructure or origins provided by third-party providers. The following sections discuss internet NEGs in more detail.

Hybrid and multi-cloud architectures

As you move your services to Google Cloud, you might need to do so in phases. Sometimes certain content can't immediately be moved to a cloud environment and might need to stay on-premises. In other cases, the content might be hosted in another cloud. Cloud CDN support for custom origins enables you to use Google's globally distributed edge caching infrastructure for such content.

Hybrid and multi-cloud architecture
Hybrid and multi-cloud architecture

In the diagram, images content resides in Google Cloud, while video resides in a Tokyo data center, which could be on-premises or in another cloud. With custom origins, origins in the Tokyo data center can be the backend source of the video content with Cloud CDN and HTTP(S) Load Balancing delivering the content to users.

Using URL maps, this deployment can direct origin pull requests for video traffic to the custom origin in Tokyo. This mapping is determined based on request URL: /video.

For images (determined based on request URL: /images), content is sourced from Google Cloud and is delivered by the Cloud CDN edge infrastructure.

Specifying a custom origin

Similar to configuring Cloud CDN with your endpoints deployed in Google Cloud, you can use the network endpoint groups (NEGs) API to add your server as the custom origin for Cloud CDN.

To specify the custom origin, use an internet NEG. An internet NEG has one of the endpoint types shown in the following table.

Endpoint address Type Definition When to use
Hostname and an optional port INTERNET_FQDN_PORT A publicly resolvable fully qualified domain name (FQDN), and an optional port, for example backend.example.com:443 (default ports: 80 for HTTP and 443) Use this endpoint when your external origin can be resolved by using an FQDN with public DNS.
IP address and an optional port INTERNET_IP_PORT A publicly accessible IP address and an optional port, for example 8.8.8.8 or 8.8.8.8:443 (default ports: 80 for HTTP and 443) Use this endpoint to specify a publicly accessible IP address and a port to connect to.

The best practice is to create the internet NEG with the INTERNET_FQDN_PORT endpoint type and an FQDN value as an origin hostname value. This insulates the Cloud CDN configuration from IP address changes in the origin infrastructure. Network endpoints that are defined by using FQDNs are resolved through public DNS. Make sure that the configured FQDN is resolvable through Google Public DNS.

After you create the internet NEG, the type cannot be changed between INTERNET_FQDN_PORT and INTERNET_IP_PORT. You need to create a new internet NEG and change your backend service to use the new internet NEG.

When using a custom origin that expects a particular value for the HTTP request's Host header, you must configure the backend service to set the Host header to that expected value. If you don't configure a user-defined request header, a backend service preserves the Host header that the client used to connect to the Google Cloud external HTTP(S) load balancer. For general information about user-defined request headers, see Creating user-defined request headers. For a specific example, see Setting up Cloud CDN with an external origin.

To automatically cache static responses from your origin, you can use the CACHE_ALL_STATIC cache mode setting (Beta).

To control cacheability for each response by using HTTP cache directives, set the cache mode to use origin headers (USE_ORIGIN_HEADERS). For information about the cache directives that Cloud CDN understands and what's not cached by Cloud CDN, see Cacheable content and Non-cacheable content.

If your origin isn't serving any per-user dynamic content, you might want to cache all responses from the origin. To do this, use the FORCE_CACHE_ALL mode. This mode caches all responses, regardless of content type or cache directives.

If you don't explicitly select a cache mode when you enable Cloud CDN on a backend, the following defaults apply:

  • Beta. The API and the gcloud command-line tool default to USE_ORIGIN_HEADERS if you enable Cloud CDN but don't specify a cache mode. The Cloud Console (when supported) defaults to CACHE_ALL_STATIC when you enable Cloud CDN on a backend.

  • GA. All newly Cloud CDN-enabled backends default to CACHE_ALL_STATIC, regardless of your configuration method (Cloud Console, API, or the gcloud tool).

Using custom origins and Google Cloud-based origins

The following figure shows an internet NEG used to deploy a custom origin with HTTP(S) Load Balancing and Cloud CDN.

Cloud CDN with custom origins and NEGs
Cloud CDN with custom origins and NEGs

What's next