Choosing a Cloud Region: Latency, Residency and the Cost of Getting It Wrong

Region choice looks trivial at provisioning time and is one of the few cloud decisions that is genuinely painful to reverse. Data has gravity, IP addresses do not move, and a live migration between regions is a project rather than a setting.

Four things vary by region, and they do not vary together.

1. Latency

Round-trip time is bounded by physics. Light in fibre travels roughly 200,000 km per second, and real paths are not straight. London to New York is about 70–80 ms round trip in practice; London to Sydney is nearer 250 ms.

What matters is that latency multiplies. A page making twenty sequential requests at 100 ms each spends two seconds waiting regardless of how fast your servers are. The fixes, in order of effectiveness:

1. Reduce round trips. Batch requests, inline critical resources, avoid chatty request chains.
2. Put static assets on a CDN. This is the single highest-value change for a distributed audience, and it is cheap.
3. Place the origin near the majority of users, not near you.
4. Only then consider multiple regions, which multiplies operational complexity.

Most teams reach for step four when steps one to three are untouched.

2. Price

The same instance costs measurably different amounts in different regions — the spread between the cheapest and most expensive regions of a single provider commonly reaches 20–40%.

The cheapest regions are usually the oldest and largest. Newer and more remote regions cost more. If latency is not critical — batch processing, CI, internal tooling, backups — deliberately choosing a cheaper region is free money.

Storage and egress rates vary too, and not always in the same direction as compute.

3. Service and capacity availability

Not every service exists in every region, and this is a persistent source of surprise. Newer managed services launch in a handful of regions first. GPU families are unevenly distributed. Some instance types simply never arrive in smaller regions.

Quota is per region as well. An account approved for high capacity in one region starts from zero in another. When evaluating any environment, confirm the region and the quota in it, not one or the other.

4. Data residency

Where data physically sits can be a regulatory requirement, a contractual commitment, or a customer expectation. Three separate questions matter:

• Physical location — which country holds the disks.
• Legal jurisdiction — which legal system governs the operator, which is not the same question.
• Access path — who can technically reach the data, which is answered by encryption and key management rather than geography.

A US-headquartered provider operating in Frankfurt satisfies the first and not necessarily the second. The European providers comparison covers that distinction in detail.

Availability zones

Within a region, most major providers offer multiple availability zones — separate failure domains with independent power and cooling, connected by low-latency links.

Deploying across zones protects against a single facility failure and costs little in latency. On several platforms it does cost money in cross-zone data transfer, which is worth modelling for chatty architectures.

Independent providers often have one facility per location. That is a genuine difference in failure tolerance and should be weighed honestly rather than ignored — though a single well-run facility is still more reliable than most self-hosted alternatives.

A practical selection process

1. Map your users. Where are they actually, by volume?
2. Establish residency constraints. Are any of them contractual or regulatory?
3. Confirm service availability for everything your architecture needs.
4. Check quota in that region for the instance families you need.
5. Compare price across the qualifying regions.
6. Measure real latency from your users' networks before committing.
7. Decide on zones — spread across them if the provider offers them.

Step six is skipped almost universally and takes ten minutes. Real measured latency from a few representative user networks is worth more than any map.

When to use multiple regions

Genuine reasons: a legally mandated residency split; a disaster-recovery requirement that a single region cannot satisfy; a user base so geographically split that no single origin serves both halves acceptably.

Insufficient reasons: it feels more robust; a competitor does it; it might be needed later.

Multi-region multiplies deployment complexity, data consistency problems and cost. It is worth it when a stated requirement demands it, and expensive when adopted speculatively — the same judgement multi-cloud architecture requires.

Frequently asked questions

Can I move a workload between regions later? Yes, but it is a migration: snapshot or replicate data, rebuild infrastructure, cut over DNS, accept downtime or build replication. Plan it as a project.

Does a CDN remove the need to choose well? For static assets, largely. For dynamic requests that hit your origin, no — origin placement still governs.

Is the cheapest region always fine for backups? Usually, provided it satisfies residency requirements and is not the same region as the primary data, which would defeat the purpose.

How do I measure real latency? Test from networks representative of your users, not from your office. Synthetic monitoring from multiple locations is the reliable method.

Provider region footprints differ considerably — the comparison page shows the catalogue side by side.