Regions and availability zones
AWS infrastructure is a hierarchy of failure-and-latency domains — Regions are isolated geographic areas, Availability Zones are independent datacenters inside one. Architect across ≥2 AZs or a single-AZ outage takes you down.
The EC2 instances ran in us-east-1a. The RDS database ran in us-east-1a. The load balancer pointed at us-east-1a. It all worked perfectly — until the morning a single availability zone in us-east-1 lost power. Every layer of the stack was in that one zone, so the whole product went dark while a competitor in the same Region, who had spread across three zones, never dropped a request. The architecture wasn’t wrong because it was complex. It was wrong because it had no second failure domain.
By the end of this lesson you will know exactly where to place a workload, why a single-AZ deployment is the quiet killer of production uptime, and what the SAA-C03 resilient-architecture domain expects you to do about it.
Region, AZ, edge: the failure-and-latency hierarchy
AWS’s global footprint is not one cloud. It is a deliberately layered set of isolation boundaries, and your job as an architect is to place workloads on the right boundary for the blast radius and latency you can tolerate.
A Region is an independent geographic area — us-east-1 (N. Virginia), eu-central-1 (Frankfurt), ap-southeast-1 (Singapore). Regions are isolated from each other by design: they share no datacenters, and AWS does not automatically replicate your data between them. You choose a Region for three reasons. Latency — put compute near your users. Data residency and law — GDPR or a banking regulator may forbid customer data from leaving Frankfurt, and because data stays in a Region unless you copy it out, choosing eu-central-1 is itself a compliance control. Price — the same instance type can cost noticeably more in some Regions than others.
An Availability Zone (AZ) is one or more discrete datacenters inside a Region, each with independent power, cooling, and physical networking, placed far enough apart that a fire, flood, or power failure in one is unlikely to hit another — yet close enough (typically within ~100 km / single-digit milliseconds) to keep replication cheap. AWS runs roughly 33 Regions worldwide, and every Region has at least three AZs (most have three to six). The two properties that make AZs the workhorse of resilient design are in tension by design: AZs fail independently (the isolation guarantee), yet are joined by high-bandwidth, low-latency private links — inter-AZ round trips inside a Region are typically ~1-2 ms, versus tens-to-hundreds of ms between Regions (e.g. us-east-1↔eu-west-1 is roughly 70-90 ms round trip). That 1-2 ms link is why you can run a database’s synchronous standby in another AZ without a meaningful latency tax, while a cross-Region synchronous standby would pay 70-90 ms on every write.
Below the Region sit two latency-only constructs worth naming. Edge locations are the CloudFront CDN points-of-presence — hundreds of them, far more than there are Regions — that cache content close to users. Local Zones push a slice of compute and storage into a metro area for ultra-low-latency workloads. Both reduce latency; neither is where your durable state lives.
Regional by default, global by exception
Before you pick a service, ask: which failure domain does it live in, and who is responsible for spreading it? The answer determines your resilience ceiling.
Most AWS services are regional: when you create an EC2 instance, an RDS database, an SQS queue, or an S3 bucket, it exists in one Region and is managed by that Region’s control plane. This has a sharp consequence for resilience — a regional service is only as available as the AZs you spread it across. You must architect across at least two AZs for high availability, because a single-AZ deployment inherits the availability of one datacenter, and datacenters fail.
A small set of services are global, with one control plane spanning all Regions: IAM (your users, roles, and policies are account-wide), Route 53 (DNS, with health checks that can fail traffic between Regions), and CloudFront (the CDN, served from edge locations everywhere). Knowing which bucket a service falls into tells you where its failure domain is and whether you even need to think about multi-Region for it.
| Scope | Examples | Failure domain | What you must do |
|---|---|---|---|
| Zonal | EC2 instance, EBS volume, single subnet | One AZ | Replicate the resource into ≥2 AZs yourself |
| Regional | S3, SQS, DynamoDB, RDS Multi-AZ, ALB | Spans AZs in one Region | Enable/configure its multi-AZ option; pick the Region for law & latency |
| Global | IAM, Route 53, CloudFront | All Regions | Nothing for AZ resilience; used to route across Regions |
▸Why this works
Why doesn’t AWS just replicate everything across Regions for you? Because cross-Region replication is a tradeoff you must own, not a default. Copying data to a second Region adds inter-Region network latency (tens to hundreds of milliseconds, far above the single-digit-ms link between AZs) and egress cost (you pay per GB to move data out of a Region). It can also break a compliance posture that depends on data never leaving its Region. So AWS keeps your data inside one Region unless you explicitly opt into replication — making “stay in-Region” the safe, cheap, lawful default and “go multi-Region” a deliberate, costed decision for disaster recovery or global latency.
A concrete multi-AZ design
When you inherit an architecture or design a new one, walk through each tier and ask: what happens to this resource if its AZ disappears? If the answer is “it goes down,” that tier needs a second AZ.
Resilience stops being abstract the moment you draw the VPC. Take a classic three-tier web service in eu-central-1 and span it across two AZs (three is better for quorum-based systems):
- VPC with one subnet per AZ per tier — say a public subnet in
eu-central-1aandeu-central-1bfor the load balancer, and a private subnet in each AZ for app servers and the database. - Application Load Balancer attached to both public subnets. An ALB is a regional service that runs nodes in every AZ you enable; it health-checks targets and stops routing to an AZ whose instances are unhealthy.
- Auto Scaling group of app servers spread across both private subnets, so capacity survives the loss of one AZ.
- RDS Multi-AZ: a primary in
eu-central-1awith a synchronous standby ineu-central-1b. AWS replicates writes to the standby and, on a primary failure, automatically fails over by repointing the database’s DNS name to the standby — typically within a minute or two, with no committed-data loss because replication was synchronous.
The failure mode this defends against is concrete: if eu-central-1a goes dark, the ALB stops sending traffic to its unhealthy targets, the Auto Scaling group still has servers in eu-central-1b, and RDS promotes the standby. The product stays up on the surviving AZ. Contrast the single-AZ version from the hook: every tier in one zone means the AZ outage is a full outage — there is nothing to fail over to. Quantify the blast radius: a real single-AZ event (the well-documented us-east-1 zonal failures are the canonical example) takes 100% of a single-AZ stack offline for the duration of the event — minutes to hours — while the cost of avoiding it was the second AZ’s standby and the ~$0.01/GB cross-AZ replication traffic, often a few dollars a month on a small fleet. The asymmetry is the whole argument: single-AZ “saves” the price of a standby and buys you a 100%-outage blast radius. This is exactly the resilience that the SAA-C03 “Design Resilient Architectures” domain tests: a passing answer almost always involves spreading a workload across multiple AZs.
A regulated EU fintech needs a highly available production database. Customer data must stay in the EU. Which deployment fits best?
Your entire stack — EC2, RDS, and the load balancer — runs in a single Availability Zone. That AZ suffers a power failure. What happens, and what was the design mistake?
- 01Why must you architect a regional service across at least two Availability Zones, and what does an RDS Multi-AZ deployment do when its AZ fails?
- 02What makes a Region different from an AZ, which AWS services are global rather than regional, and why does data residency follow from the Region choice?
AWS global infrastructure is a nested set of failure-and-latency domains. A Region is an isolated geographic area — Regions share no datacenters, and your data stays inside one unless you replicate it, which makes the Region choice your lever for latency, law (data residency), and price. Inside each Region are at least three Availability Zones, discrete datacenters with independent power, cooling, and networking but joined by single-digit-millisecond private links, so they fail independently yet support synchronous replication between them. Most AWS services are regional and are only as available as the AZs you spread them across, so high availability means architecting across at least two AZs: subnets per AZ, an ALB spanning them, an Auto Scaling group of app servers in each, and RDS Multi-AZ with a synchronous standby that fails over automatically. A small set of services are global — IAM, Route 53, CloudFront. The failure mode to fear is the single-AZ deployment: when that one zone goes dark, the whole product does, because there is no second failure domain to fall back on. Cross-Region is a separate, deliberate choice that buys disaster recovery and global latency at the price of inter-Region latency and egress cost — exactly the kind of resilient-architecture reasoning SAA-C03 expects. Now when you see a single-AZ deployment, you know both the blast radius and the fix: add a second AZ, enable multi-AZ options, and the most common production outage disappears from your risk register.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.