How to Choose a Cloud Region: Latency, Data Residency and Price

Choose the region closest to most of your users that also satisfies whatever legal obligation you have about where data sits, and only then compare prices. That order is not negotiable, because latency and residency are properties you cannot buy your way out of, while a price difference of 10% is something you can absorb. The one exception is South America and Africa, where the price gap is large enough to change the decision.

Start with where the people are

Distance costs milliseconds and nothing you deploy will get them back. Microsoft publishes median round-trip latency between Azure regions, measured continuously on its own backbone, and the numbers are the most useful public reference for this decision even if you are building on a different provider. The figures below are from the dataset dated 30 July 2026.

Translate those numbers into your own application before judging them. A page that makes one API call tolerates 150 ms without anyone noticing. A page that makes twelve sequential calls multiplies the figure, and at 169 ms per round trip that is two seconds of pure waiting. The fix is either fewer round trips or a closer region, and the second is usually cheaper to implement.

What the law says about where data sits

Residency rules are the constraint that overrides latency and price. They come from three directions: sector regulation, contracts with your own customers, and data protection law. The third is the one most small businesses meet first.

Under the GDPR, personal data can leave the European Economic Area only with a lawful transfer mechanism in place. That is a solvable problem rather than a prohibition, but the paperwork is real, and the simplest way to avoid the argument is to keep EU personal data in an EU region. Several of our clients took that route purely to shorten their security questionnaires.

Sovereignty went a step further in 2026. AWS opened the AWS European Sovereign Cloud on 15 January 2026, with its first region in Brandenburg, Germany, operating independently from existing AWS regions and located entirely within the EU. Microsoft runs its EU Data Boundary along similar lines. If you sell to European public sector bodies or regulated industries, these options are now worth evaluating rather than filing away as enterprise-only.

Three practical checks before you commit to a region:

1. Write down which of your data is personal data, and whose. Everything else is easier.
2. Check your largest customer contracts for a residency clause. They often contain one nobody remembered agreeing to.
3. Confirm the provider’s region list actually includes the country your obligation names, rather than a neighbouring one.

Then, and only then, look at price

Now the money. Cloud prices are set per region and the differences are larger than most teams expect. These are AWS’s own published S3 Standard rates for the first 50 TB a month, from the price list dated 28 September 2026.

Storage in São Paulo costs 76% more per gigabyte than in Ireland, and egress from Cape Town costs 71% more than from Frankfurt. For a small workload those percentages are small absolute numbers and should not override latency. For anything storage-heavy or download-heavy they compound into a real line on the invoice, and the egress side in particular is worth reading about separately in our piece on cloud egress fees.

What a region actually contains

A region is not a building. AWS documents 34 regions and 105 availability zones available to a standard account, with every region containing at least three zones. A zone is one or more discrete data centres with independent power, cooling and networking, close enough for low-latency replication and far enough apart that one flood does not take out two.

That structure is why the sensible first resilience step is multi-zone rather than multi-region. Running a database across two zones inside one region costs you a small amount of cross-zone traffic and buys protection against a single facility failing. Running it across two regions costs you architectural complexity, 85 ms or more of latency, and a set of consistency problems that take months to get right.

Services are not evenly distributed

New services do not launch everywhere at once, and some never arrive in smaller regions. This bites hardest when a managed service you planned around turns out to be unavailable where you deployed, usually two weeks before launch.

• Check the provider’s region availability table for every managed service in your design, not just compute and storage.
• Check whether the specific instance families you plan to commit to are offered there. Newer generations reach large regions first.
• Check quota defaults. Smaller regions sometimes start with lower limits, which turns into a support ticket on launch day.
• Check whether the region is opt-in. Some AWS regions have to be enabled on the account before anything can be created in them.

Google Cloud publishes its region and zone list with service availability per location, and both AWS and Azure do the same. Reading those tables for an hour before you choose is the cheapest insurance in this article. If you are still deciding between providers rather than regions, our provider comparison is the better starting point.

Multi-region costs more than you think

The multi-region conversation usually starts with resilience and ends with a bill. Three costs appear immediately. Inter-region traffic is charged, at $0.02 per GB out of N. Virginia. Storage is duplicated, so you pay twice for the same data. And every stateful service needs a replication story, which is engineering time rather than a configuration setting.

There is a fourth cost nobody budgets for: testing. A second region that has never served live traffic is a hypothesis, not a disaster recovery plan. If you are not prepared to fail over to it deliberately at least twice a year, the money is buying reassurance rather than resilience. For most small businesses, a well-tested backup and restore process in one region beats an untested second region, and costs a tenth as much.

A decision order that holds up

Run the decision in this order and it holds up under scrutiny later, including from an auditor:

1. Map your users. Which continent holds most of them, by revenue rather than by headcount?
2. List your legal constraints. Personal data, contractual residency clauses, sector rules.
3. Shortlist two regions that satisfy both, ideally in the same geography so a later move is short.
4. Check service and instance availability for your actual design in both.
5. Compare price last, including storage, egress and the instance families you intend to commit to.
6. Write down why you chose it. In two years somebody will ask, and the answer should not be guesswork.

If any of the underlying vocabulary is new, the introduction to cloud technology and our guide to service models cover the ground this article assumes.

Eudora Technology delivers cloud work remotely for clients across Europe, the Middle East, Asia, Africa and the Americas, which means region selection is a conversation we have most weeks. Our cloud solutions page sets out how we approach it.

If you are about to pick a region and want the latency, residency and price arithmetic done properly before you commit, we can work through it with you. Get in touch with Eudora Technology to talk about your project.