VPS hosting in Amsterdam: what matters

Why choose VPS hosting in Amsterdam

VPS hosting in Amsterdam is a network decision before it is anything else. Amsterdam is one of Europe's major interconnection points, which means a large number of independent networks meet there and hand traffic straight to each other. A server in that metro area tends to reach the United Kingdom, the Nordics, Germany, France and the Benelux countries over short paths with few networks in between.

That is the argument. The rest of this guide is about checking whether it holds for your users, because it does not hold for everyone. Amsterdam is a good default for a customer base spread across northwestern Europe. It is a poor choice if most of your traffic comes from Warsaw, Istanbul, São Paulo or Toronto, since good peering in the Netherlands does not shorten the distance to those places.

What an internet exchange actually is

An internet exchange point, or IXP, is a shared switching fabric. Independent networks rent a port on it, plug in once, and can then exchange traffic directly with the other members. In Amsterdam the best known one is AMS-IX, the Amsterdam Internet Exchange. It is not the only exchange in the city, and the number of them is not what matters to you.

To see why an exchange changes latency, you need the two ways a packet crosses between networks. The first is transit: you pay a larger network to carry your traffic to the rest of the internet. The second is peering: two networks agree to pass traffic to each other directly, usually with no money moving in either direction. Each network here is an autonomous system, or AS, a network with its own number and its own routing policy.

Transit paths are chosen by business relationships as much as by geography. A packet from a server in one European city to a broadband customer in another can legitimately travel to a third city, change networks there, and come back. Nothing is broken. The route is simply the one the money and the routing policy produced. At an exchange the two networks can hand the packet over locally instead, so the path is shorter, fewer networks are involved, and there are fewer places for congestion to appear.

Here is the part that gets skipped. An exchange in the city does not put your VPS on it. What matters is your provider's own network: which transit providers it buys from, which exchanges it joins, whether it peers with the consumer and mobile networks your users sit behind, and how much capacity it has to each. Two servers in the same building can have very different paths off it. Ask the provider for its AS number, then look that number up on PeeringDB, where networks publish the facilities and exchanges they are present at. You can also read AS numbers straight off a live path, which the measurement section below shows.

Amsterdam or Frankfurt: decide from your users, not from a map

This is the real choice most readers face, and both cities are major interconnection points. Frankfurt hosts DE-CIX and is the usual pick for central, eastern and southeastern Europe, and for paths heading toward Vienna, Warsaw, Prague and the Middle East. Amsterdam sits well for the United Kingdom, Ireland, Scandinavia and the Benelux, and for traffic that uses the subsea cables landing in northwestern Europe. Treat both of those as tendencies rather than as measurements. Routing changes, providers change upstreams, and your provider's peering is more specific than any city-level generalisation.

So decide it with your own data.

1. Write down where your users actually are. Your web server access logs, your analytics or your customer list already hold this.
2. Weight that list by something that matters, such as revenue or active accounts, instead of raw hit counts that bots inflate.
3. Rent the smallest plan in each candidate city for one month, and measure to both from real user connections.
4. Compare the numbers you collected, not the numbers on a marketing page.

One honest caveat before you spend a week on this. For a user base inside western Europe, the difference between two well connected European metros is often smaller than the latency your own application adds. A page that runs ten database queries one after another pays the round trip ten times, so the query pattern can cost more than the city choice. Measure the application too. The same questions asked from the other side are in the guide to picking a VPS in Frankfurt, and the deciding factor is often something dull, such as which location has the plan size and the disk you need.

How do you measure latency to Amsterdam yourself

Run these from the connection your users have, or as close to it as you can get. Office fibre is not a proxy for a mobile connection in Manchester.

On Debian or Ubuntu, install the tools first.

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

Start with a round trip count.

ping -c 20 ams.example.com

The summary at the end is labelled rtt min/avg/max/mdev. The avg value is the typical round trip in milliseconds, and mdev is how much it moves around, which is jitter. Read the packet loss percentage in the same block. Loss at the destination is a real problem. Loss reported at one middle hop, with clean numbers on every hop after it, is usually not a problem, because routers give low priority to replies about packets addressed to themselves.

Then look at the path itself.

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

Each line is one hop, and --aslookup prints the AS number, so you can see which networks the packet crosses and where it leaves your provider. Look for the hop where the round trip rises and stays high on every hop after it: that is where the delay is added. If mtr exits because it cannot open a raw socket, run it with sudo. Some networks give ICMP low priority or drop it, so also measure the way your users connect, over TCP to the port you serve.

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

Then separate the network from the server.

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

Every value is seconds since the request started, so the gaps between them are what you read. connect minus dns is roughly one round trip, the TCP handshake. tls minus connect is the TLS (transport layer security) handshake, which costs more round trips, so it grows faster with distance than anything else on the line. ttfb minus tls is mostly the server thinking. That split is why curl is better than ping for a buying decision. A high total with a small ttfb gap means the box is far away. A large ttfb gap with a fast connect means the box is close and the application is slow.

