Skip to main content
Back to module
Cloud Fundamentals · Cloud Concepts

Regions, zones, and availability

Reading25mLesson 2 of 3 in this module

Use regions and availability zones to design a system that survives a zone failure.

Why it matters

Hardware fails, power fails, and sometimes an entire building goes dark. Cloud providers cannot stop that, but they give you the building blocks to keep running when it happens. If you put every server in one place, one bad afternoon takes your whole service down. Understanding regions and zones is the first step in designing for availability.

The core idea

  • A region is a geographic area, such as us-east-1 (North Virginia) on AWS, West Europe on Azure or europe-west1 on Google Cloud. Each region is independent: its own power, network and services. Data you store in a region stays there unless you copy it out.
  • An availability zone (AZ) is one or more data centres inside a region, with separate power, cooling and networking, connected to the other zones by fast, low-latency links. AWS names them like us-east-1a, us-east-1b. Most regions have three or more zones.
  • Edge locations (points of presence) are smaller sites close to users that cache content for a content delivery network (CDN) such as Amazon CloudFront.

The key design rule: a zone can fail, so anything important should run in at least two zones. A whole region failing is much rarer, and protecting against it (multi-region) costs a lot more.

Choosing a region

Pick a region based on, in rough order:

  1. Data rules. Some laws or contracts require personal data to stay in a country or the EU.
  2. Latency. Closer to your users means faster responses.
  3. Service availability. New services and GPU types often launch in some regions first.
  4. Price. The same instance can cost noticeably different amounts in different regions.

Measuring availability

Availability is often written as "nines": 99.9% ("three nines") allows about 8.8 hours of downtime a year; 99.99% allows about 53 minutes. If one zone gives your server 99.5% availability and zones fail independently, two zones in parallel give roughly:

1 - (1 - 0.995) * (1 - 0.995) = 1 - 0.000025 = 99.9975%

Real systems are never perfectly independent, but the maths shows why a second zone is such a big win.

Two related terms you will hear: RTO (recovery time objective: how long you can be down) and RPO (recovery point objective: how much data, measured in time, you can afford to lose). They drive every availability decision.

Worked example: a web shop that survives a zone failure

A small shop runs a web app and a database in one region, eu-west-1.

Fragile design: one VM running both the app and the database, in eu-west-1a. If that zone fails, the shop is down and recent orders may be lost.

Zone-resilient design:

          Internet
             |
     Load balancer (spans zones a and b)
        /                 \
  App VM (zone a)     App VM (zone b)
        \                 /
  Managed database: primary (zone a) + standby (zone b)
  Backups and images in object storage (regional, multi-zone)
  • The load balancer sends traffic only to healthy app servers. If zone a fails, it routes everything to zone b.
  • An auto scaling group keeps the number of app servers at the target and replaces failed ones in a healthy zone.
  • The managed database runs a synchronous standby in another zone (AWS calls this Multi-AZ) and fails over automatically, usually within a minute or two.
  • Object storage such as S3 Standard already stores data across several zones.

The app servers must be stateless: no user sessions or uploads stored only on the local disk, or a failover loses them. Put sessions in the database or a cache and uploads in object storage.

Common mistakes

  • "It's in the cloud, so it's highly available." A single VM in one zone is no more resilient than a server in a cupboard.
  • Two servers, one zone. Redundancy inside a single zone does not survive a zone outage.
  • Stateful app servers that keep files or sessions locally.
  • Never testing failover. Stop one zone's servers on purpose (in a test environment) and watch what happens.
  • Paying for multi-region before you need it. Most beginners' systems need multi-zone, not multi-region.

Quick recap

  • Region = geographic area; availability zone = isolated data centre(s) inside it; edge location = cache near users.
  • Run anything important across at least two zones behind a load balancer, with a multi-zone database and stateless app servers.
  • Choose regions by data rules, latency, service availability and price; use RTO and RPO to decide how much resilience you need.
Also in this lesson: