Skip to main content

Application Load Balancing

Exam guide§2.3

The Application Load Balancer acts at Layer 7 (the application layer) of the OSI model, so it can make routing decisions based on the URL. It distributes HTTP and HTTPS traffic to backends on Compute Engine, GKE, Cloud Storage, Cloud Run, and App Engine, as well as external backends reached over the internet or hybrid connectivity.

It comes in two deployment types: external and internal (internal is covered later in the module).

  • Global external and classic ALBs are implemented with Google Front Ends (GFEs) distributed globally. In the Premium tier they do multi-region load balancing, sending traffic to the closest healthy backend with capacity and terminating HTTP(S) as close to the user as possible.
  • Regional external ALBs use the open-source Envoy proxy for advanced traffic management.

These can be deployed in one of three modes: global, regional, or classic.

Deployment modes​

Deployment modeNetwork service tierLoad balancing schemeIP addressFrontend portsGlobal externalPremium TierEXTERNAL_MANAGEDIPv4IPv6Can reference exactlyone port from 1-65535Regional externalPremium orStandard TierEXTERNAL_MANAGEDIPv4ClassicGlobal in Premium TierRegional in Standard TierEXTERNALIPv4IPv6 (requiresPremium Tier)
The three external Application Load Balancer deployment modes and how their network tier, load balancing scheme, IP support, and port rules differ.

Request-path architecture​

Web clientsHTTP or HTTPSClient traffic terminates hereExternal Application Load BalancerNew connection from load balancer to backendsCompute EngineCloud StorageApp EngineCloud RunGoogle Kubernetes EngineBackends external to Google CloudCloud Run functionsBackends
A client request enters through the forwarding rule and target proxy, is evaluated against the URL map, then a backend service opens a new connection to a healthy backend.

The request flows through four pieces:

  1. An external forwarding rule specifies an external IP address, port, and a target HTTP(S) proxy. Clients connect to this IP and port.
  2. The target HTTP(S) proxy receives the request, evaluates it against the URL map to make routing decisions, and can authenticate with SSL certificates.
  3. A backend service distributes requests to healthy backends. Global external ALBs also support backend buckets.
  4. One or more backends are attached to the backend service (or backend bucket).

Global external ALB end to end​

Mapping those pieces onto concrete resources shows why the global external ALB is a single global front end over regional backends. The client reaches one anycast IP; the global forwarding rule hands off to a target proxy, which consults the URL map and selects a backend service; a health check gates which instances receive traffic; and firewall rules must admit the load balancer before it can reach the managed instance groups, which live in subnetworks across two regions of one VPC.

Cloud Load BalancingAnycast IPGlobal Forwarding RuleTarget ProxyURL MapBackend ServiceHealth CheckInternetFirewall RulesNetwork: DefaultVirtual Private CloudRegion 1SubNetwork 1Backend/Instance Group: us-1-migCompute EngineRegion 2SubNetwork 2Backend/Instance Group: notus-1-migCompute Engine
A global external Application Load Balancer end to end: a client reaches the anycast IP through the internet, the forwarding rule / target proxy / URL map / backend service chain routes the request, health checks gate the backends, and firewall rules admit traffic to managed instance group backends running in two regions of one VPC.
GotchaThe IP is global, the instance groups are regional

One anycast IP fronts backends in multiple regions - the load balancer sends each request to the closest healthy region with capacity. You still create the managed instance groups per region (and open firewall rules for the health-check and client traffic ranges) before any backend is reachable.

GotchaIPv6 clients are terminated at the LB and proxied over IPv4

A global external ALB frontend can serve both IPv4 and IPv6 on the same load balancer (one forwarding rule per IP version). Client IPv6 requests terminate at the global load-balancing layer and are then proxied over IPv4 to your backends - so the backends themselves never need IPv6.

HTTPS: target proxy and SSL certificates​

An HTTPS Application LB has the same structure as an HTTP one but swaps in a target HTTPS proxy in place of the target HTTP proxy.

FactsHTTPS Application LB - what differs from HTTP
  • Uses a target HTTPS proxy (not a target HTTP proxy).
  • Requires at least one signed SSL certificate installed on the target HTTPS proxy.
  • Client SSL sessions terminate at the load balancer - the proxy decrypts, then talks to backends.
  • Supports the QUIC transport layer protocol.

To serve HTTPS you first create an SSL certificate resource holding the certificate information, then attach it to the target proxy.

