High Availability and Fault Tolerance in AWS – SAP-C02 Study Guide

Purpose of This Lesson

High availability and fault tolerance are related but distinct architectural goals. Both require designing for failure, but they differ in how much interruption and data loss the system can tolerate.

This lesson focuses on:

• Building highly available applications across multiple Availability Zones.
• Understanding when redundancy is sufficient and when instantaneous failover is required.
• Using Elastic Load Balancing, Auto Scaling, and Amazon Route 53 to improve availability.
• Distinguishing availability from durability.
• Choosing synchronous or asynchronous replication based on recovery requirements.

Key Concepts

High Availability

High availability aims to minimize service interruption. A highly available system can tolerate selected component or infrastructure failures and continue serving users, usually with a brief interruption or failover period.

Availability is commonly expressed as a percentage of uptime. For example, 99.99% availability permits approximately 52.6 minutes of unavailability per year, although the actual impact depends on how the service-level objective is measured.

High availability generally relies on:

• Redundant application instances.
• Deployment across multiple Availability Zones.
• Health checks and automated replacement of failed resources.
• Load balancing or DNS-based traffic distribution.
• Replication of stateful data.
• Monitoring and automated recovery.

A high-availability design should avoid single points of failure, but it does not necessarily guarantee zero interruption.

Fault Tolerance

Fault tolerance is a stricter objective. A fault-tolerant system is designed to continue operating with little or no observable interruption when a component fails.

Examples include:

• Redundant network interfaces or network paths.
• Mirrored storage such as RAID 1.
• Redundant power supplies.
• Synchronous replication.
• Specialized hardware or software capable of immediate failover.

Fault tolerance normally costs more than a conventional high-availability design because resources are duplicated and kept ready for immediate use. It is appropriate when even a short outage or data loss is unacceptable.

In AWS, the underlying infrastructure includes extensive redundancy. Customers are still responsible for designing their workloads to use redundant resources, multiple Availability Zones, and suitable recovery mechanisms.

Synchronous and Asynchronous Replication

Replication strategy affects both performance and data-loss risk.

Replication type	Behavior	Main advantage	Main risk or cost
Synchronous	The write is acknowledged only after the replica confirms the data has been received and written.	Stronger consistency and minimal or zero data loss for a confirmed write.	Higher latency and dependence on replica availability.
Asynchronous	The primary system continues without waiting for the replica to confirm the write.	Lower write latency and better performance over distance.	Recent writes may be lost if the primary fails before replication completes.

Synchronous replication is generally required when the recovery point objective is effectively zero. Asynchronous replication is often preferred for disaster recovery across Regions because it reduces latency and avoids requiring every write to wait for a distant replica.

Elastic Load Balancing and Auto Scaling

Elastic Load Balancing distributes incoming traffic across healthy targets. A load balancer can send requests to instances or other targets in multiple Availability Zones, reducing the impact of an instance or Availability Zone failure.

Auto Scaling complements the load balancer by maintaining the desired capacity of an application tier. It can:

• Replace unhealthy instances.
• Add instances when demand increases.
• Remove instances when demand decreases.
• Maintain capacity across multiple Availability Zones.

A load balancer without healthy replacement capacity may continue routing traffic only to the remaining targets. Auto Scaling restores the desired number of targets after a failure, but replacement is not instantaneous.

Amazon Route 53

Amazon Route 53 can improve availability at the DNS layer through routing policies such as:

• Failover routing: Directs traffic to a secondary endpoint when the primary endpoint is unhealthy.
• Weighted routing: Splits traffic among endpoints according to assigned weights.
• Latency-based routing: Sends users to the Region with the lowest expected network latency.
• Geolocation or geoproximity routing: Routes based on user or resource location.

Route 53 health checks can support DNS failover, but DNS caching means that a change may not be visible to every client immediately. DNS failover should not be treated as instantaneous application failover.

Availability Zones as a Resiliency Boundary

Availability Zones are separate locations within an AWS Region, with independent power and networking infrastructure. Deploying application resources across multiple Availability Zones helps protect against the failure of one zone.

A typical highly available web tier includes:

1. An internet-facing Application Load Balancer.
2. Application instances in private subnets across at least two Availability Zones.
3. An Auto Scaling group configured to use those zones.
4. A stateful data layer that supports the required replication and failover model.

Cross-AZ deployment improves resilience but can introduce inter-AZ data transfer charges and additional coordination latency.

Durability Versus Availability

These terms describe different failure characteristics:

• Durability: The probability that data will remain intact and not be lost or corrupted.
• Availability: The percentage of time that data or a service can be accessed.

A service can have high durability but temporarily lack availability. For example, data may remain safely stored while an endpoint, network path, or service control plane is temporarily inaccessible.

Amazon S3 is designed for extremely high durability, commonly expressed as 11 nines. This does not mean that every S3 object is available for every request at every moment, nor does it eliminate risks such as accidental deletion, incorrect permissions, or application-level corruption. Versioning, replication, backups, and access controls address different risks.

Exam-Relevant Takeaways

• High availability minimizes downtime; fault tolerance aims for continuous operation despite component failure.
• Do not confuse redundancy with automatic recovery. Redundant resources must be connected to health checks, failover, and traffic management.
• Deploying instances in multiple Availability Zones is more resilient than placing all instances in one zone.
• Elastic Load Balancing distributes traffic but does not create application capacity by itself.
• Auto Scaling replaces failed instances and adjusts capacity, but replacement takes time.
• Route 53 failover is DNS-based and is affected by DNS caching and record TTLs.
• Synchronous replication provides stronger protection against data loss but may increase latency and operational complexity.
• Asynchronous replication can lose recently committed data during a failure.
• Durability protects against data loss; availability measures accessibility over time.
• A highly durable storage service is not automatically highly available from the perspective of every application request.
• For a zero-data-loss requirement, verify that the chosen database or storage service actually supports synchronous replication and that the design accounts for write acknowledgment behavior.

Architecture Decision Guide

Requirement	Typical AWS design direction	Important tradeoff
Keep a stateless web application available during an instance failure	Load balancer across multiple Availability Zones plus an Auto Scaling group	Brief interruption may occur while the failed instance is detected and replaced
Continue operating if one Availability Zone fails	Distribute application capacity and supporting services across multiple Availability Zones	Additional cost, cross-AZ traffic, and more complex state management
Route users to a healthy regional endpoint	Route 53 health checks with failover or latency-based routing	DNS caching prevents guaranteed instantaneous failover
Avoid losing acknowledged database writes	Synchronous replication or a service configuration with synchronous standby acknowledgment	Increased write latency and possible loss of write availability during replica problems
Minimize latency for geographically distributed disaster recovery	Asynchronous cross-Region replication	Recent transactions may not exist at the recovery site
Recover failed application instances automatically	Auto Scaling health checks and replacement policies	Recovery is automated but not necessarily immediate
Protect stored objects from data loss	Durable storage, versioning, replication, backups, and appropriate permissions	Durability does not guarantee continuous access or protection from logical deletion
Require no visible interruption during hardware failure	Fault-tolerant architecture with redundant components and immediate failover	Significantly higher cost and design complexity

Common Exam Traps

• Assuming Multi-AZ means zero downtime: Multi-AZ reduces the impact of a zone failure, but failover and traffic convergence can still take time.
• Using Auto Scaling as a failover mechanism by itself: Auto Scaling restores capacity; it does not route requests. A load balancer or another traffic-management layer is also required.
• Treating a load balancer as a database failover solution: Load balancers distribute application traffic and do not solve data replication or database consistency problems.
• Confusing fault tolerance with disaster recovery: Fault tolerance handles failures with little or no interruption. Disaster recovery generally restores service after a larger failure and may involve downtime and data loss.
• Assuming asynchronous replication guarantees zero data loss: Data still in transit or waiting to be applied may be lost when the source fails.
• Assuming S3 durability equals availability: Data can be durable yet temporarily inaccessible.
• Ignoring stateful application components: Stateless web servers are easy to replace. Sessions, files, queues, and database writes need their own resilient design.
• Forgetting DNS behavior: Route 53 failover depends on health checks and DNS resolver caching; lowering TTL does not guarantee immediate propagation everywhere.
• Putting all Auto Scaling capacity in one Availability Zone: The group may replace instances, but it cannot protect against loss of the entire zone unless configured across multiple zones.

Real-World Engineer Notes

• Design availability targets from business requirements. A system requiring 99.9% availability has a very different budget and architecture from one requiring near-continuous operation.
• Define both an RTO and an RPO. RTO describes how quickly service must be restored; RPO describes how much data loss is acceptable.
• Test failure modes rather than relying solely on diagrams. Terminate instances, isolate subnets, test database failover, and validate DNS behavior.
• Keep application instances replaceable. Store durable state in managed data services or replicated storage rather than on ephemeral instance disks.
• Use health checks that measure meaningful application health, not merely whether a process is listening on a port.
• Confirm that every Availability Zone has sufficient subnets, capacity, security-group rules, route-table paths, and service dependencies.
• Consider cross-AZ charges when choosing synchronous replication or chatty distributed application designs.
• Monitor recovery time, failed health checks, target registration delay, replication lag, and capacity-shortage events.
• Protect against logical failures separately from infrastructure failures. Versioning, backups, point-in-time recovery, and controlled deployment processes help with accidental deletion or bad releases.

Quick Reference Summary

• High availability: Minimize service interruption using redundancy, health checks, failover, and automated recovery.
• Fault tolerance: Continue operating through component failure with little or no observable interruption.
• Synchronous replication: Stronger data protection, but higher latency and tighter dependency on the replica.
• Asynchronous replication: Lower latency, but possible data loss during failure.
• Elastic Load Balancing: Distributes traffic among healthy targets.
• Auto Scaling: Maintains and adjusts application capacity and replaces unhealthy instances.
• Route 53: Provides DNS routing and health-check-based failover.
• Durability: Protection against data loss or corruption.
• Availability: Ability to access a service or data over time.
• Multi-AZ architecture: Protects against localized infrastructure failure but does not automatically guarantee zero downtime.

