High Availability and Fault Tolerance

The 2am hardware failure

A retailer runs its checkout API on a single virtual machine. At 2am, the physical host underneath that instance fails, silently and completely, the way hardware eventually does no matter whose logo is on the rack. The instance is gone, and so is checkout, until someone notices and launches a replacement. That lone instance was a single point of failure: 1 resource whose failure alone took the whole system down with it. Removing single points of failure like it is what the rest of this lesson is about, and it turns out there are 2 different levels of "removed," not 1.

Recall: the building blocks you already have

You already have the 2 tools that make removal possible. Availability Zones give you physically separate locations to spread instances across, so 1 data center's bad night doesn't take out everything at once. A load balancer sits in front of those instances, health-checks each one, and routes traffic only to the ones still responding. Put the 2 together, instances spread across multiple AZs behind a load balancer, and a repeat of the 2am failure stops being catastrophic. What it becomes next, a brief hiccup or nothing at all, depends on how much spare capacity was already running the moment the failure hit.

High availability: staying up through a brief interruption

Amazon RDS Multi-AZ deployments show this pattern clearly. A primary database instance handles every read and write, while a standby in a different Availability Zone stays synchronously updated in the background, ready but idle. If the primary fails, RDS detects it, promotes the standby, and repoints the database's DNS record to it, typically in 60 to 120 seconds, with 0 data loss. For those 60 to 120 seconds, though, connections to the database do drop or queue.

That is high availability: the system recovers automatically and quickly, but the recovery itself is a visible, if brief, gap. Most applications only need this. A minute of connection errors during a rare zone failure is a very different problem than the outright outage the single-instance retailer suffered.

Fault tolerance: staying up with no interruption at all

Now go back to the checkout API, but redesigned. Say it needs 6 running instances to handle its normal load. Spread across 2 Availability Zones, 3 instances each, that is already highly available: lose 1 zone, and the surviving 3 instances keep checkout running, just at half capacity until new instances launch behind them. Spread across 3 Availability Zones instead, with 3 instances in each, 9 instances total, and losing any 1 zone still leaves 6 instances live, exactly the capacity checkout needs. Nothing about the user experience changes. That is fault tolerance: the system was never actually short of capacity, because the "spare" instances were already running and already serving traffic before the failure happened.

The comparison is the entire distinction in 1 image: a highly available design has enough redundancy to survive a failure, and a fault-tolerant design has enough redundancy that surviving it produces no dip to survive. Fault tolerance is closer to a self-sealing tire that keeps a car driving at full speed through a puncture than to a spare tire that gets the car moving again after a stop to change it, which is what high availability's recovery window looks like. Push the analogy further than that single point, though, and it breaks: a spare tire is cheap to carry unused, while fault-tolerant capacity bills you every hour it sits idle, waiting for a failure that may never come.

Where redundancy has to reach: every layer, not just compute

A system is only as available as its least redundant layer. Spreading the compute tier across zones does nothing if the database, the load balancer, or DNS is still a single point of failure underneath it.

Cloud providers build managed load balancers and managed DNS health checks to already be redundant, so the layers a team usually has to design for explicitly are compute and database.

Active-active versus active-passive

The 2 redundancy patterns above have names, and the difference between them shows up again later in this topic. Active-active means every replica is serving traffic at the same time, the way a load balancer spreads requests across all healthy compute instances right now, not just when something fails. Active-passive means 1 side does the work while the other stays synchronized and idle, ready to take over, the way an RDS Multi-AZ standby behaves.

Neither pattern is inherently better. Compute tiers are usually active-active because splitting stateless requests across many identical instances is straightforward. Databases are more often active-passive because keeping every replica simultaneously writable raises hard consistency questions that a single active writer avoids.

Misconception: "multi-AZ" does not automatically mean "fault-tolerant"

It is tempting to hear "deployed across multiple Availability Zones" and assume that settles the reliability question. It settles only half of it. Multi-AZ tells you a failure in 1 zone will not take down every instance. It says nothing about whether the surviving capacity is enough to keep serving your full load without a dip. A team that spreads 6 instances across 2 zones has genuinely improved its availability over a single-AZ deployment, but it has not made itself fault-tolerant, and assuming otherwise is exactly the gap that shows up as an unplanned capacity shortage during the next zone-level event.

Exam cues: reading a high-availability-versus-fault-tolerance question

The trap to watch for: a scenario that describes a solid multi-AZ setup and asks whether it is fault-tolerant. Check the capacity math, not just the zone count, before answering.

Where this leaves you

Both patterns start from the same move, removing a single point of failure, and then diverge on how much spare capacity you are willing to run and pay for around the clock. High availability tolerates a short, automated recovery window; fault tolerance eliminates that window by keeping the redundant capacity already live. Most applications only need the first. The next lesson turns from staying up during a failure to a related but separate question: once you have decided how much capacity a system needs, who decides when to add more of it, and when to take it away again.