Internal Load Balancing

Exam guide§2.3

Internal load balancers front a service with an RFC 1918 private IP reachable only by clients inside the VPC network (or networks connected to it over VPN/Interconnect) - never from the public internet. Three families cover the internal side of the load-balancer matrix:

#NumbersThe three internal load balancers

• Internal Application Load Balancer - Envoy proxy, regional Layer 7 (HTTP/HTTPS).
• Internal passthrough Network Load Balancer - regional Layer 4, no proxy; delivers packets straight to the backend.
• Internal proxy Network Load Balancer - Envoy proxy, Layer 4 (TCP), regional or cross-region.

Internal Application Load Balancer

An internal Application Load Balancer is an Envoy proxy-based, regional Layer 7 load balancer that runs and scales HTTP(S) traffic behind an internal IP address. Its backends live in one region, but the load balancer can be configured to be globally accessible by clients from any Google Cloud region. It optimizes traffic distribution within your VPC network or networks connected to it.

It runs in one of two deployment modes:

⇄CompareRegional internal vs cross-region internal

Regional internalManaged Envoy service; all clients and backends stay in one specified region, which helps meet regional compliance. After configuration it auto-allocates Envoy proxies to meet demand.

Cross-region internalA multi-region managed Envoy service that load balances to globally distributed backend services, directing traffic to the closest backend. Backends in multiple regions give high availability: if one region's backends go down, traffic fails over to another region.

The two internal Application Load Balancer deployment modes share the same network service tier, load balancing scheme, and IP family (rows spanning both columns) - they differ only in frontend ports: a regional internal load balancer references exactly one port (1-65535), while a cross-region internal load balancer sets none.

?DECISIONRegional internal vs cross-region internal ALB

Keep all clients and backends in one region (data-residency / compliance)→Regional internal

Need failover and closest-backend routing across regions→Cross-region internal

Pick this when: regional compliance vs high availability across regions

Internal passthrough Network Load Balancer

The internal passthrough Network Load Balancer is a regional, private, Layer 4 service. It is the choice when you need to load balance protocols beyond HTTP, or a TCP port that other load balancers do not support. It is only reachable through the internal IPs of VM instances in the same region - you point its IP at your private backend instances as their frontend.

#NumbersWhat it load balances

• Protocols: TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE.
• Or any TCP port not supported by other load balancers.
• Regional only - clients and backends in the same region.
• Uses RFC 1918 private IPs; no public IP is needed for the service.

Google Cloud internal load balancing is not device- or VM-based. It is a software-defined, fully distributed solution built on Andromeda, Google's network virtualization stack. That changes the traffic path compared to a traditional proxy:

Traditional proxy load balancing (left) terminates the client connection at the load balancer VIP, then opens a second connection to a backend - two hops. Internal passthrough Network Load Balancing (right) is software-defined on Andromeda: the VIP lives on every backend, so packets are delivered directly from client to backend with no proxy hop.

⚠GotchaPassthrough delivers packets directly - there is no proxy hop

In the traditional proxy model, traffic terminates at the load balancer, which then opens a second connection to a backend - two connections per request. Internal passthrough Network Load Balancing instead uses lightweight Andromeda load balancing to deliver traffic directly from client to backend. Because everything stays inside Google's network and your VPC/region, the result is lower latency and simpler configuration - and, being passthrough, the backend sees the real client source IP.

⚠Gotcha"TCP Load Balancing" + "Only between my VMs" = internal passthrough, and internal forces regional

In Network Services -> Load balancing -> Create, picking TCP Load Balancing and then Only between my VMs builds the internal passthrough NLB. Choosing internal restricts the balancer to a single region - you cannot make it global.

Standing one up (lab flow)

The console build order for an internal passthrough NLB is fixed:

#NumbersInternal passthrough NLB - build order

