How do you make sure thousands of people can watch the same cat video at the same time without crashing the website? That is the problem cloud load balancing solves. For the Google Professional Cloud Network Engineer exam, understanding when to use each type of load balancer — and why — is a core skill that appears in multiple question formats.
Jump to a section
A simple way to picture Cloud Load Balancing Overview and Types
A food truck festival has dozens of different trucks, each serving a specific type of food. The festival's central ordering station is the single point where customers place their orders. This station does one job: it takes an order and immediately hands it off to the correct food truck.
A customer walks up and says 'I want a cheeseburger.' The central station doesn't cook anything — it just looks at a list of all trucks, finds the truck that makes cheeseburgers, and sends the order directly to that truck. If three trucks all make cheeseburgers, the station uses a simple rule: send the new order to the truck that has the shortest queue. This keeps lines short and service fast.
Now imagine the festival expands across a whole city block. There are multiple ordering stations, each serving a different section. A customer approaches the northern station, but the cheeseburger truck is in the southern section. The northern station can forward the order to the southern station, which then sends it to the truck. Or the northern station can simply tell the customer 'please go to the southern station.' The festival organisers choose the method that matches their goal — either minimising customer walking or maximising truck efficiency.
This is exactly how cloud load balancers work. The food trucks are the backend servers. The ordering station is the load balancer. The rules for choosing which truck gets the order are load balancing algorithms. The decision about whether to forward or redirect is the difference between proxy load balancing (the load balancer handles the traffic on behalf of the server) and pass-through load balancing (the load balancer directs the client to connect directly).
A load balancer is a device or software that distributes incoming network traffic across multiple backend servers. Backend servers are the actual computers that run your application, store data, or process requests. Without a load balancer, all traffic hits one server. That single server can become overwhelmed, slow down, or crash entirely. The load balancer prevents this by spreading the load.
Load balancers operate at different layers of the OSI model — a conceptual framework that describes how network communication works across seven layers (Physical, Data Link, Network, Transport, Session, Presentation, Application). For PCNE, you need to know two layers: Layer 4 (Transport) and Layer 7 (Application).
A Layer 4 load balancer makes routing decisions based on information in the network and transport headers — specifically, the source and destination IP addresses and TCP or UDP port numbers. It does not look at the actual content of the traffic, such as the URL path or HTTP headers. This makes it extremely fast because the decision is simple. It is like a postal sorter that reads only the street address and postcode, not the content of the letter.
A Layer 7 load balancer, in contrast, examines the content of the traffic. It can read HTTP headers, URL paths, cookies, and even the body of the request. This allows much more sophisticated routing. For example, it can send all requests to '/images' to a server optimised for images, and all requests to '/api' to a compute-heavy server. The trade-off is that Layer 7 processing is slower because it requires more work per request.
Google Cloud offers several types of load balancers, each designed for specific use cases. - External load balancers handle traffic coming from the internet to your application. These are the ones your users interact with. - Internal load balancers handle traffic between your own services inside a Virtual Private Cloud (VPC) — a logically isolated network within Google Cloud. This traffic never leaves Google's network. - Global load balancers use a single anycast IP address that works across multiple regions. Anycast means that the same IP address is advertised from multiple locations, so traffic naturally flows to the closest region. This reduces latency for users worldwide. - Regional load balancers operate within a single region. They are simpler but cannot automatically route traffic to servers in another region if one region goes down.
Google Cloud's premium-tier load balancers use Google's global network backbone to route traffic. The backbone is Google's own private fibre-optic network connecting its data centres. Because it is private and highly optimised, traffic travels faster and more reliably than over the public internet. Standard-tier load balancers route over the public internet, which is cheaper but slower and less reliable.
Each load balancer type also supports different protocols. The most common ones are HTTP, HTTPS, TCP, and UDP. An external HTTPS load balancer can terminate TLS (the encryption protocol that secures web traffic), meaning it decrypts the incoming HTTPS traffic, makes routing decisions using the decrypted content, and then either re-encrypts it for the backend or sends it in plaintext if the backend is in a trusted network. This offloads the cryptographic work from your backend servers.
Google Cloud's load balancers are fully managed, which means Google handles the underlying hardware, software, scaling, and maintenance. You simply configure your rules and let the service run. When traffic spikes, the load balancer scales automatically — no manual intervention needed.
The key to passing PCNE is understanding when each type is appropriate. For a global public-facing web application, you would use an external HTTPS load balancer with premium tier routing. For a microservices architecture within a single region, you might use an internal TCP/UDP load balancer. The exam will test your ability to match the load balancer characteristics to the described scenario.
Define the traffic type
Determine whether the traffic is external (from the internet) or internal (within a VPC). This choice directly determines whether an external or internal load balancer is needed. For PCNE, you must correctly classify the traffic flow in the scenario.
Choose the OSI layer
Decide whether you need Layer 4 (fast, no content inspection) or Layer 7 (content-aware routing). If the scenario requires routing based on URL path, host header, or HTTP method, Layer 7 is required. If only port or IP-level distribution is needed, Layer 4 is sufficient.
Select global or regional scope
If users are distributed worldwide and you want low latency for all of them, choose a global load balancer with an anycast IP. If all users and backends are in a single region, a regional load balancer is simpler and cheaper. The exam tests this trade-off.
Configure health checks
Define the health check protocol, interval, timeout, and healthy/unhealthy thresholds. This is mandatory. The load balancer will not send traffic to an unhealthy backend. Health checks can be TCP, HTTP, or HTTPS probes. Misconfiguration here can cause a cascade of failures.
Set up session affinity (if needed)
Enable session affinity when the application stores state on a specific backend (e.g., shopping cart, session data). Configure the cookie that the load balancer will set and check. Without session affinity, a user might be routed to a different server and lose their session.
A real IT professional, say a cloud network engineer at a retail company, uses load balancers every day. Imagine the retail company runs an online store that sells furniture. The store has three main parts: a public website for browsing products, an API server that processes payments, and a backend database that stores all order information.
The engineer needs to design the network so that millions of shoppers can browse without slowdown, payments are processed securely, and internal services can talk to each other. Here is how they do it step by step.
First, they create an external HTTPS load balancer with a global anycast IP address. This single IP address is used for the public website. The load balancer sits at the edge of Google's network. When a customer in London visits the site, traffic enters Google's network at the nearest point of presence (PoP) — a facility where Google connects to internet service providers. The load balancer routes the traffic to the closest backend server, perhaps in the London region (europe-west2). This minimises latency. The load balancer also terminates HTTPS, so the customer's credit card details are encrypted in transit until the load balancer decrypts them. The load balancer then forwards the request to the backend server over an internal, encrypted connection.
Second, the engineer sets up health checks. A health check is a periodic request the load balancer sends to each backend server to confirm it is alive and responding correctly. If a server returns an error or does not respond, the load balancer removes it from rotation — it stops sending new traffic to that server. When the server recovers, the health check passes again, and the server is added back. This is critical for handling failures gracefully.
Third, the engineer configures session affinity. Session affinity (also called sticky sessions) ensures that once a customer starts interacting with a particular backend server, all subsequent requests from that customer go to the same server. This is important for the shopping cart: if the cart data is stored locally on a server, sending the customer to a different server would lose the cart contents. The load balancer can achieve session affinity using cookies it sets in the customer's browser, which identify the chosen backend server.
Fourth, the engineer sets up the internal load balancer for the communication between the API server and the database server. This traffic never leaves Google's network, so an internal TCP/UDP load balancer is appropriate. The internal load balancer distributes queries across multiple database replicas, ensuring no single database becomes a bottleneck.
Finally, the engineer monitors everything using Cloud Monitoring. They set alerts for unusual traffic patterns — for example, a sudden spike that might indicate a denial-of-service attack. If the load balancer's CPU utilisation on the backends exceeds 80%, they can configure autoscaling, which automatically launches new virtual machines (VMs) to handle the load. The whole system is designed to be resilient, scalable, and secure.
In summary, the IT professional's daily work involves choosing the correct load balancer for each traffic flow, configuring health checks and session affinity, monitoring performance, and adjusting architecture as the application grows.
The PCNE exam tests 'Cloud Load Balancing Overview and Types' primarily through scenario-based multiple-choice questions. You are given a description of a company's requirements — traffic patterns, performance needs, security constraints, geographic distribution — and you must select the correct load balancer type. There are also questions about specific features, such as session affinity, health checks, and TLS termination.
Key concepts the exam loves to test. - The difference between global and regional load balancers. Global load balancers use a single anycast IP and can route to any region. Regional load balancers are confined to one region. The exam will present a scenario with users spread across the world and ask which load balancer minimises latency. The correct answer is a global load balancer. - The difference between Layer 4 and Layer 7 load balancers. If the scenario requires content-based routing (e.g., routing based on URL path or HTTP header), the answer must be a Layer 7 load balancer. If the requirement is simply fast packet forwarding with no content inspection, a Layer 4 load balancer is correct. - The difference between external and internal load balancers. External load balancers face the internet. Internal load balancers handle traffic within a VPC. A common trap is a question that describes inter-service communication inside a VPC and offers an external load balancer as a distractor. The correct answer is an internal load balancer. - Premium tier versus Standard tier. Premium tier routes over Google's network backbone and is faster and more reliable. Standard tier routes over the public internet and is cheaper. The exam will ask which tier to use for latency-sensitive applications. The answer is Premium tier. - Health check mechanics. The exam may ask what happens when a backend fails a health check. The correct answer is that the load balancer marks the backend as unhealthy and stops sending new traffic to it until the health check passes again. - Session affinity methods. Google Cloud supports cookie-based session affinity. The exam may ask how to maintain a user's session across requests. The correct answer is to enable session affinity, which uses a cookie to associate the client with a specific backend.
Common traps the exam sets. - Confusing load balancer types with proxy versus pass-through. Google Cloud's external HTTPS load balancer is a proxy (Layer 7) — it terminates the connection and creates a new one to the backend. The internal TCP/UDP load balancer is pass-through (Layer 4) — it preserves the original client IP. The exam often tests this distinction. - Assuming that all load balancers support the same protocols. Each load balancer type supports a specific set of protocols. For example, the external HTTPS load balancer only supports HTTP and HTTPS. The external TCP/UDP load balancer supports TCP and UDP. - Thinking that global load balancers can only be external. There is also a global internal load balancer for inter-region traffic within a VPC. - Forgetting that health checks are mandatory for backend services. The exam may describe a scenario where a backend fails and ask what the load balancer does. The correct answer relies on health checks.
Memorise this list of definitions. - Anycast: a networking technique where the same IP address is advertised from multiple locations, and traffic is sent to the nearest one. - Backend: the server or group of servers that process the requests forwarded by the load balancer. - Frontend: the IP address and port on which the load balancer listens for incoming traffic. - Health check: a periodic probe sent to a backend to verify it is working. - Session affinity: ensuring a client's requests all go to the same backend server. - TLS termination: the process of decrypting HTTPS traffic at the load balancer. - Autoscaling: automatically adding or removing backend servers based on load.
A load balancer distributes incoming traffic across multiple backend servers to prevent any single server from becoming overwhelmed.
Layer 4 load balancers route based on IP addresses and ports; Layer 7 load balancers route based on content like URL paths and HTTP headers.
Global load balancers use a single anycast IP to serve traffic from the region closest to each user, reducing latency.
External load balancers handle internet traffic; internal load balancers handle traffic within a Virtual Private Cloud (VPC).
Health checks automatically remove unhealthy backends from rotation and add them back when they recover.
TLS termination at the load balancer offloads encryption processing from backend servers, improving their performance.
Session affinity (sticky sessions) ensures a user's requests all go to the same backend server to preserve session state.
Premium tier routing uses Google's global network backbone for lower latency and higher reliability than Standard tier which uses the public internet.
These come up on the exam all the time. Here's how to tell them apart.
Global Load Balancer
Routes traffic from a single anycast IP to backends in multiple regions worldwide.
Provides lower latency for geographically distributed users by directing them to the nearest region.
Supports premium tier routing over Google's global network backbone.
Regional Load Balancer
Routes traffic only within a single region.
Simpler to configure and lower cost for single-region applications.
Does not automatically redirect traffic to other regions if the region fails.
External Load Balancer
Handles traffic originating from the internet (outside the VPC).
Supports public IP addresses and can be global or regional.
Typically terminates TLS and provides content-based routing.
Internal Load Balancer
Handles traffic between services within a VPC (no internet exposure).
Uses private IP addresses only, never exposed to the internet.
Often used for database, caching, and microservice communication.
Layer 4 (Transport) Load Balancer
Makes routing decisions based on IP addresses and TCP/UDP port numbers only.
Does not inspect the content of the packet (no HTTP header reading).
Extremely fast and low latency, suitable for non- HTTP traffic.
Layer 7 (Application) Load Balancer
Reads HTTP headers, URL paths, cookies, and request bodies to make routing decisions.
Can perform content-based routing (e.g., /images to one server, /api to another).
Slower than Layer 4 because it processes application-level data.
Proxy Load Balancer
Terminates the client connection and creates a new connection to the backend.
The backend sees the load balancer's IP address, not the client's original IP.
Can inspect and modify traffic content, and offload SSL/TLS processing.
Pass-Through Load Balancer
Forwards packets directly to the backend without terminating the connection.
The backend sees the client's original IP address unchanged.
Cannot inspect or modify traffic content; used for simple high-speed packet distribution.
Mistake
All load balancers preserve the client's original IP address when forwarding traffic to the backend.
Correct
Only pass-through load balancers (like internal TCP/UDP) preserve the original source IP. Proxy load balancers (like external HTTPS) terminate the connection and create a new one, so the backend sees the load balancer's IP instead.
Beginners assume networking works like a simple wire carrying packets unchanged. They do not understand that proxy services rewrite the packet headers.
Mistake
A global load balancer means all traffic goes to a single central data centre.
Correct
A global load balancer distributes traffic among multiple regions around the world. The 'global' part is the single anycast IP which directs traffic to the nearest region, not a single physical location.
The word 'global' sounds like 'one gigantic thing' rather than 'a distributed network of smaller things'. People naturally imagine a single huge server in the sky.
Mistake
You need a load balancer only for external-facing websites.
Correct
Internal load balancers are equally important for distributing traffic between microservices, databases, and other backend components within a VPC. Many applications have more internal traffic than external traffic.
Most introductory tutorials focus on public websites, so beginners never consider internal traffic. The concept of internal load balancing is invisible to end users.
Mistake
HTTPS load balancers encrypt all traffic, including traffic between the load balancer and the backend.
Correct
An HTTPS load balancer terminates the HTTPS connection — it decrypts the traffic. It can then forward to the backend either over an encrypted connection (re-encrypting) or over an unencrypted connection, depending on configuration. Traffic from load balancer to backend is not automatically encrypted.
People assume encryption is end-to-end and that the load balancer is transparent to encryption. They do not realise the load balancer holds the decryption keys.
Mistake
Adding a load balancer always makes a system slower because it is an extra hop.
Correct
A load balancer can actually improve performance by distributing load, reducing queuing delays, and routing traffic to the closest backend geographically. The small overhead of the load balancer is far outweighed by the performance gains from balanced load and reduced contention.
Beginners think of networking in terms of 'fewer hops = faster'. They do not account for the benefits of parallelism and reduced competition for shared resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A load balancer distributes traffic across multiple servers, while a reverse proxy sits in front of one or more servers and can perform caching, SSL termination, and content filtering. In Google Cloud, the external HTTPS load balancer acts as both — it is a reverse proxy that also distributes load.
Google Cloud's load balancers themselves scale automatically — you do not need to provision capacity for the load balancer. However, you must configure autoscaling on the backend instances to add or remove VMs as traffic changes.
Yes, for distributing read-only queries across database replicas, you can use a TCP/UDP load balancer. For read-write databases that require consistency, you typically use a different tool (like Cloud SQL's built-in replication) because load balancers do not guarantee transactional consistency.
If all backends are unhealthy, the load balancer will return an HTTP 502 Bad Gateway error to clients. It will continue to retry health checks, and will route traffic again as soon as at least one backend becomes healthy.
Yes, Google Cloud offers a global internal load balancer that can distribute traffic across backends in multiple regions within your VPC. This is different from the regional internal load balancer, which is restricted to one region.
Yes, this is common. For example, an external HTTPS load balancer handles user-facing web traffic, while an internal TCP load balancer distributes inter-service calls between your microservices. They work independently on different traffic flows.
You've finished Cloud Load Balancing Overview and Types. Continue through the PCNE study guide to build a complete picture of the exam.
Done with this chapter?