Cloud Regions and Zones
A cloud resource must still run somewhere physical. The location choice becomes visible when users are far away, a data center fails, or policy requires data to remain in a particular place.
The Geographic Hierarchy
A region is an independent geographic area in which a provider operates infrastructure. A zone is a deployment area within a region. Providers may also offer multi-region placements that replicate or serve data across several regions.
provider footprint
└── region
├── zone A
├── zone B
└── zone C
The names are organizational abstractions, not promises that all services have identical failure behavior. Each service documents what a zone or region means for that resource.
Placement Changes System Behavior
| Placement | Useful property | Remaining risk or cost |
|---|---|---|
| One zone | Simple and often inexpensive | A zonal disruption can stop the workload |
| Several zones in one region | Better isolation from one-zone failures | A regional disruption still affects every replica |
| Several regions | Wider failure isolation and proximity to distant users | More coordination, replication, and transfer cost |
Distance also contributes to remote-call latency. Putting compute near users can shorten requests, while putting compute near its data can avoid repeated long-distance calls. Those goals may conflict.
A Placement Check
Choose placement by asking:
- Where are the users and dependent systems?
- Which failures must the service survive?
- Where is the data allowed to reside?
- Does the application tolerate asynchronous replication or stale reads?
- What extra transfer and operational cost is justified?
A multi-region label is not a complete resilience plan. The application must still route around failures, handle ambiguous network outcomes, and verify that its data service provides the required replication semantics.