Choosing a data centre location that matches your users

Region selection is usually a dropdown someone accepts the default of, and it quietly determines two things that shape the whole life of the deployment: the minimum latency your users will ever experience, and the legal regime your data sits under.

Neither is easy to change afterwards. Both deserve five minutes of thought.

Latency is physics before it is engineering

Light in fibre travels roughly two thirds the speed of light in vacuum, and network paths are not straight lines. A useful working figure is about one millisecond of round-trip time per hundred kilometres of real path, often more.

London to New York is therefore around seventy to ninety milliseconds round trip on a good path. London to Sydney is well over two hundred and fifty.

That number is a floor. No amount of caching, code optimisation or protocol tuning reduces the time a packet takes to cross an ocean. You can hide it, by moving content closer or by making fewer round trips, but you cannot remove it.

The practical consequence is that an application making several sequential round trips per page becomes visibly slow at distance in a way that is invisible when the server is nearby. A page requiring ten sequential requests costs a hundred milliseconds locally and closer to two and a half seconds from the other side of the world, before any processing.

Where your users actually are

The right region is where the majority of your users are, weighted by how much they matter, not where your company is registered and not where you happen to live.

If you have existing traffic, the answer is in your analytics: look at sessions by country and be honest about the distribution. If you do not have traffic yet, use the market you are actually selling into.

A common and avoidable mistake is choosing a region because it is the provider’s default or the cheapest, and then spending months optimising an application whose latency floor was set on day one.

When one region is not enough

Genuinely global applications need more than one location, but the answer is rarely to replicate everything everywhere. That multiplies cost and introduces data consistency problems that are considerably harder than the latency problem you started with.

The usual progression, in increasing order of complexity:

A CDN in front of a single origin. Static assets and cacheable responses are served from an edge near the user. This solves most of the perceived latency for content-heavy sites at very little architectural cost, and it should always be the first step.

Read replicas near users, writes to one region. Most applications read far more than they write. Serving reads locally and accepting the cross-region latency on writes captures a large share of the benefit with manageable complexity.

Full multi-region active-active. Every region serves reads and writes. This is genuinely hard: conflict resolution, replication lag and split-brain scenarios all become your problem. Reach for it when you have a demonstrated need, not in anticipation of one.

Most applications should stop at the first or second step. The third is a project, not a configuration change.

The legal side

Where data physically sits determines which laws apply to it, and this is not something you can contract around.

Data residency requirements may oblige you to keep certain categories of data inside a jurisdiction. This is common in healthcare, finance and public sector work, and increasingly in general privacy regulation.

Cross-border transfer rules govern moving personal data between jurisdictions, and the legal basis for those transfers has been repeatedly litigated. If your users are in the EU, where their data rests is a compliance question rather than a technical preference.

Government access regimes differ by country and, for some organisations, by the nationality of the provider rather than the location of the data centre. Whether that matters to you depends on your sector and your customers’ expectations.

The practical advice is simple: if you handle personal data for users in a regulated jurisdiction, choose a region in that jurisdiction unless someone qualified has told you otherwise. It is much cheaper than migrating later under compliance pressure.

Other things that vary by region

Price. The same instance frequently costs meaningfully more in some regions than others. Choosing a distant cheap region to save a small percentage while adding a hundred milliseconds to every request is a poor trade.

Service availability. Not every service exists in every region, and new services often arrive in a few regions first.

Capacity. Popular regions occasionally run short of specific instance types. Less popular regions in the same geography are frequently a better experience.

Deciding, briefly

Ask three questions in order. Where are the users who matter? Are there legal constraints on where their data may rest? Does the region I am considering have the services and capacity I need?

Answer those, pick the closest region that satisfies all three, and put a CDN in front. That covers the overwhelming majority of cases correctly.

For a view of how the providers differ on the points above, the cloud account catalogue lays out their respective strengths and configurations.

For the vendor’s own reference on the services involved here, see the Kamatera support library.

Independent sizing is easier to understand once you have set it yourself. Our Kamatera accounts come in two configurations, and the cloud account catalogue compares the other nine providers.

Questions people ask