Fault Tolerance

Fault tolerance means designing a system to continue operating despite specified component failures. The failure might affect a process, virtual machine, network connection, or an entire availability zone. The design must state which failures it can tolerate and what behavior remains acceptable. Running two servers does not establish fault tolerance if both depend on a single database, share the same failure domain, or lack enough remaining capacity when one fails.

Cloud architectures commonly implement fault tolerance by distributing redundant components across independent failure domains, routing requests only to healthy instances, and keeping important state outside replaceable compute instances. For example, a web application can run across multiple availability zones behind a load balancer. If an instance fails, healthy instances continue serving requests while automation replaces it. The surviving capacity must be sufficient for the expected load; replacement alone may be too slow to prevent an outage.

Compute purchasing decisions are an important application of this concept. Amazon EC2 Spot Instances use spare capacity at discounted prices, but AWS can interrupt them when that capacity is needed elsewhere. They suit interruption-tolerant workloads such as batch processing, distributed data analysis, rendering, and queue-based workers. A worker can checkpoint progress to durable storage, process tasks idempotently, and allow unfinished tasks to be retried elsewhere. A Spot interruption notice typically provides approximately two minutes of warning before stopping or terminating an instance, but applications must not depend on receiving that warning; hibernation can begin immediately.

A practical batch-processing design stores input and checkpoints durably and uses a queue to distribute tasks across workers. If a worker disappears before acknowledging completion, its task becomes available for another worker after the visibility timeout. Duplicate processing remains possible, so task handlers must prevent repeated side effects. Diversifying Spot capacity across suitable instance types and availability zones reduces exposure to a shortage in one capacity pool, but it does not guarantee capacity or uninterrupted execution.

On-Demand Instances are appropriate for short-term, unpredictable, or interruption-sensitive workloads that do not justify a usage commitment. They avoid Spot-specific reclamation, but they can still experience infrastructure failures. Reserved Instances and Savings Plans reduce costs in exchange for commitments; neither makes application code fault tolerant. Savings Plans do not reserve capacity. Zonal Reserved Instances can include a capacity reservation in a specified availability zone, whereas Regional Reserved Instances do not. On-Demand Capacity Reservations address capacity availability in a particular availability zone, not application continuity. Dedicated Hosts primarily address physical-server placement, licensing, and isolation requirements rather than fault tolerance.

A customer-facing application can combine an On-Demand baseline with additional Spot capacity when losing the Spot portion will not violate its service objectives. Predictable eligible baseline usage may benefit from Reserved Instances or Savings Plans. Conversely, a non-checkpointable, single-node job with a strict deadline is usually a poor Spot candidate. In exam scenarios, interruption tolerance is the key purchasing clue: flexible, restartable work favors Spot, while unpredictable work requiring non-Spot execution commonly favors On-Demand.

Fault tolerance has costs: redundant capacity, replicated storage, cross-zone communication, and more complex operations. Retries require limits, backoff, and idempotency to avoid duplicate actions or cascading overload. High availability emphasizes uptime and may include brief recovery interruptions; fault tolerance emphasizes continued operation during the failures covered by the design. Backups and disaster recovery support recovery after disruption but do not, by themselves, provide uninterrupted service. Test failure scenarios under load rather than assuming that redundancy or a purchasing commitment guarantees continuity.