Regions, zones and high availability
Summary: the cloud is physically organized into regions (geographical areas), themselves split into availability zones (isolated datacenters), complemented by points of presence for content delivery. Understanding this geography is indispensable for designing an application that survives a failure and for choosing where to place your data.
1. The geographical hierarchy of the cloud
The detail that matters: the availability zones of a same region are close enough for a very low latency between them (generally less than 2 milliseconds), but far enough apart so that a fire, a flood or a power outage affects only one. It is a deliberate engineering trade-off.
2. Why availability zones exist
The OVH fire in Strasbourg in March 2021 is the most instructive textbook case in Europe. An entire datacenter was destroyed. Customers who had distributed their infrastructure across several sites kept working. Those who had concentrated everything, including their backups, lost their data permanently — several companies never recovered.
The operational lesson: a backup stored in the same zone as production is not a backup. It is a copy that will disappear with the original.
3. The resilience levels
Clear recommendation: aim for level 2 — several availability zones in a single region. It covers the vast majority of real incidents, and its extra cost is modest (cross-zone transfers are billed little or not at all, unlike cross-region transfers).
Level 4 is rarely justified. It brings considerable complexity, notably on data consistency — what happens if the same user writes simultaneously in two regions? Reserve it for services where a few minutes of unavailability truly cost dearly.
4. How to choose your region
Criterion 5 is often forgotten and causes real problems. Many distributed systems — etcd, Kafka, replicated databases — need a quorum, hence an odd number of nodes. With only two availability zones, you cannot build a quorum that withstands the loss of a zone. Three zones is the practical minimum.
5. Understanding geographical latency
An unavoidable physical limit: light in an optical fibre travels about 200,000 kilometres per second. No software optimization will get around the speed of light. If your users are in Australia and your servers in France, the only solution is to bring the servers closer.
The most useful practical consequence: this is the raison d'être of content delivery networks (CDN). Your images, JavaScript files and static pages are copied to hundreds of points of presence, served from the one closest to each user.
6. Content delivery networks
Main players: Cloudflare (the most used, with a very generous free tier), AWS CloudFront, Azure Front Door, Google Cloud CDN, Fastly, Akamai (the historical pioneer).
High-impact practical advice: putting Cloudflare in front of a website is often the most cost-effective performance improvement there is — a few minutes of configuration, free in its base offering, and a very clear reduction of loading time for distant visitors.
7. Understanding availability commitments
Here is what the percentages concretely mean:
| Availability | Downtime per year | Per month | Common name |
|---|---|---|---|
| 99% | 3.65 days | 7.2 hours | Two nines |
| 99.9% | 8.76 hours | 43.8 minutes | Three nines |
| 99.95% | 4.38 hours | 21.9 minutes | — |
| 99.99% | 52.6 minutes | 4.38 minutes | Four nines |
| 99.999% | 5.26 minutes | 26 seconds | Five nines |
The composition trap, essential to understand: availabilities multiply. If your application depends on three services each showing 99.9%, your maximum theoretical availability is 0.999³ = 99.7%, i.e. nearly 26 hours of downtime per year. Every added dependency degrades your overall availability.
Design consequence: high availability is not obtained by stacking reliable services, but by designing for failure — timeouts, retries, circuit breakers, graceful degradation.
8. RTO and RPO — the two recovery objectives
These two acronyms are unavoidable as soon as you talk about a recovery plan, including in interviews.
The right order of reasoning: first define the RTO and RPO with the business leaders, in euros of loss, then design the corresponding architecture. The classic mistake is building a sophisticated architecture then discovering that the business was perfectly fine with four hours of unavailability — and that half the budget was superfluous.
9. The good resilience practices
Practice 3 is the one everyone neglects. Companies discover on the day of the incident that their backups had been corrupted for eight months, or that an element indispensable to the restoration was missing. Test a complete restoration at least once per quarter.
Remember in 30 seconds
- Hierarchy: region > availability zone > datacenter. Plus the points of presence for delivery.
- The zones of a same region are physically isolated but linked by a 1 to 2 ms latency.
- Aim for level 2: several zones in one region. Excellent resilience / cost ratio.
- Three zones minimum if you use a quorum-based system (replicated database, etcd, Kafka).
- A backup in the same zone as production is not a backup — the lesson of the 2021 OVH Strasbourg fire.
- Latency is physical: Paris-Virginia costs about 85 ms, no optimization cancels it. Hence the CDNs.
- Availabilities multiply: three services at 99.9% give 99.7% in total.
- Define RTO (tolerated downtime) and RPO (tolerated data loss) with the business, first.
- Test your restorations at least every quarter.