On this page
TL;DR
Once you see the cloud as real buildings in three nested layers, regions, availability zones, and edge locations, every latency, cost, and resilience decision downstream gets obvious instead of mysterious.
"The cloud" is just someone else's computers, in a specific place
The word *cloud* makes it sound like your app floats in some weightless everywhere. It doesn't. When you deploy to AWS, your code runs on a physical server, in a specific building, in a specific city, that you chose, maybe without realising you chose it. Almost every confusing cloud bill, latency complaint, and compliance headache traces back to not understanding where your stuff physically lives.
Three words unlock all of it: region, availability zone, and edge location. Get these and you'll know why your app is slow for users in Sydney, why "the cloud went down" only affected one area, and why moving data between two of your own services cost you money.
Who this is for
Complete beginners. No prior cloud experience needed. We use AWS terms; Azure and GCP use the same ideas with slightly different names.
The three layers, from biggest to smallest
A region is a geographic area (like eu-west-1, Ireland). Inside each region are multiple availability zones (AZs), physically separate data centres with independent power and networking, close enough to talk fast but far enough that one flooding/fire/outage doesn't take the others down. Edge locations are hundreds of small sites worldwide that cache content close to users.
See it as a picture
One region contains several isolated AZs. Static content is served from the nearest edge location; dynamic requests reach the region and are spread across AZs for resilience.
- 1
The user requests your site
Their request first goes to the nearest edge location, maybe in their own city.
- 2
Cached content is served instantly
Images, CSS, JS and other static files are already at the edge. No round-trip to the region needed.
- 3
Dynamic requests travel to the region
Anything personalised (their account, a search) goes to the region you deployed in.
- 4
The region spreads load across AZs
Your app runs in two or three AZs at once, so if one data centre fails, the others keep serving.
Why this matters for every decision you make
1. Latency: pick a region near your users
Data can't travel faster than light. A user in Sydney hitting a server in Ireland eats ~250ms round-trip *before your code runs*. Deploy in the region closest to your users. If they're global, use edge caching (a CDN) for static content and consider multiple regions for dynamic.
2. Resilience: spread across AZs
Running in a single AZ means a single data centre outage takes you down. Running across two or three AZs, which is usually free to *architect*, you just pay for the extra instances, means you survive losing one. This is the cheapest reliability win in the cloud.
3. Cost: data has gravity (and egress fees)
Moving data *out* of a region to the internet costs money (egress). Moving data *between* regions costs money. Moving between AZs in the same region often costs a little. Keeping chatty services in the same region, ideally the same AZ, keeps the bill sane.
The classic surprise bill
A team puts their app in us-east-1 and their database in eu-west-1 "to be safe." Every query now crosses the Atlantic, slow AND billed as inter-region transfer. Keep tightly-coupled services in the same region.
Look it up yourself
You can list regions and AZs from the CLI. Knowing how to read this is the first step to debugging "where is my stuff?"
# List every region 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 eu-west-1 \
--query 'AvailabilityZones[].ZoneName' --output table
# -> eu-west-1a, eu-west-1b, eu-west-1cCommon mistakes that cost people hours (and money)
- 1Deploying everything in one AZ. One data-centre blip and you're fully down. Spread across at least two.
- 2Choosing a region by habit, not by users.
us-east-1is the default everyone reaches for, but if your users are in Europe, you're adding latency for nothing. - 3Ignoring egress. Serving large files straight from the region instead of a CDN means paying premium egress on every download.
- 4Splitting coupled services across regions. App here, database there = slow queries and an inter-region transfer bill.
- 5Assuming a region is one building. It's several. That's a feature (AZs), use it for resilience.
Where to go next
The whole article in 5 lines
- A region is a geographic area; pick the one nearest your users.
- A region contains multiple availability zones, separate data centres; spread across them to survive failures.
- Edge locations cache static content close to users to cut latency.
- Data has gravity: moving it out of / between regions costs money, keep coupled services together.
- The cheapest reliability win in the cloud is multi-AZ.
Next, learn how your resources are organised *inside* a region, and how all of this maps across providers:
- Lesson: Regions & Availability Zones and Cloud Resource Hierarchy.
- Deepen the picture with Cloud Networking Fundamentals, what happens once a request reaches your region.
- See the whole journey in the Cloud Engineer path.
Your app is slow or your cloud bill is higher than expected. Where should you look first?
Check your understanding
1. A team places their app in us-east-1 and their database in eu-west-1 "to be safe." What is the actual consequence?
2. What is the cheapest reliability win described, and how does it work?
Frequently asked questions
What is the difference between a region and an availability zone?
A region is a geographic area like eu-west-1 in Ireland, while an availability zone is one of the physically separate data centres inside that region, each with independent power and networking. The AZs in a region are close enough to communicate quickly but far enough apart that a single fire, flood, or outage will not take all of them down.
How do I make my app faster for users far away?
Deploy in the region closest to your users, since data cannot travel faster than light and a Sydney user hitting an Ireland server eats roughly 250ms of round-trip latency before your code even runs. If your users are global, add edge caching with a CDN for static content and consider running in multiple regions for dynamic traffic.
Why does moving data between my own services sometimes cost money?
Data has gravity in the cloud: moving data out of a region to the internet incurs egress fees, moving it between regions costs money, and moving it between AZs in the same region often costs a little. Keeping tightly coupled, chatty services in the same region, ideally the same AZ, is the way to keep the bill sane.
Should I put my database in a different region from my app to be safe?
No. Splitting tightly coupled services across regions, for example an app in us-east-1 and its database in eu-west-1, means every query crosses the network, which is both slow and billed as inter-region transfer. For resilience, spread across availability zones within one region instead of across regions.
Was this article helpful?
Want to learn this properly?
Reading is a start. Regions & availability zones is a full interactive lesson in the Cloud Engineer path, with real terminal labs, production scenarios, and a completion record.