With backends in multiple regions, how Google Cloud Load Balancer decides which is the nearest (second nearest)

Question

We have a setup where External HTTP(s) Load Balancer has NEG based backends in multiple regions on different continents.

Documentations states that:

When you configure an external HTTP(S) load balancer in Premium Tier, it uses a global external IP address and can intelligently route requests from users to the closest backend instance group or NEG, based on proximity.

I would like to know how GLB decides on the proximity aspect and if there's a way to influence its decision making.

What we see is e.g. if we are sending traffic from Europe but Europe region, the nearest backend, is down, traffic is spread across remaining regions (backends) even though based on latency the US region (backend) is by far the nearest one. The traffic volume is nowhere near the backend capacity.

Could you explain what you exactly mean by _"remaining regions"_ ? — mario, Nov 30 '20 at 18:26
@mario by remaining regions I mean all but the nearest one. For example for traffic originating in Europe, the remaining regions are the US, Asia, Australia. — beezz, Nov 30 '20 at 21:58

score 0 · Answer 1 · answered Dec 03 '20 at 23:08

Google has 93+ POPs (Point of Presence) around the world.

Locations

Google Load Balancers use Anycast IP addresses. This means Google knows the POP the user connected thru which is typically closest to the user and can then route to the backend closest to the POP.

Anycast addressing

Cloud Load Balancing can put your resources behind a single anycast IP and scale your resources up or down with intelligent autoscaling.

Cloud Load Balancing

With backends in multiple regions, how Google Cloud Load Balancer decides which is the nearest (second nearest)

1 Answers1