External Application Load Balancer use cases

The external Application Load Balancers address many use cases. This page provides some high-level examples.

Three-tier web services

You can use an external Application Load Balancer to support traditional three-tier web services. The following example shows how you can use three types of Google Cloud load balancers to scale three tiers. At each tier, the load balancer type depends on your traffic type:

The diagram shows how traffic moves through the tiers:

  1. An external Application Load Balancer (the subject of this overview) distributes traffic from the internet to a set of web frontend instance groups in various regions.
  2. These web frontends send the HTTP(S) traffic to a set of regional, internal Application Load Balancers. For the external Application Load Balancer to forward traffic to an internal Application Load Balancer, the external Application Load Balancer must have backend instances with web server software (such as Netscaler or NGINX) configured to forward the traffic to the frontend of the internal Application Load Balancer.
  3. The internal Application Load Balancers distribute the traffic to middleware instance groups.
  4. These middleware instance groups send the traffic to internal passthrough Network Load Balancers, which load balance the traffic to data storage clusters.
Layer 7-based routing for internal tiers in a multitier app.
Layer 7-based routing for internal tiers in a multitier app (click to enlarge).

Multi-region load balancing

When you configure an external Application Load Balancer in Premium Tier, it uses a global external IP address and can intelligently route requests from users to the closest backend instance group or NEG, based on proximity. For example, if you set up instance groups in North America, Europe, and Asia, and attach them to a load balancer's backend service, user requests around the world are automatically sent to the VMs closest to the users, assuming the VMs pass health checks and have enough capacity (defined by the balancing mode). If the closest VMs are all unhealthy, or if the closest instance group is at capacity and another instance group is not at capacity, the load balancer automatically sends requests to the next closest region with capacity.

In Premium Tier, the external Application Load Balancer provides multi-region load balancing, using multiple backend services, each with backend instance groups or NEGs in multiple regions.

Representation of multiregion load balancing.
Representation of multiregion load balancing (click to enlarge).

Workloads with jurisdictional compliance

Some workloads with regulatory or compliance requirements require that network configurations and traffic termination reside in a specific region. For these workloads, a regional external Application Load Balancer is often the preferred option to provide the jurisdictional controls these workloads require.

Advanced traffic management

With global external Application Load Balancers and regional external Application Load Balancers, you can add advanced traffic management capabilities that give you fine-grained control over how traffic is handled. These capabilities help you to meet your availability and performance objectives. One of the benefits of using external Application Load Balancers for these use cases is that you can update how traffic is managed without needing to modify your application code.

For more details, see the following:

Load balancing with request routing

The external Application Load Balancer supports request routing by using URL maps to select a backend service based on the requested host name, request path, or both. For example, you can use a set of instance groups or NEGs to handle your video content and another set to handle everything else.

You can also use external Application Load Balancers with Cloud Storage buckets. After you have your load balancer set up, you can add Cloud Storage buckets to it.

For more information, see URL map concepts.

Load balancing for GKE applications

There are two ways to deploy external Application Load Balancers for GKE clusters:

Load balancing for Cloud Run, Cloud Run functions, and App Engine applications

You can use a global external Application Load Balancer as the frontend for your Cloud Run, Cloud Run functions, and App Engine applications. To set this up, you use a serverless NEG for the load balancer's backend.

This diagram shows how a serverless NEG fits into the external Application Load Balancer model.

HTTPS load balancing for serverless apps.
HTTPS load balancing for serverless apps (click to enlarge).

Related documentation:

Proxying traffic to external backends with internet connectivity

Cloud Load Balancing supports proxying traffic to external backends outside Google Cloud. You can use this type of deployment when you want to serve content from an external backend, but you want your Google Cloud load balancer to be the frontend. The load balancer proxies traffic to your external endpoint by using Google's highly reliable backbone network for most of its journey, and only hands off to the public internet close to the destination.

Internet network endpoint groups in load balancing.
Internet network endpoint groups in load balancing (click to enlarge).

Related documentation:

Load balancing with hybrid connectivity

Cloud Load Balancing supports load-balancing traffic to endpoints that extend beyond Google Cloud, such as on-premises data centers and other public clouds that you can use hybrid connectivity to reach.

The following diagram demonstrates a hybrid deployment with a global external Application Load Balancer.

Hybrid connectivity with an external Application Load Balancer.
Hybrid connectivity with an external Application Load Balancer (click to enlarge).

Related documentation:

Load balancing with Private Service Connect

You can use a global external Application Load Balancer to access services that are published using Private Service Connect.

For more information, see About Private Service Connect backends.