Setting up an external Application Load Balancer

External Application Load Balancers with Identity-Aware Proxy (IAP) are supported with the following backend types:

• Instance groups
• Zonal network endpoint groups (NEGs)
• Serverless NEGs: One or more Cloud Run services
• Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
• Hybrid Connectivity NEGs, for endpoints that extend beyond Google Cloud, such as on-premises data centers and other public clouds that you can use hybrid connectivity to reach.
• Private Service Connect NEG, endpoint that resolves to one of the following:
  • A Google-managed regional API endpoint
  • A managed service published using Private Service Connect

For general concepts, see the External Application Load Balancer overview.

If you are an existing user of the classic Application Load Balancer, make sure that you review Migration overview when you plan a new deployment with the global external Application Load Balancer.

Load balancer topologies

For an HTTPS load balancer, you create the configuration shown in the following diagram.

For an HTTP load balancer, you create the configuration shown in the following diagram.

The sequence of events in the diagrams are as follows:

1. A client sends a content request to the external IPv4 address defined in the forwarding rule.

2. For an HTTPS load balancer, the forwarding rule directs the request to the target HTTPS proxy.

   For an HTTP load balancer, the forwarding rule directs the request to the target HTTP 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

Complete the following steps before you create the load balancer.

Set up an SSL certificate resource

To create the load balancer, you must have an SSL certificate resource that can be attached to the target proxy. The SSL certificate resource can be either a certificate map or a Compute Engine SSL certificate (classic certificate).

Certificate map

You can create a certificate map as described in one of the following documents:

• Deploy a global Google-managed certificate with load balancer authorization
• Deploy a global Google-managed certificate with DNS authorization
• Deploy a global Google-managed certificate with Certificate Authority Service
• Deploy a global self-managed certificate

Compute Engine SSL certificate

For an HTTPS load balancer, create a Compute Engine SSL certificate resource as described in one of the following documents:

• Use self-managed SSL certificates
• Use Google-managed SSL certificates

We recommend using a Google-managed certificate.

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.

For more information, see the following guides:

• Access control
• IAM Conditions

Optional: Use BYOIP addresses

With bring your own IP (BYOIP), you can import your own public addresses to Google Cloud to use the addresses with Google Cloud resources. For example, if you import your own IPv4 addresses, you can assign one to the forwarding rule when you configure your load balancer. When you follow the instructions in this document to set up the load balancer, provide the BYOIP address as the IP address.

For more information about using BYOIP, see Bring your own IP addresses.

Configure the network and subnets

To create the example network and subnet, follow these steps.

Create 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. A managed instance group creates each of its managed instances based on the instance templates that you specify.

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

Before you create a managed instance group, create an instance template.

gcloud compute instance-templates create TEMPLATE_NAME \
  --region=REGION \
  --network=NETWORK \
  --subnet=SUBNET \
  --stack-type=IPV4_ONLY \
  --tags=allow-health-check \
  --image-family=debian-10 \
  --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://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

resource "google_compute_instance_template" "default" {
  name = "lb-backend-template"
  disk {
    auto_delete  = true
    boot         = true
    device_name  = "persistent-disk-0"
    mode         = "READ_WRITE"
    source_image = "projects/debian-cloud/global/images/family/debian-11"
    type         = "PERSISTENT"
  }
  labels = {
    managed-by-cnrm = "true"
  }
  machine_type = "n1-standard-1"
  metadata = {
    startup-script = "#! /bin/bash\n     sudo apt-get update\n     sudo apt-get install apache2 -y\n     sudo a2ensite default-ssl\n     sudo a2enmod ssl\n     vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\n   http://169.254.169.254/computeMetadata/v1/instance/name)\"\n   sudo echo \"Page served from: $vm_hostname\" | \\\n   tee /var/www/html/index.html\n   sudo systemctl restart apache2"
  }
  network_interface {
    access_config {
      network_tier = "PREMIUM"
    }
    network    = "global/networks/default"
    subnetwork = "regions/us-east1/subnetworks/default"
  }
  region = "us-east1"
  scheduling {
    automatic_restart   = true
    on_host_maintenance = "MIGRATE"
    provisioning_model  = "STANDARD"
  }
  service_account {
    email  = "default"
    scopes = ["https://www.googleapis.com/auth/devstorage.read_only", "https://www.googleapis.com/auth/logging.write", "https://www.googleapis.com/auth/monitoring.write", "https://www.googleapis.com/auth/pubsub", "https://www.googleapis.com/auth/service.management.readonly", "https://www.googleapis.com/auth/servicecontrol", "https://www.googleapis.com/auth/trace.append"]
  }
  tags = ["allow-health-check"]
}

Create the managed instance group and select the instance template.

resource "google_compute_instance_group_manager" "default" {
  name = "lb-backend-example"
  zone = "us-east1-b"
  named_port {
    name = "http"
    port = 80
  }
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

Add a named port to the instance group

For your instance group, define an HTTP service and map a port name to the relevant port. The load balancing service forwards traffic to the named port. For more information, see Named ports.

gcloud compute instance-groups set-named-ports lb-backend-example \
    --named-ports http:80 \
    --zone ZONE_A

Configure 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.

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