Cloud Latency From 33 Cities: 42 Regions Measured

Where should a server live when its users are everywhere? Providers answer with maps of their regions. We measured from the other end: 33 cities on six continents, to 42 regions of 5 providers (Hetzner, OVHcloud, Vultr, Akamai Linode and AWS), twice on the same day. Every figure below comes from those measurements, and the raw data is free to reuse.

Raw data: cloud-latency-2026-09.csv (CC BY 4.0). To measure your own latency to the same providers from your browser, use our cloud latency test.

Key findings

• No single region serves the world. The best one, Frankfurt, reaches 14 of the 33 cities in under 100 ms, with a median of 130 ms.
• A second region changes everything. Frankfurt and Singapore: 27 of 33 cities under 100 ms, median 39 ms.
• Three regions cover a global product. Frankfurt, US East and Singapore: 28 of 33 cities under 100 ms, and 9 cities in 10 under 114 ms.
• 7 locations, one per part of the world, put all 33 cities under 67 ms.
• Latin America needs its own region. From our Latin American cities, São Paulo answers in 31 ms; the next best location, US East, in 110 ms.
• No provider is fastest everywhere. Measured by the same probe in both rounds, AWS Singapore took 239–321 ms from Paris, Stockholm and Istanbul, against 156–201 ms for the fastest provider in Singapore. From Berlin, AWS was the fastest.
• Routes move within a day. Between our two rounds, Akamai Singapore got 81 to 84 ms faster from 4 European cities at once, measured by the same probes.
• Distance is not the whole story. Johannesburg to São Paulo took 351 ms at best, while light in fibre needs 74 ms for that distance: the packets went through Europe.

Where to host, by where your users are

For each part of the world, the median latency from its cities to the best location, and to the runner-up. The location is the best of every provider present there, so the table answers where to host, not with whom.

Where your users are	Best location (ms)	Next best (ms)
Europe Amsterdam, Berlin, Istanbul, London, Madrid, Milan, Paris, Stockholm, Warsaw	Frankfurt 14	Paris / Roubaix 18
North America Buffalo, Los Angeles, Toronto	Montreal / Toronto 12	US East 15
Latin America Buenos Aires, Mexico City, São Paulo	São Paulo 31	US East 110
Africa Fès, Johannesburg, Lagos, Nairobi, Tunis	South Africa 62	London 104
Middle East & India Delhi, Dubai	Mumbai 26	Singapore 75
East & Southeast Asia Bangkok, Denpasar, Ho Chi Minh City, Hong Kong, Jakarta, Manila, Seoul, Singapore, Taipei, Tokyo	Singapore 36	Tokyo 64
Oceania Sydney	Sydney 1	Singapore 97

How many regions do you need?

Each city is served by the nearest location of the set. The median says what a typical city gets; the "9 cities in 10" column says how bad it gets for the unlucky ones, which is usually what users complain about. One caveat: our 33 cities are not weighted by population or traffic, so a set that wins here is not automatically the best for your audience. The table by region above is the one to use for a decision.

Hosting locations	Median (ms)	9 cities in 10 under (ms)	Cities under 100 ms
Frankfurt	130	218	14 / 33
Frankfurt + Singapore	39	154	27 / 33
Frankfurt + Singapore + South Africa	38	97	30 / 33
Frankfurt + US East + Singapore	38	114	28 / 33
Frankfurt + Montreal / Toronto + São Paulo + South Africa + Mumbai + Singapore + Sydney	27	60	33 / 33

Same city, different route

Comparing providers city by city only makes sense when one probe measured all of them, which Globalping does not guarantee. The table keeps the European cities where it did, in both rounds, with the probe's network under the city. Each cell gives the first round, then the second.

From	AWS	Hetzner	Akamai (Linode)	OVHcloud	Vultr
Paris SCALEWAY	239 / 254	165 / 165	239 / 156	163 / 163	156 / 168
Stockholm Hollander & Jacobsen	271 / 292	168 / 168	342 / 258	187 / 180	180 / 179
Istanbul 2E TELEKOMUNIKASYON	285 / 321	220 / 209	281 / 197	210 / 210	201 / 182
Berlin IONOS	171 / 168	182 / 185	185 / 187	186 / 188	180 / 190
Warsaw OVH	176 / 207	209 / 209	276 / 195	–	173 / 173

Traceroutes taken during the second round explain the slow AWS cells. From Paris, the path went through NTT to Ashburn and San Jose in the United States, then Osaka, then Singapore: 237 ms, most of the way around the world. From Stockholm and Istanbul it went through Tata Communications via London, New York and Tokyo. The same three probes reached Vultr Singapore through Marseille and straight on to Singapore, in 147–185 ms. The AWS region is the same for every city; what differs is the path each origin's traffic is given. An earlier traceroute from Berlin, also through NTT, went east through Milan to Singapore, and Berlin got the fastest AWS time.

Routes also move. From Paris, Akamai Singapore answered in 239 ms at 12:30 UTC and in 156 ms at 18:10 UTC, and a traceroute taken shortly after showed a direct path through Telstra's network (156 ms). The same drop appeared from 4 European cities at once, so the change most likely happened near Akamai's end of the path rather than at any one origin. No status page announced it. This is why a provider's latency map does not settle the question, and why a route is worth monitoring.

Distance is not the whole story

