Certablo
Sign inCreate account
← Knowledge Base
Cloud Fundamentalsarchitecture

High Availability, Fault Tolerance & Resilience

A clear separation of availability, fault tolerance, reliability, and resilience, with the AWS multi-AZ and multi-Region patterns that support them.

CLF-C02

Visual overview

RESILIENCE PATTERNDistribute critical capacity across isolated failure boundaries
Users
→
Health-aware trafficRoute only to healthy capacity
→
AZ AApplicationhealthy capacity
AZ BApplicationindependent capacity
detect→isolate→fail over→recover & test
Redundancy becomes resilience only when the workload can detect faults, isolate them, move work to healthy capacity, and recover predictably.
AWS SERVICE MAPHealthy capacity across failure boundaries

Health-aware routing and replacement are building blocks for resilient architectures.

Elastic Load BalancingHealth-aware routing
EC2 Auto ScalingReplace capacity
Amazon RDSManaged data layer
EXAM-RELEVANT MECHANICS

Technical reference

Recovery objectives turn resilience into measurable requirements.

High availabilityMinimize downtime

Use redundancy, health detection, and failover.

Fault toleranceContinue through faults

Design for continued service during component failure.

RTOTime objective

Maximum targeted time to restore service.

RPOData-loss objective

Maximum targeted data loss measured in time.

Four terms that describe different goals

Availability describes whether a workload is ready to perform its function when it is needed. High availability reduces downtime by avoiding single points of failure and by recovering or failing over when components become unhealthy. Reliability is broader: the AWS Well-Architected Framework treats it as a workload's ability to perform its intended function correctly and consistently over time, including operating and testing through its lifecycle.

Fault tolerance is the ability to continue operating despite faults, usually by adding redundancy and isolating failures. Resilience focuses on the ability to withstand disruptions and recover from them. The concepts overlap, but they are not synonyms. A system can have a recovery plan and therefore be resilient without providing uninterrupted service through every possible fault.

Multi-AZ: isolate local failures

AWS Availability Zones are specifically designed as isolated locations within a Region. For production workloads, distributing critical components across multiple AZs can prevent a single AZ failure from taking down the entire service. A common application pattern places healthy compute capacity in more than one AZ and distributes traffic across that capacity.

The data tier requires equal attention. Replication, database failover, session state, and dependencies must all support the failure boundary. Some managed AWS services provide multi-AZ capabilities that simplify this work, while other architectures require the customer to construct the redundancy. Testing a failover path is as important as drawing one: untested recovery assumptions often hide dependencies that still point to the failed location.

Multi-Region: a larger isolation boundary

Using multiple AWS Regions can protect against a wider class of failures and support disaster-recovery or geographic requirements. AWS Well-Architected guidance notes, however, that a multi-Region approach introduces potential challenges. Data must be replicated or reconstructed, traffic has to move to a healthy Region, configuration needs to remain consistent, and teams must understand the cost and operational complexity of the design.

For that reason, AWS recommends evaluating whether a multi-AZ strategy within one Region already satisfies the workload's availability objectives before adopting a multi-Region design. Architecture should be driven by explicit recovery and availability requirements rather than the assumption that more Regions are always better.

Redundancy is only one part of resilience

A resilient workload needs more than duplicate resources. Health detection determines when something has failed; automated or well-practiced recovery determines what happens next; backups provide protection against data loss scenarios that live replication may reproduce; and monitoring confirms whether recovery succeeded. Operational runbooks and regular testing turn architectural redundancy into an actual recovery capability.

Resilience decisions also have business context. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) express how quickly a workload should recover and how much recent data loss can be tolerated. Those objectives influence whether a simple restore, warm standby, multi-AZ architecture, or more complex multi-Region approach is justified.

Key takeaways

  1. 01

    High availability, fault tolerance, resilience, and reliability overlap but answer different operational questions.

  2. 02

    Multi-AZ architecture is the foundational AWS pattern for isolating failures within a Region.

  3. 03

    Multi-Region designs provide greater geographic isolation but add cost and operational complexity.

  4. 04

    Real resilience also requires detection, recovery procedures, backups, monitoring, and testing.

Official AWS sources

Use these primary AWS resources for the source material behind this article and for deeper reference.