An availability zone (AZ) is an isolated location within a cloud provider’s region, made up of one or more data centers with their own power, cooling and networking. Providers design zones in the same region to be close enough to connect with low latency but far enough apart, and independent enough, that a fire, power failure or flood in one is unlikely to affect another. By running copies of an application in two or more zones, a cloud customer can keep it running when one zone fails. The term is used by the major public cloud providers, though exact designs and naming vary.
At a glance
- A region contains several availability zones; each zone is one or more data centers with independent power, cooling and networking, according to provider designs.
- Zones in a region are linked by high-speed, low-latency connections, so applications can replicate data between them.
- Deploying across zones is the standard way to survive a single data center failure in the cloud.
- Using several zones means extra servers and, with many providers, charges for data moving between zones.
- Multiple zones do not protect against region-wide or provider-wide outages, application bugs or data loss.
What problem it solves
A single data center can fail: utility power and backup systems can both fail, cooling can fail, network connections can be cut, or human error can take systems down. If all your servers are in one building, so is your risk.
Availability zones give cloud customers a practical way to spread that risk without building their own second site. Because zones are within one region, applications can keep databases synchronized and serve users from either zone with little added delay. Cloud providers often build their uptime commitments for compute and some managed services around deployments that span multiple zones. That is a key part of high availability (HA) in public cloud.
How it works
Structure. A hyperscaler typically organizes its footprint into regions, each with several zones. Each zone is separated from the others by a distance the provider chooses, balancing independence against latency. Providers describe their own designs; buyers should read them rather than assume.
Placing resources. When you create servers, disks or subnets, you choose a zone. Within a virtual private cloud (VPC), each subnet usually lives in one zone, so a multi-zone design means subnets in each.
Zonal and regional services. Some services are zonal: a server or disk exists in one zone and fails with it. Others are regional or multi-zone by default, such as many managed storage, database and load balancer services, which replicate or spread across zones automatically, sometimes as an option you pay for.
Failover. For zonal resources, your design decides what happens in a zone failure: a load balancer routes users to healthy zones, and databases fail over to replicas in another zone. Regular testing is how you find out whether it works.
Cost. Running in more zones adds capacity, and data transferred between zones is often billed per gigabyte.
To plan resilient deployments with a cloud provider, see our public cloud solution page.
When it matters for buyers
- When setting availability targets. Decide which applications need to survive a zone failure and design them across zones; leave less critical ones in one zone to save cost.
- When reading cloud SLAs. Check whether the uptime commitment applies only to multi-zone deployments.
- When reviewing a cloud bill. Inter-zone data transfer can be a surprise line item for chatty applications and replicated databases.
- After a cloud outage. Find out whether it was zonal, regional or provider-wide, and whether your design would have survived it.
- When comparing providers or hybrid options. Not every region has the same number of zones, and smaller providers may not offer zones at all.
Questions to ask vendors
- How many availability zones does the region we plan to use have, and how are they separated physically?
- Which of the services we plan to use are zonal, which are regional, and which replicate across zones by default?
- Does your SLA require deployment across multiple zones, and what does it commit to?
- How is data transfer between zones billed?
- How have past incidents affected single zones versus whole regions, and where do you publish incident reports?
- Do zone names map to the same physical locations across our accounts?
How it differs from a cloud region
A region is the larger unit: a geographic area, often a metro area or country, where a provider offers its services. An availability zone is a smaller, isolated location within that region. Spreading across zones guards against the loss of a data center while keeping latency low enough for synchronous replication. Spreading across regions guards against wider events, such as a regional disaster or a provider problem confined to one region, but adds distance, latency and cost, and usually requires asynchronous replication. Data residency rules are typically about regions, not zones.