NumbersSSL certificate facts
  • Required for an HTTPS Application Load Balancer.
  • A target proxy holds up to 15 SSL certificates.
  • One SSL certificate resource per certificate.
GotchaQUIC speeds up the client-side connection, not the backend

QUIC lets the client-to-load-balancer leg start faster, eliminates head-of-line blocking in multiplexed streams, and survives a client IP change (connection migration - handy on mobile). It is a property of the front-end HTTPS proxy, not the backend service.

GotchaSSL certificate resources only attach to proxy load balancers

An SSL certificate resource is used only with load-balancing proxies - a target HTTPS proxy or a target SSL proxy. Passthrough Network LBs terminate nothing, so they never take one.

Backend services​

A backend service bundles a health check, session affinity, a timeout, and one or more backends.

NumbersBackend service components
  • Health check - polls attached instances at configured intervals; only instances that pass receive new requests. Unhealthy instances are cut off until they recover.
  • Session affinity (optional) - overrides the default round-robin so all requests from one client go to the same VM.
  • Timeout setting - 30 seconds by default; how long the backend service waits before treating the request as a failure.
  • One or more backends, each with an instance group, a balancing mode, and a capacity scaler.
GotchaThe backend timeout is fixed, not idle

The 30-second default is a fixed timeout on the whole request, not an idle timeout. If you need longer-lived connections, raise this value.

GotchaRound-robin is the default; session affinity is best-effort

Application Load Balancing distributes requests round-robin among available instances. Turning on session affinity attempts to pin a client to the same VM - it is a best-effort override, not a guarantee.

Backends: instance group, balancing mode, capacity scaler​

  • An instance group holds the VMs - a managed instance group (with or without autoscaling) or an unmanaged instance group.
  • A balancing mode tells the LB when a backend is at full usage, based on CPU utilization or requests per second (RPS).
  • A capacity scaler is a ceiling percentage that interacts with the balancing mode.
NumbersBalancing mode + capacity scaler
  • Target 80% CPU: balancing mode 80% CPU utilization, capacity 100%.
  • Cut utilization in half: leave balancing mode at 80% CPU utilization, set capacity 50%.
GotchaRegional overflow is automatic

If all backends for a backend service in a region hit full usage, new requests are automatically routed to the nearest region that can still handle them.

GotchaBackend-service changes are not instantaneous

Changes to backend services propagate through the network over several minutes - don't be surprised if an update doesn't take effect immediately.

Backend buckets​

A backend bucket lets an external Application LB serve content straight from a Cloud Storage bucket. The URL map routes each request path to either a backend service (dynamic content on VMs/containers) or a backend bucket (static content in Cloud Storage).

User in OsloUser in New YorkApplication Load BalancerCloud Load BalancingURL map sends /love-to-fetch/ requests to the europe-north1 backend bucketURL map sends all other requests to the us-east1 backend bucketRegion: europe-north1Cloud StorageRegion: us-east1Cloud Storage
Backend buckets let an external Application Load Balancer serve static content straight from Cloud Storage: the URL map routes `/love-to-fetch/` paths to the europe-north1 bucket and everything else to the us-east1 bucket.
DECISIONBackend service vs backend bucket
Dynamic content→A backend serviceAPI responses, rendered pages, data
Static content→A backend bucket (Cloud Storage)images, CSS, downloads
Pick this when: split by whether the content is generated or static

Network endpoint groups (NEGs)​

A network endpoint group (NEG) is a configuration object naming a group of backend endpoints or services. NEGs are backends for some load balancers and for Traffic Director; a common use is routing traffic to services running in containers.

NEG typePoints to / containsEndpoint formZonalOne or more Compute Engine VMs,or services on them, in one zoneIP or IP:portInternetA single endpoint hostedoutside Google CloudFQDN:port or IP:portHybrid connectivityTraffic Director servicesrunning outside Google Cloudover hybrid connectivityServerlessCloud Run, App Engine, or Cloud Runfunctions in the same regionnone - no endpoints
The four network endpoint group types, and for each: what it points to or contains, and how its endpoints are addressed.
GotchaServerless NEGs contain no endpoints

Zonal and internet NEGs define how an endpoint is reached, whether it is reachable, and where it is. A serverless NEG carries no endpoints - it just points at a serverless service in its own region.

0%0 of 147 pages studied