Cloud infrastructure isn't one giant global computer — it's built from real buildings in real physical locations, and where you choose to run something has direct, concrete consequences for latency, fault tolerance, and even which laws apply to your data.
3 min read
A region is a distinct geographic area (e.g., US East, Europe West, Asia Pacific Southeast) where a cloud provider operates a cluster of data centers, functioning largely independently from other regions. Choosing which region to run infrastructure in isn't just a technical setting — it directly affects latency (users near that region get faster responses; users far from it don't), data residency and compliance (some regulations require certain data to physically stay within specific geographic/legal boundaries), and cost (prices can genuinely differ between regions for the same service).
Within a single region, infrastructure is further split into availability zones (AZs) — physically separate data centers (distinct power, cooling, and networking) close enough together for low-latency connections between them, but far enough apart that a single physical failure (a power outage, a fire, a networking incident) affecting one AZ shouldn't take down the others.
This is the actual mechanism behind "run in multiple AZs for high availability," a phrase that shows up constantly in real infrastructure guidance (including elsewhere in this domain, e.g., load balancer target groups spanning multiple AZs): if your application's instances are spread across 3 AZs and one AZ has an outage, the other two keep serving traffic, and the load balancer simply routes around the failed AZ. Running everything in a single AZ means a single physical incident can take your entire application down — a fully avoidable single point of failure.
Edge locations (or points of presence) are a further, much larger set of smaller facilities — not full regions or AZs, just caching/networking endpoints — positioned as close as possible to where users actually are, used primarily for content delivery networks (CDNs), covered in depth later in this domain. A cloud provider might operate a few dozen regions worldwide but hundreds of edge locations, because edge locations only need to cache and forward traffic, not run full compute/storage/database services.
Three questions drive most real region/AZ decisions:
Running in multiple regions (not just multiple AZs within one region) is a much bigger step — it typically means replicating data across regions (with real consistency trade-offs), routing users to their nearest region, and handling failover between entire regions, not just entire AZs. This is usually reserved for applications with a genuinely global user base needing low latency everywhere, or extreme resilience requirements (surviving an entire region's outage, not just one AZ's) — most applications get most of the practical benefit from solid multi-AZ design within one well-chosen region, without taking on multi-region's added complexity.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What is the difference between a region and an availability zone?
2. Why is running production infrastructure in a single AZ considered a real risk?
3. How do edge locations differ from regions and availability zones?
4. What three questions drive most real region/AZ placement decisions, per this lesson?
Cloud Computing & Infrastructure