Internal Application Load Balancer overview

This document introduces the concepts that you need to understand to configure internal Application Load Balancers.

A Google Cloud internal Application Load Balancer is a proxy-based Layer 7 load balancer that enables you to run and scale your services behind a single internal IP address. The internal Application Load Balancer distributes HTTP and HTTPS traffic to backends hosted on a variety of Google Cloud platforms such as Compute Engine, Google Kubernetes Engine (GKE), and Cloud Run. For details, see Use cases.

Modes of operation

You can configure an internal Application Load Balancer in the following modes:

Cross-region internal Application Load Balancer. This is a multi-region load balancer that is implemented as a managed service based on the open-source Envoy proxy. The cross-region mode enables you to load balance traffic to backend services that are globally distributed, including traffic management that helps ensure that traffic is directed to the closest backend relative to the forwarding rule. This load balancer also enables high availability. Placing backends in multiple regions helps avoid failures in a single region. If one region's backends are down, traffic can fail over to another region.

Regional internal Application Load Balancer. This is a regional load balancer that is implemented as a managed service based on the open-source Envoy proxy. The regional mode requires that backends be in a single Google Cloud region. Clients can be limited to that region or can be in any region, based on whether global access is disabled or enabled on the forwarding rule. This load balancer is enabled with rich traffic control capabilities based on HTTP or HTTPS parameters. After the load balancer is configured, it automatically allocates Envoy proxies to meet your traffic needs.

The following table describes the important differences between cross-region and regional modes:

Load balancer mode	Feature
Load balancer mode	Virtual IP address (VIP) of the load balancer	Client access	Load balanced backends	High availability and failover
Cross-region internal Application Load Balancer	Allocated from a subnet in a specific Google Cloud region. VIP addresses from multiple regions can share the same global backend service. You can configure DNS-based global load balancing by using DNS routing policies to route client requests to the closest VIP address.	Always globally accessible. Clients from any Google Cloud region in a VPC can send traffic to the load balancer.	Global backends. Load balancer can send traffic to backends in any region.	Automatic failover to healthy backends in the same or different regions.
Regional internal Application Load Balancer	Allocated from a subnet in a specific Google Cloud region.	Not globally accessible by default. You can optionally enable global access.	Regional backends. Load balancer can only send traffic to backends that are in the same region as the proxy of the load balancer.	Automatic failover to healthy backends in the same region.

Identify the mode

Console

In the Google Cloud console, go to the Load balancing page.

Go to Load balancing

On the Load Balancers tab, you can see the load balancer type, protocol, and region. If the region is blank, then the load balancer is in the cross-region mode. The following table summarizes how to identify the mode of the load balancer.

Load balancer mode	Load balancer type	Access type	Region
Cross-region internal Application Load Balancer	Application	Internal
Regional internal Application Load Balancer	Application	Internal	Specifies a region

gcloud

To determine the mode of a load balancer, run the following command:

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

In the command output, check the load balancing scheme, region, and network tier. The following table summarizes how to identify the mode of the load balancer.

Load balancer mode	Load balancing scheme	Forwarding rule
Cross-region internal Application Load Balancer	INTERNAL_MANAGED	Global
Regional internal Application Load Balancer	INTERNAL_MANAGED	Regional

Architecture and resources

The following diagram shows the Google Cloud resources required for internal Application Load Balancers:

Cross-region internal Application Load Balancer

This diagram shows the components of a cross-region internal Application Load Balancer deployment in Premium Tier within the same VPC network. Each global forwarding rule uses a regional IP address that the clients use to connect.

Regional internal Application Load Balancer

This diagram shows the components of a regional internal Application Load Balancer deployment in Premium Tier.

The following resources are required for an internal Application Load Balancer deployment:

Proxy-only subnet

In the previous diagram, the proxy-only subnet provides a set of IP addresses that Google uses to run Envoy proxies on your behalf. You must create a proxy-only subnet in each region of a VPC network where you use internal Application Load Balancers.

The following table describes the differences between proxy-only subnets in the cross-region and regional modes. Cross-region and regional load balancers cannot share the same subnets.

Load balancer mode Value of the proxy-only subnet --purpose flag

Cross-region internal Application Load Balancer

Load balancer mode	Value of the proxy-only subnet `--purpose` flag
Cross-region internal Application Load Balancer	GLOBAL_MANAGED_PROXY The cross-region Envoy-based load balancer must have a proxy-only subnet in each region in which the load balancer is configured. Cross-region load balancer proxies in the same region and network share the same proxy-only subnet.
Regional internal Application Load Balancer	REGIONAL_MANAGED_PROXY All the regional Envoy-based load balancers in a region and VPC network share the same proxy-only subnet.

GLOBAL_MANAGED_PROXY

The cross-region Envoy-based load balancer must have a proxy-only subnet in each region in which the load balancer is configured. Cross-region load balancer proxies in the same region and network share the same proxy-only subnet.

Regional internal Application Load Balancer

REGIONAL_MANAGED_PROXY

All the regional Envoy-based load balancers in a region and VPC network share the same proxy-only subnet.

Further:

Proxy-only subnets are only used for Envoy proxies, not your backends.
Backend VMs or endpoints of all internal Application Load Balancers in a region and VPC network receive connections from the proxy-only subnet.
For regional internal Application Load Balancers and cross-region internal Application Load Balancers the proxy-only subnet can be configured with a stack type of IPV4_IPV6 (dual-stack).
The virtual IP address of an internal Application Load Balancer is not located in the proxy-only subnet. The load balancer's IP address is defined by its internal managed forwarding rule, which is described below.

Forwarding rule and IP address

