The Application Load Balancer is a proxy-based Layer 7 load balancer that letsyou run and scale your services. TheApplication Load Balancer distributes HTTP and HTTPS traffic to backends hosted ona variety of Google Cloud platforms—such as Compute Engine,Google Kubernetes Engine (GKE), Cloud Storage, andCloud Run—as well as external backendsconnected over the internet or by using hybrid connectivity.

Application Load Balancers are available in the following modes of deployment:

• External Application Load Balancer: Load balances traffic coming from clients on theinternet. For architecture details, seeexternal Application Load Balancerarchitecture.

  Deployment mode	Network service tier	Load balancing scheme	IP address	Frontend ports
  Global external	Premium Tier	EXTERNAL_MANAGED	IPv4 IPv6	Can reference exactly one port from 1-65535.
  Regional external	Premium or Standard Tier	EXTERNAL_MANAGED	IPv4
  Classic	Global in Premium Tier Regional in Standard Tier	EXTERNAL*	IPv4 IPv6 (requires Premium Tier)

  ^* It is possible to attachEXTERNAL_MANAGED backend services toEXTERNAL forwarding rules. However,EXTERNAL backendservices cannot be attached toEXTERNAL_MANAGED forwarding rules.To take advantage ofnew features availableonly with the global external Application Load Balancer, werecommend that you migrate your existingEXTERNAL resources toEXTERNAL_MANAGED by using the migration process described atMigrateresources from classic to global external Application Load Balancer.

• Internal Application Load Balancer: Load balances traffic within your VPC network or networks connected to your VPC network. For architecture details, seeinternal Application Load Balancer architecture.

  Deployment mode	Network service tier	Load balancing scheme	IP address	Frontend ports
  Regional internal	Premium Tier	INTERNAL_MANAGED	IPv4	Can reference exactly one port from 1-65535.
  Cross-region internal*	Premium Tier	INTERNAL_MANAGED	IPv4

  ^* The load balancer uses global resources and can be deployed inone or multiple Google Cloud regions that you choose.

Theload balancing scheme is an attribute on theforwarding rule and thebackend service of a loadbalancer and indicates whether the load balancer can be used for internal orexternal traffic. The term_MANAGED in the load balancing schemeindicates that the load balancer is implemented as a managed service either onGoogleFront Ends (GFEs) or on the open sourceEnvoy proxy. In a load balancing schemethat is_MANAGED, requests are routed either to the GFE or to theEnvoy proxy.

External Application Load Balancer

External Application Load Balancers are implemented using Google Front Ends (GFEs) or managedproxies. Global external Application Load Balancers and classic Application Load Balancers use GFEs thataredistributed globally, operating togetherby using Google's global network and control plane. GFEs offer multi-region loadbalancing in the Premium tier, directing traffic to the closest healthy backendthat has capacity and terminating HTTP(S) traffic as close as possible to yourusers. Global external Application Load Balancers and regional external Application Load Balancers use the opensourceEnvoy proxy software to enableadvanced traffic management capabilities.

These load balancers can be deployed in one of thefollowing modes:global, regional, or classic.

External Application Load Balancers support the following capabilities:

• Advanced traffic management such as traffic mirroring, weight-based trafficsplitting, and request/response-based header transformations. For details, seeTraffic management overview.
• Load balancing traffic to backends hosted on a variety of Google Cloudplatforms such as Compute Engine,Google Kubernetes Engine (GKE), Cloud Run, and more.Backend support depends on the deployment mode of the load balancer. Fordetails, see theExternal Application Load Balanceroverview.
• Cached responses withCloud CDN.
• Protection from DDoS or other web attacks by usingGoogle Cloud Armor.
• Load balancing to GKE by using eitherIngress or Gateway(fully orchestrated)orstandalone NEGs.
• Organization of global external Application Load Balancers and regional external Application Load Balancers inApp Hub applications to understandthe load balancer interactions and support business functions.

The following diagram shows a sample external Application Load Balancer architecture.

For a complete overview, seeArchitecture overview forExternal Application Load Balancers.

Internal Application Load Balancer

The internal Application Load Balancers are Envoy proxy-based regional Layer 7 loadbalancers that enable you to run and scale your HTTP application traffic behindan internal IP address. Internal Application Load Balancers support backends in one region,but can be configured to be globally accessible by clients from anyGoogle Cloud region.

