The primary factors for choosing a Google Cloud load balancer are traffic type, load balancing scope, network boundary, and proxy mode. The traffic type determines whether you need an Application Load Balancer for HTTP(S) or a Network Load Balancer for TCP/UDP and other IP protocols. The scope defines if the load balancer and its backends are global (spanning multiple regions) or regional (confined to a single region). The network boundary specifies if the load balancer is external (accepting traffic from the internet) or internal (accepting traffic only from within your VPC network or connected networks). Finally, the proxy mode decides if the load balancer terminates connections (proxy) or passes packets unchanged (passthrough), which affects features like SSL offloading and client IP preservation.
Application Load Balancers are proxy-based Layer 7 load balancers designed for HTTP and HTTPS traffic. They terminate client connections at the load balancer, enabling advanced traffic management like URL-based routing, header transformations, and traffic splitting. These load balancers integrate with Cloud CDN for cached content delivery and Google Cloud Armor for DDoS and web application firewall protection. You choose an Application Load Balancer when you need intelligent routing based on HTTP parameters.
External Application Load Balancers handle traffic from the internet. The global external Application Load Balancer (Premium Tier only) uses a single anycast IP address, distributes traffic to backends in multiple regions, and terminates connections at Google's edge using Google Front Ends (GFEs) and Envoy proxies. The regional external Application Load Balancer (supports both Premium and Standard Tiers) uses a regional IP address, supports backends in a single region, and is built on Envoy proxies. The classic Application Load Balancer is global in Premium Tier but regional in Standard Tier and is built on GFEs.
Internal Application Load Balancers handle traffic within a VPC network. The cross-region internal Application Load Balancer supports backends in multiple regions and uses a global internal forwarding rule with a regional IP address. The regional internal Application Load Balancer supports backends in a single region and uses a regional internal forwarding rule. Both are built on the Andromeda virtualization stack and Envoy proxies. Internal load balancers are useful for multi-tier applications, such as routing traffic from a web tier to an application tier.
Network Load Balancers are Layer 4 load balancers that handle TCP, UDP, and other IP protocol traffic. They come in two flavors: proxy Network Load Balancers, which terminate connections, and passthrough Network Load Balancers, which pass packets directly to backends. You choose a Network Load Balancer when you need TLS offloading at scale, support for protocols like UDP or ESP, or to preserve client source IP addresses.
Proxy Network Load Balancers terminate incoming client connections and open new connections to the backends. The global external proxy Network Load Balancer (Premium Tier only) uses a global IP and supports multi-region backends. The regional external proxy Network Load Balancer (supports both tiers) uses a regional IP. The internal proxy Network Load Balancer can be regional or cross-region and uses internal IP addresses. Proxy load balancers are suitable for TCP load balancing with optional SSL offload but do not support path-based routing like Application Load Balancers.
Passthrough Network Load Balancers do not terminate connections; backend VMs receive packets with the original source and destination IPs and ports unchanged. This enables direct server return (DSR), where responses go directly from the backend to the client. The external passthrough Network Load Balancer is regional, supports TCP, UDP, ESP, GRE, ICMP, and ICMPv6, and can be in Premium or Standard Tier. It is built on Maglev and Andromeda. The internal passthrough Network Load Balancer is regional, Premium Tier only, and supports the same protocols plus SCTP, AH, and GRE. Passthrough load balancers are ideal when you must preserve client IPs or handle non-TCP/UDP protocols.
The scope of a load balancer—global or regional—determines its resilience and where traffic is terminated. A global load balancer uses a single anycast IP address, is distributed across all Google regions, and can route traffic to backends in multiple regions. It is resilient to zonal and regional outages because traffic can failover to healthy backends in another region. Global load balancers terminate TLS at Google's globally distributed edge points to minimize latency. A regional load balancer is deployed in a specific region, uses a regional IP address, and can only route to backends in that same region. It is resilient to zonal outages within its region but not to a full regional outage. Choose a regional load balancer for compliance requirements that mandate traffic stay within a specific geographic boundary.
The network boundary defines from where the load balancer accepts traffic. External load balancers accept traffic from the internet, including clients outside Google Cloud, VMs with external IPs, or VMs using Cloud NAT. Internal load balancers accept traffic only from clients within the same VPC network or from networks connected via VPC Peering, Cloud VPN, or Cloud Interconnect. Internal load balancers use internal IP addresses, keeping the traffic within your private network. The choice depends on whether your application service should be publicly accessible or private.
The proxy mode affects connection handling and feature support. Proxy load balancers (all Application Load Balancers and proxy Network Load Balancers) terminate the client connection at the load balancer (on a GFE or Envoy proxy) and establish a new connection to the backend. This allows for SSL/TLS termination, advanced traffic management, and hiding client IPs from backends (though they can be passed via headers). Passthrough load balancers (all passthrough Network Load Balancers) forward packets directly to backend VMs without modification. This preserves the original client IP address and port information for the backend and enables direct server return, reducing load balancer overhead. However, passthrough load balancers cannot perform SSL offloading or advanced HTTP-level features.
The Network Service Tier impacts performance, cost, and feature availability. The Premium Tier routes traffic over Google's high-quality global backbone as far as possible before exiting to the public internet, optimizing for performance and reliability. Global load balancers (global external Application Load Balancer, global external proxy Network Load Balancer) are only available in Premium Tier. The Standard Tier offloads traffic to the public internet closer to the source, which can reduce cost but may increase latency and variability. Some load balancers (regional external Application Load Balancer, regional external proxy Network Load Balancer, external passthrough Network Load Balancer) support both tiers, but their capabilities differ; for example, a classic Application Load Balancer is global in Premium Tier but effectively regional in Standard Tier.
Different load balancers support different advanced features. Global external and regional external Application Load Balancers support advanced traffic management like weight-based traffic splitting, request mirroring, and header transformations. External passthrough Network Load Balancers support source IP-based traffic steering and weighted load balancing based on HTTP health checks. Cloud Armor provides DDoS protection and WAF capabilities; always-on DDoS protection is available for global external Application Load Balancers, classic Application Load Balancers, and external proxy and passthrough Network Load Balancers, with advanced network DDoS protection exclusively for external passthrough Network Load Balancers. Cloud CDN integration is available for global external and classic Application Load Balancers. Load balancers also integrate with managed instance groups for autoscaling and with Google Kubernetes Engine (GKE) via the built-in Service controller.
Load balancer choice directly impacts end-user latency. Global external Application Load Balancers can reduce latency for geographically distributed users by terminating TCP/TLS at a nearby Google Front End (GFE) and using persistent connections from the GFE to backends. This means the initial three-way handshake latency is between the user and the GFE, not the distant backend. External passthrough Network Load Balancers and regional load balancers do not provide this proximity benefit; traffic flows directly to the regional backend, so latency is determined by the network distance between the user and that region. Therefore, for globally distributed users and backends, a global load balancer generally offers better perceived performance.
Traffic flow boundaries determine whether a deployment requires an external load balancer or an internal load balancer based on client origin. External load balancers evaluate and accept incoming traffic from clients located on the public internet by advertising public IP addresses. Internal load balancers restrict ingress traffic exclusively to private IP addresses reachable by clients located inside a Virtual Private Cloud (VPC) network or networks connected through Cloud VPN, Cloud Interconnect, or VPC Network Peering. The EXTERNAL and EXTERNAL_MANAGED load-balancing schemes designate public-facing entry points that terminate external client connections at the network edge. The INTERNAL_MANAGED load-balancing scheme designates private load balancers operating within VPC subnets to manage middle-tier application traffic or internal microservices. Choosing between internal and external access establishes the foundational perimeter for network firewalls, routing, and access control policies. External endpoints can be integrated with Google Cloud Armor to mitigate distributed denial-of-service (DDoS) attacks before traffic enters internal VPC resources. Internal endpoints isolate multi-tier services, such as database or web-to-application communication layers, ensuring private workloads remain unexposed to the public internet while supporting cross-region failover.
Scope selection defines whether traffic terminates across globally distributed edge locations or stays strictly contained within a single Google Cloud region. Global load balancers use a single anycast IP address across more than 80 global locations to route client traffic over Google's high-performance backbone network directly to the nearest healthy backend. Regional load balancers restrict proxy infrastructure, TLS termination, and backend destinations to a single defined region, satisfying strict compliance and data jurisdictional requirements. Network service tier selection directly influences global versus regional traffic behavior and overall performance. Premium Tier routes public traffic through the closest Google edge Point of Presence (PoP) onto Google's global backbone, enabling multi-region load balancing, anycast addressing, and fast cross-region failover. Standard Tier routes outbound traffic through transit providers and public internet routing until reaching the region hosting the target workload, constraining load balancing to regional scopes. Regional Envoy-based load balancers require a dedicated proxy-only subnet within the VPC network configured with the --purpose flag set to REGIONAL_MANAGED_PROXY. This proxy-only subnet provides an internal IP pool that Envoy proxies use to initiate new backend connections. If backend services must survive regional disasters, administrators deploy cross-region configurations where global backend services dynamically direct requests to alternate regions when primary backends become unavailable.
Protocol requirements determine whether traffic routing requires deep packet inspection at Layer 7 or stream forwarding at Layer 4. Application Load Balancers (ALBs) provide Layer 7 reverse proxy routing for HTTP, HTTPS, HTTP/2, and HTTP/3 (QUIC) traffic by parsing HTTP headers, hostnames, and uniform resource identifiers (URIs) through URL maps. Proxy Network Load Balancers (NLBs) terminate incoming client TCP or SSL connections at Layer 4, establishing a new TCP connection to forward raw payload streams to backend instances without inspecting application-level data. Application Load Balancers (HTTP/HTTPS) are chosen for web applications requiring URL path-based routing, header transformations, traffic splitting, mutual TLS (mTLS), or caching via Cloud CDN. Proxy Network Load Balancers (TCP/SSL) are chosen for non-HTTP applications, such as gaming engines, email protocols (IMAP over SSL), or custom TCP services that require TLS offloading and port remapping across any port from 1 to 65535. When terminating connections at the load balancer, the original client source IP address is replaced by the proxy's IP address. To relay client identity to backends, Proxy NLBs and regional Envoy proxies can append connection headers using the PROXY protocol. For Layer 7 ALBs, client source IP addresses and forwarding rule VIPs are automatically injected into the X-Forwarded-For HTTP request header before reaching backend services.
Backend service architecture dictates the type of compute resource and network endpoint group required to serve application traffic. Load balancers distribute requests across managed instance groups (MIGs) composed of Compute Engine virtual machines or specialized network endpoint groups (NEGs) tailored to modern application patterns. Backend capacity can be balanced using utilization metrics, connections, or requests per second (RPS), with connection draining enabled to prevent dropping in-flight transactions during scale-down events. Zonal NEGs contain GCE_VM_IP_PORT endpoints that enable container-native load balancing directly to Google Kubernetes Engine (GKE) pods without routing through node-level kube-proxy translation. Serverless NEGs point directly to serverless workloads including Cloud Run, Cloud Run functions, and App Engine, exposing them behind dedicated IP addresses with custom domain support. Hybrid NEGs use NON_GCP_PRIVATE_IP_PORT endpoints to route traffic over Cloud VPN or Cloud Interconnect directly to on-premises data centers or multi-cloud environments. Internet NEGs allow external ALBs to proxy public traffic through Google's global network edge directly to external fully qualified domain names (FQDNs) or public IP addresses hosted outside Google Cloud. Health checks monitor endpoint responsiveness by probing application endpoints at configured intervals, distinct from MIG autohealing checks. If a backend fails consecutive health checks exceeding the configured unhealthy threshold, the load balancer automatically redirects incoming requests to remaining healthy instances across configured zones or regions.
Choosing the appropriate load balancer requires evaluating the combination of client source location, application protocol, geographic resiliency requirements, and backend architecture. Global External Application Load Balancer is chosen when internet clients require low-latency access to globally distributed HTTP(S) backends, Cloud CDN caching, Cloud Armor protection, or serverless workloads across multiple regions. Regional External Application Load Balancer is chosen when internet-facing HTTP(S) applications require strict regional data residency, regional compliance boundaries, or standard network tier support. External Proxy Network Load Balancer is chosen when external clients communicate over non-HTTP TCP or SSL protocols and require a single anycast IP address, global TLS termination, or port remapping. Internal Application Load Balancer is chosen for internal microservices, private multi-tier web stacks, or GKE service-to-service communication requiring Layer 7 URL routing and mTLS across VPC networks. Internal Proxy Network Load Balancer is chosen for private non-HTTP TCP traffic flows that require cross-region backend failover, client connection proxying, and fine-grained backend locality policies within connected private networks.
Google Cloud offers three primary load balancer categories that serve different networking needs. The Application Load Balancer operates at Layer 7 and handles HTTP or HTTPS traffic, making it suitable for web applications requiring content-based routing. The proxy Network Load Balancer operates at Layer 4 for TCP with optional SSL offload, while the passthrough Network Load Balancer preserves client source IP addresses and supports additional protocols including UDP, ESP, GRE, and ICMP. Selecting the appropriate load balancer depends on whether the application is external (internet-facing) or internal, whether backends need to be deployed globally or regionally, and whether Premium or Standard Network Service Tier is required. The load-balancing scheme indicates whether a load balancer handles internal or external traffic, with managed implementations running on Google Front Ends (GFE) or the open source Envoy proxy. For internal load balancers, regional variants only allow traffic from clients in the same region by default, though global access can be enabled on the forwarding rule to permit cross-region access.
Network Service Tiers let you optimize connectivity between systems on the internet and Google Cloud instances. Premium Tier delivers traffic on Google's premium backbone, routing packets to enter and exit Google network edge points closest to the client, while Standard Tier enters and exits at the peering point closest to the Google Cloud region where the load balancer is configured. If no network tier is specified, load balancers default to Premium Tier, though certain external load balancers such as global external Application Load Balancers and global external proxy Network Load Balancers can only operate in Premium Tier. All internal load balancers always use Google's high-quality global backbone and are therefore configured to Premium Tier by default, though the internet egress charges associated with Premium Tier don't apply to internal load balancer traffic.
Internal load balancers can be accessed from on-premises or peer networks connected through Cloud VPN tunnels or Cloud Interconnect VLAN attachments. When accessing an internal load balancer through Cloud VPN, both the Cloud VPN gateway and tunnel(s) must be located in the same region as the load balancer when global access is disabled, and routes must provide response paths from the load balancer's backends to the on-premises or peer network. For Cloud Interconnect access, both the VLAN attachment and Cloud Router must be located in the same region as the load balancer when global access is disabled, and on-premises routers must provide response paths from the load balancer's backends to the on-premises network. When using VPC Network Peering to connect VPC networks, Google Cloud shares subnet routes between the networks, allowing traffic from the peer network to reach internal load balancers. However, you must create ingress firewall rules to allow traffic from client VMs in the peer network, as Google Cloud firewall rules aren't shared among networks when using VPC Network Peering. For regional internal Application Load Balancers, client VMs in the peer network must be located in the same region as the internal load balancer unless global access is configured.
Cloud Armor can be enabled on backend services for external Application Load Balancers to add additional protection against DDoS attacks and other threats. For proxy load balancers such as internal and external Application Load Balancers, Identity-Aware Proxy (IAP) is recommended as the authentication method instead of relying on client IP address tracking, since proxy load balancers don't preserve client IP addresses by default. This type of IP-based authentication is more compatible with passthrough load balancers, which preserve the original client source IP address. Backend authorization can be controlled by configuring backend VMs or endpoints to restrict access using HTTP headers such as X-Forwarded-For. Firewall rules must be configured to allow health check probes to reach backend VMs, with proxy-based load balancers requiring ingress allow rules from the proxy-only subnet range, while GFE-based load balancers require rules permitting traffic from Google Front End IP ranges.
The choice between load balancer types depends on several interrelated factors. Choose an Application Load Balancer when you need HTTP(S) traffic handling with advanced traffic management capabilities, URL-based routing, or integration with Cloud CDN. Choose a proxy Network Load Balancer when you need TLS offloading at scale, support for non-HTTP protocols, or when client IP preservation isn't required. Choose a passthrough Network Load Balancer when you need to preserve client IP addresses, support UDP traffic, or handle protocols beyond TCP and HTTP(S). For latency-sensitive applications requiring global distribution, global external Application Load Balancers direct traffic to the closest healthy backend with capacity. For compliance requirements restricting data to specific regions, regional external Application Load Balancers can serve content from only a single configured geolocation. The decision between Premium and Standard Tier hinges on whether the application has strict latency or performance requirements, with Standard Tier serving as a lower-cost alternative for applications without such demands.
A proxy Network Load Balancer terminates incoming client connections at the load balancer and opens new connections to the backends, enabling TLS offloading and port remapping but replacing the client source IP with the proxy's IP. A passthrough Network Load Balancer forwards packets directly to backend VMs without modification, preserving the original client source IP and enabling direct server return (DSR), but it cannot perform SSL offloading or advanced HTTP-level features.
Use a global external Application Load Balancer when internet clients are geographically distributed and require low-latency access to backends in multiple regions, because it terminates TCP/TLS at a nearby Google Front End (GFE) and routes traffic over Google's backbone. Use a regional external Application Load Balancer when strict data residency or compliance requirements mandate that traffic stay within a single region, or when you need Standard Tier support.
Connect an on-premises network to an internal load balancer through Cloud VPN tunnels or Cloud Interconnect VLAN attachments. The Cloud VPN gateway and tunnel(s) (or the VLAN attachment and Cloud Router) must be located in the same region as the load balancer when global access is disabled. Routes must provide response paths from the load balancer's backends to the on-premises network, and ingress firewall rules must allow traffic from the on-premises client VMs.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts