What's changed: Revamped CLF-C02 Chapter 2 to the new depth (Regions/AZs/edge/containment/selection, SPOF/multi-AZ+ELB+Auto Scaling/HA/fault tolerance/elasticity/DR)
2.2Designing for High Availability and Fault Tolerance
Understand the basics of avoiding single points of failure and achieving high availability and fault tolerance via multi-AZ deployment, load balancing, and Auto Scaling.
Good design avoids a single point of failure (SPOF) and keeps running through failures. A SPOF is a weak point whose single failure stops the whole system. On AWS, the classic high-availability pattern is three pieces: make components redundant across multiple AZs, distribute traffic with a load balancer at the entry, and let Auto Scaling adjust instance count automatically.
2.2.1Redundancy across AZs
- Place instances across multiple AZs (multi-AZ).
- Use a load balancer (Elastic Load Balancing, ELB) to distribute traffic to healthy instances across AZs.
- Use Auto Scaling to automatically adjust instance count with demand or failures (replacing lost capacity).
When these mesh, here is what happens: if an AZ fails, the ELB stops routing to it and keeps sending traffic to healthy instances in other AZs, while Auto Scaling launches replacements in another AZ to restore capacity—near-zero downtime for users. Conversely, a single-AZ, single-instance setup is itself the SPOF and goes down entirely on one failure.
2.2.2High availability, fault tolerance, elasticity
| Term | Meaning | Example |
|---|---|---|
| High availability | Minimize downtime, keep running | Multi-AZ + ELB |
| Fault tolerance | Whole keeps working despite component failure | Redundancy for no downtime |
| Elasticity | Auto scale with demand | Auto Scaling |
2.2.3Peripheral knowledge: disaster recovery (DR)
Multi-AZ is high availability "within one Region." For wide-area disasters affecting an entire Region, plan disaster recovery (DR) with backup/replication to another Region. DR has targets—RPO (how much data loss is acceptable) and RTO (how fast to recover)—and you pick strategies (backup & restore / pilot light / warm standby / multi-site) balancing cost (detailed in higher certs). For CLF-C02, it is enough to grasp "another Region for wide-area disasters" and "RPO/RTO are the targets."
Scenario: a Web API that must not go down. Run EC2 across two or more AZs, front it with an ELB, and use Auto Scaling to follow demand and auto-replace failures. This survives a single AZ outage (HA). For severe incidents, add periodic backups to another Region (DR). You eliminate SPOFs step by step.
Watch the mix-ups: (1) high availability (design to stay up) vs elasticity (auto scale with demand) are different (elasticity = Auto Scaling, HA = multi-AZ + ELB). (2) Don’t confuse multi-AZ (HA within a Region) with multi-Region (DR for wide-area disasters). (3) The load balancer itself is redundant (AWS-managed, automatically).
Common points: the pattern multi-AZ + load balancer (ELB) + Auto Scaling = high availability and the principle of avoiding SPOF. Also note HA (multi-AZ within a Region) vs DR (another Region) and HA vs elasticity.
2.2.4Section summary
- Core principle: avoid single points of failure (SPOF)
- HA pattern: multiple AZs + load balancer (ELB) + Auto Scaling
- Distinguish HA / fault tolerance / elasticity; wide-area disasters need another Region (DR, RPO/RTO)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which placement best improves high availability?
Q2. What is the main role of Auto Scaling?
Q3. Why should you avoid a single point of failure (SPOF)?
Q4. What is the main role of a load balancer (Elastic Load Balancing)?
Q5. What best prepares for a wide-area disaster affecting an entire Region?