Regions and Availability Zones

Build the mental model

Every major cloud provider spreads its data centers across the world, grouped into geographic areas. Each of these geographic areas is a region.

Within each region sit multiple availability zones: isolated locations with their own power supply, networking, and physical building, kept separate from each other.

Data location & compliance — laws may require user data stay within a geographic boundary
Latency — less distance between user and data center means a faster response
Resilience — spreading across zones means one zone's failure doesn't take everything down

Naming varies by provider

Exact naming conventions and region counts differ between providers, but the underlying provider-then-region-then-zone hierarchy is the same concept everywhere.

Region: A geographic area a cloud provider operates in — the base unit for data location, latency, and compliance decisions.

Availability Zone: An isolated location within a region, with separate power, networking, and building, that contains failures so they don't spread between zones.

text

PROVIDER -> REGION -> ZONE HIERARCHY
------------------------------------
PROVIDER -> REGION -> ZONE HIERARCHY
--------------------------------------

  CLOUD PROVIDER
       |
       +---- REGION A (example: "east" area)
       |          |
       |          +-- Zone A1
       |          +-- Zone A2
       |          +-- Zone A3
       |
       +---- REGION B (example: "west" area)
                  |
                  +-- Zone B1
                  +-- Zone B2

  Zones inside one region are isolated from each other:
  separate power, network, and physical building.

Connect it to a real scenario

Let's connect the region/zone theory to two basic facts about a real app: its user base geography and its redundancy requirement.

User Base	Redundancy → Suggested Topology
Local	Low → single-region/single-zone
Local	High → single-region/multi-zone
Global	Any → multi-region (latency-driven)

This is only a reasonable starting point, not an absolute rule — real production apps typically evolve their topology as traffic grows.

The hierarchy is provider, then region, then zone
Region choice addresses compliance and latency
Spreading across zones or regions is what buys resilience

Try the working example

javascript

function recommendTopology(app) {
  if (app.userBase === "global") {
    return "multi-region (spread across regions close to each user cluster)";
  }
  if (app.redundancyRequirement === "high") {
    return "single-region/multi-zone (one region, spread across multiple zones)";
  }
  return "single-region/single-zone (simplest starting point)";
}

const localLowRedundancy = { userBase: "local", redundancyRequirement: "low" };
const localHighRedundancy = { userBase: "local", redundancyRequirement: "high" };
const globalApp = { userBase: "global", redundancyRequirement: "low" };

console.log("Local audience, low redundancy need:", recommendTopology(localLowRedundancy));
console.log("Local audience, high redundancy need:", recommendTopology(localHighRedundancy));
console.log("Global audience:", recommendTopology(globalApp));

You should see

Local audience, low redundancy need: single-region/single-zone (simplest starting point)
Local audience, high redundancy need: single-region/multi-zone (one region, spread across multiple zones)
Global audience: multi-region (spread across regions close to each user cluster)

5-minute try-it

Add a case with `userBase: 'global'` and `redundancyRequirement: 'high'`, predict the output first, then run it and check.

One important caution

Assuming multiple zones in one region protect against a region-wide outage — they don't

Over-engineering a small app into multi-region from day one, adding unneeded complexity

Wikipedia: Availability zone — Cloud Providers & Platforms