Cloud Load Balancing is Google Cloud’s managed service for spreading incoming traffic across many servers, so that applications stay fast, available and able to grow.

The Short Definition

A load balancer sits in front of a group of servers and shares incoming requests among them. The servers behind it are called backends. Visitors never talk to a backend directly. They talk to the load balancer, which decides where each request goes. Cloud Load Balancing is a fully managed, software-defined service. That means there is no box for you to buy, no virtual machine for you to patch, and no capacity to pre-order. Google runs the machinery and scales it for you.

The Problem It Solves

One server can fail, get overloaded, or need maintenance. If your whole application lives on one server, then any of these events makes your service unavailable. Several servers solve the problem, but then something must decide which server handles which request, notice when one stops working, and add or remove servers as demand changes. That “something” is the load balancer. It gives you three gifts: availability because a failed server is skipped, scalability because you can add servers behind it, and performance because work is spread evenly and, in the global types, handled near the visitor.

Where It Is Used

Almost every serious website, mobile app back end and internal business system uses load balancing: online shops during sales, streaming services, banking portals, game servers, internal APIs used by other services, and databases or caches reached over private networks.

A few ideas about how computers talk will make every later chapter easier.

Layers of Communication

Computer communication is described in layers. Two matter most here. Layer 4, the transport layer, deals with connections and packets: it knows about addresses, ports and protocols such as TCP and UDP, but does not understand what is inside the message. Layer 7, the application layer, understands the actual content, such as a web address, a header or a cookie in an HTTP request.

Proxy versus Passthrough

A proxy load balancer ends the visitor’s connection and opens a separate, new connection to the backend. It stands in the middle as a go-between. This lets it do clever things such as reading web addresses, decrypting secure traffic and reusing connections. A passthrough load balancer does not end the connection. It forwards the packets as they are, so the backend sees the original visitor address and answers the visitor directly.

External versus Internal

An external load balancer receives traffic from the internet and delivers it into your Virtual Private Cloud network, which is your private, isolated network in Google Cloud. An internal load balancer receives traffic only from inside your network, or from networks connected to it through peering, VPN or interconnect. Internal load balancers are used between the layers of an application, such as a web tier talking to a private service tier.

Global versus Regional

A regional load balancer lives in one Google Cloud region and serves backends in that region. A global load balancer can serve backends spread across many regions behind a single address. Only external load balancers can be truly global. For internal use, a related idea called a cross-region internal load balancer can spread traffic across regions, using a regional internal address.

Google Cloud groups its load balancers into families, and each family comes in several deployment modes.

The Three Families

Deployment Modes

Within each family, you choose where the load balancer lives and who can reach it. The table below shows the modes that exist today, as described in Google Cloud’s overview. Names and previews change, so always confirm in the current documentation.

Protocols Each Family Handles

Eight words unlock almost every document and conversation about Cloud Load Balancing.

How the Pieces Fit Together

A visitor aims at an IP address and port. A forwarding rule catches that traffic and hands it to a target proxy (or, for passthrough types, straight to the backend service). For web traffic, the URL map examines the request and selects a backend service. The backend service picks a healthy backend according to its balancing rules, and the request is delivered. The reply returns along the reverse path.

flowchart LR
  V["Visitor"] --> FR["Forwarding rule: IP, port, protocol"]
  FR --> TP["Target proxy: certificates"]
  TP --> UM["URL map: routing rules"]
  UM --> BS1["Backend service A"]
  UM --> BS2["Backend service B"]
  BS1 --> B1["Backend: instance group"]
  BS2 --> B2["Backend: network endpoint group"]
  HC["Health checks"] -.-> B1
  HC -.-> B2
        

There are no load balancer machines for you to see, but understanding how Google builds the service explains its behaviour.

Software-Defined and Distributed

Traditional load balancers were boxes or virtual machines with a fixed capacity. You had to guess how big to make them, and a failure of the box was a failure of your front door. Cloud Load Balancing is software-defined and distributed. Its work is spread across a large fleet of machines inside Google’s network, so there is no single box that can run out of capacity or break and take your service with it.

Front Ends at the Edge

For global proxy-based load balancers, visitors connect to Google front end servers placed in many locations around the world, in more than eighty places according to Google’s overview. Because a single anycast address is announced from many places, a visitor’s traffic enters Google’s network at a point near them, and then travels across Google’s private backbone to the best healthy backend. This shortens the slowest and least reliable part of the journey: the public internet.

Autoscaling Without Pre-Warming

Because the service is distributed, it can absorb sudden growth in traffic without a warm-up phase that you have to request in advance. If a campaign suddenly sends a hundred times the usual visitors, the load balancer layer keeps up. For global setups, traffic can also be shifted to other regions when one fills up. Your backends still need to be able to scale, of course, and that is why managed instance groups and autoscalers are good partners.

flowchart TD
  U1["Visitor in Asia"] --> E1["Google front end near Asia"]
  U2["Visitor in Europe"] --> E2["Google front end near Europe"]
  U3["Visitor in America"] --> E3["Google front end near America"]
  E1 --> BB["Google private backbone"]
  E2 --> BB
  E3 --> BB
  BB --> R1["Backends in region 1"]
  BB --> R2["Backends in region 2"]
  BB --> R3["Backends in region 3"]
        

Where Passthrough Differs

Passthrough load balancers work at the packet level and do not terminate connections. Backends receive packets that still carry the visitor’s address, and they send their replies directly to the visitor. Because there is no proxy in the return path, this design is very efficient and suits protocols and workloads that a web proxy cannot handle.

For websites and APIs, the Application Load Balancer is the most capable and most commonly used choice.

What Makes It Smart

Because it understands HTTP and HTTPS, an Application Load Balancer can look inside each request and make decisions based on the host name, the path, headers, query values or cookies. This lets one public address serve many different services.

Content-Based Routing

flowchart TD
  REQ["HTTPS request"] --> LB["Application Load Balancer"]
  LB --> M{"Match host and path"}
  M -->|"shop.example.com/images"| IMG["Image backends"]
  M -->|"shop.example.com/checkout"| CHK["Checkout backends"]
  M -->|"api.example.com"| API["API backends"]
  M -->|"default"| WEB["Main site backends"]
        

Modern Web Features

Application Load Balancers support secure connections, modern web protocols, long-lived connections such as WebSockets, IPv6 addresses and weighted distribution of traffic. They can sit in front of virtual machines, containers on Google Kubernetes Engine, serverless services, storage buckets and even services running outside Google Cloud.

Global, Regional and Internal Variants

When your traffic is not web traffic, or when you need raw speed and preserved addresses, the Network Load Balancer family is the answer.

Proxy Network Load Balancers

A proxy Network Load Balancer ends a TCP connection and opens a new one to the backend. Some modes can also handle TLS encryption on behalf of the backends, so the backend servers do not each have to manage certificates. These are a good fit for non-web TCP services that benefit from a global front door, such as certain messaging, gaming or database protocol gateways.

Passthrough Network Load Balancers

A passthrough load balancer hands packets straight to a backend, with the original source address intact. It supports TCP and UDP and a number of other protocols. Backends reply directly to the visitor, a pattern sometimes called direct server return.

Internal Network Load Balancers

Internal Network Load Balancers serve clients inside your network. The internal passthrough type is always regional. It is commonly used for private services such as database proxies, DNS servers, caches or any internal TCP or UDP service that needs a stable internal address and automatic failover.

Four questions, asked in order, lead you to the right type almost every time.

flowchart TD
  S["Start: what traffic?"] --> Q1{"HTTP or HTTPS?"}
  Q1 -->|"Yes"| APP["Application Load Balancer"]
  Q1 -->|"No"| Q2{"Need UDP, other protocols or source IP kept?"}
  Q2 -->|"Yes"| PT["Passthrough Network Load Balancer"]
  Q2 -->|"No"| PX["Proxy Network Load Balancer"]
  APP --> Q3{"Internet or internal clients?"}
  PX --> Q3
  PT --> Q3
  Q3 --> Q4{"Backends in many regions?"}
  Q4 -->|"Yes"| GL["Global or cross-region mode"]
  Q4 -->|"No"| RG["Regional mode"]
        

Matching Needs to Types

A load balancer is only as useful as the servers behind it. Google Cloud offers several kinds of backends.

Instance Groups

An instance group is a collection of virtual machines treated as a single unit. A managed instance group is created from a template and can automatically add machines when load rises, remove them when it falls, replace unhealthy machines and update them in a rolling way. An unmanaged instance group is simply a hand-picked set of machines that you maintain yourself.

Network Endpoint Groups

A network endpoint group, usually called a NEG, is a collection of endpoints. An endpoint is simply a destination, such as an address and port. Different kinds of NEGs let the load balancer reach very different things.

The load balancer cannot send traffic only to healthy servers unless it can tell which servers are healthy. Health checks are how it finds out.

What a Health Check Does

A health check is a small, regular test sent to each backend. For example, every few seconds the checker may request a particular web page or open a connection to a port. If the backend answers correctly and quickly enough, it is counted as healthy. If it fails several times in a row, it is counted as unhealthy and the load balancer stops sending it new traffic. When it later passes several checks, it is welcomed back.

Key Settings

Make the Check Meaningful

A health check that only tests whether a port is open can pass even when the application behind it is stuck. A better design is a small dedicated health page in your application that checks the things that matter, such as whether it can reach its database, and answers quickly. Keep it light: a heavy health page run every few seconds by many checkers can itself become a load.

Firewall Rules for Health Checks

Health check probes come from specific Google address ranges. Your network firewall must allow those ranges to reach your backends, otherwise every backend looks unhealthy and the load balancer sends no traffic at all. This is one of the most common reasons a new setup does not work.

sequenceDiagram
  participant H as Health checker
  participant B1 as Backend 1
  participant B2 as Backend 2
  participant LB as Load balancer
  H->>B1: Probe
  B1-->>H: Healthy
  H->>B2: Probe
  B2--xH: No answer
  H->>B2: Probe again
  B2--xH: No answer
  H->>LB: Mark Backend 2 unhealthy
  LB->>B1: Send new requests only here
        

Choosing a healthy backend is only half the job. The other half is choosing a fair and sensible one.

Balancing Modes

A backend service has a balancing mode that defines how full a backend may get before traffic moves elsewhere. Different modes measure fullness differently: by the share of capacity in use, by requests per second, or by number of connections. You set a target for each backend group, and the load balancer fills groups up to that target, preferring groups that are closer to the visitor when capacity allows.

Locality and Overflow

In global setups, the load balancer prefers to send visitors to the nearest region that has capacity. If that region is full or unhealthy, traffic overflows to the next nearest region. This gives the best speed in normal times and graceful failover in bad times.

flowchart TD
  U["Visitor in Mumbai"] --> LB["Global load balancer"]
  LB --> D{"Nearest region healthy and below target?"}
  D -->|"Yes"| N["Send to nearest region"]
  D -->|"No"| O["Overflow to next nearest region"]
  O --> F["Serve from the next healthy region"]
        

Session Affinity

Sometimes a visitor’s later requests should go to the same backend as their earlier ones, for example when the server keeps a shopping cart in its own memory. This is called session affinity or stickiness. It can be based on the visitor’s address, a cookie or a header. It is useful but has a cost: it can make load uneven, and when the chosen backend disappears the visitor’s session is lost. A better long-term design stores session data in a shared place such as a cache or database so that any backend can serve any visitor.

Connection Draining

When a backend is being removed, for example during an update, a sudden cut would break requests in progress. Connection draining gives existing requests time to finish while sending no new requests to that backend. Setting a sensible drain period makes rolling updates smooth for users.

Timeouts and Retries

The load balancer waits a set time for backends to respond before giving up. Setting this correctly matters. Too short and slow but valid requests, such as large uploads, fail. Too long and failures hang visitors. Application Load Balancers can also retry a failed request on another backend in some conditions, which hides short-lived failures from users.

The route your traffic takes affects both speed and cost. Google offers two tiers to match.

The Two Tiers

Tier is chosen per resource, so you can mix tiers inside one project. Internal load balancers always use Premium Tier because their traffic stays on Google’s network. Global external Application and Network load balancers that rely on the global front ends require Premium Tier.

Because the load balancer is the front door, it is the best place to put locks.

Encryption in Transit

Secure web traffic uses TLS, a protocol that scrambles data between the visitor and the server so eavesdroppers cannot read it. Proxy-based load balancers can end TLS at the front door, using certificates that you attach to the target proxy. Certificates can be Google-managed, where Google obtains and renews them for you, or self-managed, where you supply and renew them. SSL policies let you control which protocol versions and cipher suites are accepted, so old, weak options can be disabled.

Encrypting to the Backend Too

Ending TLS at the load balancer and sending plain traffic to backends is simple but leaves the last hop unencrypted inside the network. Many regulated organisations prefer to re-encrypt traffic from the load balancer to the backend. Alternatively, passthrough load balancers keep encryption end to end because they never open the traffic.

Cloud Armor

Cloud Armor is Google’s web application and network security service. Attached to supported load balancers, it can filter traffic by address, country, request pattern and known attack signatures, apply rate limits, and help absorb large floods of traffic known as distributed denial-of-service attacks. Because filtering happens at Google’s edge, harmful traffic is stopped before it reaches your servers.

Identity-Aware Proxy

Identity-Aware Proxy puts a sign-in check in front of an application. Instead of relying on network location, it asks who the user is and whether they are allowed. Google’s guidance mentions it as an option for authentication when client addresses are not visible because of a proxy. It suits internal tools that you want to expose safely to staff without a traditional VPN.

The fastest request is one that never reaches your servers at all.

What Cloud CDN Is

CDN stands for content delivery network. Cloud CDN stores copies of your content, such as images, scripts and videos, at Google’s edge locations close to visitors. When a visitor asks for something that is already stored nearby, it is served immediately from the edge, without a trip to your backend. This cuts delay for the visitor and reduces load and cost for you. Cloud CDN works with supported Application Load Balancer modes, such as the global external and classic ones.

Making Caching Work

Other Performance Habits

The point of a load balancer is to keep your application available when things go wrong.

What Can Fail

Resilience Needs Redundant Backends

A global load balancer can survive the loss of a region only if there are healthy backends elsewhere with enough capacity to take over. A regional load balancer is affected by an outage of its region. So resilience depends on both the load balancer type and how redundantly you place and size your backends.

flowchart LR
  U["Visitors"] --> G["Global load balancer: one IP"]
  G --> R1["Region 1: zones A, B, C"]
  G --> R2["Region 2: zones A, B, C"]
  R1 -.->|"Region 1 fails"| X["Traffic shifts to Region 2"]
  R2 --> X
        

A front door needs a camera. Good observability tells you what is happening before users do.

What to Watch

Logging

Load balancers can write logs of requests, showing details such as the requested address, the response code, how long it took, which backend served it and the visitor’s location. Logging every request on very busy services can be costly, so many teams sample a fraction of requests. Logs go into Cloud Logging where they can be searched, charted and exported for analysis.

Troubleshooting Checklist

Load balancing costs are usually modest next to compute, but they have a shape worth understanding.

What You Pay For

In general, you are charged for the number of forwarding rules you run, for the amount of data the load balancer processes, and for network traffic leaving Google Cloud, which depends on the network tier. Optional services such as Cloud CDN and Cloud Armor have their own charges. Exact prices vary by mode, region and tier and change over time, so always use the current pricing page for estimates.

Ways to Keep Cost Sensible

Modern applications rarely run only on plain virtual machines. Load balancers adapt to each environment.

Containers on Google Kubernetes Engine

Kubernetes is a system for running many containers across a cluster of machines. Google Kubernetes Engine can create and manage load balancers automatically from simple declarations about your services, sending traffic directly to container addresses through network endpoint groups. Sending traffic straight to containers avoids an extra hop and spreads load more evenly than sending it to nodes first.

Serverless Services

Serverless platforms run your code without you managing servers. A serverless NEG lets a full Application Load Balancer sit in front of such a service. This gives you your own domain, a global address, caching, security policies and routing, features that a serverless service on its own may not provide.

Hybrid and Multi-Cloud

With hybrid and internet NEGs, a load balancer can send traffic to endpoints in your own data centre, another cloud, or any reachable address. This is a powerful tool for gradual migration and for putting Google’s edge, caching and security in front of services that live elsewhere.

flowchart TD
  LB["Application Load Balancer"] --> A["Instance group: virtual machines"]
  LB --> B["Zonal NEG: containers on GKE"]
  LB --> C["Serverless NEG: managed service"]
  LB --> D["Hybrid NEG: on-premises servers"]
  LB --> E["Internet NEG: external service"]
  LB --> F["Backend bucket: static files"]
        

Every design has a price. Here is an honest balance sheet.

The Decision in One Sentence

Use Cloud Load Balancing whenever more than one backend serves an application, choose the type by traffic, audience, location and tier, and remember that availability is a team effort between the load balancer and your backends.

Several services sit near load balancers and are often confused with them.

Better Together

A typical resilient design combines several of these. DNS points the site name at the load balancer’s address. The load balancer terminates TLS and routes by path. Cloud CDN caches static content. Cloud Armor filters attacks. Managed instance groups behind the load balancer scale up and down with demand, and health checks remove failing servers.

