Internet Topology for Fun and Latency

Why your nearest cloud region isn’t always your fastest.

Summary

Geographical proximity isn’t the same as network proximity. We’ll explore how internet routing, peering, and network egress affect latency to public cloud infrastructure, using three progressively interesting network scenarios.

What problem are you addressing?

Cloud architects often assume the geographically nearest cloud region offers the lowest latency. While this is often correct; packets don’t necessarily travel the shortest geographical path.

ISP routing, traffic interconnection points, and cloud network design influence actual performance and hence user experience. Satellite networks such as Starlink further complicate matters by separating users’ physical locations from their public IP geolocation and terrestrial network egress.

Understanding these differences helps engineers make better application- and network-architecture decisions.

Intended audience

Platform engineers, SREs, cloud infrastructure engineers, network architects, network engineers, and developers.

Level

Intermediate. General networking knowledge required.

Practical takeaways

1. Understand why geographical proximity doesn’t necessarily mean lower latency.
2. Learn when IP geolocation, ASN information, network topology, and actual latency measurements are useful—and where their limitations lie.

Outline

We’ll explore three increasingly complicated scenarios:

Using network diagrams, maps, and examples from our work at Fastah, we’ll explore how these concepts influence cloud-region selection.

How can this help other practitioners?

A practical mental model for investigating unexpected cloud latency, choosing candidate deployment regions, and recognizing when geographical assumptions break down—particularly for satellite-connected users.

Current state

Production experience and ongoing product R&D at Fastah.