How Far Is Kathmandu From the Cloud? I Measured Every Major Region Myself

I wrote a line a few weeks ago about the 2am window when Kathmandu's shared fibre isn't split forty ways and "the free tier of Gemini answers me before I've finished reading my own prompt." It was true, but it was also a feeling, not a number. This post is the number. I ran a real, repeatable latency measurement from the actual residential connection I'm writing this on — a WorldLink line in Kathmandu — to six AWS regions and three major AI APIs, this afternoon, and I'm publishing the raw runs, not just the averages.

The methodology, plainly

I measured TCP-connect time — the duration from opening a connection to completing the TCP handshake, via curl -w "%{time_connect}" — against each target's HTTPS endpoint, five runs per target, taken August 15, 2026. TCP-connect time is a well-established latency proxy (it's what tools like CloudPing use), but it isn't identical to an ICMP ping round-trip, and it isn't the same as full application latency once TLS negotiation, request processing, and response generation are added on top. I'm reporting the median of five runs per target below, and the full set of raw numbers in the table at the bottom, because a single number with the messy reality sanded off is exactly the kind of false precision this site tries not to publish.

For the six AWS regions, I used each region's public S3 endpoint (s3.<region>.amazonaws.com) — a stable, publicly documented target that isn't behind a CDN, so the measurement reflects an actual connection into that specific AWS region rather than a nearby edge cache.

The regional ladder

Mumbai wins by a wide margin — 43.9ms median, barely a sixth of the two US regions. That's not surprising geographically, but it's worth having an actual number instead of an assumption: Singapore very nearly doubles it at 81.9ms, Tokyo more than triples it at 150.7ms, and Ireland — despite being roughly as far from Kathmandu as the US East Coast on a map — lands at 174.3ms, closer to the Asia-Pacific cluster than to Oregon or Virginia. Fiber routes don't follow great-circle distance; they follow whatever cable actually got built, and Nepal's international bandwidth runs primarily through Indian transit providers, which is almost certainly why the Asia-Pacific regions cluster so much closer together than pure geography would predict.

The practical takeaway for anyone in Nepal actually choosing where to deploy: ap-south-1 (Mumbai) is not a "close enough" option, it's the only regional choice that's actually close. Every other region tested adds at minimum another 40ms, and the two US regions add a quarter of a second before a single byte of your application logic runs.

The AI APIs are suspiciously fast — here's why that's not the whole story

This is the number that genuinely surprised me while running it: api.anthropic.com completes a TCP handshake from Kathmandu in a median of 9.3ms — faster than the round-trip to Cloudflare's own 1.1.1.1 anycast resolver (11.1ms). OpenAI's API comes in at 12.3ms, Google's Gemini API at 26.2ms. None of these companies have a datacenter in or near Nepal. What they have is a CDN/edge point of presence that terminates the TLS connection close by and proxies the actual request onward — meaning the number I measured is genuinely real, but it's measuring the doorstep, not the building the model actually lives in.

I ran a traceroute to confirm this rather than just assert it. The path to api.anthropic.com stays entirely within WorldLink's own network for six hops — home router, to WorldLink's Kathmandu core, to its international gateway — before terminating at the target IP on hop seven, total round-trip under 12ms at every hop along the way. That's consistent with a nearby edge PoP, not a multi-thousand-kilometer hop to wherever Claude's inference compute actually runs. The honest implication: the connection to these APIs is fast from Kathmandu, but the time to first token on an actual request — which has to reach the real backend, run inference, and stream a response back — will be measurably higher than a bare TCP handshake suggests. This post measures the doorstep truthfully; it does not claim the building is next door.

The one hop that explains the international leg

Running the same traceroute against the Mumbai S3 endpoint turned up something worth showing rather than just describing: the first eight hops, entirely inside WorldLink's domestic network, average under 15ms round-trip apiece. Then hop nine — the point where the path leaves Nepal's domestic backbone for international transit — jumps to roughly 144ms, and the trace stops responding to ICMP past that point (common; cloud-provider edge routers routinely rate-limit or drop the ICMP replies traceroute depends on, so the missing later hops aren't evidence of a problem, just of routers declining to answer).

I want to be careful about what that single 144ms hop actually proves: per-hop traceroute timing is notoriously unreliable for pinpointing exact costs, because routers commonly deprioritize generating the ICMP time-exceeded replies traceroute measures, inflating exactly the hop where a network boundary sits. So I'm not claiming "the international leg costs precisely 144ms" as a hard fact — I'm reporting that the domestic network is fast and consistent, the international crossing is where the one large, measurable jump appears, and that's consistent with everything else in this dataset: Nepal's bottleneck to the rest of the internet isn't the last mile, it's the border.

What this actually means, practically

If you're a Nepali developer choosing an AWS or GCP region for anything latency-sensitive, this data says the choice barely requires thought: ap-south-1 (Mumbai) or its GCP/Azure equivalents in India are the only "local" option, and every other region — including ones that feel psychologically closer, like anything in Asia generally — adds real, measurable time on top. If you're calling an AI API for anything interactive, the connection itself won't be your bottleneck (9-26ms is nothing), but don't mistake that for the API being "close" — the actual generation happens somewhere else entirely, and that's where your real latency budget goes.

Sources and full raw data

• Measured directly by the author, August 15, 2026: curl -w "%{time_connect}", 5 runs per target, from a residential WorldLink connection in Kathmandu (public IP geolocation independently confirmed via ipinfo.io before publishing)
• AWS S3 regional endpoint documentation (public, non-CDN regional targets)
• traceroute output to s3.ap-south-1.amazonaws.com and api.anthropic.com, same session

Note the first run against every target ran measurably slower than the following four — a cold-connection effect (fresh DNS resolution, no TCP session reuse) rather than a network problem, which is exactly why I'm reporting the median of five runs rather than a single measurement or a mean that a single slow first run would skew.

Written by Abhishek Kushwaha, founder and writer at Global Tech Search, based in Kathmandu, Nepal.