How the Cloud Actually Works: Regions, AZs & the Edge

"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.

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

1. 1

   The user requests your site

   Their request first goes to the nearest edge location, maybe in their own city.

2. 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. 3

   Dynamic requests travel to the region

   Anything personalised (their account, a search) goes to the region you deployed in.

4. 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.

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-1c

Common mistakes that cost people hours (and money)

1. Deploying everything in one AZ. One data-centre blip and you're fully down. Spread across at least two.
2. Choosing a region by habit, not by users. us-east-1 is the default everyone reaches for, but if your users are in Europe, you're adding latency for nothing.
3. Ignoring egress. Serving large files straight from the region instead of a CDN means paying premium egress on every download.
4. Splitting coupled services across regions. App here, database there = slow queries and an inter-region transfer bill.
5. Assuming a region is one building. It's several. That's a feature (AZs), use it for resilience.

Where to go next

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.