One server in one city is a single point of failure with a single distance to every user. Multi-region dedicated servers fix both: a second or third machine in another city keeps the service up when one site has a bad day, and puts capacity closer to users who are far from the first. The catch is that physics does not care about your architecture. The distance between the cities you choose sets hard limits on how the servers can share data. This guide shows how to pick the cities, which replication model fits which distance, and what two or three regions cost.
Why go multi-region
There are three honest reasons for multi-region hosting, and it helps to know which one is yours, because they lead to different designs.
- Availability. A server, a rack or a whole facility can fail. A second region turns an outage into a failover.
- Latency. Users far from your only server wait on every request. A server near them removes most of that delay.
- Jurisdiction. Some customers need their data kept in a particular country. Dedicated servers in multiple countries, one region per jurisdiction, can satisfy each without moving everyone.
If the reason is only availability, two cities close together are usually best. If it is latency, the cities should be near the users, even if they are far from each other. Jurisdiction picks the cities for you.
The distance between regions sets the rules
Light in fibre travels about 200 km per millisecond, so no round trip between two cities can be faster than their great-circle distance divided by 100. Real routes add more on top. Here are some pairs from NexonHost's twelve locations, each distance followed by its round-trip floor:
| Region pair | Distance (floor) | Good for |
|---|---|---|
| Sofia – Bucharest | 295 km (3.0 ms) | Availability in south-east Europe |
| Amsterdam – Frankfurt | 363 km (3.6 ms) | Availability in north-west Europe |
| Frankfurt – Milan | 518 km (5.2 ms) | Germany plus Italy |
| Paris – Marseille | 660 km (6.6 ms) | France plus routes to Africa and the Middle East |
| Vienna – Sofia | 817 km (8.2 ms) | Central plus south-east Europe |
| Frankfurt – Warsaw | 890 km (8.9 ms) | Western plus Central Europe |
| Amsterdam – Madrid | 1,481 km (14.8 ms) | Northern plus Iberian users |
| Amsterdam – Bucharest | 1,787 km (17.9 ms) | North-west plus south-east Europe |
| Dublin – Ashburn | 5,461 km (54.6 ms) | Shortest transatlantic floor |
| Frankfurt – Ashburn | 6,549 km (65.5 ms) | Europe plus North America |
Synchronous or asynchronous replication
This is the decision the distance table forces.
Synchronous replication waits for the second region to confirm every commit before telling the application it succeeded. A failover to that replica loses no committed write, as long as replication was still synchronous when the primary failed. The price is that every commit waits at least one round trip. At the 3.6 ms floor between Amsterdam and Frankfurt, a single connection committing one transaction after another manages at most about 280 a second; at the 65.5 ms floor between Frankfurt and Ashburn, the ceiling is about 15. Many connections in parallel can do far more in total, but each one waits. If the other region stops answering, the primary either stops accepting writes or, in some setups, falls back to asynchronous replication, and with only two sites an automatic failover needs a tie-breaker in a third city. Synchronous replication is practical between nearby cities and painful across an ocean.
Asynchronous replication confirms the write locally and ships it to the other region a moment later. Writes stay fast at any distance, but a failover loses whatever had not yet reached the other region, which depends on how far behind the replica was, so monitor replication lag. Most multi-region setups across long distances use this, and decide in advance how much loss is acceptable.
A common pattern combines both: a synchronous pair of nearby cities for availability, plus an asynchronous copy far away for disaster recovery or for serving reads to distant users.
Three designs that work
Active–passive. One region serves all traffic; the other holds a replica and takes over if the first fails. Simplest to run, and the right starting point for most teams. Choose two cities a few milliseconds apart at the floor, then measure the real round trip between them.
Active–active reads, single writer. Every region serves reads from a local replica; all writes go to one primary. Good for content-heavy sites and APIs where reads dominate. Users get local latency for most requests. Replica reads can be a moment behind, so serve a user's own recent writes from the primary.
Active–active everything. Every region accepts writes. This needs a data model built for it, with conflict resolution or partitioning by user. Powerful, but do not start here unless your application was designed for it.
Steering users to the right region
- DNS-based steering. Return a different address depending on where the resolver is, or on health checks. Easy to start with; failover speed depends on how long resolvers cache your records, so keep TTLs short on the records you will change. Expect a tail of traffic to the old region, because some clients and connection pools keep the old address past the TTL, and run the health checks from outside both regions.
- Anycast. Announce the same /24 from several regions, and each user's network sends them to the region it prefers, usually but not always the nearest. Failover takes as long as withdrawing the route and waiting for the internet to catch up, so automate the withdrawal with health checks. It suits DNS and short HTTP requests better than long sessions, and it needs address space that can be announced from every region. The NexonHost configurator lists "Your own /24" and "Your own /24 + ASN" options; confirm with support that one prefix can be announced from each of your cities before you design around it.
- Application-level routing. A login or API gateway sends each user to their home region. Useful when data residency decides where a user's data lives.
Choosing the cities
Start from the users. List your largest audiences, then pick the city closest to each:
- North-west Europe, London and southern Scandinavia: Netherlands (Amsterdam; the Amsterdam guide has the distances)
- Germany and Central Europe: Germany (Frankfurt; the Frankfurt guide compares it with Amsterdam)
- France and Mediterranean routes: France (Paris and Marseille)
- Italy: Italy (Milan)
- Iberia: Spain (Madrid)
- Ireland and most of Britain: Ireland (Dublin)
- Austria and the Danube: Austria (Vienna)
- Poland, the Baltics, Stockholm and Helsinki: Poland (Warsaw)
- South-east Europe: Romania (Bucharest) and Bulgaria (Sofia)
- North America: USA (Ashburn)
Then work out each pair's floor, the great-circle distance in kilometres divided by 100, or read it from the table if the pair is listed. Treat a pair as a synchronous candidate only when the floor is a few milliseconds, roughly 500 km or less, and then measure between the actual servers: real round trips are always higher than the floor, sometimes several times higher where traffic detours through a hub city. If the measured round trip is above about 10 ms, plan for asynchronous replication.
What multi-region dedicated servers cost
Because seven of the eight builds are sold in every city at the same price, the arithmetic is simple: the price of one server times the number of regions. Two entry Xeon builds, each with 20 cores, 128 GB of RAM and an unmetered 1 Gbps port, cost €258 a month. Three cost €387. Those totals assume each server at €129, with the store's preselected €5 backup option set to None. If you steer with anycast, add the IP option: "Your own /24 + ASN" is €200 a month plus €100 setup on each server it is ordered with.
Unmetered ports mean replication traffic between regions does not show up as a bandwidth bill; on metered plans it eats into a transfer quota or is billed per gigabyte or at the 95th percentile. Unless your provider offers a private link between cities, that traffic crosses the public internet, so encrypt it with TLS in the replication settings or a WireGuard or IPsec tunnel between sites.
The real extra cost is operational: two places to patch, monitor and test failover. Test it on a schedule. A failover that has never been exercised is a theory. How to migrate a server without downtime covers the cut-over techniques that a failover reuses.
Where to start
Multi-region dedicated servers from NexonHost start at €129 a month per region, with seven of the eight builds, the same unmetered ports and the same DDoS mitigation in each of twelve cities across Europe and the US; the EPYC 7702 is available only in Bucharest. Every build is on the dedicated servers page; you choose the city in the store's Location menu when you configure each server, or start from one of the country pages above to have it preselected.
Prices are as of 2 October 2026. Check the product pages for current figures.
Sources
- NexonHost store configurator: builds, locations and prices for the Xeon and EPYC builds, and the preselected backup option. Retrieved 2 October 2026.
- NexonHost store configurator, Additional IPs: "Your own /24" (€100 setup) and "Your own /24 + ASN" (€200 a month + €100 setup). Retrieved 2 October 2026.
- Computed: great-circle distances from city-centre coordinates; round-trip floor = distance ÷ 100 km/ms (light in fibre at ~200 km/ms, both directions); serial commits per second ≈ 1,000 ms ÷ round-trip floor (1,000 ÷ 3.6 ≈ 278; 1,000 ÷ 65.5 ≈ 15); 2 × €129 = €258, 3 × €129 = €387.
