How to choose a VPS location that actually matters
Latency is rarely the only thing that matters. A short framework for picking a region: users, regulation, peering, and disaster geography.
"Pick the closest region to my users" is good advice for the median web app. It is also incomplete. Latency is one of four axes that determine whether a VPS location is right for your workload. Get the others wrong and you'll be migrating in six months.
1. Latency to users (the obvious one)
For interactive workloads (web apps, dashboards, games), each 50ms of round-trip time visibly slows the experience. Test before assuming.
mtr --report -c 30 your.vps.ip
Run it from the network your users are on. Office Wi-Fi is not a representative test. If you're targeting consumers, do the test from a phone on a mobile data connection. Eyeballs are surprisingly often on 4G, and CGNAT adds latency you can't control.
For our locations, rough end-user RTT looks like:
| User region | Best GetVPS location | Typical RTT |
|---|---|---|
| UK / Ireland | London | 5-15ms |
| Western Europe | Amsterdam, Frankfurt | 10-25ms |
| Nordics | Stockholm | 5-20ms |
| US East | Ashburn | 10-30ms |
| US West | Fremont | 15-40ms |
| Central US | Kansas City | 10-35ms |
| Eastern Canada | Toronto | 5-25ms |
Numbers from terrestrial fibre. Mobile and satellite add unpredictable jitter on top.
2. Regulation
Where data lives matters more than where it's processed.
- GDPR: EU and UK personal data should stay in the EEA or UK. Adequacy decisions are political and reversible. London + Amsterdam covers both regimes.
- Schrems II: US-hosted data on EU subjects is a continual compliance footnote. If your users are EU consumers, default to EU regions.
- Sector rules: finance (PSD2, MiFID), healthcare (HIPAA in the US), and gambling licences all have geographic constraints. Read your licence; ask your DPO.
3. Peering and transit quality
A datacenter on cheap blended transit will beat a top-tier facility on the wrong network for your specific traffic. Look for:
- Direct peering with the eyeball networks your users sit behind (Comcast, BT, Deutsche Telekom, etc.).
- Membership at the local IX. We connect at LINX and LONAP in London, AMS-IX and ERA-IX in Amsterdam, DE-CIX in Frankfurt, LINX NoVA and NVIX in Ashburn, ONIX and TORIX in Toronto, SFMIX and FremiX on the West Coast.
- Multiple Tier-1 transit providers, not just one.
We publish peering data per location on each region page. If your users are mostly behind a specific carrier, ask us to confirm the peering relationship before you commit.
4. Disaster geography
Single-region is not a disaster recovery strategy. When you choose a primary, choose the secondary at the same time and in a different failure domain.
- Power grid: Don't put primary and DR in the same grid. London + Amsterdam is fine. London + Manchester is not (UK National Grid covers both).
- Geopolitics: Cross at least one international border for high-stakes workloads.
- Network: Avoid both regions sharing the same submarine cable systems. The Atlantic and the North Sea each have specific cable choke points.
A reasonable EU pair: London + Frankfurt. A reasonable transatlantic pair: London + Ashburn. A reasonable US-only pair: Ashburn + Fremont.
A quick decision flow
- Where are 80% of your users? Pick the closest GetVPS region. That's your primary.
- Where is your data legally allowed to live? If the answer is narrower than your latency answer, regulation wins.
- Does your largest user network peer well with that region? Run an MTR. If RTT is bad despite geographic proximity, you have a peering problem and another region might be better.
- Pick a DR region in a different failure domain than your primary.
Most teams skip step 2 entirely and find out at audit time. Most teams skip step 4 and find out during their first prolonged incident. The framework is boring; following it puts you ahead of most operations.
Continue reading