Latency also changes with the hour, because congestion does. Sample it across a day instead of trusting one run.

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

The network is one half of the purchase. The disk and the CPU are the other half, and a well placed server on an oversubscribed node still feels slow, so put the trial plan through a proper VPS benchmark before you commit to a year.

EU data residency in plain terms

Data residency is the physical location where data is stored and processed. The Netherlands is in the European Union and the European Economic Area, so a server in Amsterdam keeps your bytes on EU infrastructure. That settles a location question, and location is only one input to a compliance question.

The GDPR (general data protection regulation) does not forbid personal data leaving the EU. It sets conditions on the transfer, and it also reaches the other companies that process data on your behalf. So the useful exercise is not "is the server in the EU". It is "where does every copy of this data end up".

That is where a residency claim usually breaks. The VPS is in Amsterdam and the database is on it. Then the backups go to object storage in another region, the application logs stream to a hosted search service, error traces go to a monitoring vendor, transactional email leaves through a third party, and user text is posted to an API for summarising. Each of those moved personal data somewhere. A location requirement covers all of them, not only the machine you chose deliberately.

Keep the two motives apart, because they lead to different designs. If a contract, a regulator or a customer requires EU infrastructure, that is a compliance requirement, it is written down, and it may force you to stay inside one region. If you want the server near your users so pages load faster, that is a latency requirement, and it may push you to add regions. Using the compliance words to justify a performance decision leaves you unable to answer either question later.

Ask the provider who can access the machine, where support staff are located, which law the company answers to, and whether any subprocessor sits outside the EEA. Get the answer in a data processing agreement, because a signed document is what an auditor asks for and a support ticket is not. For the full method, the residency framework written for Canadian data transfers directly: list the data, list every processor that touches it, write down the rule you must satisfy, then choose the location last. This is a description of the questions to ask, not legal advice.

What choosing Amsterdam does not fix

• Distance to everyone else. Signals cross fibre at roughly two thirds of the speed of light in a vacuum, and the cable route is always longer than the straight line, so a user in Singapore pays for the distance whichever European city you pick.
• A chatty application. Every request that waits for the previous one pays the round trip again.
• Single region risk. One VPS in one city is one failure domain, and good peering does not save you from deleting the wrong volume.
• Oversubscribed hardware. A busy node in a well connected city is still a busy node.

What if my users are on more than one continent

The rule is simple: put the server at the point of presence nearest your users. If your users are split across continents, a location in the middle gives both groups a slow experience, because neither group is near it.

There are two real answers. Put anything cacheable behind a CDN (content delivery network), so the origin stays in Amsterdam while images, stylesheets, scripts and cached pages are served from a node near each user. Or run a second server in the other region and solve the data problem on purpose, with read replicas or with replication whose lag you have measured and written down. Both cost more than one box. That is the honest price of a split audience.

If a large share of your traffic is North American, a VPS in Toronto will serve those users better than any European city can, and for South American users a VPS hosted in Brazil avoids a transatlantic round trip on every request. Choosing Amsterdam is right when your users are in Europe, and mostly in its north and west. That is a specific claim, and the commands above are how you check it against your own traffic.

FAQ

Is a VPS in Amsterdam faster than one in Frankfurt?

For your users, possibly. Both cities are major interconnection points, so the difference comes from where your users sit and from which networks each provider peers with, not from the city name. Amsterdam tends to suit the United Kingdom, Ireland, Scandinavia and the Benelux, while Frankfurt tends to suit central and eastern Europe. Rent the smallest monthly plan in each, then run mtr --report --aslookup and a curl -w timing run from real user connections for a week before you decide.

Does hosting in Amsterdam make my service GDPR compliant?

No. It puts the data on EU infrastructure, which answers one question. Compliance also covers your legal basis, your processors, your backups, your logs and every third-party service you send personal data to. A server in Amsterdam that ships error traces to a vendor outside the EEA has still moved that data out. Location is the easy part, and it is the part people stop at.

What is AMS-IX, and does it affect my VPS?

AMS-IX is the Amsterdam Internet Exchange, a shared switching fabric where independent networks connect and pass traffic to each other directly instead of paying a transit provider to carry it between them. It reaches your VPS only through your provider. An exchange in the city helps you when your provider is present on it and peers with the networks your users use. Ask for the provider's AS number and check where that number peers on PeeringDB.

How do I test the network to a VPS before I pay for a year?

Buy the smallest monthly plan first. Run ping -c 20 for the round trip and the loss, then mtr --report --report-wide --aslookup --report-cycles 100 to see which networks the path crosses, then a curl -w run against a real page over HTTPS to separate distance from server speed. Repeat at different hours, because congestion varies through the day, and run it from the connections your users have rather than only from your office. Keep the log so you are comparing recorded numbers instead of an impression.