Free lesson · AWS Fundamentals

Regions, Availability Zones, and the failure-domain model

Easy7 min read

What Regions And Availability Zones Actually Are

An AWS Region is a named geographic area - us-east-1, eu-west-2, ap-south-1 - containing multiple isolated data center clusters. A Availability Zone (AZ) is one of those clusters: one or more physical data centers with independent power, cooling, and physical security, connected to the other AZs in the Region by high-bandwidth, low-latency private fiber.

Two properties of that arrangement drive almost every architecture decision you will make on AWS:

AZs in a Region are far enough apart that a single flood, fire, storm, or power event is unlikely to take out more than one.
AZs in a Region are close enough together that synchronous replication between them is practical - round-trip latency is typically single-digit milliseconds.

That combination is the entire reason "deploy across multiple AZs" is the default reliability posture on AWS. You get physical fault isolation without paying the latency cost of geographic distance.

Most Regions have three or more AZs. A few older or smaller Regions have two. us-east-1 has six. Never write code or infrastructure templates that assume a fixed number - query the Region's AZ list at deploy time.

Important: The AZ names you see (us-east-1a, us-east-1b) are randomised per account. Your us-east-1a is probably not the same physical facility as another account's us-east-1a. AWS does this so customers do not all pile into "the first one." When you need to talk about a specific physical AZ across accounts - for shared VPC subnets, or a support case - use the AZ ID (use1-az1), which is stable and consistent across every account.

The Failure-Domain Hierarchy

The useful mental model is not "Regions and AZs." It is a nested hierarchy of blast radii, each one a boundary that a failure is supposed not to cross.

graph TD
    G[Global<br/>IAM, Route 53, CloudFront] --> R1[Region<br/>us-east-1]
    G --> R2[Region<br/>eu-west-1]
    R1 --> AZ1[Availability Zone<br/>use1-az1]
    R1 --> AZ2[Availability Zone<br/>use1-az2]
    R1 --> AZ3[Availability Zone<br/>use1-az3]
    AZ1 --> DC[Data Center]
    DC --> RK[Rack / Power Domain]
    RK --> H[Physical Host]
    H --> I[Your EC2 Instance]

This diagram shows the AWS failure-domain hierarchy as a tree. At the top is the global layer containing services like IAM, Route 53, and CloudFront. Below that are Regions, such as us-east-1 and eu-west-1. Each Region contains multiple Availability Zones. Each Availability Zone contains one or more data centers, which contain racks and power domains, which contain physical hosts, which finally run your EC2 instances. Each level is a boundary that a failure is designed not to cross.

Reading this bottom-up gives you the design questions:

Failure domain	Typical cause	Your mitigation
Host	Hardware fault, host degradation	Auto Scaling replaces the instance
Rack / power domain	Power or top-of-rack switch failure	Placement group choice; spread across hosts
Availability Zone	Power event, network partition, cooling failure	Deploy across 3 AZs; ELB across AZs
Region	Large-scale service event, control-plane failure	Multi-region active-passive or active-active
Global	Provider-wide event affecting a global service	Rare. Multi-cloud is the only real answer, and usually not worth it

Which Services Live At Which Scope

This is the single most practical table in this topic, and getting it wrong is the most common source of accidental single-AZ architectures.

Scope	Services	Implication
AZ-scoped	EC2 instances, EBS volumes, subnets, RDS instance (a single one), ElastiCache nodes, NAT Gateway	The resource dies with its AZ. You must place redundant copies yourself.
Regional	S3, DynamoDB, SQS, SNS, Lambda, ECS/EKS control planes, Aurora cluster storage, ELB (when configured across AZs)	AWS handles AZ redundancy internally. You still handle Region redundancy.
Global	IAM, Route 53, CloudFront, WAF (for CloudFront distributions), Organizations, Billing	One namespace worldwide. No Region field in the console.

Warning: A NAT Gateway is AZ-scoped, and this catches people constantly. If you deploy one NAT Gateway in az-a and route private subnets in az-b and az-c through it, you have built a three-AZ architecture with a one-AZ failure domain - and you are paying cross-AZ data transfer on every outbound byte. Deploy one NAT Gateway per AZ and route each AZ's private subnet through its own.