Johannesburg and São Paulo are 7,429 km apart, and submarine cables cross the South Atlantic directly (SACS runs from Angola to Brazil). The best round trip we measured was still 351 ms, where light in fibre would need 74 ms. A traceroute from Johannesburg to Vultr São Paulo went through Cape Town, London and Newark before reaching Brazil.

Fastest region from each city

The single fastest region measured from each city, and the runner-up. Values under 2 ms mean the measuring probe sits in the same data centre as the region: they say nothing about the city's users.

From	Fastest region	ms	Runner-up (ms)
Amsterdam	OVHcloud Roubaix	6	Akamai (Linode) Frankfurt 7
Berlin	Akamai (Linode) Frankfurt	10	AWS Frankfurt 11
Istanbul	Vultr Frankfurt	39	AWS Frankfurt 45
London	Akamai (Linode) London	2	Vultr Paris 8
Madrid	AWS Paris	18	OVHcloud Roubaix 20
Milan	Vultr Frankfurt	10	Akamai (Linode) Frankfurt 10
Paris	Akamai (Linode) Paris	1	Vultr Paris 1
Stockholm	Hetzner Helsinki	7	OVHcloud Roubaix 22
Warsaw	Vultr Frankfurt	20	Akamai (Linode) Frankfurt 21
Buffalo	Akamai (Linode) Toronto	12	OVHcloud Beauharnois 12
Los Angeles	AWS us-west-1	11	Akamai (Linode) Fremont 12
Toronto	Akamai (Linode) Toronto	1	OVHcloud Beauharnois 8
Buenos Aires	Vultr São Paulo	31	AWS São Paulo 33
Mexico City	Hetzner Ashburn	56	Akamai (Linode) Toronto 60
São Paulo	Vultr São Paulo	1	AWS São Paulo 2
Fès	Vultr Paris	30	Akamai (Linode) Paris 31
Johannesburg	Vultr Johannesburg	1	AWS Cape Town 35
Lagos	AWS Cape Town	56	Vultr Johannesburg 73
Nairobi	Vultr Johannesburg	62	AWS Cape Town 73
Tunis	AWS Paris	27	Akamai (Linode) Paris 32
Delhi	Akamai (Linode) Mumbai	22	AWS Mumbai 24
Dubai	AWS UAE	11	AWS Mumbai 30
Bangkok	Akamai (Linode) Singapore	27	Hetzner Singapore 32
Denpasar	Akamai (Linode) Singapore	27	Hetzner Singapore 29
Ho Chi Minh City	Akamai (Linode) Singapore	37	Vultr Singapore 42
Hong Kong	AWS Singapore	35	Hetzner Singapore 35
Jakarta	OVHcloud Singapore	14	Hetzner Singapore 14
Manila	Vultr Singapore	39	Hetzner Singapore 39
Seoul	Akamai (Linode) Tokyo	31	AWS Tokyo 34
Singapore	Akamai (Linode) Singapore	0	Vultr Singapore 1
Taipei	Vultr Tokyo	33	Akamai (Linode) Tokyo 36
Tokyo	Akamai (Linode) Tokyo	1	Vultr Tokyo 2
Sydney	Akamai (Linode) Sydney	1	Vultr Sydney 1

Measure it from where your users are

These numbers were measured from servers. To see what your own connection gets, run our cloud latency test in your browser: it times requests to 36 regions of the same providers. To see the path, not just the delay, trace the route from our servers or from 35 locations in 31 countries, and compare.

How we measured

• Probes: one Globalping probe per city for each measurement (Globalping may pick another probe in the same city from one measurement to the next), the same network TraceMapper uses for its 35 measurement locations. Our "New York" location is a probe in Buffalo, New York State, and is named Buffalo here.
• Targets: the public test endpoints each provider publishes (42 regions). AWS drops ICMP, so AWS was measured with TCP connections to port 443 of its regional DynamoDB endpoints; every other target with ICMP ping.
• Samples: 4 packets per pair. A lost TCP SYN is resent after a second, so samples more than 900 ms above the fastest one were dropped; the value is the median of the rest. Two rounds on 26 September 2026 (around 12:30 and 18:10 UTC); a pair's value is the median of its rounds.
• Checks: 2,726 valid measurements out of 2,772. Every value was compared with the minimum light needs in fibre over the distance; 2 answered faster than that and were excluded, because the reply came from a device closer than the server (Los Angeles → Akamai (Linode) Paris; Los Angeles → Vultr Frankfurt). Each traceroute shown was checked against the ping measured for the same pair. Measurements taken by a probe inside the target provider's own network were excluded too (39): they measure that provider's backbone, not a path across the internet. 124 of the 1,375 city and region pairs moved by more than 25 % between the two rounds, mostly because Globalping picked another probe in the same city; the CSV has both values.

Limits

• Server to server. Globalping probes mostly sit in hosting networks. Users on home or mobile connections add their own access network on top.
• One probe per city. Another network in the same city can take another route. The routing findings above are only those that held in every round.
• A snapshot. Routes change from one hour to the next; two rounds on one day show the stable part, not every variation.
• Not a provider ranking. A provider slower from one city is often faster from another; the table by region is the fair comparison.

Data

All 2,772 measurements, including the excluded ones and their reason, are in cloud-latency-2026-09.csv, under the CC BY 4.0 licence. Reuse them freely with a link to this page: "TraceMapper, Cloud latency from 33 cities (September 2026)".