Region, availability zone, edge location: a three-tier hierarchy
Major cloud providers' infrastructure is organized around a three-tier geographic hierarchy, each addressing a different need: latency, compliance, or fault tolerance.
Region
A region is a defined geographic area (for example 'France Central' or 'US East') grouping several data centers. Choosing a region determines where your data is physically stored — a central criterion for regulatory constraints and latency with your users.
Availability Zone (AZ)
An availability zone is one or more isolated data centers within a region, with its own power supply, its own cooling and its own physical network, but connected to the other AZs in the region via a very low-latency network. This physical isolation is what allows you to tolerate the loss of one AZ without interrupting service.
Edge location (point of presence)
An edge location is a smaller point of presence than a full region, positioned as close as possible to end users to reduce latency — typically used for content delivery (CDN) or certain edge processing. An edge location doesn't replace a region: it serves a proximity goal, not a fault-tolerance one.
Region = where your data lives. Availability zone = how you survive a data center outage. Edge location = how you reduce latency with the end user. Three different problems, three different answers.
The logic of redundancy within a region
Spreading a workload across multiple availability zones within the same region is the first line of defense against downtime — and generally the simplest to implement, since latency between AZs in the same region stays low enough for synchronous replication.
Automatic data replication
'Zone-redundant' storage services automatically replicate data across multiple availability zones, so that the loss of a single zone doesn't affect data availability. This mechanism is offered natively by most managed services from all three major providers.
Load distribution across zones
For compute workloads, deploying instances across multiple AZs behind a load balancer keeps serving traffic even if one zone becomes unavailable — provided the remaining capacity in the other zones is enough to absorb the load, a point often overlooked during initial sizing.
A generally low marginal cost
Contrary to a common assumption, spreading a standard workload across multiple availability zones within the same region generally doesn't involve a major licensing or infrastructure surcharge — the main change is architectural (replication, load balancing), not a fee tied specifically to the number of zones used.
Multi-AZ and multi-region protect against different risks
Just like the distinction between hybrid and multicloud, these are two answers to different risks, not two levels of the same spectrum.
Multi-AZ protects against a data center outage
A multi-AZ architecture survives the failure of a single availability zone — power outage, hardware incident, localized network issue. This is the baseline resilience level recommended for nearly all production workloads, with relatively low implementation cost and complexity.
Multi-region protects against a regional disaster or addresses a proximity need
A multi-region architecture survives an event affecting an entire region (major natural disaster, region-wide network outage), and additionally lets you bring the service closer to users spread across multiple geographic areas. In exchange, it involves significantly higher complexity: data synchronization across regions, application consistency, data transfer costs.
Jumping straight to multi-region without first having a solid multi-AZ architecture doesn't deliver the expected resilience: multi-region complexity is only justified once the multi-AZ level is properly mastered.
What an SLA actually guarantees
Cloud providers publish contractual availability commitments (SLAs) expressed as a percentage — but the gap between two close percentages represents much bigger differences than it looks.
The logic of the 'nines'
A 99.9% SLA ('three nines') tolerates roughly 8h45 of downtime per year. A 99.99% SLA ('four nines') tolerates roughly 52 minutes per year. A 99.999% SLA ('five nines') tolerates roughly 5 minutes per year. Each additional 'nine' represents a tenfold reduction in tolerated downtime — and usually a much higher architectural complexity and cost to achieve it.
A composite SLA degrades quickly
An architecture chaining several services, each with its own SLA, inherits an overall availability lower than the weakest individual SLA if the services aren't designed to tolerate each other's failures independently. A service at 99.99% combined with another at 99.9% doesn't guarantee 99.9% for the whole: the actual result depends on how they're architected together.
All three major providers offer financially-backed SLAs of roughly 99.9% for a single instance, and up to 99.99% for a pair of instances spread across two availability zones — comparable thresholds across providers, with the real difference coming down to the architecture the customer builds on top.
RTO, RPO and the main disaster recovery patterns
Beyond the availability percentage, two metrics concretely steer a resilience strategy: RTO and RPO. They're defined upfront, based on the actual cost of an interruption to your business — not after the fact.
RTO and RPO: two metrics, two different questions
RTO (Recovery Time Objective) answers the question 'how long can we tolerate before the service is restored?'. RPO (Recovery Point Objective) answers a different question: 'how much data can we afford to lose, measured in time since the last backup or replication?'. Both a short RTO and a near-zero RPO cost more to achieve.
The 4 main disaster recovery patterns
From least expensive to most resilient, four approaches structure most disaster recovery strategies in cloud environments.
- Backup and restore: data is backed up regularly, infrastructure is rebuilt in case of disaster. Longest RTO and RPO, lowest cost.
- Pilot light: a scaled-down version of the infrastructure runs permanently in a secondary region, ready to be scaled up when needed.
- Warm standby: a functional but scaled-down version of the application runs continuously in a secondary region, ready to absorb full traffic quickly.
- Multi-site active-active: the application runs simultaneously at full capacity in multiple regions, with near-instant failover. Shortest RTO and RPO, highest cost and complexity.
How to choose between these 4 patterns
The right choice directly depends on the actual cost of an interruption for the business concerned. An e-commerce site where every minute of downtime translates into measurable lost revenue justifies investing in multi-site active-active. An internal reporting tool, checked a few times a day, does perfectly fine with a classic backup-and-restore approach. The most common pitfall is applying the same level of requirement across the entire IT estate, without prioritizing systems by actual criticality.
The most frequent resilience pitfalls
Three mistakes regularly come up in incident analyses tied to insufficiently resilient architecture.
Single-AZ deployment for critical workloads
Deploying a production workload to a single availability zone remains one of the most frequent causes of avoidable downtime — often due to initial simplicity, without revisiting the architecture once the service becomes business-critical.
A recovery plan never tested under real conditions
A documented but never-tested disaster recovery plan creates a false sense of security. A real, regularly scheduled failover test almost always reveals gaps between the theoretical plan and current operational reality — a forgotten configuration, an unanticipated dependency, an incomplete procedure.
RTO/RPO objectives never formalized
Without explicitly defined RTO and RPO for each system upfront, it becomes impossible to objectively choose the right disaster recovery pattern — the risk is over-investing in secondary systems and under-investing in genuinely critical ones.
A high availability percentage advertised by the provider doesn't make up for a poorly designed customer architecture. The provider's SLA covers their infrastructure, not the resilience of how you use it.
The 3 major providers' infrastructure, in orders of magnitude
These figures change continuously as providers open new regions — treat them as orders of magnitude rather than fixed values, and check each provider's official documentation for an exact figure at the time of reading.
- Azure: 60+ regions, each generally including at least three availability zones — the widest geographic coverage among the three major providers.
- AWS: around 40 active regions, for over a hundred availability zones in total, each region including at least three physically separated AZs.
- Google Cloud: 40+ regions and roughly 130 zones, connected by Google's own global network backbone.
Not every region from a given provider offers the full service catalog, nor the same number of availability zones. Checking service availability and AZ count for the targeted region before designing an architecture is a basic check that's often skipped during initial design.
A central concept in the 'architecture' domain of entry-level certifications
Regions, availability zones and high availability consistently appear in the architecture domain of entry-level cloud certifications — Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner all test the ability to choose the right regional setup for a given scenario.
Further reading
Frequently asked questions
What's the difference between a region and an availability zone?
A region is a geographic area grouping multiple data centers. An availability zone (AZ) is one or more isolated data centers within that region, with its own power supply and physical network, but connected to the other AZs via a very low-latency network.
How many availability zones per region, typically?
All three major providers generally aim for a minimum of three availability zones per region, which allows tolerating the loss of one zone while keeping a majority of zones functional.
Should you always aim for a multi-region architecture?
No. Multi-region adds significant complexity and cost, justified only by an actual need for resilience against a regional disaster or proximity to globally distributed users. For most workloads, a well-designed multi-AZ architecture is more than enough.
What sets an edge location apart from a region?
An edge location is a smaller point of presence, positioned to reduce latency with end users (content delivery, edge processing), without offering the same depth of services as a full region. It serves a proximity goal, not a fault-tolerance one.
Does a 99.99% SLA guarantee no outages will ever happen?
No. An SLA guarantees a contractual availability commitment over a given period, usually paired with a financial credit if not met — not a guarantee of zero downtime. A brief outage remains compatible with meeting the SLA, as long as the annual total stays under the contractual threshold.
What's the difference between RTO and RPO?
RTO (Recovery Time Objective) measures the tolerated time before service is restored. RPO (Recovery Point Objective) measures how much data you can afford to lose, in time since the last backup. These are two independent dimensions of a resilience strategy.
Which disaster recovery pattern should I choose?
It depends on the RTO and RPO defined for the system in question, weighed against the available budget. Backup-and-restore suits systems that can tolerate several hours of downtime; multi-site active-active is justified only for systems where every minute of interruption has a major business impact.
Why test a disaster recovery plan regularly?
Because a documented but never-tested plan creates a false sense of security. The environment changes continuously (new services, new dependencies), and only a real failover test reveals the gaps between theory and current operational reality.
Do region and availability zone counts change often?
Yes, all three major providers regularly open new regions. The figures cited in this guide are orders of magnitude at a point in time — for an exact figure, each provider's official documentation remains the reference source.
Do you need to know these concepts for a cloud certification?
Yes, regions, availability zones and high availability are core concepts tested in the Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner entry-level certifications, usually in the domain dedicated to architecture.