AWS global infrastructure: Regions, Availability Zones, Local Zones, Wavelength Zones, edge locations and Outposts

By Ravindra Bagale, trainer · LinkedIn · Last updated: 8 October 2026

1. AWS global infrastructure: the six building blocks

Why. Your website must be close to its users, must keep running when a building has a problem, and sometimes must stay inside one country or one company's building. One giant data center cannot do all of this. So AWS builds different kinds of places, each for one job.

What. On the board we wrote six building blocks:

1. Regions: big areas (like Mumbai) where AWS keeps its main data centers.
2. Availability Zones (AZs): separate groups of data centers inside one Region.
3. Local Zones: small AWS sites inside big cities, close to users.
4. Wavelength Zones: AWS servers placed inside a telecom company's network, close to mobile users.
5. Edge locations: small AWS sites in many cities that keep copies of your files (this is the CDN, Amazon CloudFront).
6. Outposts: AWS hardware installed inside your own company's building.

How big is it today? These are AWS's own published numbers. They grow every year, so always check the live AWS Global Infrastructure page:

2. Region, Availability Zone and data center

Why. Before you launch a server, AWS asks you two questions: which Region, and which AZ. So you must know exactly what each word means.

What. Three levels, from big to small:

1. A data center is one building full of servers, with its own power, cooling and network.
2. An Availability Zone (AZ) is one or more data centers, with redundant power, networking and connectivity.
3. A Region is a geographic area with several AZs. AWS designs every Region with at least three AZs.

Where are the AZs of one Region?

1. All AZs of one Region are in the same metro area.
2. They are separated by a meaningful distance, many kilometres, so one local problem does not hit all of them.
3. But all of them are within about 100 km (60 miles) of each other, so they can talk very fast.
4. They are joined by AWS's own redundant, high-bandwidth, low-latency fibre, not by satellite or mobile towers. Traffic between AZs is encrypted.

India example (worked numbers).

1. Mumbai Region: 3 AZs, and each AZ has at least 1 data center, so at least 3 data centers.
2. Hyderabad Region: 3 AZs, so at least 3 data centers.
3. Total in India: 3 + 3 = 6 AZs in 2 Regions.
4. All three Mumbai AZs are in the Mumbai area. All three Hyderabad AZs are in the Hyderabad area.
5. AWS does not publish the exact address or the exact number of buildings. That is for security.

3. Why one AZ can be more than one data center: the land story

Why. Students ask: if an AZ is "a data center", why does AWS say "one or more data centers"? The answer is land.

What. The board story (suppose numbers):

1. Suppose one big data center needs 50 acres of land.
2. In one part of the metro, AWS finds one 50-acre plot. It builds one data center there. That AZ = 1 data center.
3. In a crowded part of the metro, no single 50-acre plot is free. AWS finds two plots of 25 acres each, close to each other.
4. It builds two smaller data centers, and groups both under one AZ name.
5. Total land is the same: 25 + 25 = 50 acres. Capacity is about the same. Only the number of buildings changed.
6. For you, nothing changes. You pick the AZ, for example ap-south-1b. AWS decides which building inside that AZ runs your server.

Worked example. Suppose the Mumbai Region looks like this:

All three AZs, and all four buildings, are still inside the Mumbai metro area. These acre numbers are only to learn with; AWS does not publish them.

4. Disasters, and why you run servers in at least two AZs

Why. A data center is a building. A fire, flood, earthquake or long power failure can take one building down. If your only server is in that building, your website is down.

What. Because AZs are separate, a disaster in one AZ normally does not touch the others. So you spread your servers across at least two AZs, and put a load balancer in front that checks their health.

How failover works (board arrows):

1. Users send requests to the load balancer.
2. The load balancer sends some requests to servers in AZ a and some to servers in AZ b.
3. Suppose a fire hits AZ a. Its servers stop answering.
4. The load balancer's health checks fail for those servers.
5. After a few failed checks (you choose how often it checks, for example every 10 or 30 seconds), it stops sending requests to AZ a and sends everything to AZ b.
6. Users keep using the website. Some may see a slow request or a retry, but the site stays up.

