Regions, Availability Zones and Edge Locations

By the end of this lesson you will be able to

• Describe how AWS is built physically: data centres, Availability Zones, Regions, and the edge network in front of them.
• Read a Region code, an Availability Zone name and an AZ ID, and explain why us-east-1a in your account may not be us-east-1a in mine.
• Choose a Region for a new application using compliance, latency, service availability and price, in that order.
• Say whether a service or resource is global, regional or tied to one Availability Zone, and what that means when something breaks.
• Know when Local Zones, Wavelength Zones and Outposts are the answer.
• Design an application that survives the loss of a data centre, an Availability Zone, and even a whole Region.

#Why the shape of AWS matters

In lesson 1.1 you saw that the cloud is somebody else’s computers, rented by the hour. This lesson answers the next question: where are those computers, and how are they arranged?

It matters for three reasons:

1. Failure. Disks die, power cuts happen, a fibre cable gets dug up, a flood reaches a building. AWS is laid out so that each kind of failure stays inside a box of a known size. If you know the boxes, you know where to put the copies of your application.
2. Speed. Light in fibre needs about 5 ms to travel 1,000 km. A server on the other side of the planet adds a couple of hundred milliseconds to every round trip, and no amount of CPU fixes that. Where you run decides how fast your users feel the site is.
3. Law and money. Many countries and industries say where personal or financial data may be stored. And the same server costs a different amount in different places.

AWS’s answer is a hierarchy of four layers:

#Regions

A Region is a physical location in the world where AWS runs a cluster of Availability Zones. In October 2026 AWS lists 39 Regions with 124 Availability Zones, with more announced (Saudi Arabia and Chile among them). The numbers grow every year, so check the global infrastructure page rather than memorising them; the exam never asks for the count.

Not all 39 are open to a normal account:

• An ordinary AWS account can use the 34 commercial Regions.
• AWS GovCloud (US) has two Regions for United States government work, reached only with a separate GovCloud account.
• The two China Regions (Beijing and Ningxia) are run by local partners and need a separate China account.
• The AWS European Sovereign Cloud (first Region in Brandenburg, Germany, since January 2026) is physically and logically separate from the other Regions, for European customers with strict sovereignty rules.

These separate groups are called partitions. Resources, accounts and logins do not cross partitions.

#Region codes

Every Region has a long name and a code. You will type the code all the time:

The pattern is area – direction – number: ap (Asia Pacific), south, 1. The number only counts Regions in that area; ap-south-2 is simply the second one AWS opened in “south Asia Pacific”, not a backup of ap-south-1.

#Default and opt-in Regions

Regions opened after 20 March 2019 are disabled by default in a new account; you must enable them (in the account settings or the Global View console) before you can create anything there. Hong Kong, Hyderabad, Jakarta, Melbourne, Milan, Bahrain, the United Arab Emirates, Tel Aviv, Cape Town and the newest Regions are all opt-in. The 17 older Regions, such as us-east-1, ap-south-1 and ap-southeast-1, are enabled from day one.

This is why a script that loops over “all Regions” sometimes fails with an authorisation error: the Region exists but is not enabled for that account.

#Your data stays in the Region you choose

A Region is also a data boundary. When you put an object in an S3 bucket in eu-central-1, AWS keeps it in that Region. It is copied between the Availability Zones inside the Region for durability, but it leaves the Region only if you (or a service you configure) send it elsewhere: replication to another Region, a backup copy, a user downloading it.

That promise is what makes a Region the right tool for data residency rules such as the European Union’s GDPR or a central bank’s rule that customer data must stay in the country.

#Availability Zones

An Availability Zone is one or more discrete data centres with redundant power, networking and connectivity. The AZs of a Region are:

• physically separate: many kilometres apart, so one flood, fire, storm or grid failure does not hit two of them, yet all within 100 km (60 miles) of each other;
• independent: separate power sources, cooling and network paths;
• connected by high-bandwidth, low-latency, fully redundant private fibre, fast enough for synchronous replication (writing to two AZs before telling the user “saved”), typically with single-digit-millisecond round trips.

A Region has at least three AZs (us-east-1 has six). Each AZ is named after its Region plus a letter: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c.

#AZ names and AZ IDs

Here is a detail that catches out real teams. For the oldest Regions, AWS shuffled the letters per account: your us-east-1a and my us-east-1a may be different physical AZs. AWS did this so that everyone who picked “a” (the first in the list) would not pile into the same building.

To talk about the same physical place across accounts, use the AZ ID, such as use1-az1 or aps1-az2. An AZ ID points to the same physical AZ in every account.

