Cloud Load Balancing
Google Cloud's family of load balancing products, spanning Global External HTTP(S) Load Balancers (public, distributed globally via a single IP), Regional External Load Balancers, and Internal Load Balancers reachable only from within the VPC. The right type depends on traffic type and whether the backend should ever be reachable from the public internet.
Frequently Asked Questions
Why does GCP offer separate Global, Regional, and Internal load balancer types instead of one universal product?
Each type solves a different reachability and latency problem: Global External HTTP(S) Load Balancers front public internet traffic through a single anycast IP routed to the nearest healthy region, minimizing latency for users worldwide. Regional External Load Balancers serve public traffic confined to one region for workloads that don't need global distribution. Internal Load Balancers are only reachable from within the VPC, for backend-to-backend traffic that should never be internet-exposed. Choosing the wrong type either overexposes an internal service or fails to give a public-facing app global reach.
What's a common architectural mistake teams make with GCP load balancer selection?
Defaulting to a Global External Load Balancer for internal microservice-to-microservice traffic because it's the most commonly documented option, when an Internal Load Balancer is both cheaper and more secure for that use case since it never needs a public IP or internet-facing attack surface at all. Conversely, some teams put internal-only load balancers in front of something that later needs public access and have to redo the networking rather than provisioning the right type from the start.