A pattern is a proven shape for a solution. These recur in healthy load-balanced systems.

flowchart TD
  DNS["DNS name"] --> GLB["Global external Application Load Balancer"]
  GLB --> ARM["Cloud Armor policy"]
  ARM --> CDN["Cloud CDN cache"]
  CDN --> BKT["Backend bucket: static files"]
  GLB --> W1["Web tier region 1"]
  GLB --> W2["Web tier region 2"]
  W1 --> ILB1["Internal load balancer"]
  W2 --> ILB2["Internal load balancer"]
  ILB1 --> S1["Service tier region 1"]
  ILB2 --> S2["Service tier region 2"]
        

An anti-pattern looks like a good idea but quietly causes trouble. These are the most common.

A checklist of habits shared by teams that run load-balanced systems calmly.

Test Failure on Purpose

Do not wait for a real outage to learn how your system behaves. In a test environment, stop a server, block a zone, or fail a health check, and watch what the load balancer does. Confirm that alerts fire, that traffic shifts, and that users see little or no impact.

Keep Configuration as Code

Describe load balancers, health checks, policies and certificates in infrastructure-as-code files stored in version control. Reviews catch risky changes, and rebuilding an environment becomes repeatable instead of a memory exercise.

Plan Certificates and Domains Early

Managed certificates need the domain to point at the load balancer before they finish provisioning. Plan the order of changes when moving a domain so that visitors are not served errors during the switch.

Review Quotas

Projects have limits on resources such as forwarding rules, backend services and addresses. Check them before large rollouts, and request increases ahead of time.

These are illustrative scenarios showing how organisations typically use load balancing, not claims about specific companies.

No. Cloud Load Balancing is a managed, software-defined service. Google runs and scales it, so you configure it rather than operate it.

An Application Load Balancer works with HTTP and HTTPS and understands web content, so it can route by host, path and headers. Network Load Balancers work at the connection and packet level for TCP, UDP and other protocols.

A proxy load balancer ends the visitor’s connection and opens a new one to the backend. A passthrough load balancer forwards packets directly, preserves the source address, and lets backends reply directly to the visitor.

Yes, with global external modes that use an anycast address and Google’s edge locations. Visitors enter Google’s network near them, and traffic goes to the best healthy backend.

The most common cause is a firewall that blocks the health check ranges. Other causes are a wrong port or path in the health check, or an application that is slow to answer.

With passthrough load balancers, yes. With proxy load balancers, the backend normally sees the proxy’s address, and the original address is usually passed along in a header for web traffic.

Premium Tier carries traffic on Google’s global backbone for lower delay and is required by some global modes. Standard Tier uses the public internet for much of the journey and costs less.

Attach Cloud Armor to supported load balancers, use strong SSL policies and managed certificates, keep backends private, and allow only the load balancer and health checkers through your firewall.

Yes, through hybrid and internet network endpoint groups for supported load balancer modes. This helps with migration and with putting Google’s edge in front of external services.

Yes. The load balancer scales on its own, but your backends do not. Managed instance groups with autoscaling add and remove servers as demand changes.

No. DNS can return different addresses, but it does not track backend health per request and answers can be cached for a while. A load balancer makes decisions on each connection or request.

Only when you must. It can unbalance load and loses sessions when a backend disappears. Prefer stateless backends with shared session storage.

Combine services behind a shared Application Load Balancer, cache content with Cloud CDN, choose the right network tier, sample logs on very busy services, and remove unused rules and addresses.

Choosing a type without answering the four questions, and forgetting the firewall rules for health checks. Spend a few minutes planning type, tier, backends and security before creating resources.

Cloud Load Balancing is Google Cloud’s managed way of sharing traffic across backends so that applications stay available, fast and ready to grow. It is a family, not a single product: Application Load Balancers for web traffic with smart routing, proxy Network Load Balancers for TCP with optional TLS handling, and passthrough Network Load Balancers for raw packets and preserved client addresses. Each comes in external or internal and global or regional modes, and the right choice follows from four questions about traffic, audience, location and network tier.

Around the load balancer sit the partners that make a design complete: health checks that keep traffic away from failed servers, managed instance groups and endpoint groups as backends, Cloud CDN for caching, Cloud Armor and TLS policies for protection, and monitoring for visibility. The best systems keep backends stateless and private, spread across zones and regions, test failure on purpose, and review their configuration regularly.