Forwarding rules route traffic by IP address, port, and protocol to a load balancing configuration that consists of a target proxy and a backend service.

IP address specification. Each forwarding rule references a single regional IP address that you can use in DNS records for your application. You can either reserve a static IP address that you can use or let Cloud Load Balancing assign one for you. We recommend that you reserve a static IP address; otherwise, you must update your DNS record with the newly assigned ephemeral IP address whenever you delete a forwarding rule and create a new one.

Clients use the IP address and port to connect to the load balancer's Envoy proxies—the forwarding rule's IP address is the IP address of the load balancer (sometimes called a virtual IP address or VIP). Clients connecting to a load balancer must use HTTP version 1.1 or later. For the complete list of supported protocols, see Load balancer feature comparison.

The internal IP address associated with the forwarding rule can come from a subnet in the same network and region as your backends.

Port specification. Each forwarding rule for an Application Load Balancer can reference a single port from 1-65535. To support multiple ports, you must configure multiple forwarding rules. You can configure multiple forwarding rules to use the same internal IP address (VIP) and to reference the same target HTTP or HTTPS proxy as long as the overall combination of IP address, port, and protocol is unique for each forwarding rule. This way, you can use a single load balancer with a shared URL map as a proxy for multiple applications.

The type of forwarding rule, IP address, and load balancing scheme used by internal Application Load Balancers depends on the mode of the load balancer.

Cross-region internal Application Load Balancer
	Forwarding rule	`globalForwardingRules.insert` method
	Regional IP address	`addresses.insert` method
	Load balancing scheme	`INTERNAL_MANAGED`
	IP address (optional)	`SHARED_LOADBALANCER_VIP`
	Routing from the client to the load balancer's frontend	Global access is enabled by default to allow clients from any region in a VPC to access your load balancer. Backends can be in multiple regions.
Regional internal Application Load Balancer
	Forwarding rule	`forwardingRules.insert` method
	Regional IP address	`addresses.insert` method
	Load balancing scheme	`INTERNAL_MANAGED`
	IP address (optional)	`SHARED_LOADBALANCER_VIP`
	Routing from the client to the load balancer's frontend	You can enable global access to allow clients from any region in a VPC to access your load balancer. Backends must also be in the same region as the load balancer.

Forwarding rules and VPC networks

This section describes how forwarding rules used by internal Application Load Balancers are associated with VPC networks.

Load balancer mode VPC network association

Load balancer mode	VPC network association
Cross-region internal Application Load Balancer Regional internal Application Load Balancer	Depending on whether you use an IPv4 address or an IPv6 address range, there is always an explicit or implicit VPC network associated with the forwarding rule. Regional internal IPv4 addresses and IPv6 address ranges always exist inside VPC networks. When you create the forwarding rule, you're required to specify the subnet from which the internal IP address is taken. This subnet must be in the same region and VPC network where a proxy-only subnet has been created. Thus, there is an implied network association. Network and subnet requirements. For IPv6 traffic, your network and subnets must meet the following configuration requirements: VPC network: you must use a custom mode VPC network configured with the `--enable-ula-internal-ipv6` flag. Forwarding rule subnet: this subnet must be a dual-stack (`IPv4_IPv6`) or `IPV6_ONLY` subnet with the `ipv6-access-type` set to `INTERNAL`. IPv6 address allocation options. The forwarding rule must reference a `/96` range of IPv6 addresses from the subnet's `/64` internal IPv6 address range. When you configure the forwarding rule with the `--ip-version=IPV6` flag, Google Cloud automatically allocates a random `/96` IPv6 prefix from within the range of the subnet. Limitations. To specify a custom ephemeral IPv6 address, you must use the Google Cloud CLI or the API. The Google Cloud console doesn't support specifying custom ephemeral IPv6 addresses for forwarding rules.

Cross-region internal Application Load Balancer

Regional internal Application Load Balancer

Depending on whether you use an IPv4 address or an IPv6 address range, there is always an explicit or implicit VPC network associated with the forwarding rule.

Regional internal IPv4 addresses and IPv6 address ranges always exist inside VPC networks. When you create the forwarding rule, you're required to specify the subnet from which the internal IP address is taken. This subnet must be in the same region and VPC network where a proxy-only subnet has been created. Thus, there is an implied network association.

Network and subnet requirements. For IPv6 traffic, your network and subnets must meet the following configuration requirements:

VPC network: you must use a custom mode VPC network configured with the --enable-ula-internal-ipv6 flag.
Forwarding rule subnet: this subnet must be a dual-stack (IPv4_IPv6) or IPV6_ONLY subnet with the ipv6-access-type set to INTERNAL.

IPv6 address allocation options. The forwarding rule must reference a /96 range of IPv6 addresses from the subnet's /64 internal IPv6 address range. When you configure the forwarding rule with the --ip-version=IPV6 flag, Google Cloud automatically allocates a random /96 IPv6 prefix from within the range of the subnet.

Limitations. To specify a custom ephemeral IPv6 address, you must use the Google Cloud CLI or the API. The Google Cloud console doesn't support specifying custom ephemeral IPv6 addresses for forwarding rules.

Target proxy

A target HTTP or HTTPS proxy terminates HTTP(S) connections from clients. The HTTP(S) proxy consults the URL map to determine how to route traffic to backends. A target HTTPS proxy uses an SSL certificate to authenticate itself to clients.

The load balancer preserves the Host header of the original client request.

Depending on the type of traffic your application needs to handle, you can configure a load balancer with either a target HTTP proxy or a target HTTPS proxy.

The following table shows the target proxy APIs required by internal Application Load Balancers: