A first, simple picture of the service before we open the hood.

A server is a computer that answers requests from other computers. When you open a shopping website, your phone sends a request, and a server sends back the page. A load balancer is a service that sits in front of many servers and decides which server should handle each incoming request. It also watches the servers, and if one stops working, it quietly stops sending visitors there.

Cloud Load Balancing is Google Cloud’s fully managed family of load balancers. “Managed” means Google runs, scales, patches and repairs the machinery. You do not create load balancer virtual machines, you do not guess how big they should be, and you do not warm them up before a big sale. You describe what you want, such as “send web traffic for this domain to these servers,” and Google’s infrastructure does the rest.

A short history

Google has been balancing traffic for its own products, such as Search, Gmail and YouTube, since the early days of the company. Over the years its engineers built special software for this job. Two famous pieces are the Google Front End servers that meet users at the edge of the network, and Maglev, a software system that spreads raw network traffic across many machines at very high speed. Google published research about Maglev in 2016.

When Google Cloud arrived, Google chose to offer the same style of load balancing to customers rather than selling boxes. Early on, a famous demonstration showed a Google Cloud load balancer going from nothing to over a million requests per second without any warm-up. Since then, the family has grown to include many types for web traffic, general network traffic, internal traffic and global traffic.

To appreciate the solution, first feel the pain of the problem.

Step 1: One server, many visitors

A new website often starts on a single server. That works for a few visitors. As the site becomes popular, the server gets busier, answers slow down, and eventually it runs out of memory or processing power and stops responding. You could buy a bigger server, which is called vertical scaling, but there is always a limit, and a bigger server is still a single point of failure.

Step 2: Many servers, but who gets the visitor?

The better idea is horizontal scaling: run many ordinary servers and share the work. That raises a new question. If you have ten servers, which one should answer the next visitor? You cannot tell visitors to pick one themselves. You need a single front door that all visitors use, and a smart helper behind it that picks a server for each request. That helper is the load balancer.

What a good load balancer must do

Traditional load balancers and their pain

Before cloud services, companies bought hardware boxes from vendors and placed them in racks. These boxes were expensive, had a fixed capacity, and needed experts to configure. If traffic doubled on a holiday, you needed a bigger box in advance. Later, software load balancers running on virtual machines became common, but you still had to size them, patch them, and run at least two for safety. The load balancer itself could become the bottleneck or the single point of failure it was meant to remove.

A small vocabulary that makes everything else easy.

Layers: the idea of Layer 4 and Layer 7

Network communication is described in layers, like the floors of a building. Two floors matter for load balancing. Layer 4 is the transport floor, where connections such as TCP and UDP live. A Layer 4 balancer sees only addresses and port numbers, like a postal worker who reads the address on an envelope but never opens it. Layer 7 is the application floor, where web requests live. A Layer 7 balancer reads the contents, such as the web address, the headers and the cookies, like a receptionist who opens the letter and routes it to the right department.

The key vocabulary

Proxy versus passthrough

Load balancers handle connections in two styles. A proxy balancer ends the client’s connection and opens a fresh one to the backend, so it sits in the middle of the conversation, like an interpreter. A passthrough balancer does not end the connection; it simply forwards packets to a backend, which talks to the client directly, like a switchboard operator who connects your call and then steps aside. Proxy balancers can read and change traffic and offer many features. Passthrough balancers are faster, keep the client’s original address, and support any protocol over the covered protocol families.

The chain of building blocks you will configure, from public address to servers.

One surprise for newcomers is that a Google Cloud load balancer is not a single object you create with one click and one name. It is a chain of small parts, each with one job, linked together. This design lets you reuse parts and gives fine control, much like building with labelled train carriages rather than buying a pre-welded train.

flowchart LR
  FR["Forwarding Rule: IP address and port"] --> TP["Target HTTPS Proxy: certificate and SSL policy"]
  TP --> UM["URL Map: host and path routing"]
  UM --> BS1["Backend Service: web"]
  UM --> BS2["Backend Service: api"]
  UM --> BB["Backend Bucket: static files"]
  BS1 --> B1["Managed Instance Group"]
  BS2 --> B2["Network Endpoint Group"]
  HC["Health Check"] -.-> BS1
  HC -.-> BS2
    

Walking the chain

Optional add-ons that attach to the chain

