Choosing a region feels like a dropdown. It is closer to a foundation: moving a running system between regions means migrating data, re-provisioning infrastructure and coordinating a cutover. Get it right the first time.
1. Latency to your users
Physics is not negotiable. A user in Singapore talking to a server in Virginia pays the round trip on every request, and for interactive applications this dominates every optimisation you might make in code.
Pick the region closest to where your users actually are, not where your team sits. If users are spread, put the origin near the largest concentration and use a CDN for static assets.
2. Data residency and jurisdiction
Two separate things:
- Residency is where data physically sits. Every large provider offers regions in most jurisdictions.
- Jurisdiction is whose law reaches the provider. A provider headquartered outside your region may be subject to requests from its home jurisdiction regardless of where data sits.
If jurisdiction is your concern, a European provider is a different proposition from a European region of a non-European provider. See European data residency.
3. Service availability
This is the one people forget. Not every service exists in every region, and newer capabilities land in flagship regions first. GPU and accelerator availability varies most of all.
Before committing, confirm that every service you plan to use exists in the region, and check quota for accelerators specifically. Choosing a region then discovering the GPU family you need is unavailable is an avoidable and expensive surprise.
4. Cost
Prices differ between regions for the same resources, sometimes substantially. Egress pricing also varies. For a large steady workload, region choice can move the bill meaningfully.
Do not let this override latency. Saving on compute while adding 150ms to every request is a bad trade for an interactive product.
The traps
- Resources are regional, accounts are not. It is easy to leave something running in a region you forgot about, quietly billing. Audit every region.
- Quotas are per region. Headroom in one does nothing in another. See service quotas.
- Cross-region traffic is billed and slower than you expect.
- Backups may not be where you think. Check explicitly.
- Some settings are permanent. Oracle Cloud’s home region cannot be changed after the tenancy is created.
Availability zones
Within a region, zones are separate failure domains. Spreading across zones protects against a single facility failure and is usually the highest-value resilience step available. Note that cross-zone traffic is often billable, so place components deliberately.
A short method
- Identify where your users are.
- Identify any legal constraint on where data may sit.
- Shortlist regions satisfying both.
- Confirm every needed service and quota exists there.
- Compare price across the shortlist.
- Deploy across at least two zones within the chosen region.
Comparing providers as well as regions? Start at the comparison hub.
Common questions
Can I move regions later?
Yes, but it is a migration, not a setting.
Should I run multi-region from the start?
Usually not. Multi-zone first. Multi-region adds significant complexity and is justified by specific requirements.
Does a CDN remove the need to choose well?
It helps for static assets. Dynamic requests still reach your origin.