Multi-AZ and Fault-Tolerant Architectures

Everything in the previous topic assumed the infrastructure stays where you put it. Scaling a fleet, adding readers, warming a cache: none of it helps if the building the instances live in loses power. Skill 2.2 of the exam guide is about the assumption itself, and it starts with the smallest unit of failure AWS gives you a name for.

An Availability Zone is a real place

An Availability Zone is one or more discrete data centers inside a Region, with its own power infrastructure, cooling, networking, and physical connectivity. Not a logical partition, not a rack label. AWS operates over 100 of them worldwide.

Two numbers define how AZs behave, and both are design decisions rather than accidents:

• Up to about 100 km apart. Far enough that a flood, fire, tornado, utility power failure, or fiber cut is unlikely to hit two of them at once. AZs do not share generators, cooling equipment, or power substations, and AWS staggers its own service deployments across AZs in a Region so that a bad rollout cannot land everywhere simultaneously.
• Single-digit millisecond latency between them. Close enough that you can replicate a database write synchronously to another zone and still commit fast enough for an OLTP workload.

That pairing is the whole reason Multi-AZ works. If AZs were 5 km apart, a regional storm would take out several at once. If they were 1,000 km apart, synchronous replication would add tens of milliseconds to every commit and nobody would enable it. The distance is chosen to make cross-zone redundancy both meaningful and affordable.

An AZ name is also per-account. us-east-1a in your account and us-east-1a in a colleague's account are usually different physical zones, because AWS randomizes the mapping to spread load. The stable identifier is the AZ ID (use1-az1), which is what you compare when you share subnets across accounts with AWS RAM.

Zonal, regional, global: the classification that decides everything

Here is the misconception that causes most surprise outages: "AWS is highly available, so my workload is highly available." AWS runs its services across AZs. That does not mean the specific resources you created live in more than one.

Every AWS resource sits in exactly one of three scopes, and the scope tells you what an AZ failure does to it.

Read that table as an operations checklist rather than trivia. Every zonal resource in your architecture is a question: what happens when its AZ disappears? A regional service has already answered that question for you. A zonal one has not.

Two entries deserve a closer look because they trap people:

• An EBS volume is zonal, but its snapshot is regional. You cannot attach a us-east-1a volume to an instance in us-east-1b. You can create a new volume in us-east-1b from that volume's snapshot, because snapshot data is replicated across all AZs in the Region. That asymmetry is how you move block storage between zones, and it is a favorite exam detail.
• A load balancer is regional, but its nodes are zonal. You enable an ALB or NLB in specific subnets, and AWS puts a load balancer node in each of those AZs. Enable it in one AZ and you have built a single-zone dependency with a regional-looking name. An ALB requires subnets in at least 2 AZs for exactly this reason.

Making the compute tier survive: routing is not capacity

Put an Auto Scaling group across three AZs behind an ALB and you have solved the routing problem. When a zone fails, the ALB stops sending requests to its unhealthy targets and the ASG marks those instances unhealthy and replaces them. That part is automatic.

What is not automatic is having somewhere for the traffic to go. Work the numbers.

You run 6 instances across 3 AZs, 2 per zone, and each instance can absorb 20 percent of peak traffic. At peak you are using 6 x 20 = 120 percent of what you need, which feels like comfortable headroom. Now AZ-B fails:

Surviving instances: 4
Capacity:            4 x 20% = 80% of peak
Shortfall:           20% of peak, until replacements launch and pass health checks

For several minutes you are dropping or delaying one request in five. The load balancer did its job perfectly and the site is still degraded.

The general rule is size for the loss of one full AZ, which people write as AZ+1:

This is the concrete reason AWS recommends three AZs rather than two. Two zones make AZ-redundancy cost you double; three make it cost you half again.

The deeper principle behind the table is static stability: the system should keep working correctly without needing to make any changes when a failure happens. Launching replacement instances during an AZ event is a control plane operation, and control planes have lower availability design goals than data planes, precisely because they do more complex work. Worse, an AZ failure is exactly when every other customer in that Region is also asking for capacity. A design that must scale out to survive has made its recovery depend on the busiest moment of the control plane's life. A statically stable design has the capacity already running.

Two settings that decide how evenly the load lands:

• Cross-zone load balancing lets a load balancer node in one AZ send traffic to targets in every AZ, rather than only its own. It is on by default for ALB (and can be turned off per target group) and off by default for NLB. With it off and uneven target counts per zone, an AZ with 2 targets gets the same share of traffic as an AZ with 8, and each of those 2 targets works four times harder.
• ELB health checks versus ASG health checks. By default an Auto Scaling group only watches EC2 status checks, which say the instance is running, not that your application answers. Turn on ELB health checks on the ASG so that a target failing the load balancer's HTTP check gets replaced instead of sitting there returning errors.