The load balancer distributes traffic to backends hosted on Google Cloud,on-premises, or in other cloud environments. Internal Application Load Balancers alsosupport the following features:

• Locality policies. Within a backend instance group or network endpointgroup, you can configure how requests are distributed to member instances orendpoints. For details, seeTrafficmanagement.
• Global access. When global access is enabled, clients from any region canaccess the load balancer. For details, seeEnable globalaccess.
• Access from connected networks. You can make your load balanceraccessible to clients from networks beyond its own Google CloudVirtual Private Cloud (VPC) network. The other networks must beconnected to the load balancer's VPCnetwork by using either VPC Network Peering, Cloud VPN, orCloud Interconnect. For details, seeAccess connectednetworks.
• Compatibility with GKE by using Ingress (fully orchestrated).For details, seeConfigure Ingress forinternal Application Load Balancers.
• Organization of global internal Application Load Balancers and regional internal Application Load Balancers inApp Hub applications to understandthe load balancer interactions and support business functions.

For a complete overview, seeArchitecture overview forinternal Application Load Balancers.

Use cases

The following sections depict some common use cases for Application Load Balancers.

Three-tier web services

You can deploy a combination of Application Load Balancers andNetwork Load Balancers to support conventional three-tier web services. Thefollowing example shows how you can deploy each tier, depending on your traffictype:

• Web tier. The application's frontend is served by an external Application Load Balancerwith instance group backends. Traffic enters from theinternet and is proxied from the load balancer to a set of instance groupbackends in various regions. These backends send HTTP(S) traffic to a set ofinternal Application Load Balancers.
• Application tier. The application's middleware is deployed and scaled byusing an internal Application Load Balancer and instance group backends. Theload balancers distribute the traffic to middleware instance groups. Thesemiddleware instance groups then send the traffic to internal passthrough Network Load Balancers.
• Database tier. The Network Load Balancers serve as frontends for thedatabase tier. They distribute traffic to data storage backends in variousregions.

Global access for regional internal Application Load Balancers

If youenable global access for yourregional internal Application Load Balancer,your web-tier client VMs can be in another region.

This multitiered application example shows the following:

• A globally available internet-facing web tier that load balances trafficby using an external Application Load Balancer.
• An internal backend load-balanced database tier in theus-east1 regionthat is accessed by the global web tier.
• A client VM that is part of the web tier in theeurope-west1 region thataccesses the internal load-balanced database tier located inus-east1.

Workloads with jurisdictional compliance

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

Advanced traffic management

The Application Load Balancers support advanced traffic management features thatgive you fine-grained control over how your traffic is handled.These capabilities include the following:

• You can update how traffic is managed without needing to modify yourapplication code.
• You can intelligently route traffic based on HTTP(S) parameters, such ashost, path, headers, and other request parameters. For example, you can useCloud Storage buckets to handle any static video content, andyou can use instance groups or NEGs to handle all other requests.
• You can mitigate risks when deploying a new version of your application byusing weight-based traffic splitting. For example, you can send 95% of thetraffic to the previous version of your service and 5% to the new version ofyour service. After you validate that the new version works as expected,you can gradually shift the percentages until 100% of the traffic reaches thenew version of your service. Traffic splitting is typically used for deployingnew versions, A/B testing, service migration, modernizing legacy services, andsimilar processes.

Following is an example of path-based routing implemented by using aninternal Application Load Balancer. Each path is handled by a different backend.

For more details, see the following:

• Traffic management overview forglobal external Application Load Balancers
• Traffic management overview forregional external Application Load Balancers

Extensibility with Service Extensions

The integration withService Extensionslets you inject custom logic into the load balancing path ofsupported Application Load Balancers.

For more information, seeService Extensions overview.

Migrating legacy services to Google Cloud

Migrating an existing service to Google Cloud lets youfree up on-premises capacity and reduce the cost and burden of maintainingan on-premises infrastructure. You can temporarily set up a hybriddeployment that lets you route traffic to both your currenton-premises service and a corresponding Google Cloud service endpoint.

The following diagram demonstrates this setup with an internal Application Load Balancer. If you areusing an internal load balancer, you can configure the Google Cloud loadbalancer to use weight-based traffic splitting to split traffic across the twoservices. Traffic splitting lets you start by sending 0% of the traffic to theGoogle Cloud service and 100% to the on-premises service. You can thengradually increase the proportion of traffic sent to the Google Cloudservice. Eventually, you send 100% of the traffic to the Google Cloudservice, and you can retire the on-premises service.