• Firewall rules - one allowing tcp:80 from clients and one allowing the health-check probe ranges 130.211.0.0/22 + 35.191.0.0/16; scope both with a target tag on the backends (see firewall rules).
• Instance template(s) - a startup-script-url metadata key can point at a script in a public Cloud Storage bucket; set the network tag and subnet to match the firewall rules.
• Managed instance groups - two groups (one per zone/subnet) in the same region, autoscaling on CPU.
• Backend config - region + network, add both instance groups as backends, create the health check inline.
• Frontend config - pick a subnet and optionally reserve a static internal IP for the VIP (the first usable subnet address is .2 - see reserved IPs); set the port to 80.
• Test - from a utility VM in the same region, curl the VIP repeatedly and watch responses hop between the backends.

Internal proxy Network Load Balancer

The internal proxy Network Load Balancer is a proxy-based, Layer 4 load balancer powered by Envoy and the Andromeda stack. It runs and scales TCP service traffic behind a regional internal IP accessible only to clients in the same VPC network (or connected networks). Unlike passthrough, it terminates the client's TCP connection at an Envoy proxy, then opens a second TCP connection to backends - which may be in Google Cloud, on-premises, or another cloud.

It is available in regional internal and cross-region internal modes. A regional deployment chains these resources inside a single region, with a proxy-only subnet and health check alongside and global firewall rules:

≡FactsRegional internal proxy NLB - request path

• Client VM - connects to the load balancer's regional internal IP.
• Forwarding rule (regional) - the front door for that IP; hands the request to the target proxy.
• Target TCP proxy (regional) - terminates the client TCP connection.
• Backend service (regional) - distributes to healthy backends.
• Backends - instance groups or NEGs.
• Alongside: a proxy-only subnet (regional), a health check (regional), and firewall rules (global).

A regional internal proxy Network Load Balancer keeps the whole chain in one region: the client VM hits the regional forwarding rule, which the regional target TCP proxy terminates and passes to the regional backend service, which spreads traffic across instance-group or NEG backends. A regional proxy-only subnet and health check support it, while firewall rules are global.

In cross-region internal mode the forwarding rule, target proxy, and backend service become global, so a single deployment spans multiple regions. A client in either region can reach the forwarding rule in either region, and the shared global backend service fans out to backends in both:

A cross-region internal proxy Network Load Balancer spans regions: each region has a client VM and a global forwarding rule (with a regional IP address) in its own subnet, but they share a single global target proxy and global backend service. A client in either region can reach the forwarding rule in either region, and the backend service fans out to instance-group or NEG backends in both regions - so a regional failure fails over to the other.

⚠GotchaCross-region mode uses a global forwarding rule with a regional IP

In cross-region internal mode the forwarding rule and target proxy become global, so a single deployment spans multiple regions. Each global forwarding rule still uses a regional IP address that clients connect to. Traffic is directed to the closest backend, and spreading backends across regions gives high-availability failover if one region goes down.

Internal load balancing supports 3-tier web services

A classic use case is the 3-tier web service, where internal load balancing keeps the inner tiers private:

A 3-tier design: an external Application Load Balancer gives users worldwide one global IP, spreading traffic across web-frontend backends in asia-east1, us-central1, and us-west1. In each region an internal Network Load Balancer fronts the middleware (application) tier, so neither the application tier nor the database tier behind it is ever exposed externally.

#NumbersThe three tiers

• Web tier - an external Application Load Balancer gives users in San Francisco, Iowa, Singapore, and beyond a single global IP, with backends spread across us-west1, us-central1, and asia-east1 (a global load balancer).
• Application (internal) tier - each region's web backends reach an internal Network Load Balancer fronting the middleware, with backends in zones like us-west1-a, us-central1-b, and asia-east1-b.
• Database tier - sits in each of those zones, behind the internal tier.

⚠GotchaOnly the web tier is exposed externally

Because the application tier and database tier sit behind internal load balancers, neither is reachable from the internet. This simplifies security and network pricing - only the external web tier needs a public frontend.