Choose the right GCP load balancer type based on protocol, scope, and requirements.
Last verified: May 2026
Output will appear here...The chooser presents a decision tree based on three axes: traffic scope (internal vs external), protocol (HTTP/S, TCP, UDP), and geographic reach (regional vs global). Each leaf node maps to one of the seven GCP load balancer products with a one-line rationale. It also surfaces capabilities that frequently surprise teams (e.g., 'this LB doesn't support Cloud CDN' or 'this LB requires Premium tier networking') so the choice is informed.
The GCP Load Balancer Chooser helps you select the right Google Cloud load balancer based on your protocol requirements, traffic scope (internal vs. external), and regional vs. global needs. GCP offers seven distinct load balancer products with different capabilities, and choosing the wrong one leads to architecture rework. The tool walks you through a decision tree and explains each option's features.
Your team has been running an internal API mesh on GKE behind Internal TCP/UDP Load Balancers, and now needs to add HTTPS termination, mTLS to backends, and per-path routing. The chooser walks you through your requirements and recommends migrating to Internal Application Load Balancer. You read the migration considerations (different health check semantics, different IP requirements, BackendService vs target pool model) and plan the cutover with full awareness of the differences — not 3 weeks into a migration.
If you need a global anycast IP that can fail over between regions automatically, only the External Application Load Balancer (global) supports it. Regional load balancers — even the External Network LB — give you a regional IP that won't failover if the entire region goes down.
Internal Application Load Balancer is the right answer for most internal microservice meshes, NOT Internal TCP/UDP. The Application LB supports HTTPS termination, content-based routing, and gRPC, while the TCP/UDP LB is purely passthrough. Teams that pick TCP/UDP for an internal mesh end up regretting the lack of L7 features.
For UDP workloads (game servers, VoIP, DNS), External Network LB is your only option — none of the proxy or Application LB types handle UDP. Plan health checking carefully, since UDP doesn't have the same TCP-level signal that backends are healthy.
GCP offers: External Application LB (global HTTP/S), Regional External Application LB (regional HTTP/S), Internal Application LB (internal HTTP/S), External Network LB (TCP/UDP passthrough), Regional Internal TCP/UDP LB (internal passthrough), External Proxy Network LB (TCP proxy), and Internal Proxy Network LB (internal TCP proxy). The choice depends on traffic scope, protocol, and whether you need content-based routing.
Use global load balancers for internet-facing services that need anycast IPs, multi-region backends, and automatic failover. Use regional load balancers for single-region deployments or when you need to keep traffic within a specific region for data residency or latency requirements.
Cloud CDN integrates only with the External Application Load Balancer (global HTTP/S). When enabled, it caches responses at Google's edge locations worldwide. Regional and internal load balancers do not support Cloud CDN since they don't operate at the global edge.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.