• Cloud CDN caches popular content at the edge so that many requests never reach your servers.
• Cloud Armor adds a web application firewall and denial-of-service defence.
• Identity-Aware Proxy demands sign-in before a user can reach an internal application.
• Certificate Manager stores and renews TLS certificates for many domains.
• Firewall rules in your VPC network decide which traffic may reach each backend machine.

Google groups its load balancers into three main families, each with external and internal members.

Family one: Application Load Balancers

These are Layer 7 proxy balancers for HTTP, HTTPS and HTTP/2 traffic, including gRPC and WebSockets. They understand web requests and offer routing by hostname and path, caching, and security add-ons. They come in global external, regional external, regional internal and cross-region internal flavours, plus an older “classic” external flavour that remains for existing setups.

Family two: Proxy Network Load Balancers

These are Layer 4 proxy balancers for TCP traffic, with or without TLS. They end the client connection like Application balancers but do not read web content. They suit non-web protocols that still benefit from global reach or TLS termination, such as certain game or messaging services.

Family three: Passthrough Network Load Balancers

These are Layer 4 passthrough balancers for TCP, UDP and other protocols. They never end the connection. They preserve the real client address and let backends answer the client directly. They are regional and come in external and internal forms.

The flagship design: one address, edge servers everywhere, and Google’s private network in between.

One address for the whole world: anycast

Normally an IP address belongs to one place. With anycast, the same IP address is announced from many Google locations around the world at once. Internet routing then delivers each user’s traffic to the closest location that announces it. A visitor in Mumbai, another in London and a third in Sao Paulo all type the same address, yet each lands at a different nearby Google edge site.

Google Front Ends at the edge

At each edge site, powerful servers called Google Front Ends, or GFEs, accept the user’s connection. They finish the TCP and TLS handshake right there, close to the user. A handshake needs several back-and-forth messages, and doing them over a short distance makes the first page load much faster than doing them across an ocean. After that, the GFE forwards the request over Google’s private backbone network toward the chosen backend region, instead of sending it across the unpredictable public internet.

flowchart TD
  U1["User in Mumbai"] --> IP["One anycast IP address"]
  U2["User in London"] --> IP
  U3["User in Sao Paulo"] --> IP
  IP --> E1["Nearest Google edge: Google Front End"]
  E1 --> BB["Google private backbone network"]
  BB --> R1["Backends in asia-south1"]
  BB --> R2["Backends in europe-west1"]
  BB --> R3["Backends in us-east1"]
    

Choosing the region and the server

Inside the load balancer, a two-step choice happens. First, which region? By default the balancer prefers the region closest to the user that still has healthy capacity. If that region is full or unhealthy, traffic spills over to the next closest. Second, which backend in that region? Here the balancer follows the balancing mode and algorithm you configured, for example “send to the backend with the fewest active requests.”

Why there is no machine to break

The global load balancer is not one machine or even one cluster. It is software spread across Google’s edge and infrastructure, backed by Google’s software-defined networking layer called Andromeda. When one edge server fails, neighbours take over its share within moments. When traffic spikes, more edge capacity is used automatically. This is why the service needs no warm-up and no capacity planning from you.

Follow one web request from the user’s phone to your server and back.

sequenceDiagram
  participant C as Client
  participant E as Edge Proxy
  participant P as Policy Layer
  participant B as Backend VM
  participant H as Health Checker
  H->>B: Probe health endpoint
  B-->>H: Healthy
  C->>E: TCP and TLS handshake
  E->>E: Terminate TLS and read HTTP request
  E->>P: Check security policy and URL map
  P-->>E: Allowed and route to backend service
  E->>B: New connection and forward request
  B-->>E: Response
  E-->>C: Response to client
    

What the backend sees

Because a proxy balancer opens its own connection to the backend, the backend sees the balancer’s address as the source. To learn the true client address, the balancer adds a header called X-Forwarded-For that lists the original address. Application code that wants to log or rate-limit by client must read this header rather than the connection address. Passthrough balancers behave differently, because the real client address arrives unchanged.

A load balancer is only as useful as the things it can send traffic to, and Google supports many kinds.

Instance groups

A managed instance group, or MIG, is a set of identical virtual machines created from one template. Google can add or remove machines automatically, which is called autoscaling, and replace broken machines automatically, which is called autohealing. An unmanaged instance group is a hand-made collection of machines that may differ from each other. MIGs are the classic and still very popular backend.

Network endpoint groups

A network endpoint group, or NEG, is a list of endpoints, where an endpoint is an address and port or a service. NEGs give finer control than instance groups, because the load balancer can target a single container or service instead of a whole machine.

Why container-native balancing matters

Without NEGs, traffic first reaches a node in a Kubernetes cluster and then hops again to the right Pod, which adds delay and makes health checks less accurate. With container-native load balancing, the balancer sends requests straight to Pods, so there are fewer hops, and balancing and health checks see the real application.

Mixing backends

One URL map can send “/static” to a backend bucket, “/api” to a GKE service, and “/legacy” to an internet NEG that points to an older system. This lets teams migrate step by step. You move one path at a time to the new platform while users keep the same address.

A balancer that sends visitors to a broken server is worse than no balancer at all.

A health check is a small, repeated test. Probe machines inside Google’s network send a request to every backend at a regular interval. If the backend replies correctly several times in a row, it is marked healthy. If it fails to reply correctly several times in a row, it is marked unhealthy and receives no new traffic until it recovers.

The knobs you can set

Protocols and what they prove

• TCP: proves that a port accepts connections, nothing more.
• HTTP and HTTPS: prove that the application answers a specific web path with a success code. This is far more meaningful, because a server can accept connections while its application is stuck.
• gRPC and HTTP/2: match modern service protocols.

The firewall detail that trips everyone

Health check probes come from special Google address ranges, commonly listed as 130.211.0.0/22 and 35.191.0.0/16, and for proxy-based regional balancers from a dedicated proxy-only subnet in your network. Your VPC firewall must allow them to reach your backends. If it does not, every backend looks unhealthy, and the balancer returns errors even though your servers are fine. Always confirm the current ranges in Google’s documentation.

Designing a good health endpoint

Create a dedicated path such as “/healthz” that checks the things the application truly needs, such as its ability to reach its database, but keep it light and fast. Avoid heavy work in the check, because probes arrive from many places often. Avoid making the check depend on slow external services, or one outside outage will remove every server at once.

The rules that decide which healthy backend gets the next request.

Balancing modes: how capacity is measured

Each backend group has a balancing mode that tells the balancer how to measure how full that group is.

Local balancing algorithms

Once a region and backend group are chosen, the balancer chooses one endpoint. Newer proxy-based balancers let you pick the method.

• Round robin: take turns, one after another. Simple and fair when all requests are similar.
• Least request: pick the endpoint with the fewest requests in progress. Best when requests differ a lot in cost.
• Ring hash and Maglev hashing: pick based on a hash of something stable such as the client address or a header, so the same key keeps landing on the same endpoint even when endpoints change slightly.
• Random: pick any healthy endpoint, useful at very large scale where simplicity wins.

Locality policies for global balancers

Global balancers also need a policy for spreading traffic across zones and regions. One common approach fills the nearest region first and spills over only when it is nearly full, often called a waterfall. Another spreads traffic evenly among all healthy regions that are close enough, which reduces the risk of one region being overwhelmed. Your choice trades lower latency against more even load.

Session affinity

Some applications keep temporary data in the memory of the server that handled the first request, such as a shopping cart held locally. If the next request goes elsewhere, the cart appears empty. Session affinity, also called stickiness, tries to send a visitor back to the same backend. Options include using the client address, a cookie that the balancer creates, or a value from a header. Affinity is a best effort, not a guarantee: if the chosen backend becomes unhealthy or the group changes, the visitor is moved.

Turning the load balancer from a simple distributor into a smart traffic controller.

Routing by host and path

