Regions, Availability Zones and Edge Locations
Cloud providers divide the world into regions, regions into availability zones, and push content to edge locations. Choosing correctly affects latency, cost, compliance and resilience.
Concept
Cloud capacity is not one enormous computer. It is organised into a hierarchy, and every architecture decision in later modules refers to it.
| Level | What it is | Roughly how many |
|---|---|---|
| Region | A geographic area containing several isolated data centre groups | Tens per provider |
| Availability Zone (AZ) | One or more data centres inside a region with independent power, cooling and networking | Two to six per region |
| Data centre | An individual building full of racks | One or more per zone |
| Edge location | A small site near users that caches content and terminates connections | Hundreds per provider |
Architecture
REGION (for example, a region in southern India)
|
+-- Availability Zone A ---- independent power, cooling, network
| +-- data centre
+-- Availability Zone B ---- independent power, cooling, network
| +-- data centre
+-- Availability Zone C ---- independent power, cooling, network
+-- data centre
Zones are kilometres apart: far enough that one flood, fire or
power event does not take two, close enough that the link between
them is fast - typically low single digit milliseconds.
EDGE LOCATIONS dozens of cities, close to users, caching content
and terminating TLS near the visitorThat distance trade off is the whole design. Zones are separate enough to fail independently, and near enough to replicate a database synchronously between them.
Why it is used
- Zone redundancy is the cheapest real resilience you can buy. Spreading instances across two zones survives a data centre failure with no application change.
- Region choice controls latency. Distance is round trip time, and no amount of tuning removes it.
- Region choice controls compliance. Data residency rules are enforced by where the region physically is.
- Edge locations shorten the first hop. Static content and TLS handshakes are served near the user, even when the application is far away.
Important terminology
| Term | Meaning |
|---|---|
| Region code | The identifier used in commands and endpoints, such as YOUR_REGION in these examples. |
| Multi AZ | Resources deployed into more than one zone in one region. The normal production baseline. |
| Multi region | Resources in more than one region. Used for disaster recovery or global latency. |
| Cross zone traffic | Traffic between zones. Usually charged, and a real line on the bill. |
| Regional service | A service that is already spread across zones for you, such as object storage. |
| Zonal service | A service that lives in one zone, such as a single virtual machine or a disk volume. |
| Point of presence | Another name for an edge location. |
| Data residency | A legal requirement that data stays within a jurisdiction. |
How to choose a region
- Compliance first. If the law requires the data to stay in a country, the list is already short. This overrides everything below.
- Latency to your users. Measure it. Do not assume the nearest region on a map is the fastest by network path.
- Service availability. Newer services do not launch everywhere at once. Confirm the ones you need exist there.
- Cost. Prices differ measurably between regions for identical resources.
- Zone count. Three zones give better failure options than two.
Commands
# List the regions available to your account
aws ec2 describe-regions --query "Regions[].RegionName" --output table
# List the availability zones inside one region
aws ec2 describe-availability-zones --region YOUR_REGION --query "AvailabilityZones[].[ZoneName,ZoneId,State]" --output table
# Measure round trip time to a regional endpoint
ping -c 5 YOUR_REGIONAL_ENDPOINT
# Compare connection setup time between two endpoints
curl -s -o /dev/null -w "connect=%{time_connect} total=%{time_total}" https://YOUR_ENDPOINT_A
curl -s -o /dev/null -w "connect=%{time_connect} total=%{time_total}" https://YOUR_ENDPOINT_B
# See whether a response came from a cache near you
curl -sI https://YOUR_DOMAIN | grep -i -E "x-cache|age|server"Command options worth knowing
| Option | Effect |
|---|---|
--query "Regions[].RegionName" | Extracts just the names from a verbose response. |
ZoneId versus ZoneName | Zone names are shuffled per account, so the same name is not the same physical zone for two accounts. ZoneId is the stable identifier. |
ping -c 5 | Five probes then stop, rather than running until interrupted. |
curl -w "%{time_connect}" | TCP setup time, which is dominated by distance and is the cleanest latency signal. |
The zone name shuffle catches people out. If two teams both deploy to zone "a", they may be in different physical zones. CompareZoneId, notZoneName, when this matters.
Hands on lab
- List the zones in two different regions and note how many each has.
- Pick three public endpoints you believe are in different parts of the world.
- Measure
time_connectto each, three times, and take the lowest value for each. - Rank them by latency and compare that ranking to a map. Network paths do not follow straight lines.
- Run the header check on a site you know uses a CDN and look for a cache hit indicator.
- Write down which region you would choose for users in your city, and state your reason in one sentence.
Expected output
$ aws ec2 describe-availability-zones --region YOUR_REGION --output table
--------------------------------------------
| DescribeAvailabilityZones |
+---------------+--------------+------------+
| YOUR_REGION-1a | use1-az4 | available |
| YOUR_REGION-1b | use1-az2 | available |
| YOUR_REGION-1c | use1-az6 | available |
+---------------+--------------+------------+
$ curl -s -o /dev/null -w "connect=%{time_connect}" https://near.example
connect=0.021
$ curl -s -o /dev/null -w "connect=%{time_connect}" https://far.example
connect=0.198
Reading: roughly 180 ms of extra round trip is distance.
Nothing in your application configuration will remove it.Common mistakes
- Deploying everything into one zone. It works perfectly until the day it does not, and then nothing is left.
- Assuming zone names match across accounts. They do not. Use zone ids.
- Forgetting cross zone data transfer charges. A chatty application spread across zones can pay noticeably for the privilege.
- Choosing a region by price alone. A cheap region far from your users trades a small saving for a permanent latency penalty.
- Assuming every service exists in every region. Check before designing around one.
- Believing an edge location can make a slow application fast. Edges cache content; they do not speed up your database queries.
Troubleshooting
| Problem | Possible causes | Commands to diagnose | Fix | Prevention |
|---|---|---|---|---|
| Application slow for one group of users | Users far from the chosen region; no edge caching | curl -w connect time from that location; check cache headers | Add a CDN; consider a closer region or a read replica | Measure latency from real user locations before launch |
| Zone failure took the whole service down | All resources in one zone; database with no standby | List resources grouped by zone | Spread across at least two zones; enable multi AZ on the database | Make multi AZ the default in your infrastructure code |
| Unexpected data transfer charges | Cross zone or cross region chatter | Break the bill down by transfer type; map which components talk across zones | Co-locate chatty components; cache; batch calls | Review traffic paths in design review |
| Cannot create a resource in a region | Service not offered there; account limit | Read the exact error; check service availability and quotas | Choose a supported region or request a limit increase | Confirm service availability during design |
Security considerations
- Region choice is a compliance control. Confirm data residency requirements before the first resource exists, because moving data later is slow and expensive.
- Audit every region, not only the ones you use. Resources created in an unused region are easy to miss and are a classic hiding place for unauthorised compute.
- Traffic between regions crosses networks you do not control. Encrypt it in transit, always.
- Keep at least one backup copy in a different region so a regional event does not take the data and its only backup together.
Best practices
- Deploy production across at least two availability zones by default.
- Choose the region on compliance, then measured latency, then service availability, then cost.
- Use zone ids when zone identity actually matters across accounts.
- Put static content behind an edge cache and keep dynamic requests short.
- Restrict which regions can be used, so nothing appears where nobody is watching.
- Keep components that talk to each other constantly in the same zone, and keep the redundant copy in another.
Interview questions
- What is the difference between a region, an availability zone and an edge location?
- Why are availability zones physically separated but close together?
- What are the four factors you would weigh when choosing a region, and which one overrides the rest?
- Why can zone name "a" mean different physical zones in two accounts?
- When does a multi region design become justified, given it costs far more than multi AZ?
Mini assignment
For an application serving users in two countries with a legal requirement that customer records stay in one of them, write a half page region plan. State the primary region and why, the number of zones you will use, where the disaster recovery copy lives, whether you will use an edge cache and for what, and one cost you expect this design to add.
Conclusion
Regions decide latency and legality, availability zones decide whether one data centre failure matters, and edge locations shorten the last mile for content. Two zones by default, and a deliberate region choice, cover most of what production needs.