Choosing a VPS Location in Europe: Latency, GDPR and Data Residency

Every VPS order form has a location dropdown, and most people pick their own country without checking whether it matters. This post covers the two reasons it can: how distance becomes delay, and how to measure that for your own users, and what GDPR and "data residency" require of the place a server sits.

How distance becomes latency

A signal in optical fibre travels at roughly 200,000 km per second, about two thirds of the speed of light in a vacuum. That gives a useful rule of thumb: 1 ms of round-trip time for every 100 km of distance, as a floor. Real routes are longer than a straight line and pass through routers, so measured figures are higher than the floor, but never lower.

These are physics, not measurements; yours will be higher. The pattern is what matters: within western Europe the differences are a handful of milliseconds, across the Atlantic they are tens.

A single round trip is not what a visitor waits for. A new HTTPS connection needs one round trip for TCP, one for TLS 1.3 and one for the request and first byte of the response, after a DNS lookup. So distance costs roughly three round trips per new connection. Ten milliseconds extra becomes thirty, which nobody notices. Eighty extra becomes a quarter of a second, which people do.

Tip: traffic follows ISPs' peering agreements, not geography. Two cities 300 km apart can be linked through a third much further away, which is why you measure.

Measure it for your own audience

Run these from where your visitors are: your own connection, a colleague's, a mobile hotspot.

Round-trip time and packet loss:

ping -c 20 203.0.113.10

Look at avg and mdev in the last line. A low average with a high deviation is a jittery path, which hurts SSH and remote desktops more than web pages.

The path, hop by hop, with loss and latency per hop:

mtr -rwbz -c 100 203.0.113.10

-r prints a report, -w keeps long hostnames, -b shows names and addresses, -z adds each hop's AS number and -c 100 sends 100 probes. Add -4 or -6 to force a protocol; the IPv6 path is often different from the IPv4 one.

Tip: loss on a middle hop that does not continue to the final hop is not a problem. Routers rate-limit their replies to probes while forwarding real traffic normally.

What a browser experiences, phase by phase:

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

The values are cumulative seconds since the start. tcp minus dns is one network round trip. ttfb minus tls is a round trip plus the time the server spent building the page. If ttfb is 800 ms and the round trip is 15 ms, moving the server closer changes nothing; the application is the slow part.

Use a looking glass for the reverse direction

All of the above tests from you towards a server. A looking glass tests from the provider's network towards you, which is the direction most of a web page travels. Ours is at lg.vpspioneer.com and tests over both IPv4 and IPv6. Enter your own address, and ask someone in your target market to do the same, before ordering.

When a CDN makes location matter less

A CDN keeps copies of your static files, and optionally whole pages, on servers near the visitor. For a mostly cacheable site the origin's location stops mattering, because most requests never reach it. The details are in what a CDN is and when you need one.

It does not help with everything:

• Logged-in and dynamic pages such as carts, dashboards and admin panels go to the origin every time.
• APIs and webhooks are rarely cacheable.
• The legal question gets harder: the CDN is another company handling visitors' data, in more countries.

For a public content site behind a CDN, choose the location on price and trust. For an application, put the server close to its users and to whatever it talks to most: an application 30 ms from its database pays that on every query.

What GDPR asks about location

This is a summary for orientation, not legal advice; for anything contractual, ask a qualified adviser.

GDPR does not say personal data must stay in one country. It regulates who handles it and under which safeguards.

• Controller and processor. If you decide why and how personal data is processed, you are the controller. A hosting company that stores it on your behalf is a processor.
• Data processing agreement. A controller needs a written contract with each processor covering what it may do, security measures and sub-processors. Ask a host for its DPA before you sign up.
• Transfers outside the EEA. Moving personal data to a country outside the EEA requires a legal basis: an adequacy decision for that country, or safeguards such as standard contractual clauses plus an assessment of the destination.
• The UK. The European Commission has an adequacy decision for the UK, and the UK treats the EEA as adequate in the other direction, so data moves both ways without extra clauses. Adequacy decisions are reviewed periodically, so check the current status.

For our own position, we are a UK company with servers in France, and our terms and policies are on the legal pages.

Data residency versus data sovereignty

Data residency is where the data physically sits, including backups and replicas. It is a fact you can verify and write into a contract.

Data sovereignty is whose laws can reach that data. That depends on where the server is and on who operates it: a server in Frankfurt run by a company headquartered outside Europe may face legal demands from that company's home jurisdiction as well as German law.

Tip: when a client's questionnaire asks "where is our data stored", answer for every copy. The server may be in France while the off-site backups, the email service and the error tracker are somewhere else entirely.

France, Germany, the Netherlands or the UK

Paris, Frankfurt, Amsterdam and London all host large internet exchanges and are a few milliseconds apart, so the network difference is small. The contractual difference can be decisive: a form that says "EU" rules out London, and one that says "UK" rules out the rest.

A short decision procedure

1. List where your users are, by country, from your analytics.
2. List any contract or policy that names a country or region for storage.
3. If step 2 gives an answer, that is your location.
4. Otherwise shortlist two locations and measure from your users' side with mtr and the curl timing line, over IPv4 and IPv6 (why both matter).
5. If the difference is under 20 ms, choose on price, support and trust.

Our Cloud VPS servers are in France, which by this reasoning suits UK and western European audiences and EU residency requirements.