Cloud Load Balancing in Google Cloud: The Traffic Police for Your Applications
A beginner-friendly guide to Google Cloud's load balancers: what they are, how a request travels through them, which type to choose, and how to keep your applications fast, secure, and affordable.
Picture a big railway station on the day of a festival. Thousands of passengers arrive at once, but there are only a few ticket counters. If everybody rushes to counter number one, that line grows endless while counters two and three sit empty. So the station appoints a smart officer at the entrance. The officer looks at every counter, sees which ones are open and which are overloaded, and politely sends each passenger to the best place. If one counter closes for lunch, the officer stops sending people there. Cloud Load Balancing is that officer for your applications. It stands in front of your servers, spreads visitors fairly, avoids the broken ones, and keeps the whole station moving. This tutorial explains the service from zero, one small idea at a time.
1What Is Cloud Load Balancing?
It is Google Cloud’s managed service for sharing incoming traffic across many servers.
The simple definition
A load balancer is a system that receives requests from users and distributes them across a group of servers, often called backends. A request is simply a message from a user’s browser or app, such as “show me the home page” or “save this order.” Cloud Load Balancing is Google’s version of this idea, and it is fully managed. That means Google runs and maintains it, and you do not install, patch, or size any special machines for it.
Google describes the service as software-defined and distributed. It is not a single box in a data center that could run out of power or capacity. It is built on large-scale Google technology, including systems named Maglev, Andromeda, Google Front Ends, and Envoy, and it scales as traffic grows.
A load balancer is the host at a busy restaurant. Guests do not choose their own tables. The host greets everyone at the door, knows which tables are free, and guides each group to the best spot. If a table is being cleaned, the host sends guests elsewhere without them even knowing.
Why does it exist?
Without a load balancer, you would give users the address of one server. If that server becomes busy, everyone slows down. If it crashes, everyone loses the service. Adding more servers does not help by itself, because users would need to know which one to visit. A load balancer solves this by giving users a single, stable address while hiding the many servers behind it.
Where is it used?
Websites, mobile app back-ends, game servers, streaming platforms, payment systems, internal company tools, and microservices all use load balancing. Whenever more than one server shares a job, or whenever a service must stay available during failures and updates, a load balancer is almost always involved.
“Cloud Load Balancing” is the name of the whole service family. Inside it are several different kinds of load balancers, such as Application Load Balancers and Network Load Balancers. Choosing the right kind is a major part of this tutorial.
2The Problems a Load Balancer Solves
Five everyday headaches disappear when traffic has a smart front door.
Overloaded servers
Traffic is shared so no single server is crushed while others are idle.
Failed servers
Health checks detect broken servers, and traffic is steered to healthy ones automatically.
Slow users far away
Global load balancers bring users in near Google’s network edge and send them to a close backend.
Risky updates
New versions can be released gradually, with a small share of users first, instead of all at once.
Attacks and clutter
Security tools sit at the front door, so malicious traffic is stopped before touching your servers.
Think of a courier company with many delivery riders. A dispatcher gives each new parcel to a rider who is free, skips riders who are sick, and sends parcels to the depot nearest the customer. Without a dispatcher, parcels would pile up at whichever rider the customer happened to call.
Scaling horizontally
There are two ways to make a service stronger. Vertical scaling means buying a bigger server. Horizontal scaling means adding more servers of the same size. Bigger servers eventually hit a ceiling and are a single point of failure. Horizontal scaling has no such ceiling, but it needs something to share the traffic among all those servers. That something is the load balancer, which is why it is the foundation of almost every large cloud design.
Older load balancers sometimes needed a “warm-up” before a huge launch. Google states that Cloud Load Balancing can handle a jump from no traffic to full traffic in seconds without pre-warming. You still need enough backend capacity behind it, which is where autoscaling groups help.
3The Core Building Blocks
Every Google Cloud load balancer is assembled from a small set of parts.
You will meet the same few terms again and again in the console, in documentation, and in interviews. Learn them now. Think of them as a chain: a request enters at the first part and passes from one to the next until it reaches a server.
Forwarding Rule
The front door. It holds the IP address, the port, and the protocol that users connect to, and points traffic at the next part.
Target Proxy
The part that ends the user’s connection (in proxy-based types) and applies settings such as HTTPS certificates.
URL Map
A set of routing rules for web traffic. It decides which backend service handles which host name or path.
Backend Service
A group of backends plus the rules for sharing traffic among them, such as the balancing method and health check.
Health Check
A regular test that asks each backend, “Are you working?” Unhealthy backends stop receiving traffic.
Backend
The actual place that runs your application: virtual machines in a group, containers, serverless services, or even servers outside Google Cloud.
Network Endpoint Group
A flexible list of backend targets, called endpoints, such as individual containers, serverless apps, or outside addresses.
SSL Certificate
A digital identity card that lets browsers trust your site and encrypt the connection.
flowchart LR
U["User"] --> FR["Forwarding rule: IP, port, protocol"]
FR --> TP["Target proxy: TLS and settings"]
TP --> UM["URL map: routing rules"]
UM --> BS["Backend service"]
BS --> B1["Backend 1"]
BS --> B2["Backend 2"]
BS --> B3["Backend 3"]
HC["Health check"] -.-> BS
Imagine a large office building. The forwarding rule is the main gate with its street address. The target proxy is the reception desk that checks identity. The URL map is the directory board saying “Accounts: floor two, Sales: floor five.” The backend service is a department, the backends are the employees in it, and the health check is the attendance register that shows who is absent today.
Not every load balancer uses every part. A passthrough Network Load Balancer, for example, has no target proxy and no URL map because it simply forwards packets. The next chapters show which parts appear in which type.
4How a Request Travels Through the Load Balancer
Following one click from a browser to a server explains most of the design.
Step-by-step journey
sequenceDiagram
participant User as User browser
participant Edge as Google edge
participant LB as Load balancer
participant BE as Healthy backend
User->>Edge: Request to the single IP address
Edge->>LB: Enter Google network near the user
LB->>LB: Apply routing rules and health status
LB->>BE: Forward to a healthy, nearby backend
BE-->>LB: Response
LB-->>User: Response returned
The user asks for your website
The browser looks up your domain name and receives the load balancer’s IP address.
Traffic enters Google’s network
For global load balancers, the single IP address is announced from many places around the world, a technique called anycast. The user’s request enters Google’s network at a point near them, and Google states its global proxy load balancers use Google Front Ends in over 80 locations.
The connection is handled
In proxy-based types, the load balancer ends the user’s connection, checks certificates, and reads the request.
Rules pick a backend
The load balancer applies routing rules, checks which backends are healthy, and chooses one with spare capacity, usually the closest.
The backend answers
The server prepares the page, and the response flows back to the user, either through the load balancer or, in passthrough types, directly.
Anycast is like a national helpline number. No matter where you are in the country, when you dial it, the call is routed to the nearest call centre. You remember one number, and the network quietly finds the closest helper.
Many beginners think a load balancer simply rotates through servers one by one. Real load balancers consider health, distance, current load, and routing rules. Round-robin is only one of several possible strategies.
5The Family of Load Balancers
Four simple questions decide which load balancer fits your job.
Question 1: What kind of traffic?
Networking people describe traffic in layers. Layer 7 means the application level, where the load balancer can read web requests such as addresses and headers. Layer 4 means the transport level, where it sees only connections and packets, like TCP and UDP. Google’s two main families follow this split.
Application Load Balancer
Layer 7. For HTTP and HTTPS traffic. Can route by host name, path, and headers. Always proxy-based.
Proxy Network Load Balancer
Layer 4. Ends the TCP connection and opens a new one to the backend. Some modes support SSL offload.
Passthrough Network Load Balancer
Layer 4. Forwards packets unchanged, so backends see the original client address. Supports TCP, UDP, and other IP protocols.
Question 2: Proxy or passthrough?
A proxy load balancer ends the client’s connection and starts a new one to the backend. A passthrough load balancer does not end anything; it passes the packets along, and the backend answers the client directly, a method called direct server return. Passthrough keeps the client’s original address visible and avoids proxy overhead, while proxy types can do more clever things, like reading web requests.
Question 3: External or internal?
External load balancers serve users on the internet. Internal load balancers serve clients inside your Google Cloud network or networks connected to it, such as through VPN or interconnect. An internal load balancer is how your own microservices find each other privately.
Question 4: Global or regional?
A global load balancer can use backends in many regions behind one IP address. A regional one uses backends in a single region. Internal setups that must span regions use a cross-region internal load balancer.
| Traffic | Product | Scope options |
|---|---|---|
| HTTP and HTTPS | Application Load Balancer | Global external, regional external, classic external, regional internal, cross-region internal |
| TCP, with optional SSL offload | Proxy Network Load Balancer | Global external, regional external, classic external, regional internal, cross-region internal |
| TCP, UDP, and other IP protocols (external) | Passthrough Network Load Balancer | Regional external, with a global external mode noted as Preview |
| TCP, UDP, and other IP protocols (internal) | Internal Passthrough Network Load Balancer | Regional only |
Application Load Balancers are like a receptionist who reads each visitor’s letter and sends them to the right department. Proxy network load balancers are like a security guard who takes the visitor’s call and phones the right person. Passthrough load balancers are like a signpost that simply points the visitor down the right corridor and lets them walk there themselves.
Google has renamed and reorganized its load balancer products over the years, and some modes carry the word “classic.” Always confirm current names and availability on the official overview page before you design.
6Application Load Balancers in Depth
The Application Load Balancer is the most popular choice, because most modern services speak HTTP.
Smart routing with URL maps
The URL map is the brain of an Application Load Balancer. It reads each incoming request and decides where it should go. You can send requests for one host name to one set of servers and another host name to a different set. You can send paths that begin with a certain prefix, such as the images area, to servers or storage built for images, and the checkout area to servers built for payments. One load balancer and one public address can therefore front many different services.
flowchart TD
U["Users"] --> LB["Application Load Balancer: one IP"]
LB --> UM{"URL map rules"}
UM -->|"shop path"| S1["Shop service"]
UM -->|"api path"| S2["API service"]
UM -->|"images path"| S3["Storage bucket for images"]
UM -->|"default"| S4["Main website"]
A URL map is the sorting room of a post office. Each letter is read, and letters addressed to different cities go into different bags. One post office door serves the whole country.
Useful features
HTTPS termination
The load balancer handles encryption with managed certificates, so backend servers do less cryptographic work.
Host and path routing
Send different parts of a site to different backend services.
Header-based and weighted routing
Direct requests by headers or split a percentage of traffic to a new version for safe testing.
Redirects and rewrites
Change addresses, for example forcing visitors from HTTP to the secure HTTPS version.
Session affinity
Optionally keep a user connected to the same backend, useful for applications that remember things on the server.
Modern web protocols
Support for faster web protocols such as HTTP/2, and in supported modes newer options, helps pages load quickly.
Global, regional, and classic
The global external Application Load Balancer fronts backends in multiple regions behind one address and is the usual choice for public websites with worldwide users. The regional external version keeps traffic inside a single region, which helps when rules require data to stay in a specific place. The classic version is the earlier generation, which behaves as global in the Premium network tier and regional in the Standard tier. For new designs, Google generally points to the newer modes, so check the current guidance.
Putting business logic into overly complicated routing rules. Keep the load balancer’s job simple: find the right service. Let the application itself handle detailed decisions, or your rules become hard to understand and test.
7Network Load Balancers in Depth
When the traffic is not ordinary web traffic, or when speed and client addresses matter, Layer 4 is the answer.
Proxy Network Load Balancers
These handle TCP traffic. The load balancer ends the client’s connection and opens a separate connection to the backend. In some external modes, it can also offload SSL, which means it handles the encryption so backends do not need to. They are good for secure non-web TCP services, such as certain messaging, mail, or custom application protocols, where you still want global reach and smart failover. Because they proxy the connection, the backend does not see the original client address by default.
Passthrough Network Load Balancers
These forward packets without ending any connection. The backend sees the real client address and replies straight to the client. They handle a wide range of protocols, including TCP, UDP, and others such as ESP, GRE, and ICMP, with some internal modes supporting even more. They suit gaming servers, voice and video over UDP, VPN gateways, and any workload where preserving the client’s address or avoiding proxy overhead is important.
| Question | Proxy Network LB | Passthrough Network LB |
|---|---|---|
| Ends the client connection? | Yes | No |
| Backend sees original client address? | Not by default | Yes |
| Protocols | TCP, with optional SSL offload in some modes | TCP, UDP, and other IP protocols |
| Response path | Through the load balancer | Directly to the client |
| Typical use | Secure TCP services with global reach | UDP, gaming, VPN, and address-sensitive workloads |
A proxy is a phone operator who answers your call, then rings the right person and relays the conversation. A passthrough is a switchboard that connects your line directly to the right person, who then speaks to you without an operator in the middle.
Multiplayer game servers
Games often use UDP for fast updates. A passthrough load balancer spreads players across game servers while keeping latency low and preserving player addresses.
Secure custom TCP services
A proxy load balancer can terminate SSL for a custom protocol and still give users one global address.
Network appliances and VPN gateways
Internal passthrough load balancing can spread traffic across groups of firewalls or gateways while keeping packets unchanged.
If your application needs the real visitor address for logging, security, or fraud checks, either choose passthrough or learn how your proxy load balancer passes the original address along, for example in a header or with the proxy protocol where supported.
8Internal Load Balancing
Not every request comes from the internet. Many come from your own services.
Modern applications are often split into many small services that call each other, such as a cart service calling a pricing service. Each of those services may run on several servers, so callers need a stable address. Internal load balancers provide that address inside your private network. They are not reachable from the public internet; only clients in your Virtual Private Cloud network, or in connected networks via VPC Network Peering, Cloud VPN, or Cloud Interconnect, can use them.
flowchart LR
I["Internet users"] --> EXT["External Application Load Balancer"]
EXT --> WEB["Web tier"]
WEB --> ILB1["Internal load balancer"]
ILB1 --> APP["App tier"]
APP --> ILB2["Internal load balancer"]
ILB2 --> DATA["Data services"]
Why use internal load balancers?
Advantages
- Private services stay off the public internet
- Each tier can scale and fail independently
- Stable internal addresses simplify configuration
- Health checks protect internal calls from broken servers
- Works across hybrid networks that connect to your office or data center
Disadvantages / Trade-offs
- Extra components to design, monitor, and pay for
- Some internal modes are regional, so cross-region needs specific cross-region types
- Envoy-based internal types use proxy-only subnets that you must plan for
An internal load balancer is the internal phone directory of a company. Employees dial “Accounts” and are connected to whoever is available in that department. Outsiders never see this directory, and the staff list can change without anyone needing to learn new numbers.
Exposing internal services through a public load balancer for convenience. Keep internal calls on internal load balancers and private addresses, so there is simply nothing for outsiders to attack.
9Backends: Where Traffic Finally Lands
A load balancer is only as useful as the places it can send traffic.
Google says backends can run on Compute Engine, on Google Kubernetes Engine, and even outside Google Cloud. Different backend types suit different styles of application.
Managed instance groups
Groups of identical virtual machines that can autoscale and heal themselves. The classic choice for server-based applications.
Zonal network endpoint groups
Lists of individual targets, such as virtual machines or container addresses, which gives finer control than a plain group.
Serverless network endpoint groups
Let the load balancer front serverless products such as Cloud Run, App Engine, and Cloud Run functions.
Internet and hybrid endpoint groups
Point to servers outside Google Cloud, in your own data center or another provider, helping gradual migrations.
Backend buckets
Serve static files such as images and scripts straight from Cloud Storage, with the option of caching.
Backends are the different kinds of workers a manager can assign tasks to: permanent staff in the office, freelancers who work on demand, partners at other companies, and a storeroom of ready-made materials. The manager, our load balancer, does not care who does the work, only that the right task reaches a worker who can handle it.
How traffic is shared among backends
Each backend service includes settings that decide how much traffic each backend gets. Common ideas are balancing by number of requests, by connections, or by processor use, together with a capacity setting for each backend. When a backend is full, new requests flow to others. For global load balancers, traffic generally prefers backends close to the user and spills over to farther regions only when nearby ones are full or unhealthy.
Autoscaling partners
The most powerful combination is a load balancer with an autoscaled managed instance group. As traffic rises, the group adds virtual machines, and the load balancer starts sending requests to them once they pass health checks. When traffic falls, the group removes machines, and the load balancer stops using them, with connection draining giving in-flight requests time to finish.
Design backends so any server can handle any request, with shared data stored in databases or caches. This makes scaling, failover, and updates far simpler and reduces your need for session affinity.
10Health Checks and Automatic Failover
The quiet superpower of load balancing is noticing trouble before users do.
What a health check does
A health check is a small, repeated test sent by Google to each backend. It might ask a web server for a simple status page, or try to open a connection on a certain port. If a backend answers correctly several times in a row, it is marked healthy. If it fails several times, it is marked unhealthy, and the load balancer stops sending it traffic. When it recovers, it is welcomed back automatically. You choose the protocol, port, how often to check, how long to wait, and how many passes or failures change the status.
A health check is a doctor’s morning round in a hospital. Every patient is checked at regular times. Anyone who is not well enough is moved out of the busy ward until they recover, so the ward keeps working smoothly.
Failover across regions
With a global load balancer, if all backends in one region become unhealthy, traffic moves to backends in another region. Google states that multi-region failover is a built-in capability. This protects you from large problems, such as a regional outage, which single-region designs cannot survive. Regional load balancers spread backends across zones, which survives a zone failure but not a full regional outage.
flowchart TD
U["Users worldwide"] --> G["Global load balancer"]
G --> R1["Region A backends: healthy"]
G -. "traffic moves only if A fails" .-> R2["Region B backends: standby or active"]
HC["Health checks"] --> R1
HC --> R2
Designing good health checks
Test something meaningful
A check that only confirms the web server process is running may miss a broken database connection. A better check confirms that the app can do its essential work.
Keep it light
Health checks run very often from many places. Make the test quick and cheap so that it never becomes a load on its own.
Allow the health check traffic
Your firewall rules must permit Google’s health check probes to reach the backends. A very common cause of “all backends unhealthy” is a firewall that blocks them.
Tune the thresholds
Too sensitive and servers flap in and out of service; too relaxed and failures last longer than necessary.
A health check that depends on a shared database. If the database is slow, every backend fails its check at once, and the load balancer sees no healthy servers. Keep checks focused on the server itself, and handle dependencies with application-level error messages.
11Network Service Tiers: Premium and Standard
Where the traffic travels affects both speed and price.
Google Cloud offers two network service tiers. In the Premium tier, traffic uses Google’s own global backbone network for most of the journey, which generally gives better performance and lower delay. In the Standard tier, traffic travels over the ordinary public internet, which usually costs less but with less predictable performance. Google notes that some load balancing services are available only in the Premium tier, and that classic Application Load Balancers and proxy Network Load Balancers are global in Premium but regional in Standard.
| Point | Premium tier | Standard tier |
|---|---|---|
| Path of traffic | Google’s global backbone | Public internet |
| Performance | Generally lower delay and more consistent | Varies with internet conditions |
| Price | Higher | Lower |
| Global load balancers | Required for global external Application and proxy Network modes | Not available for those modes |
| Best for | Worldwide users and user-facing apps | Cost-sensitive, region-bound workloads |
Premium tier is a private expressway that you enter close to your home and leave close to your destination. Standard tier is the public road network, where your route and travel time depend on local traffic. The expressway costs more, but your trip is smoother.
Premium is the default. Start there for public, global services, and consider Standard only for regional workloads where the savings are worth slightly less predictable performance.
12Security at the Front Door
The load balancer is the first place to stop bad traffic.
Shared responsibility
Google secures its network and the load balancing infrastructure. You decide which services are exposed, what rules apply, which certificates are used, and how your backends are protected. Many cloud incidents happen on the customer’s side of this line.
Layers of protection
TLS encryption
Use HTTPS so that data between users and your service is encrypted. Google-managed certificates can be renewed automatically.
Cloud Armor
A web application firewall and DDoS defense service that works with the load balancer to block attacks and unwanted traffic.
Identity-Aware Proxy
Lets you require sign-in for internal web applications at the load balancer, without changing the application.
Firewall rules
Limit which sources can reach your backends, ideally only the load balancer and health check ranges.
Private backends
Keep backend servers without public addresses, so the only way in is through the load balancer.
Access control with IAM
Control who can create or change load balancers, certificates, and rules.
A well-protected building has a guard at the gate, a metal detector at the door, a badge reader on each floor, and locks on the vault. No single control is enough. Each layer catches what the previous one missed.
Why the front door is a good place for security
Because every request passes through the load balancer, filtering there means your servers never even see most harmful traffic. Google notes that requests blocked by Cloud Armor do not travel through the load balancer, which also reduces your processing costs. Large-scale floods, called distributed denial of service attacks, are absorbed by Google’s wide network at the edge rather than overwhelming a single server.
Protecting the load balancer but leaving backend servers directly reachable from the internet. Attackers can then skip the front door entirely. Allow backend traffic only from the load balancer and health check ranges.
13Speed: Caching, CDN, and Performance
The fastest request is the one your servers never have to answer.
Cloud CDN
A content delivery network, or CDN, keeps copies of popular files in many places around the world, close to users. Cloud CDN works together with global external Application Load Balancers. When a user asks for an image or script that is already cached nearby, the answer comes from the cache and never reaches your servers. This makes pages load faster and reduces load on your backends. Google notes that cache hits do not pass through the load balancer, which also lowers data processing charges.
A CDN is a chain of neighborhood libraries that keep copies of the most popular books. Readers borrow from the nearest branch instead of traveling to the central warehouse each time, and the warehouse is spared a constant stream of visitors.
Other performance helpers
Entering Google’s network near the user
With global load balancers, connections enter Google’s network at an edge close to the user, so the slow part of the journey over the public internet is short.
Connection reuse and modern protocols
Proxy-based load balancers can keep long-lived connections to backends and support efficient web protocols, saving setup time on each request.
Compression and caching headers
Sending smaller responses and telling browsers what they can cache reduces both delay and bandwidth.
Routing to the nearest healthy backend
Global load balancers prefer nearby backends, lowering delay, and spill to farther ones only when needed.
Images, style sheets, scripts, and downloads rarely change. Serving them through Cloud CDN, ideally from a backend bucket in Cloud Storage, is often the cheapest and simplest speed improvement available.
14Safe Releases and Traffic Management
A load balancer can make deploying new versions far less scary.
Releasing a new version of an application to everyone at once is risky. If there is a hidden bug, every user suffers. With traffic management features in Application Load Balancers, you can route a small percentage of requests to the new version, watch for errors, and increase the share slowly. If problems appear, you send all traffic back to the old version in moments.
flowchart LR
U["Users"] --> LB["Application Load Balancer"]
LB -->|"95 percent"| V1["Version 1: stable"]
LB -->|"5 percent"| V2["Version 2: canary"]
Canary release
Send a tiny share of traffic to the new version first and grow it if all looks healthy.
Blue-green release
Run two full environments, old and new, and switch traffic from one to the other in one step, with an easy way back.
Header-based testing
Let staff or testers reach the new version by adding a special header, while normal users stay on the old one.
Mirroring
Copy live requests to a test backend to see how it behaves, without sending its replies to users, where the feature is available.
A canary release is like a restaurant offering a new dish to a few tables before adding it to the whole menu. If diners love it, it spreads to all tables. If something is off, the kitchen quietly removes it with little harm done.
A canary is only useful if you compare error rates and delay between versions. Set up dashboards and alerts before you release, not after.
15Monitoring, Logging, and Metrics
The load balancer sees every request, which makes it a great place to measure your service.
Metrics
Cloud Monitoring collects numbers about each load balancer, such as how many requests arrive, how many succeed or fail, how long responses take, and how many backends are healthy. These numbers help you spot trends and set alerts. For example, a sudden rise in server error responses can warn you of a broken release within minutes.
Logs
Request logging records details of requests passing through, such as the address requested, the response status, and the time it took. Because logs can be large and costly for busy services, load balancers let you decide how much to record, for instance by sampling a fraction of requests. Logs are valuable for troubleshooting, security investigations, and understanding user behavior.
Request rate
How much traffic you receive over time. Unexpected spikes may mean a campaign or an attack.
Error responses
The share of requests that fail. Server-side errors point to trouble in the backends.
Latency
How long users wait. Watch typical and worst-case values, not just averages.
Backend health
The number of healthy versus unhealthy backends. A drop is an early warning.
Cache hit ratio
With Cloud CDN, how often responses come from the cache rather than the backend.
Blocked requests
With Cloud Armor, how many requests were stopped and why.
The load balancer is like the turnstile at a stadium. It counts everyone who enters, notices how long the queues are, and knows which gates are closed. Management uses those numbers to open more gates before the crowd gets angry.
Set alerts on error rates and response time, which users feel directly, rather than only on server processor use. A service can have idle processors and still be failing its visitors.
16Pricing and Cost Optimization
The bill has a few clear parts, and knowing them helps you avoid surprises.
What you pay for
According to Google’s pricing page, the cost of load balancing is made of several components that depend on the type you use. Forwarding rules are billed hourly. The data processed by the load balancer is billed per gigabyte, with charges for both inbound and outbound data, although global forwarding rules are noted as having no separate global data processing charge. Internal load balancers based on Envoy use proxy instances billed hourly, with a minimum of three proxy instances per load balancer, even when there is no traffic. Internet data transfer out of Google Cloud is billed under network pricing rather than as a load balancer charge. Features such as Cloud CDN and Cloud Armor are billed under their own pricing. Exact prices vary by region and change over time, so always check the official page and calculator.
| Cost component | How it works |
|---|---|
| Forwarding rules | Billed per rule per hour; global and regional rules are counted separately |
| Data processed | Billed per gigabyte for inbound and outbound data, depending on the type |
| Proxy instances | For Envoy-based internal types, billed hourly with a minimum of three instances |
| Internet egress | Billed separately as network data transfer |
| Cloud CDN and Cloud Armor | Priced separately; cache hits and blocked requests do not pass through the load balancer |
| Special features | Extra charges for some options, such as certain certificate types or custom headers |
Paying for a load balancer is like paying for a toll road. There is a fixed fee for keeping the gate open, which is the forwarding rule, plus a charge for each load that passes through, which is data processed. Using a bypass road, like a cache, lowers the toll bill.
Ways to keep the bill sensible
Share one load balancer across services
Use URL map routing so that many services sit behind one forwarding rule rather than one per service.
Cache aggressively
Use Cloud CDN for static content so fewer requests reach backends and the load balancer.
Block unwanted traffic early
Cloud Armor rules stop harmful requests before they incur processing charges.
Choose the right tier
Use Standard tier for region-bound, cost-sensitive services where performance variation is acceptable.
Delete what you do not use
Remove forgotten test load balancers and unused reserved addresses, which continue to cost money.
Creating many small internal load balancers of the Envoy-based type without checking minimum charges. Each can add a baseline cost even with no traffic, so consolidate where it makes sense.
17Design Patterns and Anti-Patterns
Good designs are repeated by many teams. Bad ones are repeated even more often by accident.
Patterns that work
Global front door with regional backends
One global external Application Load Balancer, with backends in two or more regions, gives users a single address, nearby service, and failover if a region fails.
Tiered design with internal load balancers
An external load balancer fronts the web tier, and internal load balancers connect web, application, and data tiers privately.
Static content from a backend bucket with CDN
Dynamic requests go to servers, while images and scripts come from Cloud Storage with caching, a fast and cheap split.
Serverless behind a load balancer
Fronting Cloud Run services with a load balancer provides a custom domain, security rules, and multi-region reach.
Edge security with Cloud Armor
Attach web application firewall and rate-limiting rules at the load balancer so servers see only reasonable traffic.
Anti-patterns to avoid
Problem
Backends keep important user data, such as shopping carts or sessions, only in their own memory.
Why It’s Harmful
When a server is replaced, scaled in, or fails, users lose their data, and the team must rely on sticky sessions that limit balancing and failover.
Correct Approach
Keep state in a shared database or cache so that any backend can serve any user.
Problem
Backend servers have public addresses and open firewalls, so users and attackers can reach them directly.
Why It’s Harmful
Attackers can bypass the load balancer, Cloud Armor rules, and certificates altogether.
Correct Approach
Keep backends private and allow traffic only from the load balancer and health check ranges.
Problem
One backend region, one zone, and one instance sit behind the load balancer.
Why It’s Harmful
The load balancer itself may be highly available, but the application still has a single point of failure.
Correct Approach
Run backends in several zones, and several regions for critical services, with autohealing and health checks.
Problem
A separate public load balancer is created for every tiny service.
Why It’s Harmful
Costs and management work multiply, and security rules become inconsistent from one load balancer to another.
Correct Approach
Use URL map routing to place many services behind one load balancer with shared security policies.
18Advantages, Trade-offs, and Best Practices
Every technology choice gives something and takes something.
Advantages
- Fully managed, with no appliances to size, patch, or replace
- One global anycast address can front backends in many regions
- Built-in health checking and automatic failover
- Scales quickly with traffic without pre-warming
- Integrates with Cloud CDN, Cloud Armor, and autoscaling groups
- Works with virtual machines, containers, serverless services, and external servers
Disadvantages / Trade-offs
- Many types and modes can confuse beginners at first
- Costs have several parts, and some options carry baseline charges
- Routing rules and settings can become complex if not kept tidy
- Misconfigured firewalls or health checks are a common source of outages
- Features differ between types, so not every capability is available everywhere
Best practices checklist
Choose the type deliberately
Work through traffic type, proxy or passthrough, external or internal, and global or regional before building.
Spread backends across zones and regions
Remove single points of failure behind the load balancer as well.
Always use HTTPS for public sites
Use managed certificates, redirect HTTP to HTTPS, and keep certificates renewed.
Layer your defenses
Combine Cloud Armor, firewall rules, private backends, and least-privilege IAM.
Automate configuration
Define load balancers in infrastructure-as-code so changes are reviewed and repeatable.
Measure and rehearse failure
Monitor errors and latency, and test failover so the first real outage is not the first practice.
19Choosing the Right Load Balancer
A simple path of questions leads to the right product almost every time.
flowchart TD
S["What traffic do you have?"] --> Q1{"HTTP or HTTPS?"}
Q1 -->|"Yes"| A["Application Load Balancer"]
Q1 -->|"No"| Q2{"Need to keep client IP or use UDP?"}
Q2 -->|"Yes"| PT["Passthrough Network Load Balancer"]
Q2 -->|"No, TCP only"| PX["Proxy Network Load Balancer"]
A --> Q3{"Users on internet?"}
PX --> Q3
PT --> Q3
Q3 -->|"Yes"| EXT["External type"]
Q3 -->|"No, internal only"| INT["Internal type"]
EXT --> Q4{"Backends in many regions?"}
Q4 -->|"Yes"| GL["Global mode"]
Q4 -->|"No"| RG["Regional mode"]
| Your situation | Good starting choice |
|---|---|
| Public website or API for worldwide users | Global external Application Load Balancer |
| Website that must keep data and TLS handling inside one region | Regional external Application Load Balancer |
| Microservices calling each other privately | Regional internal Application Load Balancer |
| Secure custom TCP service for global users | Global external proxy Network Load Balancer |
| Game servers using UDP, or need for real client addresses | External passthrough Network Load Balancer |
| Private TCP or UDP service inside your network | Internal passthrough Network Load Balancer |
If you know another cloud
People who have used other clouds can map ideas across. The names differ, but the concepts are close cousins, and exact feature sets are not identical.
| Idea | Google Cloud | Amazon Web Services | Microsoft Azure |
|---|---|---|---|
| Web traffic, Layer 7 | Application Load Balancer | Application Load Balancer | Application Gateway |
| Fast Layer 4 traffic | Network Load Balancer | Network Load Balancer | Azure Load Balancer |
| Global entry and acceleration | Global external Application Load Balancer with one anycast IP | Global Accelerator and CloudFront | Front Door |
| Backend health test | Health check | Target group health check | Health probe |
| Edge firewall | Cloud Armor | AWS WAF | Web Application Firewall |
If your traffic is web traffic, start with an Application Load Balancer. Reach for Network Load Balancers when you need non-web protocols, the real client address, or the lowest possible overhead.
20Real-World and Industry Examples
Here is how different kinds of teams typically put load balancing to work.
Online shopping during a mega sale
A retailer fronts its shop with a global Application Load Balancer, autoscaled backends, and Cloud CDN for images. Traffic bursts at the start of the sale are spread across servers, and static files come from caches near shoppers.
Streaming and media sites
Media companies use caching at the edge for popular files and route live viewers to nearby backends, keeping start times short even for large audiences.
Multiplayer gaming
Game studios use passthrough load balancers for UDP traffic, spreading players across many game servers while keeping delay minimal.
Banks and payment providers
Financial teams combine regional load balancers, strict TLS settings, Cloud Armor, and private backends so that sensitive traffic is inspected at the front door and stays inside approved regions.
Software-as-a-service platforms
A single load balancer with URL map rules fronts dozens of microservices, sending each host name and path to the right service, and supports safe canary releases of new features.
Companies moving to the cloud gradually
Teams place a load balancer in front of both new cloud backends and older servers in their own data center, then slowly shift traffic to the cloud without changing the public address.
21Frequently Asked Questions
Questions beginners ask most often, answered in plain words.
No. Cloud Load Balancing is a managed, software-defined service. You configure it, and Google runs the infrastructure and scales it for you.
Application Load Balancers work at the web level and can route by host name, path, and headers for HTTP and HTTPS traffic. Network Load Balancers work at the connection and packet level for TCP, UDP, and other protocols.
A proxy load balancer ends the client’s connection and opens a new one to the backend. A passthrough load balancer forwards packets unchanged, so the backend sees the original client address and replies directly.
It is one address that is announced from many locations. Users reach the nearest entry point to Google’s network, so a single address can serve the whole world with low delay.
Through health checks, which test each backend repeatedly. Backends that fail are taken out of rotation until they pass again.
Yes. An Application Load Balancer can use URL map rules to send different host names and paths to different backend services, all behind one address.
Yes. Serverless network endpoint groups let a load balancer front products such as Cloud Run, App Engine, and Cloud Run functions, giving you custom domains, security rules, and multi-region reach.
It can terminate HTTPS using certificates, including Google-managed ones. You should also consider encrypting the connection between the load balancer and backends if your rules require it.
Mainly by forwarding rules per hour and data processed per gigabyte, with extra components for some types, such as proxy instances for Envoy-based internal load balancers. Internet egress, Cloud CDN, and Cloud Armor are billed separately.
Premium is the default and is needed for global external modes, giving better performance over Google’s backbone. Standard costs less and uses the public internet, and is available only for some regional external modes.
The most common causes are firewall rules that block health check probes, a wrong port or path in the check, or an application that is not actually listening. Check these first.
No. It removes the load balancer as a weak point and shifts traffic away from failures, but your backends still need to be spread across zones or regions with health checks and autohealing.
22Summary and Key Takeaways
Cloud Load Balancing is Google’s managed traffic officer. It gives users a single front door, then spreads their requests across healthy backends, moving traffic away from failures and toward nearby capacity. You choose between Application Load Balancers for web traffic, proxy Network Load Balancers for TCP, and passthrough Network Load Balancers for UDP and client-address-sensitive workloads, then decide whether the traffic is external or internal and global or regional. Behind the scenes, forwarding rules, target proxies, URL maps, backend services, and health checks work as a chain. With Cloud CDN, Cloud Armor, autoscaling backends, safe release strategies, and good monitoring, a beginner can build an application that is fast, secure, and resilient, and keep the bill in check by sharing load balancers, caching, and blocking bad traffic early.
Key Takeaways
- One front door, many servers — A load balancer gives users one address and spreads traffic across backends, so no single server is overloaded or a single point of failure.
- Pick the type with four questions — Decide traffic type, proxy or passthrough, external or internal, and global or regional before building.
- Know the parts — Forwarding rule, target proxy, URL map, backend service, health check, and backends form the chain that every request follows.
- Health checks drive failover — Keep checks meaningful and light, allow their traffic through firewalls, and spread backends across zones and regions.
- Secure the front door — Use HTTPS, Cloud Armor, firewall rules, private backends, and least-privilege IAM together; never leave backends directly exposed.
- Be fast and release safely — Use Cloud CDN for cacheable content, global entry near users, and canary or blue-green releases to deploy with confidence.
- Mind the bill — Costs come from forwarding rules, data processed, and some mode-specific extras, so share load balancers, cache, block early, and delete unused resources.