Choosing a server location: latency, data residency and compliance

This article is general information, not legal advice.

Server location latency — how much physical distance actually adds to a request's round trip — is mostly down to physics, and it's only half the decision: choosing a region also touches data residency and privacy obligations, which are a separate question from speed. For a business with customers across Australia and Nepal or South Asia, region choice is worth treating as a deliberate decision. This post covers the physics of latency and how to measure it yourself, the difference between data residency and data sovereignty, what Australia's APP 8 requires at a high level, and where a CDN fits in. It builds on the pillar guide, cloud servers explained, which covers regions more briefly alongside the rest of server selection.

Server location and latency: why distance sets a floor#

Data in a fibre-optic cable travels at roughly two-thirds the speed of light in a vacuum — about 200,000 km/second, because glass fibre has a refractive index of around 1.47. Worked through, that comes to approximately 4.9 microseconds per kilometre travelled one-way, or about 9.8 microseconds of round-trip time for every kilometre of one-way distance, according to fibre-latency calculations published by network hardware vendor M2 Optics. No amount of server tuning changes this — it's physics, not engineering.

Applying that formula to the straight-line ("great circle") distance between two cities — as calculated by Air Miles Calculator for several of these routes — gives a theoretical minimum: a floor, not a prediction:

Real-world latency on any of these routes will be higher than this table shows, often noticeably so. Undersea and terrestrial cables don't run in a straight line between two cities — they follow specific routes and landing stations — and every router, switch and peering point along the way adds a small additional delay. Treat the table as a lower bound on what's physically possible, not a benchmark of what you'll actually get.

How to measure your own latency#

Don't take a vendor's marketing page or a distance calculation as the final word — measure the real path from where your users actually are to the server you're considering.

# Round-trip time (ICMP) - a quick sanity check
ping -c 20 your-server-ip-or-hostname

# Hop-by-hop path and per-hop latency - shows WHERE time is being spent
mtr --report --report-cycles 50 your-server-ip-or-hostname

# Real HTTP-level timing, including DNS, TLS and time to first byte
curl -o /dev/null -s -w "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" https://your-site.example

ping gives you a fast, simple round-trip figure. mtr (a combination of traceroute and ping) shows which hop along the route is adding the most delay, which is useful when latency is higher than you'd expect. curl -w shows what a real request experiences end to end — DNS lookup, connection, TLS handshake and time to first byte — which is closer to what a visitor actually feels than a raw ping. Run these from a connection similar to your users' (a home or mobile connection in the target country, not just your office) for a realistic picture.

Data residency vs data sovereignty#

These two terms get used interchangeably, but they answer different questions:

• Data residency is about geography: in which country is the data physically stored?
• Data sovereignty is about jurisdiction: whose laws can reach that data, and who can compel access to it?

The two don't always line up. A server physically located in Australia doesn't automatically mean only Australian law governs the data on it — that can also depend on where the company operating the infrastructure or the application is headquartered and incorporated, and what agreements apply to the relationship. If sovereignty matters to your business or your clients (for example, a requirement that data never be subject to a specific foreign jurisdiction), that needs its own check — it isn't answered simply by picking a region on a map. If your main concern is more practical than legal — keeping data reasonably close to home and reducing the number of parties involved — choosing a regional provider and asking directly where data is stored and who can access it goes a long way.

Australia's APP 8, at a high level#

Australian Privacy Principle 8 (APP 8) applies to organisations covered by the Privacy Act 1988 and governs disclosing personal information to a recipient outside Australia. In plain terms, per the OAIC's APP 8 guidelines:

• Before disclosing personal information to an overseas recipient, an organisation must take steps that are reasonable in the circumstances to ensure the recipient doesn't breach the Australian Privacy Principles. In practice, this is usually done through a contract requiring the recipient to handle the information appropriately and to report data breaches.
• The OAIC draws a distinction between "use" and "disclosure": routing data through an overseas server in transit is generally treated as a "use," while storing data with an overseas provider is generally treated as a "disclosure" that triggers APP 8 — unless the arrangement gives the Australian organisation effective control over access and security.
• Under the related accountability provision, the organisation stays responsible for what happens to the data overseas. If the overseas recipient mishandles it in a way that would breach the Privacy Act, the original organisation can be treated as if it had committed that breach itself, even after taking reasonable steps upfront.

None of this means personal information must stay in Australia. It means an organisation needs to actively manage the arrangement — knowing where data is stored, having a proper contract in place, and understanding what the provider will and won't do — rather than assuming an offshore server is automatically a problem, or automatically fine. Where a workload is genuinely sensitive, choosing a region and a provider that can answer these questions clearly is part of that due diligence, alongside routine safeguards like the ones in our Linux server hardening checklist and a tested backup strategy.

CDNs: a complement, not a replacement#

A content delivery network (CDN) caches static content — images, stylesheets, scripts, sometimes whole cacheable pages — at edge locations spread around the world, so a visitor's browser can fetch that content from somewhere near them rather than from your origin server. This can noticeably improve perceived speed for visitors far from your server's region, without moving your application or database anywhere.

A CDN doesn't answer the residency or sovereignty questions above, because your data still lives and is processed at the origin — the CDN is only caching a copy of what's already public and cacheable. It's a genuine complement to a well-chosen region, not a substitute for choosing one deliberately.

Choosing between Sydney, Singapore, Mumbai and Europe#

For a business split between Australia and Nepal/South Asia, the practical options usually come down to a handful of OVHcloud regions such as Sydney, Singapore, Mumbai, Frankfurt or London. As a starting point:

• Mostly Australian users: Sydney keeps latency lowest for that audience.
• Mostly Nepali or South Asian users: Mumbai is geographically closest to Nepal; Singapore is a major regional connectivity hub and often performs well across South and Southeast Asia more broadly.
• A genuine mix of both, or existing European relationships: Singapore is a common middle ground for Australia–South Asia traffic; Frankfurt or London may make more sense if you have specific European data-location expectations or a significant European audience.

Whichever you're leaning towards, confirm it with the measurements above rather than geography alone — actual network routing sometimes produces surprises that a map doesn't predict. If you're also weighing this decision against currency, billing and how a local partner buys infrastructure on your behalf, see buying cloud servers from Nepal.

What to do next#

If latency to a specific audience is your main concern, cloud servers covers the regions available and how we help choose between them. If cost is the deciding factor once you've settled on a region, current plans and prices sets out what's available. For how we secure and back up a server once it's placed in the right region, see the hardening checklist and backup guide.