Lesson 3 of 17Intermediate13 min

Regions and Availability

By the end of this lesson

Choose where workloads run, and why location matters legally and technically.

A region is a geographic area where a provider operates datacentres — UK South, West Europe, us-east-1. When you create a resource you pick one, and that choice decides where your data physically sits, how far it is from your users, what it costs and sometimes whether you are allowed to hold it there at all.

Inside most regions there are availability zones: groups of datacentres close enough to each other for fast replication, far enough apart to have separate power and network. A zone can fail without the region failing.

The vocabulary, which is nearly identical across providers:

Region: A named geographic location holding a cluster of datacentres. Each region prices independently and offers a slightly different catalogue of services.
Availability zone: An isolated part of a region with its own power, cooling and network. Two zones in a region are typically a few milliseconds apart, which is close enough to replicate a database synchronously.
Data residency: The requirement that data stays within a named country or legal area. It is a legal constraint on your architecture, not a technical preference, and it sometimes comes with a contract clause naming the region.
Edge location: A smaller site used to cache content close to users. Useful for static files and photos; it does not move your database closer to anyone.

Distance costs time, and the numbers are worth holding onto. Within a region, a call between two of your own services is typically under a millisecond to a few milliseconds. Between neighbouring countries, expect tens of milliseconds each way. Between continents, 100 to 300 milliseconds each way is normal, and no amount of tuning changes it — the limit is physics and network routing, not your code.

That matters most where a single user action causes several round trips. If the mobile app used by field staff makes one request and the employees API makes four database calls, an API in one continent and a database in another turns a fast page into a visibly slow one. Keep chatty components in the same region as each other. Put the region near the users, not near the development team.

How to choose a region, roughly in order of how often each factor decides it:

Legal obligation — if your organisation or your customer's contract requires data to stay in a country, that decides it and the rest of this list is tie-breaking
Where your users are — for field staff working across the UK, a UK or nearby European region beats a cheaper one in another hemisphere
Service availability — newer services reach the largest regions first, and discovering a missing service after you have built around it is painful
Price — the same virtual machine can differ by tens of percent between regions, which matters at scale and is noise for one small service
Where the rest of your system already is — splitting a system across regions for a small saving buys you latency and data transfer charges

Two very different levels of resilience. The gap between them in cost and complexity is much larger than the gap in the diagram most people have in their heads.

	Zone redundancy in one region	Multiple regions
Protects against	One datacentre losing power, network or cooling	An entire region becoming unavailable
How the data is kept in step	Synchronous replication between zones, so no writes are lost	Asynchronous replication, so a failover can lose recent writes
Effort to set up	Often a checkbox or one setting when you create the resource	A second copy of everything, plus traffic routing, plus a tested failover procedure
Ongoing cost	A modest premium on some services	Close to double the infrastructure, plus cross-region data transfer charges
What breaks in practice	Little — it is largely invisible once enabled	The failover you never rehearsed, and the data that was mid-replication
Who needs it	Almost any production service	Services where an hour of regional downtime has a cost that justifies all of the above

Checking what is available where, before you commit

Shell

# Azure — which regions can you use, and which support zones?
az account list-locations --query "[].{name:name, display:displayName}" --output table
az vm list-skus --location uksouth --query "[?name=='Standard_D2s_v5'].locationInfo[0].zones"

# AWS — the same two questions
aws ec2 describe-regions --query "Regions[].RegionName" --output table
aws ec2 describe-availability-zones --region eu-west-2 --output table

Ask these questions before you create anything. Moving a running service between regions is a migration, not a setting — you create new resources, copy data, cut over traffic and then remove the old ones.
The Azure SKU query is the useful one: it tells you whether the specific machine size you want exists in that region with zone support. Not every size is offered in every region.
The AWS availability zone listing shows how many zones the region has. Three is common and is what most zone-redundant designs assume.
Region names are not portable knowledge. Azure uses names like uksouth and westeurope; AWS uses eu-west-2 and us-east-1. They are different labels for the same idea, and you will look them up every time.

Common mistake

Common mistakes when starting out

Accepting whatever region the portal suggested. The default is usually near the provider's largest capacity, not near your users or inside your legal boundary, and it ends up in production because nobody revisited it.

Building multi-region before the service has users. It roughly doubles the infrastructure, doubles the deployment surface, and introduces replication lag as a source of bugs. Zone redundancy in one region handles the failure you are far more likely to see.

Forgetting that backups have a location too. A database in a UK region with backups replicated to another continent may breach the same rule you were careful about for the live data.

Splitting the API and its database across regions to use a cheaper one. Every query now pays the distance twice, and you pay for the data crossing the boundary.

Summary

A region is a geographic cluster of datacentres; availability zones are isolated sites within one region
Region choice is decided first by legal obligation, then by where your users are
Distance is fixed: milliseconds within a region, tens between countries, hundreds between continents
Zone redundancy is cheap and usually worth it; multi-region roughly doubles cost and complexity
Neither zones nor regions protect you from your own bad change — that is what backups are for

Practice

Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.

Think about it

Choose a region for the field staff app

The employees API and its database serve staff working across the United Kingdom. HR has told you employee records must not leave the UK. Your cloud account's default region is in the United States, where compute happens to be cheaper.

Which region do you choose, and what would you need before choosing anything else?

Show solution

A UK region. The residency requirement is a constraint, not a factor to weigh against price, so it decides the choice on its own.

To choose anything else you would need documented agreement from whoever owns that obligation, and it would have to cover backups, logs and any copy used for testing. Logs are the one people miss: an error log containing employee names has left the country just as surely as the database would have.

The latency argument points the same way. Round trips from the UK to a US region add roughly 80 to 100 milliseconds each way, which is noticeable to someone tapping through screens on a phone in a van.

Challenge

Cost the resilience

Write down what a second region would actually require for the employees API: list every component that needs a copy, and every new thing that could go wrong.

Show solution

Components: compute, database with replication, object storage with replication, secret store, log collection, container registry access, and something to route users to the healthy region.

New failure modes: replication lag meaning the second region is behind, a failover that promotes a stale database, configuration drift between the two copies, traffic routing that sends a user to a region their session does not exist in, and a rehearsal that never happens because it is disruptive.

Writing the list is the point of the exercise. Multi-region is not one decision; it is a dozen, each with its own way of failing. Most teams get better value from zone redundancy, tested backups and a rehearsed restore.

Saved in this browser only.