Choosing a Cloud Region: Latency, Law and Cost

Region is one of the first choices a cloud console asks you to make and one
of the hardest to change afterwards. Instances, volumes and most managed
services are regional, so moving means rebuilding rather than reconfiguring.
Ten minutes of thought here saves a weekend later.

Latency: how much it actually matters

Physical distance sets a floor on round-trip time that no amount of
optimisation removes. Light in fibre is not negotiable, and a connection between
continents carries tens of milliseconds of unavoidable delay each way.

Whether that matters depends entirely on how chatty your application is. A
page that makes one request tolerates distance reasonably well. An application
that makes thirty sequential round trips to render a view multiplies the penalty
by thirty, and the difference between a nearby region and a distant one becomes
the difference between fast and sluggish.

The practical test is simple: find out where your users actually are, then
pick the nearest region to the majority of them. If they are spread across
continents, see the section on multiple regions below.

One thing worth separating out: latency between your own components matters
more than most people expect. An application server and its database in
different regions will feel slow no matter how close either is to the user,
because every query crosses that distance. Keep tightly coupled components in
the same region, ideally the same zone.

Law: where the data is allowed to sit

For some organisations this overrides everything else. Personal data
belonging to people in the EU or UK carries obligations about where it is stored
and transferred, and the simplest way to satisfy them is to keep it inside the
relevant jurisdiction.

Sector rules can be stricter still. Health, financial and public sector work
frequently comes with contractual requirements naming specific countries, and in
those cases the region decision is made for you by the contract rather than by
engineering preference.

If this applies to you, decide it first and treat the remaining criteria as
tie-breakers within the regions that qualify. Providers with a European focus
are covered in the guides to
OVHcloud and
Hetzner, and the
implications are set out in
data residency and GDPR.

Cost: the variation is real

The same instance type costs different amounts in different regions.
Variation reflects local power, property and connectivity costs, and it is large
enough to be worth checking rather than assuming.

Two cautions on optimising for this. First, an estimate built on the cheapest
region is not an estimate of your bill unless you deploy there. Second, choosing
a distant cheap region to save on compute often costs more in cross-region data
transfer than it saves, particularly if your components talk to each other
frequently.

What else differs between regions

Regions are not identical catalogues. Newer services often launch in a
handful of major regions first and arrive elsewhere later, sometimes much later.
Specific instance families, particularly GPU and high-memory types, are
available in fewer places than general purpose ones.

If your plan depends on a particular service or instance family, confirm it
exists in your preferred region before you commit. Discovering that the GPU
instances you need are not available where you built everything else is an
expensive surprise.

Zones within a region

Larger providers subdivide regions into availability zones: separate
facilities, close enough for fast private networking, far enough apart to fail
independently. Spreading across zones is how you survive a single facility
failing.

Two things to know. Traffic between zones may be billed where traffic within
a zone is free. And for a single-server deployment, zones are irrelevant, since
there is nothing to spread. Zone strategy becomes meaningful at the point where
you have redundancy to arrange.

When to use more than one region

Multi-region is genuinely hard. It means handling data replication, deciding
what happens when regions disagree, and accepting cross-region transfer costs
and latency. It is the right answer for a global user base with real latency
requirements, or for disaster recovery obligations that specify geographic
separation.

It is the wrong answer as a default. A single region plus a CDN for static
assets covers the large majority of the benefit for a small fraction of the
complexity, and most applications that think they need multiple regions actually
need a content delivery network and a nearer single region.

A decision order that works

1. Eliminate regions that legal or contractual requirements rule out.
2. Of those remaining, prefer the one nearest the majority of your users.
3. Confirm the services and instance types you need exist there.
4. Compare prices among the qualifying regions and use that as the
   tie-breaker.
5. Keep every component of one application in the same region.