Prepare and test your skills
Prepare and test your skills
Protocol and layer-specific routing is the choice between Layer 7 load balancing for HTTP(S) content and Layer 4 load balancing for TCP, UDP, and other IP protocols. In Google Cloud, Application Load Balancers (opens in a new tab) provide proxy-based Layer 7 routing with inspection of HTTP requests, while Network Load Balancers (opens in a new tab) provide Layer 4 routing based on connection and packet information without inspecting HTTP content. The protocol that clients use determines which type can handle the traffic and which routing features are available.
Application Load Balancers are proxy-based Layer 7 load balancers that distribute HTTP and HTTPS traffic to backends. A client connection terminates at the load balancing layer, which then opens a new connection from the load balancer to the selected backend hosted on Compute Engine, Google Kubernetes Engine (GKE), on-premises, in other clouds, or at external backends outside Google Cloud. Because the load balancer understands HTTP(S), it can apply URL maps and advanced traffic rules to select a backend service based on host name, request path, headers, and other request parameters.
Application Load Balancers support HTTPS termination, IPv6 termination, and content-based routing such as sending video requests to one set of instance groups and all other requests to another set. Client IPv6 requests are terminated at the load balancing layer and then proxied to backends over IPv4 or IPv6 when backends are configured as dual-stack. These load balancers are available as external load balancers that accept internet traffic and as internal load balancers that use an internal IP address accessible only to clients in the same VPC network or connected networks.
Network Load Balancers are Layer 4 load balancers that handle TCP, UDP, or other IP protocol traffic without parsing HTTP. A Network Load Balancer is implemented either as a proxy load balancer or as a passthrough load balancer, and the choice controls where connections terminate and whether original packet information is preserved. Both forms support external deployment for internet clients and internal deployment behind an internal IP address for VPC clients.
Proxy and passthrough Network Load Balancers differ in protocol breadth and connection handling. Proxy Network Load Balancers are reverse proxies that distribute TCP traffic with optional SSL offload, while passthrough Network Load Balancers distribute TCP or UDP traffic and also support other IP protocols such as ESP, GRE, ICMP, and ICMPv6. Choose a proxy Network Load Balancer when TCP proxying with traffic controls and off-premises backends is needed, and choose a passthrough Network Load Balancer when client source addresses must be preserved or non-TCP protocols must pass through.
Proxy handling means the load balancer terminates the client connection and starts a separate backend connection. All Application Load Balancers and proxy Network Load Balancers work this way by using Google Front Ends (GFEs) (opens in a new tab) or Envoy proxies to terminate incoming connections and then forward traffic to the closest available backend. Traffic therefore flows from the client to the load balancer, then from the load balancer to the backend over a new connection, which enables SSL offload, request routing, and advanced traffic management.
Passthrough handling means the load balancer does not terminate the connection or act as a proxy. Load-balanced packets are received by backend VMs with the source and destination IP addresses, protocol, and source and destination ports unchanged, connections are terminated at the backend VMs, and responses flow directly from the backend VMs to the clients without returning through the load balancer. This direct path is called direct server return (DSR). Use passthrough handling when the backend must see the original client packet, when proxy overhead should be avoided, or when responses should return directly to preserve performance and address transparency.
Choosing by protocol and routing requirements means matching traffic type first, then routing and termination behavior. Application Load Balancers fit flexible HTTP(S) features, proxy Network Load Balancers fit TCP proxying with SSL offload, and passthrough Network Load Balancers fit address preservation and UDP plus additional IP protocols. Geographic control over TLS termination is an additional criterion: a regional load balancer (opens in a new tab) is deployed in a chosen region, connects only to backends in that same region, and guarantees that TLS terminates only in that region.
The following comparison summarizes the main options by traffic type and connection handling:
| Load balancer type | Traffic type | Connection handling |
|---|---|---|
| Application Load Balancers | HTTP or HTTPS | Proxy terminates client connections; routes by host, path, headers, and request parameters |
| Proxy Network Load Balancers | TCP with optional SSL offload | Proxy terminates client connections at the load balancer, then forwards to backends over TCP |
| Passthrough Network Load Balancers | TCP or UDP, plus ESP, GRE, ICMP, and ICMPv6 | No proxy termination; backends terminate connections and return responses directly to clients |
A global load balancer terminates TLS in globally distributed locations to minimize latency between clients and the load balancer, which matters when compliance requires traffic to stay in a specific region and a regional deployment must be used instead.
Exam tip: Choose an Application Load Balancer for HTTP(S) URL-based routing and SSL termination, and choose a passthrough Network Load Balancer when you must preserve client source IP addresses or handle UDP, ESP, GRE, ICMP, or ICMPv6.
Geographic scope and accessibility selection is the decision of where a load balancer distributes traffic from and where its backends live. In Google Cloud, scope is global versus regional or cross-region, while accessibility is external versus internal. Together they determine whether clients connect over the internet or inside a Virtual Private Cloud (VPC) network and whether backends can span one region or many.
Global and regional scope defines how widely a load balancer is distributed and where its backends can be located. A global load balancer (opens in a new tab) supports backends in multiple regions and is itself distributed across all regions, while a cross-region load balancer (opens in a new tab) is the internal equivalent that spans multiple regions. A regional load balancer supports backends in a single region only and is distributed across multiple zones within that region, which makes it resilient to zonal outages but not to an outage of its own region.
Even though the IP address of a regional load balancer is located in one region, a regional load balancer is globally accessible. Clients from other regions can still reach it, but traffic is terminated in the region where the load balancer and its backends are deployed. Global load balancers terminate Transport Layer Security (TLS) in locations distributed globally to minimize latency between clients and the load balancer, while regional load balancers guarantee that TLS is terminated only in the chosen region. Global load balancers provide access through a single anycast IP address and provide IPv6 termination, while cross-region load balancers provide access through a regional internal IP address from the regional subnet in the VPC network.
Choose a global or cross-region load balancer when the application or content is distributed across multiple regions or when flexibility to add multi-region backends as the application grows is needed. Choose a regional load balancer when the following conditions apply:
External and internal accessibility defines who can send traffic to the load balancer. External load balancers (opens in a new tab) distribute traffic that comes from the internet to a Google Cloud VPC network. Internal load balancers distribute traffic that comes from clients in the same VPC network (opens in a new tab) as the load balancer or from clients connected to that VPC network by using VPC Network Peering, Cloud VPN, or Cloud Interconnect.
An internal load balancer uses an internal IP address that is accessible only to systems in the same VPC network or systems connected to that VPC network. Only external load balancers are available as global load balancers. For internal load balancers with backends in multiple regions, the cross-region load balancer is used, and clients from any Google Cloud region can send traffic to it. Load balancing should also be configured for traffic between tiers of the application stack, not just between external clients and the application.
Traffic flows through a conventional three-tier web service in order:
Matching scope and accessibility means pairing the client location with the backend geography and compliance needs. A globally distributed application with backends in North America, Europe, and Asia uses a global external load balancer so requests are sent to the closest healthy backend with capacity. A workload with regulatory requirements that network configuration and traffic termination reside in a specific region uses a regional external Application Load Balancer for jurisdictional control.
The following comparison summarizes scope by backend placement and frontend access:
| Load balancer scope | Backend scope | Frontend access |
|---|---|---|
| Global | Backends in multiple regions, distributed across all regions | Single anycast IP address, reachable from the internet with IPv6 termination |
| Cross-region internal | Backends in multiple regions, distributed across multiple regions | Regional internal IP address from the VPC subnet, reachable from any Google Cloud region |
| Regional | Backends in a single region only, distributed across multiple zones in the region | Regional IP address in the deployment region, globally reachable but terminates traffic in that region |
Exam tip: Only external load balancers use the global scope name; an internal load balancer that spans regions is called cross-region, not global.
Advanced traffic management and security integration is the combination of load-balancer traffic controls with protective services that filter and stabilize requests before they reach backends. In Google Cloud, the global external Application Load Balancer (opens in a new tab) distributes HTTP and HTTPS traffic across backends in multiple regions, while Google Cloud Armor screens requests and Cloud CDN accelerates delivery from edge locations. Together they improve availability, performance, and resistance to overload and attack without changing application code.
Load-balancing health checks are probes that determine whether each backend can actually serve traffic and direct new requests only to responsive backends. Autoscaling ensures enough infrastructure exists for the current load, but it cannot detect a crashed application on a VM that still shows as RUNNING. Health checks solve that gap by removing unresponsive VMs or endpoints from rotation until they recover.
When backends are Managed Instance Groups (MIGs), a second layer of health checking can enable autohealing for stronger reliability. Autohealing uses its own health check to detect unavailable VMs, proactively deletes those VMs, and creates replacement VMs in their place. Use load-balancer health checks to protect traffic routing, and add MIG autohealing when failed instances should be replaced automatically rather than left running.
Rate limiting is a control that caps how much load an application or resource must accept during rapid or sustained traffic spikes. Spikes can come from malicious distributed denial-of-service (DDoS) attacks or from non-malicious causes such as configuration errors in client software. Without limits, the application or the resources it depends on can fail and become unavailable.
Google Cloud supports rate limiting through quotas, such as quotas on the number of API requests a service can receive. Project-level quotas for specific resources can also cap usage and therefore limit the billing a project can incur. Choose rate limiting when availability and cost must be protected against both attack traffic and unexpected client behavior.
The programmable global front end is an internet-facing entry point built from the global external Application Load Balancer, Cloud CDN, and Google Cloud Armor (opens in a new tab) security policies. The load balancer is a proxy-based Layer 7 load balancer that can send traffic to Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, App Engine, on-premises, and other-cloud backends. Cloud Armor provides Layer 7 filtering that scrubs incoming requests for common web attacks and other Layer 7 attributes, while protection against volumetric DDoS attacks is enabled by default.
A user request moves through this front end in a fixed order:
This order matters because edge filtering and caching absorb unwanted or repeatable traffic early. The architecture also supports traffic splitting for version management, such as sending 60% of users to one backend and 40% to another, plus configurable timeouts, retries, and balancing modes.
Exam tip: Cloud Armor edge policies run before the Cloud CDN cache check, while backend policies run only after a cache miss — cacheable allowed traffic never reaches the backend evaluation.
Network Service Tiers control how traffic travels between internet users and Google Cloud workloads. Premium Tier brings inbound traffic onto Google's high-performance network at the point of presence closest to the sender, routes it internally to the correct Compute Engine VM or other resource, and sends outbound traffic back out through the PoP closest to the destination. This reduces public-internet hops and improves perceived availability for global applications with backends in more than one region. Choose Premium Tier when global performance matters more than minimizing network cost, since Premium Tier is more expensive than Standard Tier.
Cloud Load Balancing adds advanced traffic management (opens in a new tab) controls for shaping how connections are handled. The supported controls include peer capabilities that can be combined on the same deployment:
Cloud CDN integration for cached content delivery is supported with the global external Application Load Balancer and the classic Application Load Balancer. Google Cloud Armor integration protects infrastructure from DDoS and targeted application attacks, with specific features varying by load balancer.
Load-balancer scope defines where backends can live and how failures are contained. A global load balancer supports backends in multiple regions, while a regional load balancer (opens in a new tab) supports backends in a single region but remains globally accessible and is resilient to zone outages. Even with a regional IP address, clients from other locations can still reach a regional load balancer.
The following comparison summarizes when each scope fits:
| Scope | Backend placement | Choose when |
|---|---|---|
| Global load balancer | Backends in multiple regions | External traffic must fail over across regions or terminate close to global users |
| Regional load balancer | Backends in a single region | Global features are not needed and zone-outage resilience within one region is sufficient |
Load balancing should also be applied between tiers inside the application, not only at the internet edge. In a 3-tier web stack, an internal load balancer provides reliable communication between the web tier and the application tier. When selecting a type, weigh availability together with geographic control over TLS termination, performance, cost, and traffic type, including whether HTTP(S) needs an Application Load Balancer or TCP, UDP, and other IP protocols need a Network Load Balancer.
Application Load Balancers are proxy-based Layer 7 load balancers that distribute HTTP and HTTPS traffic and route by host name, request path, headers, and other request parameters, while Network Load Balancers are Layer 4 load balancers that handle TCP, UDP, or other IP protocol traffic without parsing HTTP. Choose an Application Load Balancer for flexible HTTP(S) features such as URL maps and HTTPS termination, choose a proxy Network Load Balancer for TCP proxying with optional SSL offload, and choose a passthrough Network Load Balancer when client source addresses must be preserved or UDP plus ESP, GRE, ICMP, and ICMPv6 must pass through.
Proxy handling means the load balancer terminates the client connection and starts a separate backend connection, which enables SSL offload, request routing, and advanced traffic management. Passthrough handling means the load balancer does not terminate the connection, backend virtual machines receive packets with source and destination IP addresses and ports unchanged and terminate connections themselves, and responses return directly to clients through direct server return (DSR).
A global load balancer supports backends in multiple regions through a single anycast IP address, a cross-region internal load balancer is the internal equivalent that spans multiple regions and uses a regional internal IP address reachable from any Google Cloud region, and a regional load balancer supports backends in a single region only and is distributed across multiple zones within that region. Choose global or cross-region when backends are distributed across multiple regions or flexibility to add multi-region backends is needed, and choose regional when backends are needed in one region only, only IPv4 termination is required, or jurisdictional or compliance requirements mandate that traffic and Transport Layer Security (TLS) termination stay in a given region.
Last updated