A URL map compares each request with rules. A host rule looks at the website name, such as “shop.example.com” versus “blog.example.com.” A path rule looks at the part after the name, such as “/api/*” versus “/images/*.” The first matching rule picks the backend service. A default rule catches everything else. This is how one front door can serve dozens of different applications.

Powerful extras on proxy-based Application balancers

A safe release in five steps

Speed, simplicity and the real client address, at the cost of fewer smart features.

Packets, not conversations

A passthrough balancer works with packets, which are the small units that carry data across a network. For each new connection it picks a backend by hashing connection details, such as the source and destination addresses, ports and protocol. It then keeps sending packets from that same connection to the same backend. Because the balancer does not end the connection, it needs no TLS certificates and does not read your data.

Direct server return

With passthrough balancers, the response does not travel back through the balancer. The backend sends it straight to the client, and the client sees the reply as coming from the balancer’s address. This is called direct server return. It saves effort, because responses are usually much bigger than requests, such as a video chunk compared with a short request for it.

Maglev for the external type

For external passthrough balancing, Google uses a system based on Maglev. Many ordinary servers run the Maglev software, and network routers spread incoming packets among them evenly. Each Maglev machine uses consistent hashing to pick the backend, so even if two different Maglev machines receive packets from the same connection, they pick the same backend. This lets the front layer grow, shrink and survive failures without breaking connections.

The internal type uses the network itself

The internal passthrough balancer has no separate machines in the middle at all. The decision is made inside Google’s software-defined network on the hosts that run your virtual machines. That is why it adds almost no delay and has no choke point.

Not all traffic comes from the internet; much of it flows between your own services.

Modern systems are built from many small services that call each other, such as a web service calling an order service, which calls a payment service. Each of these inner calls also needs balancing and failover. Internal load balancers have private addresses that are reachable only from inside your network, from connected networks, or from on-premises sites linked by VPN or Interconnect.

The proxy-only subnet

Internal and regional proxy-based balancers run Envoy proxies inside your network. To give them room, you reserve a special proxy-only subnet in each region. The proxies use addresses from this block to talk to your backends, and your firewall rules must allow traffic from it. Forgetting to reserve the subnet is a very common setup error.

flowchart TD
  U["Users on the internet"] --> EL["External Application Load Balancer"]
  EL --> W["Web tier: managed instance group"]
  W --> IL["Internal Application Load Balancer"]
  IL --> A["App tier: services on GKE or VMs"]
  A --> IP2["Internal Passthrough Network Load Balancer"]
  IP2 --> D["Data tier: database proxies"]
    

Reading the picture

Users reach only the external balancer, which protects and caches. The web tier calls an internal Application balancer to reach the services in the app tier, so services can be added or moved without changing any address that callers use. At the bottom, a passthrough balancer in front of database proxies spreads raw database connections quickly while keeping the real source address for auditing.

Global access and cross-region internal balancing

By default an internal regional balancer accepts calls only from the same region. You can enable global access so clients in other regions can reach it. A cross-region internal Application balancer goes further, using one address that fronts backends in several regions, giving private applications multi-region failover.

A simple path through the family tree.

flowchart TD
  S["Start: what traffic do you serve?"] --> Q1{"Is it web traffic: HTTP or HTTPS?"}
  Q1 -->|"Yes"| Q2{"Are clients on the internet?"}
  Q1 -->|"No"| Q3{"Need the client IP kept and any protocol such as UDP?"}
  Q2 -->|"Yes"| G["External Application Load Balancer: global or regional"]
  Q2 -->|"No"| I["Internal Application Load Balancer"]
  Q3 -->|"Yes"| P["Passthrough Network Load Balancer"]
  Q3 -->|"No"| X["Proxy Network Load Balancer for TCP with TLS offload"]
    

Questions to ask yourself

How the service stays fast when a million people arrive at once.

Scaling without warm-up

With traditional balancers, a sudden surge could overwhelm the balancer before you had time to add capacity. Cloud Load Balancing is built from distributed software that uses Google’s enormous shared infrastructure, so it absorbs surges without manual preparation. For very large events, such as a product launch or ticket sale, Google still encourages customers to talk with their account team and to make sure that quotas and backend capacity are ready, because the backends are your responsibility.

Where your own scaling fits in

The balancer spreads the work, but the servers must be able to do it. A managed instance group can use autoscaling that watches signals such as processor use or the amount of traffic the balancer sends it, and adds or removes machines. This creates a lovely loop: the balancer reports load, the autoscaler adds machines, new machines pass health checks, and the balancer starts using them.

Premium Tier and Standard Tier

Google Cloud offers two Network Service Tiers. In the Premium Tier, traffic enters Google’s network at the edge closest to the user and then stays on Google’s private backbone, which usually means lower and steadier delay. Global external balancers need this tier. In the Standard Tier, traffic travels over the public internet for most of its journey and enters Google’s network close to the region where your backends live, which costs less but gives less predictable performance and works with regional scope.

Practical speed-ups

• Turn on Cloud CDN for cacheable content so that repeat requests never reach your servers.
• Enable HTTP/2 and HTTP/3 toward clients, which allows many requests over one connection.
• Compress responses either on the backends or through supported edge features, to move fewer bytes.
• Keep backends close to users by deploying in several regions and letting the global balancer pick the nearest.
• Use connection reuse by setting backend keepalive timeouts longer than the balancer’s idle timeout.
• Tune timeouts so slow requests do not hold resources forever, while genuine long operations such as uploads still finish.

What happens when a server, a zone or a whole region disappears.

Layers of protection

flowchart TD
  U["Users"] --> G["Global External Application Load Balancer"]
  G --> A["Region A: healthy, serves nearby users"]
  G -.->|"health check fails"| B["Region B: unhealthy, receives no traffic"]
  G --> C["Region C: healthy, takes spillover"]
  A -->|"overflow when full"| C
    

What the failover really needs

Failover only helps if the remaining regions can carry the extra load. If you run two regions at ninety percent each, losing one region means the other cannot cope. A common rule is to keep enough headroom that any one region can fail and the others still run safely, often called N plus one capacity. Your data layer must also be ready, because a stateless web tier in three regions is little use if the database exists in only one.

Passthrough failover groups

Passthrough balancers offer a failover feature in which you mark some backends as primary and others as standby. When too few primary backends are healthy, traffic moves to the standby group. This helps with appliances such as firewalls that should run in active and standby pairs.

Draining and graceful change

When you remove a backend or deploy a new version, connection draining lets requests already in progress finish for a set time while new requests go elsewhere. Without draining, users can see failed downloads or broken checkouts during deployments.

The balancer is your front gate, so it is the best place to put locks and guards.

Encryption with TLS

TLS is the protocol that encrypts web traffic, which is why you see a padlock in a browser. The balancer holds the certificate, a digital identity card that proves your site is genuine. You can use Google-managed certificates, which Google obtains and renews for you once your domain points at the balancer, or your own certificates. Certificate Manager helps you handle many certificates, wildcard names and automatic renewal.

An SSL policy controls which TLS versions and cipher choices are allowed. Choose a modern profile and set a sensible minimum version so that old, weak encryption is refused. For traffic from the balancer to your backends, you can use HTTPS too, so data stays encrypted all the way, which many compliance rules require.

Cloud Armor: the guard at the gate

Cloud Armor attaches to a backend service and examines requests at the edge before they reach your servers.

Identity-aware access

Identity-Aware Proxy, or IAP, can sit on the balancer and require users to sign in with their organisation’s identity before reaching the application. This replaces the old habit of putting internal tools behind a VPN. Each request is checked against who the user is and what they are allowed to do.

Protecting the backends

• Give backend machines no public IP addresses where possible, so the balancer is the only door.
• Write firewall rules that allow traffic only from the balancer and health check ranges, not from the whole internet.
• Use least-privilege permissions in IAM so only the right teams can edit balancer settings.
• Turn on audit logs to see who changed a URL map, a certificate or a security policy.
• Verify the forwarded client address carefully, because anyone can send a fake forwarded header; trust only the value added by the balancer.

The balancer rarely works alone; it is the doorway to your other Google Cloud services.

Google Kubernetes Engine

Kubernetes is a system that runs containers, which are small packaged applications. In Google Kubernetes Engine, you describe how outside traffic should reach your containers using an Ingress or the newer Gateway API. GKE then creates and manages the Google Cloud load balancer for you, including the URL map, health checks and network endpoint groups. A Service of type LoadBalancer creates a Network balancer for non-web traffic.

Serverless products

A serverless NEG allows Cloud Run, Cloud Functions and App Engine apps to sit behind a global balancer. This unlocks features that serverless URLs do not offer alone, such as a custom domain with your own certificates, Cloud Armor, Cloud CDN, and routing several functions under one address. It also enables multi-region serverless setups, where the balancer picks the nearest region that has your service deployed.

Cloud CDN and Cloud Storage

A content delivery network, or CDN, stores copies of popular files in many cities so that users download from nearby. Cloud CDN works together with the Application balancer: on a cache hit the edge answers immediately, and on a miss it fetches the file from the backend and stores it for later. Pairing a backend bucket with the CDN is a cheap and fast way to serve a static website or large downloads.

Infrastructure as code

Because a balancer is a chain of several objects, clicking through the console again and again invites mistakes. Teams usually describe the whole chain in a tool such as Terraform, review changes like any other code, and apply them the same way in every environment. This also makes it easy to rebuild the setup after an accident or to copy it for a new project.

Reading the dashboard of your front gate.

Metrics worth watching

Request logs

You can enable logging on a backend service and set a sampling rate, such as logging every request or one in ten. Each log entry records the client, the URL, the response code, the latency and a field that explains the outcome, such as whether the response came from the backend, from the cache, or was blocked by a security policy. Logs flow to Cloud Logging, where you can search them, build alerts from them, or export them to BigQuery for deeper analysis.

Reading the common error codes

Alerts that earn their keep

• Alert when the share of 5xx responses stays above a small threshold for several minutes.
• Alert when the number of healthy backends drops below the minimum you need.
• Alert when the slowest one percent of latencies crosses your service goal.
• Alert when certificates are close to expiry, if you manage your own.
• Alert on unusual spikes of denied requests, which can signal an attack or a wrongly written rule.

Knowing what you pay for helps you design wisely.

The main parts of the bill

Exact prices differ by balancer type, region and tier, and Google updates them from time to time, so always use the official pricing page and calculator for real numbers.

Ways to keep the bill sensible

• Share one balancer across many services by using host and path rules, instead of creating a separate balancer for each small service.
• Cache aggressively with Cloud CDN, because a cache hit avoids both backend work and some transfer cost.
• Compress content to reduce the number of gigabytes processed and transferred.
• Keep traffic in one region where possible; cross-region and cross-zone transfers inside your own system can add charges.
• Choose the right tier for each workload: Premium for latency-sensitive users, Standard for cost-sensitive, regional workloads.
• Delete unused balancers and reserved addresses, which keep billing even when nothing uses them.

An honest look at both sides, so you can choose with open eyes.

The trade-offs in plain words

• Smart versus simple: Application balancers read and route web content but add a little processing; passthrough balancers are leaner but see less.
• Global versus regional: global reach brings the best user experience and failover but needs the Premium Tier and careful data design.
• Managed versus control: you give up some deep tuning in exchange for never having to operate the balancer.
• Sticky versus stateless: affinity helps old applications but hides scaling problems.

Comparing with other options

Habits that work, and traps that catch many teams.

Patterns that work

Anti-patterns to avoid

Putting every idea together in one realistic build.

Imagine a small company that sells handmade goods online. At first all customers are in one country, but the owners plan to ship worldwide within a year. They want fast pages, no downtime during sales, protection from bots and a safe way to ship new versions. Let us design their front door step by step.

What the customer experiences

A customer in Singapore opens the site. DNS returns the single global address. The request reaches a nearby Google edge, where the encrypted connection is completed quickly. Cached images return instantly from the edge. The page request passes the security checks and is routed to the shop service in the nearest healthy region. If that region has a bad hour, the customer is served from the other region and never sees an error page.

A checklist for a healthy setup and a path for when things go wrong.

Best practices

Common mistakes

A troubleshooting path

Where these ideas show up in practice.

A quick reference to return to whenever a word feels unfamiliar.

Quick answers to the questions that beginners ask most often.

No. It is a managed, distributed service. There are no balancer machines for you to create, patch or resize.

Yes. A global external balancer on the Premium Tier uses one anycast address and sends each user to the closest healthy backend region.

Application balancers work at Layer 7 and understand web requests, so they can route by host and path. Network balancers work at Layer 4 and deal with connections and packets for any protocol.

The most common causes are a firewall blocking the health check ranges, the wrong port or path, or an application that returns errors on the check path. Fix these first.

Not the balancer itself. You still need backends, databases, quotas and autoscaling that can handle the load, and it is wise to load test before important launches.

Yes, using serverless network endpoint groups. This lets you add custom domains, Cloud Armor and Cloud CDN to serverless services.

With proxy balancers, read the forwarded header that the balancer adds. With passthrough balancers, the real address arrives directly.

Yes. Internet network endpoint groups and hybrid connectivity network endpoint groups can reach other clouds or your own data center.

No. It is a best effort. If the chosen backend becomes unhealthy or is removed, the visitor moves to another one, so applications should not depend on it for correctness.

DNS only hands out addresses, and cached answers make failover slow. A load balancer inspects each connection or request, checks backend health continuously and reacts within seconds.

Yes. Host and path rules in the URL map let one balancer front many sites and services, which also reduces cost and certificate work.

An internal Application balancer, often with Identity-Aware Proxy, is a good starting point. It stays private and gives routing and sign-in features without extra servers.

The whole story in a few lines before you go.

Cloud Load Balancing turns the old, fragile idea of a traffic box into a distributed service that lives at the edge of Google’s network. It accepts users at the nearest location, applies security and routing rules, picks a healthy backend, and keeps working when machines, zones or whole regions fail. Your job is to choose the right family, define clear backends and health checks, protect the edge, and watch the dashboards.