Loading...
An isolated data center within a cloud region, your unit of fault tolerance
Quick Definition
An availability zone, often shortened to AZ, is an isolated data center location within a cloud region, with its own independent power, cooling, and networking. A region such as Mumbai or Virginia contains several availability zones, typically three or more, placed far enough apart that a failure in one does not affect the others. Distributing workloads across multiple zones is the standard way to achieve fault tolerance and high availability, though data moving between zones is usually billed and can add meaningfully to networking costs.
Cloud regions are made up of availability zones: physically separate data centers with their own power, cooling, and networking. If one zone fails, the others keep running. Spreading your application across zones is the standard way to survive hardware and facility failures.
The reliability benefit is real, and so is a hidden cost: data moving between zones is usually billed. Architectures that constantly shuttle traffic across zones can incur surprising data transfer costs, so high-availability design and cost design should be considered together.
Example. A service runs in three zones, but its database lives in one. Every read from the other two zones crosses a zone boundary and is billed. Adding read replicas in each zone improves speed and removes most of the cross-zone charge.
When you review reliability architecture, put cross-zone traffic on the checklist. The Cloud Cost Management guide covers networking costs that hide in resilient designs.
Two is the minimum for genuine fault tolerance, since a single zone gives you no protection against a facility failure. Three is the common standard, because it keeps a majority of nodes available when one zone is lost, which matters for consensus-based systems such as databases and etcd. Going beyond three rarely improves resilience enough to justify the extra cross-zone data transfer cost.
Usually not. Most cloud providers charge for data moving between availability zones in both directions, typically at a per-gigabyte rate that is lower than internet egress but far from zero. This is why zone-aware design matters: an architecture that constantly shuttles traffic between zones, such as a service in three zones reading from a database in one, can generate substantial and entirely avoidable transfer charges.
A region is a broad geographic area, such as Mumbai, Frankfurt, or Northern Virginia, and it is the level at which you choose where your data lives. An availability zone is one isolated data center location inside that region, and it is the level at which you design for failure. Put simply: you choose a region for latency, data residency, and price, and you spread across zones within it for resilience.
On AWS, no. Zone names such as us-east-1a are mapped randomly per account, so one account's us-east-1a is not necessarily the same physical zone as another account's us-east-1a. AWS provides zone IDs, such as use1-az1, which are consistent across accounts and should be used whenever you need to reason about physical placement, for example when coordinating across accounts to avoid cross-zone traffic.
Workloads running only in that zone become unavailable, while workloads distributed across other zones in the same region keep serving traffic. This is the entire point of multi-zone architecture, but it only works if both your compute and your data are replicated across zones; a service spread across three zones with a single-zone database still fails when that database's zone goes down.