GCP External Load Balancers Explained | Regional vs Global, Proxy vs Passthrough
External load balancers are how internet traffic reaches your GCP application. GCP offers several types with meaningfully different behaviour: some terminate connections and inspect HTTP, others forward raw packets without modification. The type you choose affects TLS handling, source IP visibility, user latency, and what firewall rules your backends require.
Simple explanation
An external load balancer sits in front of your application and accepts traffic from the public internet. Instead of one VM handling all requests, the load balancer distributes incoming connections across multiple backend VMs. It continuously checks which backends are healthy and stops sending traffic to ones that fail. Clients connect to a single IP address and never need to know which specific backend VM handled their request.
Think of a hotel front desk. Guests arrive at one entrance and ask for a room. The desk clerk assigns them to whichever room is available and ready. The guests never walk the corridors looking for an open door themselves. If a floor is under maintenance, the clerk simply stops assigning rooms there. The load balancer is the front desk: one point of contact, with the routing logic hidden behind it.
What makes GCP load balancers different from each other is how they handle the connection after it arrives. Some terminate TLS at the load balancer. Some forward packets directly without touching them. Some are limited to a single region. Some route users to the nearest edge node globally. Choosing the wrong type leads to configuration pain later.
What this page will help you choose
By the end of this page you will be able to:
- Pick the right external load balancer type for HTTP, HTTPS, TCP, and UDP traffic
- Decide between regional and global load balancers based on your user geography
- Understand the difference between proxy-based and passthrough load balancers
- Know which firewall rules each type requires and why
- Recognise when an external load balancer is not the right answer at all
Which external load balancer should I use?
| Traffic scenario | Best GCP load balancer | Why it fits | Example |
|---|---|---|---|
| HTTPS web app with users across multiple regions | Global external Application LB | Anycast routes users to nearest Google edge; supports URL routing, TLS, and CDN | E-commerce site with customers in Europe, the US, and Asia |
| HTTPS web app with users in one region | Regional external Application LB | Simpler and less expensive than global; handles TLS and HTTP routing | Internal business tool accessed only from one office region |
| TCP app needing TLS termination, no HTTP logic | External proxy Network LB | Terminates TLS at the proxy without HTTP header inspection | A non-HTTP TCP service that needs encrypted transit |
| TCP/UDP app requiring original client IP at the backend | External passthrough Network LB | Forwards packets unmodified; backend VMs see the real client IP as the source | Game server, syslog collector, FTP service |
| Service only accessible from within your VPC | Internal LB (not external) | Internal load balancers use private IPs and are not internet-reachable by design | App tier behind a web tier, database proxy |
How external load balancers work
Every GCP external load balancer is built from the same core components, even if the names differ slightly between types:
- Frontend IP and forwarding rule. The public IP address clients connect to. A forwarding rule ties the IP, port, and protocol to a target proxy or backend service.
- Target proxy (Application and proxy LBs only). A target HTTPS or SSL proxy terminates the TLS connection from the client. It then forwards the decrypted request to the backend service. Application Load Balancers also apply a URL map here to decide which backend handles each request path.
- Backend service. Defines which backend group or NEG handles traffic and references the health check. This is where you configure session affinity, connection draining, and capacity settings.
- Health check. GCP probes backends at a regular interval. Backends that fail health checks are removed from rotation automatically. Without a working health check, the load balancer has no way to know which backends are available.
- Backend instance groups or NEGs. The actual VMs or containers handling requests. For VM-based backends, managed instance groups provide automatic replacement of unhealthy instances and integrate cleanly with autoscaling.
When a backend fails health checks, the load balancer stops sending new connections to it and shifts traffic to the remaining healthy instances. For Application Load Balancers, TLS handshakes are never initiated toward an unhealthy backend.
GCP external load balancer types explained
External Application Load Balancers
These operate at layer 7 and are the standard choice for HTTP and HTTPS applications. They terminate TLS at GCP infrastructure, inspect HTTP headers and URL paths, and can route to different backends based on URL map rules. Two modes are available:
- Global. Uses an Anycast IP. Traffic enters Google’s network at the nearest edge point of presence and travels to your backends over Google’s private network. Supports multi-region backends with automatic failover. Covered in depth on the Global Load Balancing page.
- Regional. Uses a regional IP. All traffic is handled in the chosen region regardless of where clients are located. Simpler and less expensive than global when users are concentrated in one area.
Backend VMs behind an Application Load Balancer do not see the original client IP as the network source. They receive traffic from GCP proxy ranges. The original client IP is available in the X-Forwarded-For HTTP header. TLS termination means backends receive plain HTTP (or re-encrypted HTTPS if you configure backend HTTPS), which offloads certificate management from individual VMs. For certificate options, see SSL Certificates in GCP.
Choosing a regional Application LB when users are spread across multiple continents causes unnecessary latency. A user in Tokyo connecting to a regional LB in us-central1 traverses the full Pacific on the public internet before reaching Google’s infrastructure. A global LB would have entered Google’s edge in Tokyo and then used Google’s private network for the rest of the journey.
External proxy Network Load Balancers
These operate at layer 4 and terminate TCP or SSL/TLS connections at GCP infrastructure. They proxy the connection to backends without inspecting HTTP headers or applying URL routing. Available in both global and regional modes.
Backends receive traffic from GCP proxy IP ranges, not from the original client IP. If you need the client IP at the backend, the PROXY protocol option can pass it as a structured header that the backend application must parse. Most teams using this type do so because they need TLS termination at a TCP level without HTTP-level logic.
If you need to route /api versus /assets to different backends, you need an Application Load Balancer, not a proxy Network LB. Proxy Network LBs operate at layer 4 and have no awareness of URL paths or HTTP headers at all.
External passthrough Network Load Balancers
These operate at layer 4 and forward packets to backends without modifying them. The load balancer does not terminate any connection; it passes packets through end-to-end. This means:
- Backend VMs see the original client IP as the network source
- There is no TLS termination at the load balancer
- There is no HTTP inspection or URL routing
- Any protocol running over TCP or UDP is supported, not only HTTP
Passthrough LBs are regional only. They are the right choice when you need the real client IP at the backend or when you are running non-HTTP protocols. Because they pass traffic directly to VMs, backend firewall rules need to allow internet-sourced traffic on the service port.
Passthrough load balancers do not handle TLS. TLS handshakes arrive directly at backend VMs. If the VM is not configured to terminate TLS, the connection fails with a handshake error. This is a common and time-consuming mistake to diagnose. If you want TLS handled at the load balancer, use an Application LB or proxy Network LB.
Regional vs global external load balancers
The regional versus global distinction matters most for latency, resilience, and cost. Here is how they compare:
| Regional | Global | |
|---|---|---|
| IP type | Regional IP | Anycast IP (same IP, multiple edge locations) |
| Where traffic enters Google’s network | Always at the load balancer’s region | At the nearest Google edge node to the user |
| Latency for distant users | Public internet all the way to the region | Short public internet hop, rest on Google’s private network |
| Backend geography | Single region only | Multi-region with automatic failover |
| Cross-region failover | No | Yes, traffic shifts automatically if a region is unhealthy |
| Typical use | Single-region apps, users in one area | Global user base, multi-region resilience |
| Cost | Lower | Higher, Premium network tier required |
Imagine you run a courier service with one depot in Chicago. Packages from New York, London, and Tokyo all travel to Chicago first, then get sorted. That is a regional load balancer. Now imagine the same service but with depots in every major city. A package from Tokyo goes to the Tokyo depot and is sorted locally. The customer address is the same everywhere, but the nearest depot handles it. That is Anycast with a global load balancer. Same IP, different entry point depending on where the request originates.
When global is the better answer
Use a global load balancer when your users are geographically distributed and latency matters, when you want automatic cross-region failover without DNS changes, or when you need to serve from backends in multiple regions simultaneously. A global e-commerce site serving customers across Europe, the Americas, and Asia Pacific is the textbook case. See Multi-Region Architectures for how global load balancers fit into resilient cross-region designs.
When regional is the better answer
Use a regional load balancer when your users are concentrated in one geography, when you have a single-region deployment, or when you want to avoid the additional cost and complexity of global Anycast. A regional deployment combined with autoscaling managed instance groups handles substantial single-region traffic efficiently without requiring global infrastructure.
When to use an external load balancer
- Public web applications. Any app reachable from the internet needs a public IP entry point. An external load balancer is the standard way to provide this without directly exposing individual VMs.
- Multi-zone deployments. Spreading backends across multiple zones for availability is only useful if traffic reaches all of them. A load balancer distributes across zones and removes unhealthy ones from rotation automatically.
- Multi-region deployments. A global external Application LB routes users to the nearest healthy region and fails over without DNS changes when a region has problems.
- TLS offload. Rather than managing TLS certificates on every backend VM, the load balancer terminates TLS centrally. Google-managed certificates auto-renew, removing the risk of expired certificates taking down HTTPS.
- Keeping backends less exposed. Behind an Application Load Balancer, your backend VMs only receive traffic from GCP proxy IP ranges, not directly from internet clients. This is a meaningful reduction in attack surface compared to assigning public IPs to every VM.
- One stable public IP for a dynamic backend pool. Managed instance groups add and remove VMs automatically. The load balancer’s IP stays the same regardless of what is running behind it.
- DNS and routing stability. Point your domain name to the load balancer IP via Cloud DNS. Backends can change without requiring DNS updates or client reconfiguration.
For HTTPS, use Google-managed TLS certificates on your Application Load Balancer. They provision automatically when the DNS record points to the load balancer IP and renew themselves before expiry. You never need to manually rotate a certificate. See SSL Certificates in GCP for setup details.
When NOT to use an external load balancer
- Private internal services. If the service should only be reachable from inside your VPC, use an internal load balancer instead. External load balancers assign public IPs and are internet-reachable by design.
- Cloud Run services. Cloud Run has built-in HTTPS ingress with automatic TLS and scaling. You do not need to add an external load balancer in front of a Cloud Run service unless you specifically need custom domain routing, Cloud Armor policies, or CDN integration via a global Application LB.
- Small lab or test environments. For a single VM you are testing temporarily, assigning a public IP directly to the VM is simpler. Load balancers add multiple interdependent components and have their own costs. Do not over-engineer a dev environment.
- Global LB when users are regional. A global load balancer costs more than a regional one. If all your users are in one city or one country, a regional load balancer is the practical choice. The Anycast benefit only matters when users are spread across geographies.
Proxy vs passthrough
The proxy versus passthrough distinction is one of the most important concepts to understand before picking a load balancer type. It affects TLS handling, client IP visibility, and how you write firewall rules.
A proxy load balancer is like a translator at a meeting. The client speaks to the translator, and the translator relays the message to the expert in their own language. The expert never directly speaks to the original client. A passthrough load balancer is more like a traffic controller at a roundabout: it waves vehicles toward the right lane without touching them. The driver and the destination are in direct contact the whole time.
| Proxy-based (Application LB, proxy Network LB) | Passthrough (passthrough Network LB) | |
|---|---|---|
| Connection handling | Terminates the client connection; opens a new connection to the backend | Forwards packets to the backend; connection is end-to-end |
| Client IP at backend | Not visible as the network source; available in X-Forwarded-For header (Application LB only) | Original client IP is the network source |
| TLS termination | Happens at the load balancer | No termination; TLS goes directly to the backend VM |
| HTTP awareness | Full header inspection and URL routing (Application LB) | None; raw packets only |
| Backend firewall exposure | Backends only need to allow GCP proxy ranges | Backends receive direct client traffic; must allow internet source ranges |
| Protocol support | HTTP, HTTPS, TCP, SSL | TCP and UDP; any protocol |
With an Application Load Balancer, backend access logs will show GCP proxy IP ranges as the source for every request, not the original client IPs. This is expected behaviour. To get the real client IP in your application, read the X-Forwarded-For header. The load balancer populates this header automatically.
In practice: if you are running a web application and want TLS handled centrally at the load balancer, you want a proxy-based type. If you are running a non-HTTP protocol or need the real client IP as a network-level source at the backend, you want passthrough.
Common mistakes
- Choosing regional when users are spread globally. Users connecting to a US-only regional LB from Tokyo traverse the public internet across the Pacific before reaching Google. The latency difference compared to a global Anycast LB can be several hundred milliseconds. If your users are geographically distributed and latency matters, use a global load balancer.
- Missing health check firewall rules. This is by far the most common reason a newly created load balancer forwards no traffic. Health check probes come from GCP’s IP ranges (
35.191.0.0/16and130.211.0.0/22), not from the load balancer’s frontend IP. Without a firewall rule allowing those ranges to reach backends on the service port, every backend fails its health check and traffic goes nowhere. See Firewall Rules Explained for how to write these correctly. - Choosing passthrough while expecting TLS termination. Passthrough load balancers forward raw packets. TLS handshakes arrive directly at backend VMs. If you want TLS handled at the load balancer layer, use an Application LB or proxy Network LB. Choosing passthrough with TLS-unaware backends causes handshake failures that can be hard to diagnose.
- Confusing backend traffic source ranges. Behind an Application LB, backends see GCP proxy ranges as the source, not the original client IPs. Writing a firewall rule that allows only the frontend IP of the load balancer will block all backend traffic. Allow the health check and proxy ranges, not the frontend IP.
- Using unmanaged instance groups as backends. Unmanaged groups require manual VM management. If a VM fails, no automatic replacement happens. Use managed instance groups for any production load balancer backend. They auto-replace unhealthy instances and integrate with autoscaling.
- Not planning backend group type early. You can use managed instance groups, unmanaged groups, zonal NEGs, or serverless NEGs as backends. Switching backend group type later often means recreating the backend service. Decide on your backend architecture before building the load balancer.
- Expecting backend logs to show real client IPs with an Application LB. Backend access logs will always show GCP proxy ranges as the source. Read the
X-Forwarded-Forheader in your application logs to get the original client IP. Use Cloud Monitoring and load balancer access logs for traffic visibility at the load balancer layer.
Firewall and security considerations
Health check rules
All GCP load balancer types require firewall rules allowing ingress from 35.191.0.0/16 and 130.211.0.0/22 to reach your backends on the service port. These are the source ranges GCP uses for health check probes.
Missing the health check firewall rule is the single most common load balancer configuration error. Without it, every backend fails its health check and the load balancer sends no traffic at all. The load balancer will appear to be configured correctly but will return 502 or no-response errors to clients.
# Allow GCP health check probes to reach backends tagged web-backend
gcloud compute firewall-rules create allow-lb-health-checks \
--network=production-vpc \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:443 \
--source-ranges=35.191.0.0/16,130.211.0.0/22 \
--target-tags=web-backendProxy-based load balancers
Backend VMs behind an Application LB or proxy Network LB only need to allow traffic from GCP proxy IP ranges (35.191.0.0/16 and 130.211.0.0/22). Your backend VMs are not directly reachable from the internet. All client traffic flows through the proxy layer first. This is a genuine security benefit over directly assigning public IPs to backend VMs.
Passthrough Network LBs
Because passthrough load balancers forward packets directly, client traffic arrives at backends with the original internet source IP. Backend firewall rules need to allow ingress from client IP ranges on the service port, which means backend VMs are more directly exposed to internet traffic than they would be behind a proxy-based load balancer. Combine this with strict use of IP management and application-level hardening.
TLS certificates
For Application Load Balancers handling HTTPS, TLS certificates are attached to the target HTTPS proxy. Google-managed certificates auto-provision and auto-renew with no manual intervention. Self-managed certificates require you to handle renewal. For the full picture, see SSL Certificates in GCP.
For a complete walkthrough of firewall rules for load balancer scenarios, see Firewall Rules Explained.
External vs internal load balancers
External load balancers accept traffic from the public internet via a public IP. Internal load balancers use private RFC 1918 addresses and only accept traffic from within your VPC or connected hybrid networks. Most production architectures use both: an external load balancer at the internet-facing edge and internal load balancers for the private tiers behind it.
A common pattern is a three-tier architecture: a web tier behind an external Application LB, an application tier behind an internal Application LB, and a database tier with no load balancer at all. The web tier receives public traffic. The app tier is only reachable by the web tier via its private IP. The database is only reachable by the app tier. Nothing in the app or database tier is internet-accessible.
If you are unsure whether a service needs an external or internal load balancer, ask one question: should this service ever be reachable from outside your VPC? If the answer is no, use an internal load balancer. External load balancers should only exist at the edges of your architecture where you intentionally accept internet traffic.
For the full comparison of public and private addressing, see Private vs Public IP Addresses.
Related architecture choices
Choosing a load balancer type is one decision. Several others follow directly from it:
- MIGs vs unmanaged instance groups. Managed instance groups integrate with health checks, auto-replace failed VMs, and support autoscaling. For load balancer backends in production, always use managed groups.
- Zonal vs regional resilience. A managed instance group can span multiple zones in a region. Distributing backends across zones means one zone going down does not take your service offline. Plan zone distribution before you build, not after.
- DNS and certificates. Point your domain to the load balancer IP via Cloud DNS. Use Google-managed TLS certificates to remove the risk of expired certificates. These two choices are independent but both affect your HTTPS setup.
- Monitoring and alerting. Load balancer request rates, backend health, and error rates are available in Cloud Monitoring. Set up alerts on backend health and 5xx rates so you catch problems before users report them.
- Troubleshooting unhealthy backends. When backends are failing health checks or traffic is not reaching them, start with the Troubleshooting Network Issues page for a systematic diagnostic approach.
Key takeaways
- Use an External Application LB for HTTP and HTTPS: global for multi-region users, regional for single-region deployments
- Use an External proxy Network LB for TCP/SSL when you need TLS termination but not HTTP-level routing
- Use an External passthrough Network LB when you need the original client IP at the backend, or for non-HTTP protocols
- Global load balancers use Anycast: users enter Google’s network at the nearest edge node; regional load balancers route all traffic through one region regardless of user location
- Proxy-based load balancers terminate the client connection; backends see GCP proxy ranges, not the original client IP
- Always allow health check probes from
35.191.0.0/16and130.211.0.0/22: this is the most common reason a new load balancer forwards no traffic - For production backends, use managed instance groups, not unmanaged ones
- If traffic should stay private and never cross the internet, use an internal load balancer instead
Frequently asked questions
What is an external load balancer in GCP?
A GCP external load balancer accepts traffic from the public internet and distributes it across backend VMs or services. It gives your application a single public IP address, handles health checking, removes failed backends from rotation, and depending on the type can terminate TLS, inspect HTTP headers, or forward raw packets to backends without modification.
What is the difference between regional and global external load balancers in GCP?
A regional external load balancer has a regional IP address and routes all traffic to backends in that one region, regardless of where users are located. A global external load balancer uses an Anycast IP advertised from multiple Google edge locations worldwide. Users connect to the nearest edge node, then traffic travels over Google's private network to a healthy backend. Global load balancers reduce latency for geographically distributed users and support automatic cross-region failover.
Does a GCP external load balancer preserve the original client IP?
It depends on the type. The external passthrough Network Load Balancer forwards packets without modification, so backend VMs see the original client IP as the network source. Application Load Balancers and proxy Network Load Balancers terminate the client connection at GCP infrastructure. Backends receive traffic from GCP proxy IP ranges, not from the original client. With Application Load Balancers, the original client IP is available in the X-Forwarded-For HTTP header.
Which GCP load balancer should I use for HTTPS?
Use an External Application Load Balancer, either global or regional depending on where your users are. Application Load Balancers handle TLS termination, inspect HTTP headers, and support URL-based routing to different backends. The global variant uses Anycast for lower latency across multiple regions. If you only need TLS termination without HTTP-level routing, an External proxy Network Load Balancer is an alternative, but Application Load Balancers are the standard choice for HTTPS web applications.
Do I need firewall rules for GCP external load balancers?
Yes. For all load balancer types, you need a firewall rule allowing GCP health check probes from 35.191.0.0/16 and 130.211.0.0/22 to reach your backend VMs on the service port. Without this rule, all backends appear unhealthy and the load balancer sends no traffic. For Application Load Balancers, backends also need to allow traffic from the same GCP proxy ranges. For passthrough Network Load Balancers, backends receive direct client traffic, so you also need a rule allowing ingress from client IP ranges on the service port.