HA vs Fault Tolerance: Definitions and Trade-offs

High Availability (HA) and Fault Tolerance (FT) are two distinct reliability goals that architects often confuse. High availability means a system experiences minimal downtime — it can tolerate failures but may have brief interruptions during recovery. Fault tolerance means a system continues operating without any interruption even when components fail, by having fully redundant paths that take over instantly.

Availability is measured as a percentage of uptime over a year. 99.9% availability (three nines) means roughly 8.7 hours of downtime per year, while 99.99% (four nines) allows only 52.6 minutes. 99.999% (five nines) allows just 5.26 minutes. Each additional nine typically requires more redundancy, automation, and cost. The SAA-C03 exam often asks you to identify which architecture meets a given availability target.

A highly available architecture tolerates the failure of one component by automatically detecting the failure and switching to a healthy replacement within seconds or minutes. Examples include RDS Multi-AZ (automatic failover to standby in a different AZ), Auto Scaling Groups replacing terminated instances, and Elastic Load Balancers routing away from unhealthy targets. There is a brief disruption, but the system recovers without manual intervention.

A fault-tolerant architecture has active redundancy — multiple identical components serving requests simultaneously so that when one fails, the others absorb the load instantly with zero downtime. Examples include active-active ELB with multiple EC2 instances, DynamoDB Global Tables serving reads and writes in multiple regions simultaneously, and Aurora with multiple read replicas. Fault tolerance requires more resources running at all times.

Fault tolerance is significantly more expensive than high availability because it requires fully provisioned redundant capacity at all times. A highly available RDS Multi-AZ instance doubles your database cost for a standby that only activates on failure. A fault-tolerant multi-region active-active Aurora deployment may cost four times as much but eliminates all downtime during regional failures. Architects must balance the cost of redundancy against the business cost of downtime.

Recovery Time Objective (RTO) is the maximum acceptable time for a system to be unavailable. High availability architectures target low RTO — typically minutes — through automated failover. Fault-tolerant architectures target near-zero RTO. When designing for HA, you must choose services and configurations that guarantee recovery within your RTO budget. For example, RDS Multi-AZ provides roughly 60-120 second RTO, suitable for many HA requirements.

A Single Point of Failure (SPOF) is any component whose failure causes the entire system to fail. Common SPOFs include a single EC2 instance with no ASG, a single-AZ RDS database, a single NAT gateway, or a single availability zone. Eliminating SPOFs is the first step toward both HA and FT. The SAA-C03 exam frequently tests your ability to identify and eliminate SPOFs in given architecture diagrams.

Achieving HA or FT is much simpler for stateless services (like web servers or Lambda functions) because any instance can handle any request. Stateful services (databases, caches, file systems) are harder — you must synchronise state across replicas, handle replication lag, and ensure consistency during failover. AWS services like EFS (shared file system), ElastiCache with replication groups, and Aurora (shared storage) are designed to make stateful HA easier.

Common HA patterns on AWS include: 1) Multi-AZ Load Balancing — distribute EC2 instances across AZs behind an ALB. 2) Read Replicas — offload read traffic, promote in DR. 3) S3 for stateless assets — S3 is inherently HA with 11 nines of durability. 4) Global Accelerator — static Anycast IPs that route to healthy endpoints across regions. Each pattern trades cost for a specific level of availability.

Fault-tolerant patterns require active redundancy everywhere. Key FT patterns: DynamoDB is inherently fault-tolerant — it replicates data across three AZs with no failover required. S3 has built-in FT. Aurora Multi-Master (now Aurora Serverless v2 multi-writer) allows writes to multiple AZs simultaneously. Kinesis stores data across multiple AZs by default. Choosing managed services with built-in FT is the most cost-effective path to zero-downtime architectures.

Designing for HA or FT is only as good as your testing. AWS recommends using AWS Fault Injection Simulator (FIS) to run controlled experiments that terminate instances, throttle APIs, or inject network failures. You should verify that failover actually completes within your RTO, that data is not lost beyond your RPO, and that alarms fire correctly. Regular game days and chaos engineering exercises reveal gaps in your resilience assumptions before production incidents do.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: High Availability minimises downtime through automated recovery (minutes RTO), Fault Tolerance eliminates downtime through active redundancy (zero RTO), and cost scales significantly with each level of resilience. Eliminating Single Points of Failure is the foundation of both approaches. Next up we explore multi-AZ patterns for stateful services.