This guide uses an example to teach the fundamentals of using an external backend (sometimes called a custom origin) with a global external Application Load Balancer. An external backend is an endpoint that is external to Google Cloud. When you use an external backend with a global external Application Load Balancer, you can improve performance by using Cloud CDN caching.
The guide shows you how to configure a global external Application Load Balancer with a Cloud CDN-enabled backend service that proxies requests to an external backend server.
Before following this guide, familiarize yourself with the
Internet NEG overviewdocumentation, including the
limitations.
The following architecture diagram shows a global external Application Load Balancer frontend with an external backend.
Figure 1. A global external Application Load Balancer with an external backend (click to enlarge). PermissionsTo follow this guide, you need to create an internet NEG and create or modify an external Application Load Balancer in a project. You should be either a project Owner or Editor (roles/owner
or roles/editor
), or you should have both of the following Compute Engine IAM roles.
To set up your environment, see the following sections.
Configure network endpointsConfigure a network endpoint to expose your external backend to Google Cloud. Make sure that the endpoint—either an IP:Port combination or a fully-qualified domain name (FQDN) and port—is reachable over the internet. This endpoint is later referenced from the internet NEG.
For detailed configuration requirements for internet NEG endpoints, see the Internet NEGs overview.
Allow the external backend to receive traffic from Google CloudTo allow requests from Google Cloud to reach your external backend, you must allowlist the IP address ranges that Google uses to send requests to external backends. To look up the IP addresses that need to be allowed to send traffic to your external backends, query the _cloud-eoips.googleusercontent.com
DNS TXT record by using a tool such as dig
or nslookup
.
Examples:
Run the following nslookup
command:
nslookup -q=TXT _cloud-eoips.googleusercontent.com 8.8.8.8
The output looks like the following:
Non-authoritative answer: _cloud-eoips.googleusercontent.com text = "v=spf1 ip4:34.96.0.0/20 ip4:34.127.192.0/18 ~all"
Note the CIDR ranges following ip4:
and ensure that these ranges are allowed by the firewall rules or cloud access control lists (ACLs) configured on your external backend.
Run the following dig
command:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
The output contains two IP address ranges, as follows:
34.96.0.0/20
34.127.192.0/18
Create the global external Application Load Balancer with an internet NEG backend.
Reserve an external IP addressReserve a global static external IP address that clients use to reach your application.
Note: This step is required for this example, and recommended in general. Reserving an IP address is also essential if you are using a custom domain for your external backend (also required for Google-managed SSL certificates). With a custom domain, you must update your DNS records to point your domain to this IP address. ConsoleIn the Google Cloud console, go to the External IP addresses page.
Click Reserve external static address to reserve an IPv4 address.
Enter a name.
For Network Service Tier, select Premium.
For IP version, select IPv4.
For Type, select Global.
Click Reserve.
gcloud compute addresses create LB_IP_ADDRESS_NAME \ --network-tier=PREMIUM \ --ip-version=IPV4 \ --global
Note the IPv4 address that was reserved:
gcloud compute addresses describe LB_IP_ADDRESS_NAME \ --format="get(address)" \ --globalSet up the internet NEG Console
In the Google Cloud console, go to the Network endpoint groups page.
Click Create network endpoint group.
Enter a name.
For Network endpoint group type, select Network endpoint group (Internet).
For Default port, enter 443
.
For New network endpoint, select Fully qualified domain name and port.
Enter the Fully qualified domain name.
For Port type, select Default, and verify that Port number is 443
.
Click Create.
Create an internet NEG, and set the --network-endpoint-type
to internet-fqdn-port
(the hostname and port where your external backend can be reached):
gcloud compute network-endpoint-groups create INTERNET_NEG_NAME \ --network-endpoint-type="internet-fqdn-port" \ --global
Add your endpoint to the NEG. If a port isn't specified, the port selection defaults to port 80
(HTTP) or 443
(HTTPS; HTTP/2) depending on the protocol configured in the backend service. Make sure to include the --global
flag:
gcloud compute network-endpoint-groups update INTERNET_NEG_NAME \ --add-endpoint="fqdn=FULLY_QUALIFIED_DOMAIN_NAME,port=443" \ --global
In the Google Cloud console, go to the Load balancing page.
To create an HTTPS load balancer, you must have an SSL certificate. We recommend using a Google-managed certificate.
Verify that the following options are configured with these values.
Property Value (type a value or select an option as specified) Protocol HTTPS Network Service Tier PremiumSelect an existing SSL certificate or create a new certificate.
To create an HTTPS load balancer, you must have an SSL certificate resource to use in the HTTPS proxy. You can create an SSL certificate resource by using either a Google-managed SSL certificate or a self-managed SSL certificate.
To create a Google-managed certificate, you must have a domain. The domain's A record must resolve to the IP address of the load balancer (in this example, example-ip
). We recommend using Google-managed certificates because Google Cloud obtains, manages, and renews these certificates automatically. If you don't have a domain, you can use a self-signed SSL certificate for testing.
Use this checkbox to enable HTTP to HTTPS redirects.
Enabling this checkbox creates an additional partial HTTP load balancer that uses the same IP address as your HTTPS load balancer and redirects HTTP requests to your load balancer's HTTPS frontend.
This checkbox can only be selected when the HTTPS protocol is selected and a reserved IP address is used.
If you want to test this process without setting up an SSL certificate resource (or a domain as required by Google-managed certificates), you can set up an HTTP load balancer.
To create an HTTP load balancer, verify that the following options are configured with these values:
Property Value (type a value or select an option as specified) Protocol HTTP Network Service Tier Premium IP version IPv4 IP address Select the IP address created in the Reserve an external IP address step. Port 80 Optional: HTTP keepalive timeout Enter a timeout value from 5 to 1200 seconds. The default value is 610 seconds.Click Done.
gcloud compute backend-services create BACKEND_SERVICE \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
gcloud compute backend-services add-backend BACKEND_SERVICE \ --network-endpoint-group=INTERNET_NEG_NAME \ --global-network-endpoint-group \ --global
gcloud compute url-maps create URL_MAP_NAME \ --default-service=BACKEND_SERVICE \ --global
Perform this step only if you want to create an HTTPS load balancer. This step is not required for HTTP load balancers.
To create an HTTPS load balancer, you must have an SSL certificate resource to use in the HTTPS target proxy. You can create an SSL certificate resource by using either a Google-managed SSL certificate or a self-managed SSL certificate. We recommend using Google-managed certificates because Google Cloud obtains, manages, and renews these certificates automatically.
To create a Google-managed certificate, you must have a domain. If you don't have a domain, you can use a self-managed SSL certificate for testing.
To create a Google-managed SSL certificate resource:gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --domains DOMAINTo create a self-managed SSL certificate resource:
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --certificate CRT_FILE_PATH \ --private-key KEY_FILE_PATH
Create a target HTTP(S) proxy to route requests to your URL map.
For an HTTP load balancer, create an HTTP target proxy:
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAME \ --global
For an HTTPS load balancer, create an HTTPS target proxy. The proxy is the portion of the load balancer that holds the SSL certificate for HTTPS Load Balancing, so you also load your certificate in this step.
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --ssl-certificates=SSL_CERTIFICATE_NAME \ --url-map=URL_MAP_NAME \ --global
Replace the following:
TARGET_HTTP_PROXY_NAME
: the name of the target HTTP proxy.TARGET_HTTPS_PROXY_NAME
: the name of the target HTTPS proxy.SSL_CERTIFICATE_NAME
: the name of the SSL certificate.URL_MAP_NAME
: the name of the URL map.--http-keep-alive-timeout-sec
option. The timeout value must be between 5 to 1200 seconds. The default value is 610 seconds.Create a forwarding rule to route incoming requests to the proxy.
For an HTTP load balancer:
gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=LB_IP_ADDRESS_NAME \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --global \ --ports=80
For an HTTPS load balancer:
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=LB_IP_ADDRESS_NAME \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --global \ --ports=443
After the load balancer is created, note the IP address that is associated with the load balancer—for example, 30.90.80.100
. To point your domain to your load balancer, create an A
record by using your domain registration service. If you added multiple domains to your SSL certificate, you must add an A
record for each one, all pointing to the load balancer's IP address. For example, to create A
records for www.example.com
and example.com
, use the following:
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
If you use Cloud DNS as your DNS provider, see Add, modify, and delete records.
Test the load balancer Note: It might take a few minutes for the load balancer configuration to propagate globally after you first deploy it.Now that you have configured your load balancer, you can start sending traffic to the load balancer's IP address. If you configured a domain, you can send traffic to the domain name as well. However, DNS propagation can take time to complete, so you can start by using the IP address for testing.
ConsoleIn the Google Cloud console, go to the Load balancing page.
Click the load balancer that you just created.
Note the IP address of the load balancer.
Send traffic to the load balancer.
If you created an HTTP load balancer, you can test your load balancer by going to http://IP_ADDRESS
. Replace IP_ADDRESS
with the load balancer's IP address. You should be directed to the application you're running on the external backend.
If you created an HTTPS load balancer, you can test your load balancer by going to https://IP_ADDRESS
. Replace IP_ADDRESS
with the load balancer's IP address. You should be directed to the you're application running on the external backend.
If that does not work and you are using a Google-managed certificate, confirm that your certificate resource's status is ACTIVE. For more information, see Google-managed SSL certificate resource status.
Alternatively, you can use curl
from your local machine's command line. Replace IP_ADDRESS
with the load balancer's IPv4 address. If you're using a Google-managed certificate, test the domain that points to the load balancer's IP address. For example:
curl -s 'https://www.example.com:443' --resolve www.example.com:443:IP_ADDRESS
Optional: If you are using a custom domain, you might need to wait for the updated DNS settings to propagate. Then, test your domain in the web browser.
For help with troubleshooting, see Troubleshooting external backend and internet NEG issues.
This section expands on the configuration example to provide alternative and additional configuration options. All of the tasks are optional. You can perform them in any order.
Enable Cloud CDNWhen Cloud CDN is enabled, the external Application Load Balancer sends requests to the internet NEG backend only when there is a Cloud CDN cache miss.
ConsoleIn the Google Cloud console, go to the Load balancing page.
Click the name of the load balancer that you want to modify.
Click editEdit.
Click Backend configuration.
For the backend service with the internet NEG backend, click editEdit.
Select Enable Cloud CDN.
Optional: Modify the cache mode and TTL settings.
Click Update.
To review your changes, click Review and finalize, and then click Update.
gcloud compute backend-services update BACKEND_SERVICE \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global \ --enable-cdn \ --cache-mode=CACHE_MODE
Set the cache mode by replacing CACHE_MODE
with one of the following:
CACHE_All_STATIC
: automatically caches static content.USE_ORIGIN_HEADERS
(default): requires the origin to set valid caching headers to cache content.FORCE_CACHE_ALL
: caches all content, ignoring any private
, no-store
, or no-cache
directives in Cache-Control
response headers.To authenticate requests sent to your external backend, you can set a custom header to indicate that the request came from a Google Cloud load balancer. For example, you can configure the external backend to expect a particular value for the HTTP request's Host
header, and you can configure the backend service to set the Host
header to that expected value.
Use the following steps to configure the backend service to add a custom Host
header to each request.
In the Google Cloud console, go to the Load balancing page.
Click the name of the load balancer that you want to modify.
Click editEdit.
Click Backend configuration.
For the backend service with the internet NEG backend, click editEdit.
Click Advanced configurations.
For Custom request headers, click Add header:
Host
.FQDN_NEG_ENDPOINT
.Click Update.
To review your changes, click Review and finalize, and then click Update.
gcloud compute backend-services update BACKEND_SERVICE \ --custom-request-header "Host: HEADER_VALUE" \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
Make sure that you also configured the external backend to expect a Host
header so that it can authenticate incoming requests.
For general information about custom request headers, see Configure custom request headers. For other authentication methods, see Authenticate requests to the external backend.
Enable IAP on the external Application Load BalancerNote: IAP isn't compatible with Cloud CDN.
You can configure IAP to be enabled or disabled (default). If enabled, you must provide values for oauth2-client-id
and oauth2-client-secret
.
To enable IAP, update the backend service to include the --iap=enabled
flag with the oauth2-client-id
and oauth2-client-secret
.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \ --global
Optionally, you can enable IAP for a Compute Engine resource by using the Google Cloud console, gcloud CLI, or API.
Update client HTTP keepalive timeoutThe load balancer created in the previous steps has been configured with a default value for the
client HTTP keepalive timeout.
To update the client HTTP keepalive timeout, use the following instructions.
ConsoleIn the Google Cloud console, go to the Load balancing page.
For an HTTP load balancer, update the target HTTP proxy by using the gcloud compute target-http-proxies update
command:
gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
For an HTTPS load balancer, update the target HTTPS proxy by using the gcloud compute target-https-proxies update
command:
gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Replace the following:
TARGET_HTTP_PROXY_NAME
: the name of the target HTTP proxy.TARGET_HTTPS_PROXY_NAME
: the name of the target HTTPS proxy.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: the HTTP keepalive timeout value from 5 to 600 seconds.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4