Setting up an HTTP-to-HTTPS redirect for external HTTP(S) load balancers

This example demonstrates how to redirect all requests from port 80 to port 443.

At a high level, to redirect HTTP traffic to HTTPS, you must do the following:

1. Create a normal HTTPS load balancer with a reserved external IP address. This page walks you through a basic setup and provides links to some other possible setups.
2. Test the HTTPS load balancer to make sure that it's working.
3. Redirect traffic to the HTTPS load balancer.
   To do this, you must add a partial HTTP load balancer that has a frontend but no backends. The frontend receives requests and then redirects them to the HTTPS load balancer. It does this by using the following:
   • A forwarding rule with the same reserved external IP address that your HTTPS load balancer uses (referred to in step 1)
   • A target HTTP proxy
   • A URL map that redirects traffic to the HTTPS load balancer

As shown in the following diagram, the HTTPS load balancer is a normal load balancer with the expected load balancer components.

The HTTP load balancer has the same IP address as the HTTPS load balancer, a redirect instruction in the URL map, and no backend.

HTTP-to-HTTPS redirect configuration

To learn how to set up HTTP-to-HTTPS redirect for internal load balancing, see Setting up HTTP-to-HTTPS redirect for internal HTTP(S) load balancers.

Setting up a basic HTTPS load balancer

This example walks you through setting up and testing an HTTPS load balancer.

Note: If you already have a functioning HTTPS load balancer, skip to Redirecting traffic to your HTTPS load balancer.

This setup guide shows you how to create a simple external HTTPS load balancer with the following resources:

• The default Virtual Private Cloud (VPC) network
• A Compute Engine managed instance group
• A named port that specifies port 80 for backend traffic
• A default URL map
• A simple backend health check
• A simple frontend forwarding rule
• A reserved external IP address
• An SSL certificate

For a content-based, multi-region example that includes IPv6 and SSL certificate setup, see Setting up a multi-region, content-based external HTTPS load balancer.

For general concepts, see the External HTTP(S) Load Balancing overview.

If you're using GKE, the load balancer is typically configured by the Kubernetes Ingress controller. For more information, see Configuring Ingress for external load balancing.

HTTPS load balancer topology

In this guide, you create the configuration that is illustrated in the following diagram.

Simple HTTPS Load Balancing (click to enlarge)

The sequence of events in the diagram is as follows:

1. A client sends a content request to the external IPv4 address defined in the forwarding rule.
2. The forwarding rule directs the request to the target HTTPS proxy.
3. The target proxy uses the rule in the URL map to determine that the single backend service receives all requests.
4. The load balancer determines that the backend service has only one instance group and directs the request to a virtual machine (VM) instance in that group.
5. The VM serves the content requested by the user.

Before you begin

Make sure that your setup meets the prerequisites.

Set up an SSL certificate resource

Create an SSL certificate resource as described in the following:

• Using self-managed SSL certificates
• Using Google-managed SSL certificates

We recommend using a Google-managed certificate.

This example assumes that you already have an SSL certificate resource named www-ssl-cert.

Warning: Don't use a self-signed certificate for production purposes.

Set up permissions

To complete the steps in this guide, you must have permission to create Compute Engine instances, firewall rules, and reserved IP addresses in a project. You must have either a project owner or editor role, or you must have the following Compute Engine IAM roles.

Task	Required role
Create instances	Instance Admin
Add and remove firewall rules	Security Admin
Create load balancer components	Network Admin
Create a project (optional)	Project Creator

For more information, see the following guides:

• Access control
• IAM Conditions

Creating a managed instance group

To set up a load balancer with a Compute Engine backend, your VMs need to be in an instance group. This guide describes how to create a managed instance group with Linux VMs that have Apache running, and then set up load balancing.

The managed instance group provides VMs running the backend servers of an external HTTPS load balancer. For demonstration purposes, backends serve their own hostnames.

Console

1. In the Google Cloud Console, go to the Instance groups page.

   Go to the Instance groups page

2. Click Create instance group.
3. On the left, choose New managed instance group.
4. For Name, enter lb-backend-example.
5. Under Location, select Single zone.
6. For Region, select your preferred region. This example uses us-east1.
7. For Zone, select us-east1-b.
8. Under Instance template, select Create a new instance template.
9. For Name, enter lb-backend-template.
10. Ensure that the Boot disk is set to a Debian image, such as Debian GNU/Linux 9 (stretch). These instructions use commands that are only available on Debian, such as apt-get.

11. Under Management, security, disks, networking, sole tenancy, on the Management tab, insert the following script into the Startup script field.

    #! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    

12. On the Networking tab, add the network tags: allow-health-check

13. Click Save and continue.

14. Under Autoscaling mode, select Don't autoscale.

15. Under Number of instances, enter 2.

16. To create the new instance group, click Create.

Note: Because the external HTTP(S) load balancer is a proxy, you don't need to select Allow HTTPS traffic under Firewall. In Configuring a firewall rule, you create the only necessary firewall rule for this load balancer.

gcloud

1. Create the template.

   gcloud compute instance-templates create lb-backend-template \
      --region=us-east1 \
      --network=default \
      --subnet=default \
      --tags=allow-health-check \
      --image-family=debian-9 \
      --image-project=debian-cloud \
      --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
   

2. Create the managed instance group based on the template.

   gcloud compute instance-groups managed create lb-backend-example \
      --template=lb-backend-template --size=2 --zone=us-east1-b
   

Adding a named port to the instance group

For your instance group, define an HTTP service and map a port name to the relevant port. Once configured, the load balancing service forwards traffic to the named port.

Console

1. In the Google Cloud Console, go to the Instance groups page.

   Go to the Instance groups page

2. Click the name of your instance group (in this example lb-backend-example) and click Edit Group.
3. Click Specify port name mapping.
4. Click Add item.
5. For the port name, enter http. For the port number, enter and 80.
6. Click Save.

gcloud

gcloud compute instance-groups unmanaged set-named-ports lb-backend-example \
    --named-ports http:80 \
    --zone us-east1-b

Configuring a firewall rule

In this example, you create the fw-allow-health-check firewall rule. This is an ingress rule that allows traffic from the Google Cloud health checking systems (130.211.0.0/22 and 35.191.0.0/16). This example uses the target tag allow-health-check to identify the VMs.

Console

1. In the Google Cloud Console, go to the Firewall page.

   Go to the Firewall page

2. Click Create firewall rule to create the second firewall rule.
3. For Name, enter fw-allow-health-check.
4. Under Network, select Default.
5. Under Targets, select Specified target tags.
6. Populate the Target tags field with allow-health-check.
7. Set Source filter to IP ranges.
8. Set Source IP ranges to 130.211.0.0/22 and 35.191.0.0/16.
9. Under Protocols and ports, select Specified protocols and ports.
10. Select the tcp checkbox, and then type 80 for the port numbers.
11. Click Create.

gcloud

gcloud compute firewall-rules create fw-allow-health-check \
    --network=default \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:80

Reserving an external IP address

Now that your instances are up and running, set up a global static external IP address that your customers use to reach your load balancer.

Console

1. In the Google Cloud Console, go to the External IP addresses page.

   Go to the External IP addresses page

2. To reserve an IPv4 address, click Reserve static address.
3. For Name, enter lb-ipv4-1.
4. Set Network Service Tier to Premium.
5. Set IP version to IPv4.
6. Set Type to Global.
7. Click Reserve.

gcloud

gcloud compute addresses create lb-ipv4-1 \
    --ip-version=IPV4 \
    --global

Note the IPv4 address that was reserved:

gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global

Setting up the load balancer

In this example, you are using HTTPS between the client and the load balancer, so you need one or more SSL certificate resources to configure the proxy. We recommend using a Google-managed certificate.

Console

1. In the Google Cloud Console, go to the Load balancing page.

   Go to the Load balancing page

2. Click Create load balancer.
3. Under HTTP(S) Load Balancing, click Start configuration.
4. Select From Internet to my VMs, and then click Continue.
5. For the load balancer Name, enter web-map-https.
6. Click Backend configuration.
   1. Under Create or select backend services & backend buckets, select Backend services > Create a backend service.
   2. Add a name for your backend service, such as web-backend-service.
   3. Under Protocol, select HTTP.
   4. For the Named Port, enter http.
   5. In Backends > New backend > Instance group, select your instance group, lb-backend-example.
   6. For the Port numbers, enter 80.
   7. Retain the other default settings.
   8. Under Health check, select Create a health check, and then add a name for your health check, such as http-basic-check.
   9. Set the protocol to HTTP, and then click Save and continue.
   10. Retain the other default settings.
   11. Click Create.
7. In Host and path rules, retain the default settings.
8. In Frontend configuration, use the following values:
1. Set Protocol to HTTPS.
2. Set IP address to lb-ipv4-1, which you created earlier.
3. Ensure that Port is set to 443 to allow HTTPS traffic.
4. Click the Certificate drop-down list and select your primary SSL certificate.
5. Click Done.
9. Click Review and finalize.
10. When you finish configuring the load balancer, click Create.
11. Wait for the load balancer to be created.
12. Click the name of the load balancer.
13. On the Load balancer details screen, note the IP:Port for your load balancer.

gcloud

1. Create a health check.

       gcloud compute health-checks create http http-basic-check \
           --port 80
       

2. Create a backend service.

       gcloud compute backend-services create web-backend-service \
           --protocol=HTTP \
           --port-name=http \
           --health-checks=http-basic-check \
           --global
       

3. Add your instance group as the backend to the backend service.

       gcloud compute backend-services add-backend web-backend-service \
           --instance-group=lb-backend-example \
           --instance-group-zone=us-east1-b \
           --global
       

4. Create a URL map to route the incoming requests to the default backend service.

       gcloud compute url-maps create web-map-https \
           --default-service web-backend-service
       

5. If you haven't aleady done so, create the global SSL certificate resource, as shown in:
   • Creating a Google-managed SSL certificate resource
   • Creating a self-managed SSL certificate resource

   The following example assumes that you already have a certificate file called certificate-file and a private key file called private-key-file. The example creates an SSL certificate resource called www-ssl-cert.

       gcloud compute ssl-certificates create www-ssl-cert \
           --certificate=certificate-file \
           --private-key=private-key-file \
           --global
       

6. Create a target HTTPS proxy to route requests to your URL map. 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 https-lb-proxy \
           --url-map web-map-https --ssl-certificates www-ssl-cert
       

7. Create a global forwarding rule to route incoming requests to the proxy.

       gcloud compute forwarding-rules create https-content-rule \
           --address=lb-ipv4-1\
           --global \
           --target-https-proxy=https-lb-proxy \
           --ports=443
       

Testing traffic sent to your instances

Now that the load balancing service is running, you can send traffic to the forwarding rule and watch the traffic be dispersed to different instances.

Console

1. In the Google Cloud Console, go to the Load balancing page.

   Go to the Load balancing page

2. Click the load balancer that you just created.
3. In the Backend section, confirm that the VMs are healthy. The Healthy column should be populated, indicating that both VMs are healthy (2/2). If you see otherwise, first try reloading the page. It can take a few moments for the Cloud Console to indicate that the VMs are healthy. If the backends do not appear healthy after a few minutes, review the firewall configuration and the network tag assigned to your backend VMs.
4. If 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.
5. After the Cloud Console shows that the backend instances are healthy, you can test your load balancer using a web browser by going to https://IP_ADDRESS. Replace IP_ADDRESS with the load balancer's IP address.
6. If you used a self-signed certificate for testing, your browser displays a warning. You must explicitly instruct your browser to accept a self-signed certificate.
7. Your browser should render a page with content showing the name of the instance that served the page, along with its zone (for example, Page served from: lb-backend-example-xxxx). If your browser doesn't render this page, review the configuration settings in this guide.

When you are finished, the Cloud Console displays information about your HTTPS load balancer as follows.

Redirecting traffic to your HTTPS load balancer

Now that you have created an HTTPS load balancer and verified that it's working, you can redirect your HTTP traffic to it. You do this by setting up the partial HTTP load balancer.

This example uses the 301 response code. You can instead use a different response code.

Configuring the URL map that redirects traffic

To configure the redirect, you can use the Cloud Console or import a YAML file.

Console

