Choosing a cloud region: latency, residency and the price you did not expect

Choosing a cloud region is one of the few decisions that is genuinely hard to reverse. Everything else can be resized, rebuilt or migrated within a week. Moving a running system between regions means copying data, changing addresses, re establishing every integration and accepting a maintenance window.

It is worth an hour of thought. Four factors decide it.

1. Where your users are

Latency is physics. Light in fibre travels roughly two thirds the speed of light in vacuum, and a round trip between London and Sydney will not go below about 250 milliseconds no matter what you buy.

For an application with several sequential requests per page, that difference is visible. Pick the region closest to the majority of your users, and use a CDN for static assets so the remainder are served from an edge location rather than the origin.

If your users are genuinely spread across continents, a single region plus a CDN is still usually the right first answer. Multi region application deployment is expensive and complicated, and most teams that build it discover the CDN would have solved ninety percent of the problem.

2. Where your data is allowed to be

For some workloads this overrides everything else. Personal data belonging to EU residents, health records, financial records and government data all carry residency requirements that constrain the region, and sometimes the provider’s legal domicile as well.

Two things to check rather than assume:

• Where backups go. A region compliant service with cross region replication switched on may be moving data somewhere it should not.
• Where managed services actually process. Some services have a control plane in a different region from the data plane. If that matters to you, confirm it rather than inferring it.

This is also why European operators such as Hetzner and OVHcloud come up in procurement conversations. Legal domicile is sometimes part of the requirement, not just the physical location of the disk.

3. What is actually available there

Regions are not uniform. New services launch in a handful of regions first and expand over months or years. Instance families vary. GPU availability varies enormously. Some regions have three availability zones, some have more, and a few have fewer.

Before committing, check that the specific services, instance types and accelerator hardware you need exist in that region. Discovering that your chosen region lacks the GPU family your model needs is a bad week.

4. Price

The same instance type can differ by twenty percent or more between regions of the same provider, driven by power costs, land costs, taxes and local demand. Egress rates differ too, and in some regions considerably.

Price should be the tiebreaker, not the deciding factor. Saving fifteen percent on compute while adding a hundred milliseconds to every request is a bad trade for a user facing service. For batch work with no latency sensitivity, it is a perfectly good one.

Availability zones are the resilience answer

Within a region, availability zones are physically separate facilities with independent power and cooling, connected by low latency links. Spreading across zones protects against the failure of a single facility at a fraction of the cost and complexity of a multi region design.

Almost every availability requirement short of surviving a whole region outage is met by using zones properly. Note that cross zone traffic is generally billed, which is covered in data transfer costs.

The cloud region decisions that lock in

• Oracle Cloud home region. Set at signup, permanent, and it holds your identity resources. This one deserves genuine thought.
• Data gravity. Once several terabytes live in a region, moving them costs both egress charges and time.
• Addresses and DNS. Static addresses are regional. Anything hard coded against them has to change.
• Compliance attestations. Region specific certifications may need re establishing elsewhere.

A short checklist

1. Map your users. Pick the closest region with the services you need.
2. Confirm residency requirements, including backups and replication targets.
3. Verify the instance families and accelerators you need are available there.
4. Check quotas in that region, not the one you tested in.
5. Compare price as a tiebreaker between otherwise equal options.
6. Use multiple availability zones. Use multiple regions only when you have a stated reason.

If a move turns out to be necessary anyway, moving a workload between providers covers the same problem at a larger scale.