Load balancing for GKE applications

There are three ways to deploy Application Load Balancers for GKEclusters:

• GKE Gatewaycontroller. Supported only bythe global external Application Load Balancers, classic Application Load Balancers, andregional internal Application Load Balancers. For setup instructions, seeDeployinggateways.
• GKE Ingresscontroller. You can use thebuilt-in GKE Ingress controller, which deploysGoogle Cloud load balancers on behalf of GKE users. Thisis the same as the standalone load-balancing architecture, except that itslifecycle is fully automated and controlled by GKE. Supportedby both external and internalApplication Load Balancers. For setup instructions, see the following:
  • Configuring Ingress forexternal Application Load Balancers
  • Configuring Ingress forinternal Application Load Balancers
• Standalone zonal NEGs.Standalone NEGs are deployed and managed through the GKE NEGcontroller, but all the load balancing resources (forwarding rules, healthchecks, and so on) are deployed manually. These are supported by both externaland internal Application Load Balancers.

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

You can use an Application Load Balancer as the frontend for yourGoogle Cloud serverless applications. This lets you configure yourserverless applications to serve requests from a dedicated IP address that isnot shared with any other services.

To set this up, you use a serverless NEG as the load balancer's backend. Thefollowing diagrams show how a serverless application is integrated with anApplication Load Balancer.

Global external

This diagram shows how a serverless NEG fits into a global external Application Load Balancerarchitecture.

Regional external

This diagram shows how a serverless NEG fits into a regional external Application Load Balancerarchitecture. This load balancer only supports Cloud Runbackends.

Regional internal

This diagram shows how a serverless NEG fits into the regional internal Application Load Balancermodel. This load balancer only supports Cloud Runbackends.

Cross-region internal

This diagram shows how a serverless NEG fits into the cross-region internal Application Load Balancermodel. This load balancer only supports Cloud Runbackends.

Related documentation:

• Serverless NEGs overview
• Set up a global external Application Load Balancer with a Cloud Run,Cloud Run functions, or App Enginebackend
• Set up a regional external Application Load Balancer with a Cloud Runbackend
• Set up a regional internal Application Load Balancer with a Cloud Runbackend
• Set up a cross-region internal Application Load Balancer with Cloud Run

Load balancing to backends outside Google Cloud

Application Load Balancers support load-balancing traffic to endpoints that extendbeyond Google Cloud, such as on-premises data centers and other cloudenvironments. External backends are typically accessible in one of the followingways:

• Accessible over the public internet. For these endpoints, you use aninternet NEG as the load balancer's backend. The internet NEG is configured topoint to a single FQDN:Port or IP:Port endpoint on the external backend.Internet NEGs can be global or regional.

  The following diagram demonstrates how to connect to external backendsaccessible over the public internet using a global internet NEG.

  

  For more details, seeInternet NEGsoverview.

• Accessible by using hybrid connectivity (Cloud Interconnect orCloud VPN). For these endpoints, you use a hybrid NEG as the loadbalancer's backend. The hybrid NEG is configured to point to IP:Port endpointson the external backend.

  The following diagrams demonstrate how to connect to external backendsaccessible by using Cloud Interconnect or Cloud VPN.

  External

  

  Internal

  

  For more details, seeHybrid NEGsoverview.

Integration with Private Service Connect

Private Service Connect allows private consumption of servicesacross VPC networks that belong to different groups, teams,projects, or organizations. You can use Private Service Connectto access Google APIs and services or managed services in anotherVPC network.

You can use a global external Application Load Balancer to access services that are published by usingPrivate Service Connect. For more information, seeAboutPrivate Service Connectbackends.

You can use an internal Application Load Balancer to send requests to supported regional Google APIsand services. For more information, seeAccess Google APIs throughbackends.

High availability and cross-region failover

Cross-region failover is only available with global external Application Load Balancers,classic Application Load Balancers, and cross-region internal Application Load Balancers. These load balancerslet you improve service availability when you create global backend serviceswith backends in multiple regions. If backends in a particular region are down,traffic fails over to another region gracefully.

To learn more about how failover works, see the following topics:

• Global external Application Load Balancers: How requests aredistributed
• Cross-region internal Application Load Balancers: High availability and cross-regionfailover