The data tier: three ways to survive a zone

Compute is replaceable. Data is not, so the database layer gets its own answer, and RDS gives you three shapes with very different properties.

The Multi-AZ DB instance deployment is the classic one and the most commonly tested. RDS keeps a standby in a second AZ, replicates every commit to it synchronously, and on failure flips the DNS CNAME behind your endpoint to point at the promoted standby. Your application keeps the same connection string and just needs to reconnect. Two consequences follow from "synchronous":

• Write and commit latency go up compared to Single-AZ, because every commit waits for the second zone. This is the cost you are paying for the durability.
• The standby is not a spare server you can use. It accepts no connections. If a scenario asks for read offloading, the answer is a read replica or a Multi-AZ DB cluster, never the standby.

Aurora takes a different route: the cluster volume itself spans three AZs and holds six copies of your data, so instance-level replication does not exist. Losing an AZ removes some instances but not the storage, which is why an Aurora reader can be promoted so quickly.

The single-AZ dependencies people leave in place

Even a carefully built multi-AZ architecture usually has a few zonal chokepoints. These are the ones worth auditing:

• NAT gateway. Created in one subnet, so one AZ. Route every private subnet through a single NAT gateway and one zone's failure cuts outbound internet for the entire VPC. Deploy one per AZ and give each private subnet a route table pointing at the gateway in its own zone. This also removes cross-AZ data transfer charges, so the resilient design is often the cheaper one.
• EFS One Zone. Cheaper storage class, and the name is the warning. EFS Standard replicates across AZs; One Zone does not.
• Instance store volumes. Physically attached to the host. Not just zonal, but instance-lifetime. Stopping the instance loses the data.
• A Single-AZ RDS instance with a read replica in another AZ. This looks like Multi-AZ on a diagram, but the replica is asynchronous and promotion is a manual, minutes-long operation. It is a recovery plan, not a failover mechanism.
• A load balancer enabled in one subnet. Covered above, and easy to create by accident in a test environment that later becomes production.

What Multi-AZ does not do

Multi-AZ protects against infrastructure failure inside one zone. That is a specific and limited promise. It does nothing about:

• Logical corruption. A DELETE without a WHERE clause replicates synchronously to the standby in milliseconds. Both copies are now equally wrong. Recovery means point-in-time recovery or a snapshot.
• Accidental deletion. Deleting the DB instance deletes its standby too.
• Region-wide events. Every AZ in the table above lives in one Region. Surviving the loss of a Region is a different architecture, and the last lesson in this topic covers the four ways to build it.
• A bad deployment. New code that returns HTTP 500 returns it identically in all three zones.

This is the cleanest way to hold the boundary in your head: Multi-AZ is high availability, and it protects against things breaking. Backups and cross-Region replication are disaster recovery, and they protect against things being wrong. The exam separates them consistently, and so should your design.

Exam tips

• The phrases "survive an Availability Zone failure", "high availability", and "automatic failover" point at Multi-AZ. The phrases "accidental deletion", "data corruption", "restore to a point in time", and "Region outage" point at backups or a DR strategy, and Multi-AZ is the wrong answer even though it sounds protective.
• Any answer that reads from a Multi-AZ DB instance standby is wrong. The option exists to be rejected. Read offloading is a read replica or a Multi-AZ DB cluster.
• Numbers to hold: Multi-AZ DB instance failover 60 to 120 seconds, Multi-AZ DB cluster failover typically under 35 seconds, Aurora storage 6 copies across 3 AZs, ALB requires at least 2 AZs.
• When a stem describes an outage that affected everything despite multiple AZs, look for a shared zonal dependency. A single NAT gateway is the classic one; a single-subnet load balancer is the other.
• Cross-zone load balancing: on by default for ALB, off by default for NLB. Uneven target counts per AZ plus cross-zone off equals uneven load.
• If a question asks how much capacity to run in each AZ, the intended answer is enough that the remaining zones can carry the full load without scaling out. That is static stability, and its justification is that Auto Scaling is a control plane operation.

The decision rule to carry forward: for every resource in your architecture, name its scope. Zonal resources need a sibling in another zone and something that routes around the failure; regional resources have already solved it. Everything in this lesson keeps a workload running through infrastructure failure, and none of it helps when the data itself is wrong. That is what the next lesson is for, and it starts with the mechanism underneath every AWS backup: the snapshot.