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:
||Changhua County, Taiwan|
||Jurong West, Singapore|
||St. Ghislain, Belgium|
||London, England, UK|
||Montréal, Québec, Canada|
||São Paulo, Brazil|
||Council Bluffs, Iowa, USA|
||Moncks Corner, South Carolina, USA|
||The Dalles, Oregon, USA|
||Los Angeles, California, USA|
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.
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
The internal HTTP(S) load balancer's URL map directs traffic to one backend
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.
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:
Web tier: Traffic enters from the internet and is load balanced by a global, external HTTP(S) load balancer.
Application tier: The application tier is scaled using the regional internal HTTP(S) load balancer.
Database tier: The database tier is scaled using the internal TCP/UDP load balancer.
The diagram shows three types of GCP load balancers.
- A global, external HTTP(S) load balancer distributes traffic from the Internet to a set of Web frontend instance groups in various regions.
- These frontends send the HTTP(S) traffic to a set of regional, internal HTTP(S) load balancers (the subject of this overview).
- The HTTP(S) load balancers distribute the traffic to middleware instance groups.
- These middleware instances send the traffic to internal TCP/UDP load balancers, which load balance the traffic to data storage clusters.
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
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
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.
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
gcloudcommand-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.
- See Preparing for Internal HTTP(S) Load Balancing setup for information on configuring Internal HTTP(S) Load Balancing.
- See Proxy-only subnets for internal HTTP(S) load balancers for information on managing the proxy-only subnet resource required by Internal HTTP(S) Load Balancing.