Note: "Global" services still have a home Region for their control plane - historically us-east-1 for several of them. Their data plane is globally distributed and highly resilient, but administrative operations (creating an IAM role, changing a Route 53 record, requesting an ACM certificate for CloudFront) can be impaired during a large us-east-1 event even if your workload runs entirely in Frankfurt. Design your emergency runbooks so they do not require creating new IAM roles during an incident.

Choosing A Region

Four criteria, roughly in the order they usually decide the answer:

Latency to users. Physics wins. A user in Mumbai served from us-east-1 pays ~200ms round trip before your application does any work.
Data residency and compliance. GDPR, sectoral regulation, and government contracts frequently make this a hard constraint that overrides everything else.
Service availability. New services and new instance families launch in a handful of Regions first and reach the rest over months or years. Check before you commit.
Price. Per-unit prices vary by Region - sometimes materially. us-east-1 is usually among the cheapest; some Regions run 10–30% higher for the same resource.

Tip: A fifth criterion nobody lists but everyone hits: us-east-1 is the default for a reason and a liability for the same reason. It has the most services, the earliest launches, the lowest prices - and the highest density of large-scale service events, plus the control-plane concentration described above. Building in us-east-1 is fine. Assuming us-east-1 is fine is not.

The Cost Dimension

Multi-AZ is a reliability decision with a cost consequence that appears on a line item most people do not read.

Same AZ, private IP: free.
Cross-AZ within a Region: charged, and historically charged in both directions - you pay for the byte leaving AZ-A and again for it arriving in AZ-B.
Cross-Region: charged, at a higher rate.
Out to the internet: charged, at the highest rate.

A chatty microservice mesh spread evenly across three AZs can generate a cross-AZ transfer bill larger than the compute it runs on. The mitigations are topology-aware routing (keep a request inside one AZ once it enters), and caching. Do not solve it by collapsing to one AZ.

Common Failure Modes

Warning: The three-AZ architecture with a one-AZ dependency. Compute spread across three AZs, database in one, or NAT in one, or a self-managed service discovery node in one. Draw the dependency graph, not the deployment diagram.

Hardcoded AZ names. us-east-1a in a CloudFormation template breaks in a new account and silently concentrates capacity. Use the AZ list from the API.

Assuming AZ failure means total AZ loss. Real AZ events are more often partial and slow - elevated error rates, elevated latency, some API calls failing - than a clean power-off. Health checks that only detect "dead" miss these. This is why "gray failure" is the harder reliability problem.

Capacity assumption during an AZ event. When one AZ fails, everyone's Auto Scaling Groups simultaneously try to launch replacement capacity in the surviving AZs. That capacity is not guaranteed to exist. Pre-provisioning to N+1 in each AZ is more reliable than assuming you can scale into the gap.

Why This Matters In An Interview

Interview: What interviewers are listening for:

You reach for multi-AZ without being asked, and you can say why - physical fault isolation with latency low enough for synchronous replication.

You distinguish AZ-scoped from Regional resources correctly when you sketch a design. Placing a NAT Gateway or an RDS primary without saying "one per AZ" or "Multi-AZ enabled" is a visible gap.

You mention that multi-Region is expensive and complex and you can name the cost - not just the money, but the consistency problem it creates. Reaching for multi-Region unprompted often reads as over-engineering.

Common follow-ups:

"What happens if an AZ goes down?" → Walk the dependency graph: load balancer stops routing there, ASG launches in remaining AZs, RDS Multi-AZ fails over (60–120 seconds typical), in-flight requests to that AZ fail. Then mention capacity contention.

"How many AZs would you use, and why not two?" → Three. With two AZs, losing one means losing 50% of capacity and you must run 200% to survive it. With three, you run 150%. Three is also the minimum for quorum-based systems.

"Would you go multi-Region?" → Ask for the RTO/RPO requirement first. Almost always the correct opening move.

Practice

Exercise: Starter. Open the Service Quotas or EC2 console and list the AZs in your default Region. Find the AZ IDs (use1-az1 form) and note how they map to the letter names in your account.

Intermediate. Take any architecture diagram you have - yours or a public reference architecture - and annotate every resource with its scope: AZ, Regional, or Global. Find the AZ-scoped resources that only appear once.

Advanced. Design a three-tier web application that survives the loss of any one AZ with no data loss and under two minutes of degraded service. Write down, for each tier, what specifically happens in the first 120 seconds of the AZ failing - including where capacity comes from.