Regions and Availability Zones

From data center to region

A cloud provider's infrastructure is built in layers, each one protecting against a bigger kind of failure:

1. Data center: a building full of servers, storage and network equipment. A fire, a flood or a failed power feed can take out one building.
2. Availability zone: one or more data centers that fail independently of other zones.
3. Region: several zones close enough together for fast links, far enough apart that one local disaster does not hit them all.
4. Edge locations: many small sites near users, mainly for caching and fast network entry.

At the time of writing, AWS lists more than 30 regions, Microsoft Azure more than 60 and Google Cloud around 40, and all three keep adding more. The counts matter less than the pattern, which is the same everywhere.

Availability zones

An availability zone (AZ) is an isolated location within a region, made up of one or more data centers with their own power supply, cooling and network connections. Zones in one region are typically tens of kilometers apart: far enough that a flood, fire or power failure in one should not affect another, close enough that the private fiber links between them add only a millisecond or two of latency.

That low latency is what makes zones useful. A database can copy every write to a standby in another zone synchronously — waiting for confirmation before reporting success — without making the application noticeably slower. Between regions, hundreds or thousands of kilometers apart, that would be too slow, so cross-region copies are usually asynchronous and may lag behind.

Zones are a way to build fault tolerance at data center scale, similar in spirit to how RAID (redundant array of independent disks) survives a failed disk (see RAID). They help only if you actually place copies of your application in more than one zone; the provider does not do that for you unless the service says it is zone-redundant.

$ aws ec2 describe-availability-zones --region eu-central-1 \
    --query "AvailabilityZones[].[ZoneName,ZoneId]" --output text

eu-central-1a	euc1-az2
eu-central-1b	euc1-az3
eu-central-1c	euc1-az1

Regions

A region is a geographic area where a provider runs a group of availability zones (or, in some Azure regions, data centers without zones), connected by a low-latency network. Each region has a name such as eu-central-1 (AWS, Frankfurt), westeurope (Azure, Netherlands) or europe-west4 (Google Cloud, Netherlands).

Regions are deliberately independent. Most resources you create — a virtual machine, a disk, a virtual network — live in exactly one region, and nothing is copied to another region unless you configure it. That independence limits the damage of a failure, and it is also what lets you promise that data stays in one country.

Not every region is identical. New services and instance types often appear in a few large regions first, and some services exist only in some regions. Check the provider's region table before you design around a service.

Region pairs in Azure

Azure pairs many regions with another region in the same geography, usually hundreds of kilometers away — for example North Europe (Ireland) with West Europe (Netherlands). Within a pair, Azure rolls out planned platform updates to one region at a time, prioritizes recovering one region of each pair in a widespread outage, and uses the pair as the default target for geo-redundant storage. Some newer regions have no pair; there you choose a second region yourself. AWS and Google Cloud have no formal pairs: you pick the second region.

Edge locations and CDNs

Regions are few and large. To get closer to users, providers also run many small sites in cities around the world. An edge location (also called a point of presence, PoP) is such a site: it terminates user connections nearby, caches content and forwards the rest over the provider's own backbone network to the region where your application runs. There are hundreds of edge locations, far more than regions.

Content delivery networks

A content delivery network (CDN) uses these edge locations to serve copies of content — images, videos, scripts, downloads, sometimes whole web pages — from the location nearest to each user. The first request for a file goes to the origin (your storage bucket or web server); the edge keeps a copy for a set time (its time to live, TTL) and answers the next users itself.

• Faster: a user in Lisbon gets the image from Lisbon, not from Frankfurt.
• Less load on the origin: most requests never reach it, which also reduces outbound data transfer from the region.
• Protection: the CDN absorbs traffic spikes and many denial-of-service attacks before they reach your servers.

Users usually reach the nearest edge through the Domain Name System (DNS): the CDN's name servers answer with the address of a nearby edge location, or the edges share one anycast address. See DNS: TTL and caching for how cached answers expire. The same trade-off applies to CDN caches: a long TTL means fewer origin requests but slower updates.

Choosing a region

Four questions decide most region choices:

1. Compliance and data residency. Data residency is the requirement that data is stored, and sometimes processed, in a specific country or area. It can come from law, from contracts or from a customer's policy. The General Data Protection Regulation (GDPR) does not strictly require personal data to stay in the European Union (EU), but it restricts transfers outside the European Economic Area, so many European organizations choose EU regions to keep things simple.
2. Latency to users. The closer the region is to most users, the faster every request feels.
3. Service availability. The services and instance types you need must exist in that region.
4. Price. The same instance type or storage can cost noticeably more in one region than in another, and data transfer between regions is billed.