1. In the Google Cloud Console, go to the Load balancing page.
   Go to the Load balancing page

2. Under HTTP(S) load balancing, click Start configuration.
3. Select From Internet to my VMs, and then click Continue.
4. For the Name of the load balancer, enter web-map-http.
5. Keep the window open to continue.
6. Skip the Backend Configuration section.
   This load balancer doesn't need a backend.
7. In the left column of the screen, click Host and path rules.
8. Select Advanced host and path rule (URL redirect, URL rewrite).
9. Under Action, select Redirect the client to different host/path.
10. Under Path redirect, select Full path redirect.
11. Under Redirect response code, select 301 - Moved Permanently.
12. Under HTTPS redirect, select Enable.
13. Click Done.
14. Keep the load balancer configuration page open to continue.

gcloud

1. Create a YAML file /tmp/web-map-http.yaml. This example uses MOVED_PERMANENTLY_DEFAULT as the response code.

   kind: compute#urlMap
   name: web-map-http
   defaultUrlRedirect:
      redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
      httpsRedirect: True
   

2. Create the HTTP load balancer's URL map by importing the YAML file. The name for this URL map is web-map-http.

   gcloud compute url-maps import web-map-http \
      --source /tmp/web-map-http.yaml \
      --global
   

   If you are updating an existing URL map, the following prompt appears:

   Url Map [web-map-http] will be overwritten.
   
   Do you want to continue (Y/n)?
   

   To continue, press Y.

3. Verify that the URL map is updated. Your HTTP load balancer's URL map should look something like this:

   gcloud compute url-maps describe web-map-http
   

   creationTimestamp: '2020-03-23T10:53:44.976-07:00'
   defaultUrlRedirect:
    httpsRedirect: true
    redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   fingerprint: 3A5N_RLrED8=
   id: '2020316695093397831'
   kind: compute#urlMap
   name: web-map-http
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/web-map-http
   

Configuring the HTTP frontend with the same reserved IP address

To redirect traffic, you must reuse the same IP address that your HTTPS load balancer uses.

If you're using gcloud, you must make sure that your target HTTP proxy points to the URL map that redirects traffic. If you're using the Cloud Console, this is handled for you.

Console

1. On the load balancer configuration page, click Frontend configuration.
2. For Name, enter http-content-rule.
3. Set Protocol to HTTP.
4. Set IP version to IPv4.
5. Set IP address to the same IP address that you used for your HTTPS load balancer.
6. Ensure that Port is set to 80 to allow HTTP traffic.
7. Click Done.
8. Keep the window open to continue.
9. In the left panel, click Review and finalize.
10. Compare your settings to what you intended to create.
11. If everything looks correct, click Create.

gcloud

1. Create a new target HTTP proxy or update an existing target HTTP proxy, using web-map-http as the URL map.

   gcloud compute target-http-proxies create http-lb-proxy \
      --url-map=web-map-http \
      --global
   

   OR

   gcloud compute target-http-proxies update http-lb-proxy \
      --url-map=web-map-http \
      --global
   

2. Create a global forwarding rule to route incoming requests to the proxy.

   gcloud compute forwarding-rules create http-content-rule \
      --address=lb-ipv4-1 \ # Same IP address used for HTTPS load balancer
      --global \
      --target-http-proxy=http-lb-proxy \
      --ports=80
   

When you are finished, the Cloud Console displays two load balancers, as follows.

The Cloud Console displays information about your web-map-http load balancer as follows.

Testing the HTTP-to-HTTPS redirect

Note the reserved IP address that you are using for both load balancers.

gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global

Important: If your HTTPS load balancer has a different IP address than your HTTP load balancer, the redirect won't work. In this case, delete your HTTP forwarding rule and create a new one that uses the same IP address as the HTTPS load balancer.

In this example, assume that the reserved IP address is 34.98.77.106. The http://34.98.77.106/ URL redirects to https://34.98.77.106/.

After a few minutes have passed, you can test this by running the following curl command. Be sure to replace 34.98.77.106 with your reserved IP address.

curl 34.98.77.106:80

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://34.98.77.106/">here</A>.
</BODY></HTML>

What's next

• Clean up the load balancer setup.