Worked examples: how much capacity is left?

What AWS promises (EC2 SLA). AWS's service level agreement for EC2 shows the same idea in numbers:

1. A single EC2 instance: 99.5% monthly uptime commitment.
2. EC2 running across two or more AZs in a Region: 99.99% monthly uptime commitment.
3. A 30-day month has 30 × 24 × 60 = 43,200 minutes.
4. 99.5% allows 43,200 × 0.005 = 216 minutes (3 hours 36 minutes) of downtime in a month.
5. 99.99% allows 43,200 × 0.0001 = 4.32 minutes in a month.
6. Same servers, just spread across AZs, and the promise is 50 times stronger.

5. Why Regions are isolated from each other

Why. If something goes wrong in one Region, it should not spread to the whole world, like a disease kept inside one area.

What.

1. Every Region is physically separate and independent of the other Regions.
2. A problem in the Mumbai Region stays in the Mumbai Region. Singapore, Tokyo and the rest keep running.
3. Your data stays in the Region you chose. AWS does not copy it to another Region on its own.
4. Regions are still connected through the AWS global network, so you can choose to copy data between them (for example, replicate a database or an S3 bucket).

Worked example.

1. Website A runs only in Mumbai. If the whole Mumbai Region has a serious problem, website A is down.
2. Website B runs in Mumbai, and keeps a copy ready in Singapore (ap-southeast-1).
3. If Mumbai has a problem, website B switches its users to Singapore.
4. Website B costs more (two copies), but survives even a whole-Region problem. You decide if your business needs that.

6. Restricted Regions: China and AWS GovCloud (US)

Why. Some Regions cannot be used from a normal AWS account. They exist for legal and compliance rules.

What. Two groups:

China Regions.

1. They are run separately under Chinese law.
2. The Beijing Region is operated by a local company, Sinnet. The Ningxia Region is operated by NWCD.
3. You need an AWS (China) account. Your normal AWS account cannot see these Regions, and a China account cannot see the normal ones.

AWS GovCloud (US).

1. Two isolated US Regions, operated by US citizens on US soil.
2. The root account holder must pass a screening as a US person.
3. They exist for US government compliance programmes (for example FedRAMP High) and for sensitive, controlled government data.

The board drawing: why governments care about shared hardware. In AWS, one big physical server (the host) is sliced into many virtual servers:

1. Suppose a host has 1,000 GB of storage and 500 GB of RAM.
2. Each virtual server you rent gets, suppose, 4 GB RAM and 8 GB of disk.
3. By RAM: 500 ÷ 4 = 125 virtual servers. By disk: 1,000 ÷ 8 = 125 virtual servers.
4. So up to about 125 customers can share one physical machine (a real host keeps a little for itself).
5. AWS keeps virtual servers strongly isolated from each other. Still, some governments' rules demand separate Regions, special staff and special audits. That is why GovCloud exists.

7. Default Regions and opt-in Regions

Why. When you open a new AWS account, some Regions appear in the Region list and some don't. Students think the missing ones are broken or blocked. They are just switched off by default.

What. The rule (from AWS):

1. Regions launched before 20 March 2019 are enabled by default. You can use them from day one, and you cannot disable them.
2. Regions launched after 20 March 2019 are opt-in Regions. They are disabled by default for every account.
3. A disabled opt-in Region does not show in the console's Region list until you enable it.
4. Enabling is free. You pay only for what you create there.

Enabled by default (17):

Opt-in, disabled by default (17):

Worked example: counting.

1. A normal AWS account sees 17 default + 17 opt-in = 34 Regions in AWS's Regions table.
2. Mumbai is a default Region, so you can launch there on day one.
3. Hyderabad is an opt-in Region, so you must enable it first.
4. When you sign up from India, AWS may suggest enabling the nearer opt-in Region (Hyderabad) if it is closer to your contact address than Mumbai.

