Region is the one deployment decision that is expensive to reverse. Instances resize, databases migrate, but moving a production system to another continent is a project. Yet most teams pick a region in ten seconds from a dropdown. This article offers a method built on three questions, where users are, where data is allowed to be, and where the second copy lives, and shows how it plays out on three providers with very different footprints: AWS, Hetzner and Tencent Cloud.
Question one: where are the users?
Latency is dominated by distance and by the number of network hops, not by the provider’s brand. A region on the same continent as your users, ideally in the same part of it, is the single biggest improvement you can make. For an API called from a browser, round trips compound: a page that makes several sequential requests feels the distance several times over.
Measure rather than guess. Before committing, stand up a small instance in each candidate region and time requests from the locations that matter, including mobile networks if that is how users arrive. If users are spread across continents, accept that one region will serve some of them poorly and decide whether a second region or a content delivery network for static assets closes the gap.
Question two: where is the data allowed to live?
Residency is a legal question and it overrides latency. Some data must stay in a jurisdiction because of regulation, a customer contract or a processing agreement. Decide this per data category, not per application: user records may need to stay in the EU while anonymised analytics can go anywhere.
Provider footprints shape the answer. Hetzner’s data centres are in Germany and Finland with additional presence in the United States and Singapore, which makes European residency the natural choice and other regions an option. Scaleway keeps every region inside the EU. Tencent Cloud and Alibaba Cloud have regions in mainland China, where public-facing hosting involves local regulatory steps, as well as international regions across Asia-Pacific, Europe, the Americas and the Middle East. The European options are compared in European data residency cloud providers.
Question three: where does the second copy go?
Redundancy has two levels. Within a region, most large providers offer multiple availability zones, independent facilities close enough for synchronous replication; AWS regions are organised this way, and IBM Cloud and Scaleway use multi-zone designs too. Across regions, you protect against a whole-region event at the cost of asynchronous replication and higher complexity.
Choose the second location by the same residency rules as the first. A backup copied to a region in another jurisdiction is a residency decision, whether or not you intended it. For most small systems, two zones in one region plus off-site backups in a compliant location is the right amount of redundancy; a second active region is a later step that needs its own justification.
Practical constraints that override the ideal
- Service availability: not every service or instance family exists in every region. GPU capacity and newer managed services often launch in a few regions first.
- Quotas: on hyperscalers, limits such as vCPU quotas are set per region, so an account approved in one region may start from defaults in another.
- Price: the same instance can carry different rates in different regions; check the published price for the region you intend, not the headline.
- Dependencies: if your database, payment provider or identity service lives somewhere specific, put latency-sensitive components near it.
Worked examples
| Situation | Reasonable choice | Why |
|---|---|---|
| SaaS for German and Austrian companies, EU residency required | Hetzner in Germany, second zone in Finland for backups | Local latency, EU jurisdiction, low cost |
| Consumer app with users mainly in South-East Asia and China | Tencent Cloud in an Asia-Pacific region first; mainland region once compliance work is done | Proximity, staged regulatory effort |
| Global B2B API with US and EU customers | AWS in one US and one EU region, static assets on a CDN | Multi-zone in each region, broad service coverage |
Write the decision down
Record the region, the reasons, the residency rule for each data category and the location of backups in your infrastructure repository. Region choice is rarely revisited, so the note is what stops a future engineer from copying a backup somewhere it should not go. To see every provider’s footprint in one place, use all cloud providers at a glance, and for account-level questions the general section of the Cloud FAQ.