• Shuffled names apply to accounts created before November 2025 in nine early Regions: N. Virginia, N. California, Oregon, Singapore, Sydney, Tokyo, Ireland, São Paulo and GovCloud (US-West). Every Region launched after November 2012 uses the same mapping for everyone, and so do accounts created since November 2025.
• You find the mapping with aws ec2 describe-availability-zones (it shows ZoneName and ZoneId), on the EC2 dashboard, or from inside an instance at placement/availability-zone-id in the metadata service (lesson 4.3).

When does this matter? Whenever two accounts must line up: sharing a subnet with another account, placing an application next to a partner’s database to avoid cross-AZ charges, matching a reserved capacity in one account to servers in another. Always compare AZ IDs, never names.

#How to choose a Region

You will pick a Region for every new application. Ask four questions, in this order, because the first one can rule out every other answer:

1. 1. Compliance: where is the data allowed to live?

   Law, regulators, contracts or the customer’s own policy may say the data must stay in a country or a group of countries. If so, only Regions in that place are candidates, even if another Region is faster or cheaper. This is a hard filter, not a preference.

2. 2. Latency: where are the users?

   Pick the candidate closest to most of your users (network distance, not just map distance). A user in Dhaka typically sees round trips of roughly 30–70 ms to Mumbai, Hyderabad or Singapore, but well over 200 ms to N. Virginia. For a chatty web page that makes dozens of requests, that difference is seconds.

3. 3. Services: is everything you need available there?

   New services and new features do not reach every Region at once; many start in us-east-1 and spread over months. Check the AWS services by Region list for every service and feature you depend on, including instance types (a GPU type may exist in only a few Regions).

4. 4. Price: what does it cost there?

   Prices differ by Region, sometimes by 20–50 % for the same instance. N. Virginia and Ohio are among the cheapest; São Paulo and some newer Regions are among the most expensive. Each service’s pricing page shows the price per Region.

Two smaller factors sometimes break a tie: whether the Region is opt-in (more setup), and how many AZs it has (some designs want more than three).

#Edge locations and the global network

Regions are few and far between: there is no Region in most countries. To get close to users everywhere, AWS also runs points of presence (PoPs) in hundreds of cities: in October 2026, more than 750 PoPs and 15 regional edge caches in over 100 cities.

You do not launch servers in an edge location. You use them through the services that run there. CloudFront itself is covered in Chapter 11; here you only need the idea:

#Getting closer: Local Zones, Wavelength and Outposts

Sometimes even the nearest Region is too far, or the data may not leave a specific building. AWS has three ways to stretch a Region outwards. Each one is attached to a parent Region and is managed from it.

All three extend a VPC from the parent Region. Your instances in a Local Zone use the parent Region’s IAM, its console and its APIs.

#What happens when the link to the parent Region breaks

Local Zones, Wavelength Zones and especially Outposts depend on a network link to their parent Region for the control plane (launching, changing, monitoring). When that link is down:

• instances that are already running keep running, and local traffic keeps flowing;
• you cannot launch, stop or change resources, and services that need the Region (IAM checks for new sessions, CloudWatch delivery) are delayed or unavailable.

So for an Outpost, the service link is treated as critical infrastructure, with redundant connections, and you size the Outpost so it has spare capacity already running.

#Global, regional or zonal: the scope of every service

Every AWS service and every resource lives at one of three scopes. Knowing the scope tells you where it can be used, what a failure takes out, and whether you need a copy elsewhere.

Some details the exam likes:

• S3 looks global in the console and bucket names are unique worldwide (one global namespace), but every bucket is created in one Region and its data stays there.
• An EBS volume can attach only to an instance in the same AZ. To move it, take a snapshot (snapshots are regional) and create a new volume in the other AZ (Chapter 5).
• An AMI is regional; copy it to use it in another Region (lesson 4.3). A VPC is regional; a subnet sits in one AZ (lesson 3.2).
• “Global” services still have a home. Their control plane often runs in us-east-1. That is why a TLS certificate for CloudFront must be requested in us-east-1, and WAF rules for CloudFront are created there. Day-to-day use (signing in, checking permissions, answering DNS) is served everywhere.

#Designing for failure at each level

Now put the pieces together. Each layer of the hierarchy is a failure domain: something that can go wrong as one unit. A good design puts copies in different failure domains.

#Multi-AZ: the normal standard

For anything in production, run in at least two AZs (three is better). This is what the exam calls high availability:

• web and app servers in two or more AZs behind a load balancer, managed by an Auto Scaling group that launches replacements in a healthy AZ (Chapter 6);
• a database with a synchronous standby in a second AZ (Multi-AZ, Chapter 7);
• one NAT gateway per AZ, so losing one AZ does not cut the others off from the internet (lesson 3.4).

A design with one instance or one AZ is never highly available, however large the instance is.