How to enable an opt-in Region (console):

1. Sign in as the root user or as an IAM user with permission to enable Regions.
2. Click your account name at the top right.
3. Click Account. This opens the Account page in Billing and Cost Management.
4. Scroll down to the AWS Regions section.
5. Select the Region, for example Asia Pacific (Hyderabad), and click Enable.
6. Confirm with Enable region.
7. Wait. It usually takes a few minutes, and sometimes several hours, because AWS copies your IAM users and credentials to that Region.
8. When the status shows Enabled, the Region appears in the Region list at the top right.

8. Region codes, and why not city names

Why. City names change. Programs don't like change.

What. Suppose AWS had named the Region "bombay":

1. Thousands of companies write the Region name inside their Python, Java and Node.js programs, scripts and settings files.
2. The city is renamed to Mumbai. If AWS renamed the Region too, every one of those programs would break on the same day.
3. So AWS uses a fixed code that never changes: ap-south-1. The display name can say "Mumbai", but programs use the code.

How to read a Region code:

1. Area: ap = Asia Pacific, us = United States, eu = Europe, ca = Canada, sa = South America, af = Africa, me = Middle East, il = Israel, mx = Mexico.
2. Direction inside that area: south, southeast, northeast, east, west, north, central.
3. Number: 1 for the first Region in that direction, 2 for the second, and so on.

Worked examples:

In a program it looks like this: region = "ap-south-1". If you write the city name instead, the AWS tools will not understand it.

9. AZ codes, and how many AZs a Region has

Why. When you launch a server you pick a subnet, and every subnet lives in exactly one AZ. So you will read AZ codes every day.

What. AZ code = Region code + one letter.

1. Mumbai Region ap-south-1 has 3 AZs.
2. Their codes are ap-south-1a, ap-south-1b and ap-south-1c.
3. N. Virginia us-east-1 has 6 AZs: us-east-1a to us-east-1f.

