Internal HTTP(S) Load Balancing concepts

Internal HTTP(S) Load Balancing is a proxy-based, regional Layer 7 load balancer that enables you to run and scale your services behind a private load balancing IP address that is accessible only in the load balancer's region in your VPC network.


Google Cloud Platform (GCP) Internal HTTP(S) Load Balancing is a private, proxy-based HTTP and HTTPS load balancer. It distributes traffic to backend VM instances or endpoints in network endpoint groups (NEGs) in a single region of your VPC network using a URL map. The load balancer is accessible only in the chosen region of your VPC network on a private, internal (RFC 1918) IP address.

For information about how an internal HTTP(S) load balancer compares to other GCP load balancers, refer to Choosing a load balancer.

Traffic types, scheme, and scope

An internal HTTP(S) load balancer is defined by a single URL map, which references one or more backend services with an internal managed load balancing scheme. Each backend service supports one of the following protocols — HTTP, HTTPS, or HTTP/2 — and either backend VMs or endpoints in a network endpoint group (NEG).

Because the scope of an internal HTTP(S) load balancer is regional, not global, clients and backend VMs or endpoints must all be in the same region. Clients in connected networks can use a Cloud VPN tunnel or Cloud Interconnect attachment in the same region as the load balancer.

Load balancing locations

Internal HTTP(S) Load Balancing is available in the following regions:

Region Location
asia-east1 Changhua County, Taiwan
asia-east2 Hong Kong
asia-southeast1 Jurong West, Singapore
australia-southeast1 Sydney, Australia
europe-north1 Hamina, Finland
europe-west1 St. Ghislain, Belgium
europe-west2 London, England, UK
europe-west3 Frankfurt, Germany
europe-west4 Eemshaven, Netherlands
northamerica-northeast1 Montréal, Québec, Canada
southamerica-east1 São Paulo, Brazil
us-central1 Council Bluffs, Iowa, USA
us-east1 Moncks Corner, South Carolina, USA
us-west1 The Dalles, Oregon, USA
us-west2 Los Angeles, California, USA

High-level diagram

Each internal HTTP(S) load balancer has a private IP address that acts as the frontend to its backend VMs or endpoints. Your internal client requests stay internal to your network and region.

Internal services with Layer 7-based load balancing (click to enlarge)
Internal services with Layer 7-based load balancing (click to enlarge)

Use cases


One common use case is load balancing traffic among services. In this example, the user gets video and image content using the same base URL, mygcpservice.internal, with paths /video and /images.

The internal HTTP(S) load balancer's URL map directs traffic to one backend service for video and another backend service for images, based on the URL map's path matcher.

The following diagram shows three services: video, images, and payments.

Internal (micro) services with Layer 7-based load balancing (click to enlarge)
Internal (micro) services with Layer 7-based load balancing (click to enlarge)

3-tier web services

You can use Internal HTTP(S) Load Balancing to support traditional 3-tier web services.

In the following diagram, three different types of load balancers scale the three tiers:

The diagram shows three types of GCP load balancers.

  1. A global, external HTTP(S) load balancer distributes traffic from the Internet to a set of Web frontend instance groups in various regions.
  2. These frontends send the HTTP(S) traffic to a set of regional, internal HTTP(S) load balancers (the subject of this overview).
  3. The HTTP(S) load balancers distribute the traffic to middleware instance groups.
  4. These middleware instances send the traffic to internal TCP/UDP load balancers, which load balance the traffic to data storage clusters.
Layer 7-based routing for internal tiers in multi-tier app (click to enlarge)
Layer 7-based routing for internal tiers in multi-tier app (click to enlarge)

Architecture and resources

An internal HTTP(S) load balancer's frontend consists of an internal IP address, an internal forwarding rule, and a target HTTP or HTTPS proxy. A single URL map directs traffic to one or more backend services with a load balancing scheme of INTERNAL_MANAGED. Each backend service distributes traffic among its backend instance groups or backend NEGs according to a configurable balancing mode. Within each instance group or NEG, traffic is further distributed according to a configurable policy. Refer to traffic distribution for details about how this works.

Each backend service is regional. All of the backends in a given backend service must either be instance groups or NEGs. Unmanaged instance groups, managed zonal instance groups, and managed regional instance groups are supported.

The following diagram shows the GCP resources required for an HTTP(S) internal load balancer.

Internal HTTP(S) Load Balancing components (click to enlarge)
Internal HTTP(S) Load Balancing components (click to enlarge)

The following resources define an internal HTTP(S) load balancer:

  • A regional internal forwarding rule, which specifies the internal IP address and port of your load balancer (the address used when clients connect to the load balancer), and the target proxy to which it forwards each incoming request.

  • A regional target HTTP(S) proxy receives a request from the user and forwards it to the URL map. A target HTTPS proxy supports up to a documented number of SSL certificates that allow the proxy to prove its identity to the clients.

  • A regional URL map parses the URL of a request and forwards requests to specific backend services based on the host and path of the request URL.

  • A regional backend service distributes requests to healthy backends (instance groups or NEGs).

  • A regional health check reports the readiness of your backends.

  • One or more backends must be connected to the backend service. Backends can be any of the following types:

    • Managed instance groups (zonal or regional)
    • Unmanaged instance groups (zonal)
    • Network endpoint groups (zonal)

    You cannot use instance groups and NEGs on the same backend service.

  • A proxy-only subnet whose IP addresses are the source of traffic from the load balancer to your backends. You must create one proxy-only subnet in each region of a VPC network in which you use internal HTTP(S) load balancers. This subnet is shared by all of your internal HTTP(S) load balancers in the region.

  • A firewall for your backends to accept connections from the proxy-only subnet. Refer to the example in Configuring firewall rules.


  • Internal HTTP(S) Load Balancing operates at a regional level. There's no guarantee that a request from a client in one zone of the region is sent to a backend that's in the same zone as the client. Session affinity doesn't reduce communication between zones.

  • Unlike external HTTP(S) Load Balancing, Internal HTTP(S) Load Balancing isn't compatible with the following features:

  • GCP doesn't warn you if your proxy-only subnet runs out of IP addresses.

  • You must use the gcloud command-line tool or the API to configure internal HTTP(S) load balancing during Beta. Configuration via the GCP Console isn't supported during the Beta.

What's next