Use external backends (also called 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 following terms are sometimes used interchangeably because they have the same or similar meanings:
- external backend: A backend that resides outside of Google Cloud and is reachable across the internet. The endpoint in an internet NEG.
- custom origin: Same as an external backend. In CDN, origin is the industry-standard term for a backend instance that serves web content.
- internet network endpoint group (NEG): The Google Cloud API resource that you use to specify an external backend.
- external endpoint: Same as an external backend.
To maintain consistency with the load balancing documentation, this document uses the term external backend except when referring to the internet NEG API resource.
Supported backend types 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:
- Instance groups
- Zonal network endpoint groups (NEGs)
- Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
- Internet NEGs for external backends
- Buckets in Cloud Storage
External backends can be hosted within an on-premises infrastructure or origins provided by third-party providers. The following sections discuss external backends 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 external backends enables you to use Google's globally distributed edge caching infrastructure for such content.
In the diagram,
images content resides in Google Cloud, while
resides in a Tokyo data center, which could be on-premises or in another cloud.
With external backends, 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 external backend in Tokyo.
This mapping is determined based on request URL:
For images (determined based on request URL:
/images), content is sourced
from Google Cloud and is delivered by the Cloud CDN edge
Specifying an external backend
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 external backend for Cloud CDN.
To specify the external backend, 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||
||A publicly resolvable fully qualified domain name (FQDN), and an
optional port, for example
||Use this endpoint when your external backend can be resolved by using an FQDN with public DNS.|
|IP address and an optional port||
||A publicly accessible IP address and an optional port, for example
||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
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_IP_PORT. You need to create a new internet
NEG and change your backend service to use the new internet NEG.
When using an external backend that expects a particular value for the HTTP
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
To automatically cache static responses from your origin, you can use the
CACHE_ALL_STATIC cache mode setting.
To control cacheability for each response by using HTTP cache
directives, set the cache mode to use origin headers (
information about the cache directives that Cloud CDN understands and
what's not cached by Cloud CDN, see Cacheable
content and Non-cacheable
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
mode. This mode caches all responses, regardless of content type or cache
If you don't explicitly select a cache mode when you enable Cloud CDN
on a backend, the API and the
gcloud command-line tool default to
and the Cloud Console defaults to
Using external backends and Google Cloud-based origins
The following figure shows an internet NEG used to deploy an external backend with HTTP(S) Load Balancing and Cloud CDN.
- To learn about what content is cached, see Caching overview.
- To resolve issues, see Troubleshooting external backend and internet NEG issues.