"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.
Note: 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
| In the real world | In tech |
|---|---|
| 🌍 A country | Region |
| 🏢 Separate buildings in that country | Availability Zones |
| 🏪 Corner shops near every neighbourhood | Edge locations |
Each term is just a different zoom level on 'where your code runs'.
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
This part is interactive in the original. Open the full version on TheSimplifiedTech
- The user requests your site: Their request first goes to the nearest edge location, maybe in their own city.
- Cached content is served instantly: Images, CSS, JS and other static files are already at the edge. No round-trip to the region needed.
- Dynamic requests travel to the region: Anything personalised (their account, a search) goes to the region you deployed in.
- 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.
Warning: 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?"
explore.sh
# 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-1c
Common mistakes that cost people hours (and money)
- Deploying everything in one AZ. One data-centre blip and you're fully down. Spread across at least two.
-
Choosing 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. - Ignoring egress. Serving large files straight from the region instead of a CDN means paying premium egress on every download.
- Splitting coupled services across regions. App here, database there = slow queries and an inter-region transfer bill.
- Assuming 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.
Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.
Top comments (0)