Choosing the Right Cloud Load Balancer Type

Overview and What You Will Learn

In this lab, you will create a Global External HTTP(S) Load Balancer with a health check and backend service, then compare its configuration against an internal load balancer meant only for traffic within the VPC - directly experiencing why "load balancer" in GCP is really a family of distinct products, not a single service.

Why This Matters in Production

A team builds an internal microservice meant to only ever be called by other services inside the same VPC, but configures it behind a Global External HTTP(S) Load Balancer - accidentally exposing an internal-only service to the public internet, discovered only during a security review months later. Choosing the correct load balancer type from the start is a security decision, not just a performance one.

Core Principles

GCP's load balancing products span from global, external, internet-facing options down to internal, VPC-only options - the right choice depends on traffic type, whether the backend needs to be reachable from outside the VPC at all, and whether traffic needs global or regional distribution.

Detailed Step-by-Step Practical Lab

1. Create a project and enable Compute Engine:

2. Reserve a static global external IP for a public-facing load balancer:

3. Create a health check the load balancer will use to verify backend health:

4. Create a backend service and a global HTTP(S) load balancer using it:

5. Now create an Internal Load Balancer for a service meant to stay reachable only within the VPC:

Note

--load-balancing-scheme=INTERNAL is what specifically makes this an internal-only load balancer - there is no global IP, no public-facing proxy, and the resulting backend is reachable only from within the same VPC (or a peered/connected network), never from the public internet.

6. Confirm the difference in reachability by checking each load balancer's forwarding configuration:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Configuring a backend service meant only for internal traffic behind a Global External Load Balancer by default, accidentally exposing it to the public internet. Always confirm --load-balancing-scheme=INTERNAL (or the equivalent internal-only configuration) is used for any backend that should never be reachable from outside the VPC.

Tip

A Global External HTTP(S) Load Balancer is the right default for a public-facing web application needing traffic distributed across multiple regions - it uses a single global IP address and Google's own global network to route users to the nearest healthy backend, similar in concept to what Azure Front Door or AWS Global Accelerator provide, but natively built into GCP's core load balancing product.

• A Regional External Load Balancer trades global reach for staying within a single region - appropriate when a compliance requirement or a very region-specific latency need makes global distribution unnecessary or undesirable.
• Health checks differ by protocol and load balancer type. An HTTP health check (used for the public web load balancer) checks a specific path and expects an HTTP response; a TCP health check (used for the internal load balancer here) simply confirms a port accepts connections, a distinction worth matching to the actual backend protocol.

Quick Reference & Troubleshooting Commands