Estimating latency from distance

Light in optical fiber travels at about two thirds of its speed in vacuum: roughly 200,000 km per second, or 200 km per millisecond. Real cables do not follow the shortest path, and routers, queues and the servers add time (see where latency comes from). This script turns those facts into a rough estimate of the round-trip time from Amsterdam to a few region locations. The route factor and overhead are assumptions, so treat the result as an order of magnitude, not a measurement.

import math

FIBER_KM_PER_MS = 200      # light in glass: about 200,000 km/s = 200 km per ms
ROUTE_FACTOR = 1.5         # cables do not follow the shortest path
OVERHEAD_MS = 5            # routers, queues and the servers themselves

def great_circle_km(lat1, lon1, lat2, lon2):
    """Distance over the earth's surface (haversine formula)."""
    r = 6371  # mean earth radius in km
    p1, p2 = math.radians(lat1), math.radians(lat2)
    dp = p2 - p1
    dl = math.radians(lon2 - lon1)
    a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2
    return 2 * r * math.asin(math.sqrt(a))

def estimated_rtt_ms(km):
    one_way = km * ROUTE_FACTOR / FIBER_KM_PER_MS
    return 2 * one_way + OVERHEAD_MS

user = ("Amsterdam", 52.37, 4.90)
regions = [
    ("Frankfurt", 50.11, 8.68),
    ("Dublin", 53.35, -6.26),
    ("Northern Virginia", 38.95, -77.45),
    ("Singapore", 1.35, 103.82),
    ("Sydney", -33.87, 151.21),
]

print(f"Estimated round trip from {user[0]}:")
for name, lat, lon in regions:
    km = great_circle_km(user[1], user[2], lat, lon)
    print(f"  {name:18} {km:6.0f} km  ~{estimated_rtt_ms(km):4.0f} ms")

Estimated round trip from Amsterdam:
  Frankfurt             364 km  ~  10 ms
  Dublin                756 km  ~  16 ms
  Northern Virginia    6212 km  ~  98 ms
  Singapore           10492 km  ~ 162 ms
  Sydney              16643 km  ~ 255 ms

A web page that needs ten sequential round trips to load feels instant from Frankfurt and sluggish from Sydney, and no amount of bandwidth fixes that: only moving the content closer does. That is why global services use a CDN, or run in several regions.

Designing across zones

Services come in three flavors, and the difference decides what survives a zone failure:

• Zonal: the resource lives in one zone you pick. A single virtual machine and its disk are zonal; if that zone fails, they are unavailable until it recovers.
• Zone-redundant: the provider spreads the resource over several zones for you, such as zone-redundant storage or a load balancer that spans all zones.
• Regional or global: the service is managed by the provider across a region or worldwide, such as identity services or DNS.

To make your own application survive a zone failure, combine the two: run identical copies of the zonal parts (the virtual machines, VMs) in at least two zones, and put a zone-redundant load balancer in front of them.

Points that are easy to overlook:

• Capacity after a failure. If three VMs each run at 70% and one zone fails, the remaining two must carry 105% each. Size for the loss of a zone, or let autoscaling add instances in the surviving zones (see Compute).
• State. Copies in several zones only help if they share their data: a database with a standby in another zone, zone-redundant storage, no files kept only on one VM's disk.
• Cost. More instances cost more, and some providers bill data transferred between zones.

When a whole region fails

Region-wide outages are rare but real. They are usually caused not by a disaster hitting every building, but by a software fault or a configuration change in a shared control system — the part of the cloud that creates, scales and routes resources. AWS's us-east-1 region, the oldest and largest, has had several widely noticed incidents, for example in December 2021 and in October 2025, that also affected services in other regions which depended on it.

During such an outage you may find that:

• running resources keep working, but you cannot create or change any;
• every zone in the region is affected at once, so multi-AZ designs do not help;
• your provider's status page and console are slow or unreachable themselves.

Protection against region failure means a second region: backups or replicas copied there, and a tested plan to run the service from it. How much data you may lose and how long recovery may take are business decisions, expressed as the recovery point objective and recovery time objective (see RPO and RTO). The strategies are covered in High Availability, Scaling and Disaster Recovery.

Names across providers