Choosing the right load balancer in Google Cloud starts with understanding what type of traffic your application handles. Application Load Balancers operate at Layer 7 and process HTTP or HTTPS traffic, offering features like URL-based routing and SSL offloading. Network Load Balancers operate at Layer 4 and handle TCP, UDP, or other IP protocols such as ESP, GRE, ICMP, and ICMPv6.
The next decision involves whether you need an external load balancer that accepts traffic from the internet or an internal load balancer that distributes traffic only within your Virtual Private Cloud (VPC) network. External load balancers receive traffic from the internet or from Google Cloud VMs with external IP addresses, while internal load balancers accept traffic only from clients in the same VPC or from networks connected via VPC Network Peering, Cloud VPN, or Cloud Interconnect.
You must also choose between global and regional scope. Global load balancers distribute traffic across multiple regions using a single anycast IP address, making them suitable for applications with users worldwide. Regional load balancers operate within a single region and are required when compliance mandates that traffic stay within a specific geographic area, when you need IPv4-only termination, or when you require precise control over where TLS termination occurs.
Finally, decide between proxy and passthrough behavior. Proxy load balancers terminate incoming client connections at the load balancer and open new connections to backends, which changes the source IP address seen by backends. Passthrough load balancers preserve the original client packet information including source IP, destination, and port, allowing backends to terminate connections directly.
External load balancers distribute traffic that originates from the internet to your Google Cloud VPC network. These load balancers use external IP addresses that are reachable from anywhere on the internet, and they form the entry point for user traffic destined for your applications.
Internal load balancers distribute traffic from clients that already exist within your VPC network or from networks connected to your VPC. These load balancers use internal IP addresses that are accessible only to systems in the same VPC or to connected networks. Internal load balancers are commonly used for three-tier web architectures where an external Application Load Balancer fronts web servers, which then communicate with internal Application Load Balancers or internal passthrough Network Load Balancers that distribute traffic to application and database tiers.
Global load balancers distribute traffic across multiple regions and direct users to the closest healthy backend. When you configure a global external Application Load Balancer in Premium Tier, it uses a global external IP address and can route requests to backend instance groups in different regions based on proximity. If the closest VMs are unhealthy or at capacity, the load balancer automatically sends requests to the next closest region with available capacity.
Regional load balancers operate within a single region and can only distribute traffic to backends in that same region. Choose a regional load balancer when your compliance requirements mandate that all traffic remain within a specific region, when you only need IPv4 termination without IPv6 support, or when you want to control exactly where TLS termination occurs. Regional load balancers guarantee that TLS is terminated only in the region where you deploy the load balancer and its backends, whereas global load balancers terminate TLS in distributed locations globally to minimize latency.
Proxy load balancers terminate incoming client connections at the load balancing layer using Google Front Ends (GFEs) or Envoy proxies, then establish new connections to the backends. All Application Load Balancers and proxy Network Load Balancers work this way. The proxy terminates the client-facing connection and creates a separate backend connection, meaning the backend sees traffic originating from the load balancer's IP addresses rather than the original client IP.
Passthrough load balancers do not terminate client connections. Instead, load-balanced packets arrive at backend VMs with their source and destination IP addresses, protocol, and ports unchanged. The backend VMs terminate the connections directly, and response traffic goes directly back to clients without passing through the load balancer. This behavior is known as direct server return (DSR). Choose passthrough load balancers when you need to preserve client source IP addresses, when you require support for protocols like UDP, ESP, GRE, ICMP, or ICMPv6, or when you have authentication systems that rely on tracking the original client IP address.
Traffic steering lets you direct traffic to specific backend services based on HTTP parameters such as request headers, query parameters, or cookies. For example, you can route requests with a user-agent:Mobile header to backend services optimized for mobile devices, while routing desktop browser traffic to different backends. Traffic steering uses URL maps to evaluate host rules and path matchers, then routes requests to the appropriate backend service based on your configured rules.
Traffic splitting enables you to distribute a percentage of traffic across multiple backend services, which is essential for deploying new versions of services gradually. You can send 95% of traffic to the current production version and 5% to a new version, then gradually shift the percentages as you validate the new version works correctly. This approach, sometimes called canary deployment, reduces the risk of widespread issues when releasing changes.
Request mirroring copies incoming traffic to an additional service for purposes such as compliance logging or testing. When enabled, each request is sent to both the primary backend and the mirror backend, but the client receives only the response from the primary backend.
A backend service defines how load balancers distribute traffic to your backends and includes settings for health checks, session affinity, connection tracking, and failover behavior. Backend services support both instance groups and network endpoint groups (NEGs) as backends, with NEGs enabling you to load balance traffic to individual containers or services.
Health checks verify that backends are healthy and capable of handling traffic. The load balancer only sends traffic to backends that pass health checks. You should configure health checks to match the type of traffic being load balanced—for HTTP backends, use HTTP health checks; for HTTPS backends, use HTTPS health checks; and for TCP traffic, use TCP or SSL health checks.
Session affinity controls whether the load balancer attempts to send requests from the same client to the same backend. Options include client IP affinity, generated cookie affinity, and HTTP cookie-based affinity. Note that weighted traffic splitting takes precedence over session affinity configuration.
Failover configuration lets you designate backup backends that receive traffic when all primary backends become unhealthy. You can configure failover policies at the backend service level to ensure high availability.
Google Cloud offers two network service tiers that affect how traffic is routed to your load balancers. Premium Tier routes traffic through Google's high-quality global backbone network, entering and exiting Google's network at points of presence closest to the user. Standard Tier offloads traffic to the public internet as close as possible to the destination region, which is less expensive but may result in higher latency.
Global external Application Load Balancers and global external proxy Network Load Balancers support only Premium Tier. Classic load balancers can operate in either Premium or Standard Tier, with Premium Tier providing global distribution and Standard Tier limiting distribution to a single region. Regional external Application Load Balancers and regional external proxy Network Load Balancers support both tiers. External passthrough Network Load Balancers support both tiers for IPv4 addresses, but IPv6 addresses are only available in Premium Tier.
Cloud CDN integrates with global external Application Load Balancers and classic Application Load Balancers to cache content at Google's edge locations, reducing latency and origin load. When a request arrives, Cloud CDN serves cached content directly from the edge when possible, only forwarding to origin backends on cache misses.
Google Cloud Armor provides DDoS protection and web application firewall capabilities. Always-on DDoS protection is available for global external Application Load Balancers, classic Application Load Balancers, external proxy Network Load Balancers, and external passthrough Network Load Balancers. Cloud Armor can also filter traffic based on Layer 7 attributes, blocking malicious requests before they reach your backends.
Service Extensions integration allows you to insert custom logic into the load balancing data path for supported Application Load Balancers, enabling scenarios like custom authentication, additional security scanning, or traffic analysis.
External load balancers distribute incoming traffic from the public internet to backends inside a Google Cloud VPC network. These load balancers accept requests from internet clients, Google Cloud virtual machines (VMs) with external IP addresses, or VMs routing outbound through Cloud NAT. External load balancers use external forwarding rules configured with either the EXTERNAL or EXTERNAL_MANAGED load-balancing scheme. They allow organizations to expose web frontends, public APIs, and internet-facing services to globally dispersed users.
Internal load balancers distribute traffic exclusively from private client sources located inside a VPC network or connected private environments. Clients can reach internal load balancers from the same VPC network, peered VPC networks through VPC Network Peering, or on-premises networks connected via Cloud VPN or Cloud Interconnect. These load balancers use internal forwarding rules configured with either the INTERNAL or INTERNAL_MANAGED load-balancing scheme and draw private IP addresses directly from VPC subnets. Using internal load balancers keeps intermediate application tiers, databases, and microservices isolated from the public internet.
Global load balancers deploy their frontend infrastructure across distributed Google points of presence (PoPs) to serve clients worldwide through a single anycast IP address. Client traffic enters Google's high-quality global backbone at the nearest edge PoP, which terminates Transport Layer Security (TLS) close to the user and reduces latency. Global load balancers can route requests across multi-region backends, directing traffic to the closest healthy instance group or network endpoint group (NEG) that has available capacity. If a localized regional backend fails or reaches capacity limits, global external load balancers automatically reroute requests to the next closest region with available capacity. Global external Application Load Balancers and proxy Network Load Balancers require the Premium Tier of Network Service Tiers.
Regional load balancers operate within a single Google Cloud region and distribute traffic only to backends located in that same region. Network traffic and TLS connections terminate strictly inside the selected region rather than at global edge PoPs. This regional containment is required for workloads subject to jurisdictional compliance or data sovereignty regulations that mandate traffic termination within specific geographic borders. Regional load balancers are resilient to zonal outages within their designated region, but an outage across the entire region impacts the regional load balancer and its backends. Regional external load balancers can utilize either Standard Tier or Premium Tier for regional external IPv4 addresses.
Multi-tier architecture structures an application into specialized web, application, and database layers that connect sequentially through dedicated external and internal load balancers. In a standard three-tier design, traffic from the internet enters an external Application Load Balancer at the public edge web tier. Backend web servers then forward incoming HTTP(S) requests to an internal Application Load Balancer that manages the middle application tier. The application tier processes business logic and routes database queries to an internal passthrough Network Load Balancer, which balances TCP or UDP traffic directly to database clusters.
Cross-region internal load balancing and global access extend private internal endpoints across regional boundaries without exposing workloads publicly. A cross-region internal Application Load Balancer or cross-region internal proxy Network Load Balancer uses a regional internal IP address from a VPC subnet, yet it can receive traffic globally from clients in any Google Cloud region and route to backends across multiple regions. Similarly, enabling global access on a regional internal passthrough Network Load Balancer or regional internal Application Load Balancer allows client VMs in distant regions to access the regional internal IP address. These access options enable organizations to design multi-region topologies while keeping internal service-to-service communication entirely on Google's private network.
Application Load Balancers are proxy-based Layer 7 load balancers designed for HTTP(S) traffic. They terminate the client's TCP or TLS connection at the load balancer's proxy, which then opens a new connection to a backend. This allows for advanced traffic management like URL-based routing, header transformations, and traffic splitting. Choose an Application Load Balancer when you need content-aware routing, SSL offloading at the load balancer, or integration with services like Cloud CDN and Google Cloud Armor. These load balancers are available as external (global or regional) for internet traffic and internal (cross-region or regional) for traffic within your VPC network.
Network Load Balancers are Layer 4 load balancers that handle TCP, UDP, and other IP protocol traffic. They come in two distinct sub-types: proxy-based and passthrough, which fundamentally change how traffic is handled.
Proxy Network Load Balancers are Layer 4 reverse proxies. Like Application Load Balancers, they terminate the client connection (TCP, with optional SSL) and then proxy a new connection to the backend. This provides features like SSL offloading and advanced traffic controls but does not preserve the original client source IP address by default. Choose a proxy Network Load Balancer for TCP traffic when you need load balancing to backends in multiple regions (global) or a single region (regional), or when you need SSL termination but not HTTP-level features.
Passthrough Network Load Balancers are not proxies. They forward traffic directly to backend VMs without terminating the connection, a method known as direct server return (DSR). The backend VMs receive the packets with the original source and destination IPs, ports, and protocols unchanged, and responses go directly back to the client. Choose a passthrough Network Load Balancer when you must preserve the client's source IP address, need to load balance protocols like UDP, ESP, or ICMP, or want to avoid the overhead of a proxy. They are always regional and are available as external (for internet traffic) or internal (for VPC traffic).
The decision flow starts with traffic type: use an Application Load Balancer for HTTP(S) and a Network Load Balancer for other protocols. Next, decide on the traffic flow: external load balancers accept traffic from the internet, while internal load balancers only accept traffic from within your VPC or connected networks. Then, consider scope: a global or cross-region load balancer distributes traffic to backends in multiple regions, while a regional load balancer is confined to backends in a single region. Finally, for Network Load Balancers, you must choose between proxy (for termination and advanced features) and passthrough (for client IP preservation and protocol support).
Choose an internal load balancer when your clients exist entirely within your VPC network or connected private environments such as peered VPCs, Cloud VPN, or Cloud Interconnect. Internal load balancers keep intermediate application tiers, databases, and microservices isolated from the public internet, which is essential for three-tier architectures where web servers communicate with application servers that then communicate with databases.
Proxy load balancers terminate the client connection at the load balancer and create a new connection to the backend, meaning the backend sees traffic from the load balancer's IP rather than the original client IP. Passthrough load balancers forward packets unchanged to backends, preserving the original source IP, destination, port, and protocol, and responses go directly back to clients without passing through the load balancer.
Use a regional load balancer when compliance requirements mandate that all traffic remain within a specific geographic region, when you only need IPv4 termination without IPv6 support, or when you require precise control over where TLS termination occurs. Regional load balancers are also required when your backends exist in only one region and you do not need cross-region traffic distribution.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts