Skip to main content

Regions, Availability Zones, and Failure Domains

What This Concept Is​

A region is a geographic area (for example, us-east-1 in Virginia, europe-west1 near Brussels, australiaeast in Sydney). Regions are designed for isolation. Application dependencies, shared configuration or global-service dependencies can still correlate failures across regions. Check the particular service control/data-plane scope and applicable data-location constraints; different regions need not imply different legal jurisdictions.

An availability zone (AZ) is a logically separate datacenter or cluster of datacenters inside a region, with its own power, cooling, and network. Available zones and latency vary by region, service and workload. Consult current provider documentation and measure the actual path. Separation reduces some shared risks; it does not guarantee independence against every event.

The failure-domain hierarchy is roughly:

  • host - a single physical server (often your smallest implicit failure domain for a VM)
  • rack - one row of hosts sharing power and switch
  • AZ - an isolated datacenter unit
  • region - a whole geographic area
  • provider - the rarest but not zero case (a control-plane bug, a global routing incident, a bad DNS push)

Cross-provider names differ but the shape matches:

  • AWS: Region -> Availability Zone (consult current region inventory) -> rack/host
  • GCP: Region -> Zone (consult current region inventory) -> cluster/rack
  • Azure: Region -> Availability Zone (where supported by region and service) -> rack

Designing in the cloud means deciding, for each workload, how many of these failure domains it must survive.

Why It Matters Here​

Every later decision in this semester assumes you know what a region and an AZ are:

  • a VPC is scoped to a region, its subnets are scoped to AZs (Cluster 3)
  • a load balancer can distribute traffic across AZs; a bad config can strand you in one (Cluster 3)
  • S3 is region-scoped; EBS volumes are AZ-scoped; you cannot attach an EBS volume across AZs (Cluster 4)
  • RDS Multi-AZ is a different thing from RDS cross-region replication, and they cost different amounts (Cluster 4)
  • data egress between regions is expensive; between AZs it is still metered (Cluster 4)
  • global services can have regional control-plane or endpoint dependencies; verify the specific operation rather than inferring resilience from the label (Cluster 5)

If you cannot name your region and AZs, you cannot reason about failure, latency, cost, or compliance.

Concrete Example​

You deploy a single EC2 instance in us-east-1a. A storm knocks out the power in that one AZ.

  • the instance is gone until power returns
  • any EBS volume attached to it is inaccessible, because EBS is AZ-scoped
  • for this scenario, assume the other named zones remain available
  • verify every required regional/global service and route separately
  • inspect cross-region dependencies before claiming other workloads are unaffected

If you instead ran an autoscaling group across 1a, 1b, and 1c behind an Application Load Balancer, the ALB's health checks would fail the 1a target, and traffic would continue flowing through 1b and 1c while 1a recovers. That only supports an AZ-resilience claim if surviving capacity, data availability, routing and all required dependencies also satisfy the operation’s contract.

For "region-resilient," you need a second region (separate geography with explicitly reviewed failure and data-location assumptions) and some way to route traffic there - typically Route 53 failover, Global Accelerator, or DNS-based multi-region. The cost is real: data replication across regions is billed per GB, and running hot-hot in two regions roughly doubles your infrastructure bill.

Cross-provider sanity check. GCP offers regional resources (load balancers, Cloud SQL HA with two zones) and multi-regional (Cloud Storage "multi-region buckets" stored across several regions transparently). Azure exposes three flavors: zonal services (pinned to a single AZ), zone-redundant services (replicated across AZs transparently), and regional services (no zonal awareness). The mental model - "which failure does this specific resource survive?" - generalizes even when the labels don't.

Before you commit, run aws ec2 describe-availability-zones --region us-east-1 --all-availability-zones (or the GCP gcloud compute zones list equivalent) and save the output. Treat AZ lists like you would treat a subnet allocation - a design artifact, not a runtime surprise.

Common Confusion / Misconception​

"Multi-AZ means multi-region." No. Multi-AZ is cheap, low-latency, and survives a datacenter outage. Multi-region is expensive, higher-latency, and survives a whole regional outage. They solve different problems.

"An AZ letter is stable across accounts." No. AWS maps AZ names (us-east-1a) to physical AZs per account to balance load. Your 1a is not necessarily the same physical AZ as another account's 1a. When you need to pin (for example, to match another account's zone on a shared VPC), use AZ IDs (e.g., use1-az1).

"Global services are free of region concerns." Check request and provisioning dependencies separately, including regional endpoints and credential acquisition. A global label alone does not establish failure independence.

"More AZs is always better." Additional zones can reduce concentration risk, but benefits depend on placement, surviving capacity, quorum, routing and mandatory dependencies. Stateless replica count says nothing by itself about data durability. There is no universal three-zone optimum or linear cost rule.

Gotcha: AZ capacity is finite. During the opening hours of a regional incident, other AZs in the same region see a stampede and may temporarily refuse new instance launches. A recovery plan that needs new instances can fail when provisioning is unavailable. Model launch refusal locally first and distinguish already provisioned capacity from planned recovery; use any real failure experiment only within its explicitly authorized scope.

How To Use It​

For every workload, before you write any config:

  1. Name the region and write down why (latency to users, compliance, service availability, cost, feature completeness - some services launch in us-east-1 six months before they land elsewhere).
  2. Decide the failure domain the workload must survive: single-AZ, multi-AZ, or multi-region. Write the RTO/RPO targets next to that decision.
  3. For each stateful component (database, cache, object store), confirm whether its replication story matches that goal.
  4. For each stateless component, confirm it can be scheduled in any AZ (no hidden AZ affinity in storage).
  5. Write down what happens during a single-AZ failure, and run a tabletop test of it.
  6. For multi-region designs, write down the promotion procedure and test it - cross-region failover that has never been rehearsed usually fails when used.
  7. Audit the region list against data-residency rules: which regions are you allowed to put this data in?

Check Yourself​

  1. Why can you not attach one EBS volume to instances in two different AZs?
  2. An RDS instance is set to "Multi-AZ." Does that protect you from the region-wide failure of us-east-1?
  3. Your app is deployed in us-east-1a only. Your RTO is 30 minutes. What is wrong?
  4. How would you verify control-plane and request-path dependencies of a global service before using it in a multi-region design?
  5. You have a 50 ms RTT user budget. Synchronous replication of writes from us-east-1 to eu-west-1 is ~80 ms RTT. What does this imply for "active-active multi-region"?

Mini Drill or Application​

Pick a region near you and one far away. In ten minutes:

  1. List the zones actually available from current provider documentation or an authorized read-only inventory; do not assume a fixed count.
  2. For a simple web app (ALB + app servers + database + object store), decide which AZs each component lives in.
  3. Mark which components survive a single-AZ failure and which need extra work.
  4. Estimate, in words only, how much more expensive cross-region replication would be versus multi-AZ (order of magnitude).
  5. Draft a one-line entry for your ADR log: "We picked region X because Y; we tolerate Z failures; we do not tolerate W."

Read This Only If Stuck​