Flashcards

1. Q: What is the primary objective of high availability?

A: Minimize service interruption and maintain access through failures.

1. Q: How does fault tolerance differ from high availability?

A: Fault tolerance aims to continue operating with little or no interruption when components fail, while high availability may include a brief recovery or failover period.

1. Q: What is the main data-loss risk of asynchronous replication?

A: Writes that have not yet reached the replica may be lost if the source fails.

1. Q: Why does synchronous replication increase latency?

A: The primary must wait for the replica to confirm that the write has been received and written.

1. Q: What does Elastic Load Balancing do when a target fails?

A: Health checks remove the unhealthy target from request distribution, directing new traffic to healthy targets.

1. Q: What does Auto Scaling add to a load-balanced architecture?

A: It maintains desired capacity and replaces unhealthy instances.

1. Q: Why should application instances be deployed across multiple Availability Zones?

A: To reduce dependence on a single zone and continue operating if one zone becomes unavailable.

1. Q: What is Route 53 failover routing used for?

A: Directing DNS responses to a secondary endpoint when the primary endpoint fails health checks.

1. Q: Why is Route 53 failover not necessarily instantaneous?

A: DNS resolvers and clients may cache responses until their TTL expires.

1. Q: What does durability measure?

A: The likelihood that data remains intact and is not lost or corrupted.

1. Q: Can data be durable but unavailable?

A: Yes. Data may remain stored safely while the service or network path used to access it is temporarily unavailable.

1. Q: Which replication model best supports a zero-data-loss requirement?

A: Synchronous replication, assuming the write is acknowledged only after the required replica confirms it.

Practice Questions

Question 1

A company runs a web application on Amazon EC2. It requires the application to remain available if an individual instance fails and to automatically restore the desired number of instances. Which design best meets these requirements?

A. One EC2 instance with an Elastic IP address and an EBS snapshot schedule
B. An Application Load Balancer and an Auto Scaling group spanning multiple Availability Zones
C. Amazon Route 53 weighted routing to one EC2 instance
D. A single EC2 instance with two attached EBS volumes

Correct answer: B

Explanation: The load balancer routes traffic to healthy targets, while Auto Scaling replaces failed instances and maintains capacity. Multiple Availability Zones reduce the impact of a zone-level failure. An Elastic IP, snapshots, or additional volumes do not provide this complete traffic-distribution and automated-recovery behavior.

Question 2

A financial application requires that a successfully acknowledged transaction not be lost if the primary database fails. Which replication characteristic is most appropriate?

A. Asynchronous replication with a long replication interval
B. Synchronous replication in which the write is acknowledged after the replica confirms it
C. Periodic snapshots to Amazon S3
D. DNS failover using a short Route 53 TTL

Correct answer: B

Explanation: Synchronous replication reduces the possibility of losing an acknowledged write because the replica confirms the write before acknowledgment. Snapshots and asynchronous replication can leave a recovery-point gap, while DNS failover only changes traffic routing.

Question 3

An application uses Route 53 failover routing to direct users from a primary regional endpoint to a secondary endpoint. During a regional outage, some users continue reaching the primary endpoint for several minutes. What is the most likely explanation?

A. Auto Scaling cannot operate across Regions
B. Route 53 health checks cannot detect endpoint failures
C. DNS responses may be cached by recursive resolvers and clients
D. Elastic Load Balancing disables Route 53 health checks

Correct answer: C

Explanation: Route 53 failover is DNS-based. Existing DNS responses can remain cached until their TTL expires, so clients may not immediately receive the secondary endpoint. This is a normal limitation of DNS-based failover.

Question 4

A team claims that its S3-based backup solution provides continuous access because S3 offers extremely high durability. Which statement correctly evaluates the claim?

A. Durability and availability are identical measurements
B. High durability means objects cannot be deleted accidentally
C. S3 durability protects against data loss, but it does not guarantee that every request will always be successful or immediately accessible
D. S3 durability applies only when objects are replicated to another Region

Correct answer: C

Explanation: Durability concerns preserving data, whereas availability concerns the ability to access it over time. Versioning, replication, backups, and permissions may be needed to address accidental deletion, corruption, or access failures.

Question 5

A workload can tolerate losing a few seconds of data but must minimize write latency while replicating to a disaster recovery Region. Which approach is most suitable?

A. Synchronous cross-Region replication for every write
B. Asynchronous replication to the recovery Region with monitoring of replication lag
C. No replication, with manual rebuild from application logs
D. Route 53 latency-based routing without data replication

Correct answer: B

Explanation: Asynchronous replication avoids making every write wait for a distant Region and is appropriate when some data loss is acceptable. The resulting RPO must be measured and monitored through replication lag. Route 53 controls traffic routing but does not replicate application data.