High availability does not mean “never down”. It means that no single failure (a server, a building, an AZ) stops the service, and that recovery is automatic and quick. Nothing in one Region can promise to survive the loss of that Region.

#Static stability: have the capacity before you need it

During a big AZ outage, thousands of customers try to launch replacement servers in the surviving AZs at the same moment, and launching (a control plane action) may be slow or throttled. Running servers and traffic (the data plane) keep working.

So the robust design is statically stable: it already has enough capacity running in the remaining AZs to carry the load if one AZ disappears. With three AZs, run each at no more than about two-thirds of its capacity; with two AZs, each must be able to carry everything. Reserving capacity in each AZ (lesson 4.4) is another way to guarantee it.

#Multi-Region: when one Region is not enough

A second Region costs real money and complexity: double infrastructure, data replication, a plan for which Region is in charge. Use it when:

• the business must survive a Region-wide event (a strict disaster-recovery requirement);
• users are spread over continents and need low latency everywhere;
• data must be kept in several countries, each in its own Region.

The building blocks come later in the course: Route 53 health checks and failover routing (Chapter 8), S3 cross-Region replication (Chapter 10), Aurora Global Database and DynamoDB global tables (Chapters 7 and 15), and disaster-recovery strategies from backup-and-restore to active-active (Chapter 23).

#Data transfer is not free between places

Moving data inside one AZ over private addresses is free. Between AZs of the same Region it typically costs $0.01 per GB in each direction, and between Regions more again (often about $0.02 per GB). Data coming in from the internet is free; data going out to the internet is charged. Multi-AZ is still the right default, but a very chatty design (thousands of small calls back and forth between AZs) can surprise you on the bill. Lesson 1.4 shows how to catch that early.

#Try it yourself

# 1. Regions your account can use right now, and their opt-in status
aws ec2 describe-regions --all-regions \
  --query "Regions[].{Region:RegionName,Status:OptInStatus}" --output table
aws account get-region-opt-status --region-name ap-south-2

# 2. AZ names and AZ IDs in a Region: compare the ZoneId with a colleague’s account
aws ec2 describe-availability-zones --region ap-south-1 \
  --query "AvailabilityZones[].{Name:ZoneName,Id:ZoneId,State:State}" --output table

# 3. Local Zones and Wavelength Zones attached to a Region (opt-in status too)
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones \
  --query "AvailabilityZones[?ZoneType!='availability-zone'].{Name:ZoneName,Type:ZoneType,Group:GroupName,OptIn:OptInStatus}" \
  --output table

# 4. Is a service offered in a Region? (public parameters published by AWS)
aws ssm get-parameters-by-path --region us-east-1 \
  --path /aws/service/global-infrastructure/regions/ap-south-1/services \
  --query "Parameters[].Value" --output text | tr '\t' '\n' | sort | head -40

# 5. Rough latency from your machine to a few Regions (TCP connect time in seconds)
for r in ap-south-1 ap-southeast-1 eu-central-1 us-east-1; do
  printf "%-16s " $r
  curl -o /dev/null -s -w "%{time_connect}\n" https://ec2.$r.amazonaws.com
done

# 6. From inside an EC2 instance: which AZ name and which physical AZ ID am I in?
TOKEN=$(curl -sX PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone-id; echo

Open infrastructure.aws to see every Region, AZ and edge location on a map, and the AWS Health Dashboard in the console to see current events per Region and per service.

#Summary

Key takeaways

• AWS is built in layers: data centres → Availability Zones (one or more data centres, isolated, within 100 km of each other, linked by low-latency fibre) → Regions (at least three AZs) → plus an edge network of 750+ PoPs and 15 regional edge caches.
• In October 2026: 39 Regions, 124 AZs. A normal account sees the 34 commercial Regions; GovCloud (US), China and the European Sovereign Cloud are separate partitions. Regions opened after 20 March 2019 are opt-in.
• Region codes look like ap-south-1; AZ names add a letter (ap-south-1a). In nine early Regions, for accounts created before November 2025, letters are shuffled per account: compare AZ IDs (aps1-az1) across accounts.
• Choose a Region by compliance first, then latency, then service availability, then price. Data stays in the Region you put it in.
• Global: IAM, Route 53, CloudFront, WAF on CloudFront, Global Accelerator, Organizations. Regional: VPC, S3 buckets (global names), AMIs, most services. Zonal: EC2 instances, EBS volumes, subnets, NAT gateways.
• Local Zones (a city without a Region), Wavelength (5G networks) and Outposts (your own building) extend a parent Region; running workloads survive a broken link to it, but management does not.
• Production runs Multi-AZ (that is “high availability”), ideally statically stable; a second Region is for Region-wide disasters, global latency or multi-country data rules. Cross-AZ and cross-Region traffic is charged.

Self-check: Regions, Availability Zones and the edge30 questions