How many AZs? (AWS's Regions table today)

Why does N. Virginia have so many?

1. AWS adds AZs to a Region when demand there grows.
2. us-east-1 is AWS's oldest Region, and it has grown to 6 AZs.

Worked example: planning a high-availability website in Mumbai.

1. Mumbai has 3 AZs.
2. You need at least 2 for high availability, so pick ap-south-1a and ap-south-1b.
3. You make one subnet in each AZ.
4. You launch 2 web servers in each subnet: 4 servers in total.
5. If one AZ fails, 2 of 4 servers (50%) keep the site running, as in section 4.

10. How to choose a Region

Why. The Region decides how far your server is from your users, which services you get, where your data legally sits, and what you pay.

What. Check these four things, in this order:

1. Distance to users. Pick the Region closest to most of your users. Users in India: Mumbai or Hyderabad. A client whose users are in the US: a US Region such as us-east-1.
2. Law and data rules. Some data must stay inside a country. Pick a Region in that country.
3. Services. New AWS services do not reach every Region on day one. Check that your Region has what you need.
4. Price. Prices differ by Region. Compare on the AWS pricing page; never guess.

Worked example.

1. A Pune coaching institute's website; all students are in Maharashtra. Choose Mumbai ap-south-1.
2. An online shop with customers in the US. Choose a US Region, for example N. Virginia us-east-1.
3. A company that must keep customer data inside India and wants a second copy far from Mumbai. Use Mumbai as the main Region and Hyderabad ap-south-2 (enable it first) for the copy.

Which Region does the console open in? The console opens in your default Region (you can set it in the console settings) or the one you used last. It does not pick a Region from your GPS.

11. Local Zones

Why. A Region's big data centers usually sit outside the city centre, where large plots of land are available. Think of IT parks on the edge of a city, like Hinjewadi or Kharadi on the edge of Pune. For most websites this is fine. But some users need answers really fast, and every kilometre adds delay.

What. A Local Zone is a smaller AWS site placed inside or near a big city, close to the users.

1. It is an extension of a parent Region. For example, the Delhi Local Zone belongs to the Mumbai Region.
2. You can run your own servers there: EC2, EBS volumes, VPC subnets, load balancers, and some other services.
3. It connects back to its parent Region over AWS's own high-bandwidth network, so the rest of your setup can stay in the Region.
4. AWS says Local Zones are for applications that need single-digit millisecond latency to users.
5. Prices are set per Local Zone. Check the pricing page; don't assume they match the Region.

Who uses it? Anyone for whom a few milliseconds matter: real-time multiplayer games, live media and video editing, and stock traders.

India Local Zones (AWS's list today):

How to read a Local Zone name: us-west-2-lax-1a = parent Region us-west-2 (Oregon), location lax (Los Angeles), group 1, zone a.

Worked example (suppose numbers).

1. A trading app user in Delhi. Each request to a server in the Mumbai Region takes, suppose, 30 ms there and back.
2. The same request to a server in the Delhi Local Zone takes, suppose, 3 ms.
3. One screen makes 10 requests one after another.
4. Region: 10 × 30 = 300 ms. Local Zone: 10 × 3 = 30 ms.
5. For a normal website, 300 ms is fine. For a trader, the faster one wins.

12. Wavelength Zones

Why. Mobile users are the hardest to serve fast. Your phone's request goes to the tower, then through the telecom company's network, then out to the internet, then to the AWS Region. Each step adds delay. What if the AWS server sat inside the telecom network itself?

What. A Wavelength Zone is AWS compute and storage placed inside a telecom company's data center, at the edge of its mobile (5G) network.

1. Phones on that telecom company's network reach your server without going out to the public internet first.
2. That cuts the delay to a very small number of milliseconds.
3. Like a Local Zone, it is an extension of a parent Region.
4. You can run EC2 instances, EBS volumes and subnets there.
5. Uses: multiplayer games, live video with less delay, AR/VR, machine learning on video at the edge, connected cars.

Where are they? AWS's Wavelength list today has partners such as Verizon (USA), KDDI (Japan), Bell (Canada), BT (UK), Orange (Morocco) and Sonatel (Senegal). A zone name looks like us-east-1-wl1-nyc-wlz-1 (parent Region us-east-1, New York City). There is no Wavelength Zone in India in AWS's list today.

Worked example (suppose hops).

1. Without Wavelength: phone → tower → telecom network → internet → AWS Region. Suppose 12 network hops.
2. With Wavelength: phone → tower → telecom network → Wavelength Zone. Suppose 4 hops.
3. Fewer hops means less waiting. In a live game, the other player sees your move sooner.

Local Zone, Wavelength Zone, edge location: side by side

13. The latency problem: distance and waiting time

Why. Users leave slow apps. If the first screen takes too long, they open a competitor's app.

What. The board example. The app's server is in the Mumbai Region. A user opens it and loads a photo of 1 MB.

To keep the maths easy, on the board we used a simple classroom number:

1 MB travelling 100 km takes 100 ms. (Only a teaching number, see the real-world note below.)

Worked example 1: a user in Pune, about 150 km from Mumbai.

1. 150 km ÷ 100 km = 1.5.
2. 1.5 × 100 ms = 150 ms per image.
3. That is fast. Nobody notices.

Worked example 2: a user in Delhi, about 2,000 km from Mumbai.

1. 2,000 km ÷ 100 km = 20.
2. 20 × 100 ms = 2,000 ms = 2 seconds per image.
3. The first screen of a photo app shows, suppose, 7 images (stories, profile photo, posts).
4. 7 × 2 s = 14 seconds before the screen is ready.
5. Users want it in 1 to 2 seconds. At 14 seconds, they have already left.

14. Edge locations and CDN (Amazon CloudFront)

Why. We cannot build a full Region in every city. But we can keep copies of popular files in many cities. That is a CDN (Content Delivery Network). AWS's CDN is Amazon CloudFront, and the places where it keeps copies are edge locations.

What.

1. Edge locations are smaller AWS sites in many big cities.
2. AWS runs them. You cannot launch your own EC2 server in an edge location.
3. You use them through CloudFront: you tell CloudFront where your real server (the origin) is, and CloudFront serves your files from the edge nearest each user.
4. AWS publishes 750+ CloudFront Points of Presence in 100+ cities across 50+ countries, plus 15 Regional edge caches.
5. In India, CloudFront Points of Presence are listed in Bengaluru, Chennai, Hyderabad, Kolkata, Mumbai, New Delhi and Pune.
6. Edge locations connect to AWS Regions over the AWS global network backbone: AWS's own private fibre, not the public internet.

How. The Delhi story, step by step (classroom numbers):

1. A user in Delhi opens the app. The image request goes to the Delhi edge location, not to Mumbai.
2. The edge checks its cache. This image has never been asked for in Delhi. It's a miss.
3. The edge fetches the image from the origin in Mumbai, over AWS's private backbone.
4. The edge keeps a copy (caches it) and sends the image to the user.
5. This first user still waits for the trip to Mumbai. On the board we estimated about 700 ms to 1 s for that first image. It is faster than 2 s because the private backbone has fewer hops than the public internet.
6. Now a friend in Agra, about 150 km from Delhi, opens the same post. The request goes to the Delhi edge.
7. The image is already there. It's a hit. No trip to Mumbai.
8. Classroom maths: 150 km → 150 ms per image. 7 images × 150 ms = 1,050 ms, about 1.1 seconds, instead of 14 seconds.

Public internet vs AWS backbone. The public internet is like a city bus: it stops at many stops (hops), tower by tower. The AWS backbone is like a private car on an expressway: fewer stops, a clear road.

Worked example 2: how much work the origin saves.

1. Suppose one image is requested 1,000 times in a day from the Delhi edge.
2. Only the first request is a miss. The other 999 are hits.
3. The origin in Mumbai serves 1 request instead of 1,000.
4. Hit ratio = 999 ÷ 1,000 = 99.9%.

15. Uploading through the edge

Why. A student asked: if downloads come from the nearest edge, can uploads also go through the edge instead of crossing the internet to the main server?

What. Yes.

1. Your upload enters the nearest edge location.
2. From there it travels over the AWS backbone to the origin, instead of the public internet.
3. CloudFront can pass uploads (HTTP PUT and POST) through to your origin.
4. For S3, S3 Transfer Acceleration uses the CloudFront edge locations to speed up uploads to a bucket that is far away.

Worked example.

1. A user in Pune uploads a 100 MB video to a bucket in N. Virginia (us-east-1).
2. Without the edge: the upload crosses the public internet all the way. Like a public bus with many stops.
3. With the edge: the upload enters the nearest Indian edge location (Pune or Mumbai), then rides the AWS backbone to N. Virginia. Like taking the expressway.

16. What the edge keeps, and what it deletes

Why. An edge location is small. It cannot keep every file of every website forever. So it must decide what to keep.

What. Rule 1: pull, don't push. The edge does not receive every file in advance. It waits for users to ask.

Rule 2: limited space, so the least recently used goes first (LRU).

1. Suppose an edge has room for only 4 videos (real edges are far bigger; this is to learn with).
2. Users ask in this order: A, B, C, D. All four are misses. The edge now holds A, B, C, D.
3. Someone asks for A again. Hit. A is now the most recently used.
4. Someone asks for E. Miss. The edge is full, so it deletes the least recently used video. That is B.
5. The edge now holds A, C, D, E.
6. If someone asks for B later, it is a miss again, and the edge fetches B from the origin again.

Rule 3: every copy has an expiry time. The website owner sets how long a copy may be reused, for example "suppose 14 days" for a reel. After that, the edge checks with the origin again.

The CDN domain. Big apps often serve images and videos from a separate CDN domain.

1. A request to the main domain (suppose example.com) goes to the origin servers.
2. A request to the CDN domain (suppose mycdn.net, or a CloudFront domain like d111111abcdef8.cloudfront.net) goes to the nearest edge location.

17. See a CDN yourself in browser DevTools

Why. You don't have to believe me. Open any big website and you can see its CDN with your own eyes.

How (Firefox or Chrome on a laptop):

1. Open a big website. In class we looked at instagram.com's login page, as an example.
2. Press F12 to open DevTools.
3. Click the Network tab, then the Images filter.
4. Reload the page.
5. Look at the Domain column. In class the images came from static.cdninstagram.com, a separate CDN domain, not the main domain.
6. Click one image row, then look at Headers → Response headers.
7. Find cache-control. In class it was: public, max-age=31536000, immutable.

Worked example: turn max-age into days.

1. max-age is in seconds.
2. One day = 60 × 60 × 24 = 86,400 seconds.
3. 31,536,000 ÷ 86,400 = 365 days.
4. So the browser may reuse this image for one whole year without asking again. immutable says the file at this address never changes; a new version gets a new address.

What max-age means, and what it doesn't.

1. It tells browsers and caches how long they may reuse the copy.
2. It does not prove how long the CDN's edge keeps the file. The edge can still delete it earlier, by LRU, when space is needed.

This website is only an example of what you can see in your own browser; it is not a statement about how that company runs its servers.

18. AWS Outposts

Why. Some companies want AWS services (EC2, RDS, S3) but must keep certain data or systems inside their own building. Reasons: data-residency or compliance rules, very low latency to machines on site, or local data processing. A suppose example: a bank that must keep some sensitive data in its own data center.

What. AWS Outposts puts AWS's own hardware in your building.

1. AWS delivers and installs AWS-owned racks or servers in your data center. (Racks are standard 42U racks; Outposts servers are 1U or 2U.)
2. AWS operates, monitors and maintains the hardware.
3. You use the same AWS console, APIs and tools: EC2 instances, EBS volumes, and on racks also S3, RDS and more.
4. The data you keep on the Outpost stays in your building.
5. An Outpost is an extension of an AZ and its parent Region. It needs a network connection back to that Region, called the service link.

The board numbers: durability and availability. On the board we wrote "11 nines". Here is exactly what that is:

1. Amazon S3 (S3 Standard) is designed for 99.999999999% (11 nines) durability of objects over a year. Durability = your file is not lost.
2. S3 Standard is designed for 99.99% availability. Availability = you can reach your file right now.
3. These are S3's design numbers, not a promise for every AWS service. Other services have their own numbers.

Worked example: what 11 nines means.

1. Store 10,000,000 objects (1 crore). Expected loss per year = 10,000,000 × 0.00000000001 = 0.0001 objects.
2. That is, on average, one object lost every 10,000 years.
3. Store 1,000,000,000 objects (100 crore). Expected loss = 0.01 objects a year, so on average one object every 100 years.

Worked example: what 99.99% availability means.

1. One year = 365 × 24 × 60 = 525,600 minutes.
2. 0.01% of that = 525,600 × 0.0001 = 52.56 minutes a year when it may be unreachable.
3. Your own website's uptime still depends on your design: one server in one AZ is far weaker than servers in several AZs (section 4).

19. All six together

20. Homework: try at home

Recap

Samjla ka? Try the DevTools test tonight. Udya laptop gheun ya, practical suru karu. Halu halu kalel.

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. Acre numbers, hop counts, latency figures marked "suppose" and the "100 ms per 100 km" rule are classroom numbers for learning. AWS counts are from AWS's own pages and change often, so check the live AWS pages. Instagram appears only as an example of what you can see in your own browser.