Stop 11 · Cloud Architecture PatternsTopics · 2/9

High Availability & Fault Tolerance

In short

Servers fail. Disks die, a whole data centre loses power. Highly available systems are built so users barely notice when one part breaks.

Designing systems to keep running despite individual component failures — redundancy across availability zones, no single points of failure, and automatic failover are the core techniques.

During a power cut the blob character relaxes under a running fan while an inverter glows.

Think of it like this

The home inverter

The power goes at 10 p.m. in the middle of a cricket match. Click, the inverter takes over, the fan keeps spinning and the TV stays on. You only find out because the neighbours are shouting. That's high availability.

Watch it happen

One zone goes dark

Users

Load balancer

AZ-a servers

AZ-b servers

GET /

1/6Users hit one load balancer that spans two availability zones, separate data centres in one region.

The big ideas

What you need to know

Redundancy

At least two of everything important, in different availability zones: servers, database replicas, NAT gateways.

No single point of failure

Look for anything with exactly one copy. A single NAT gateway or one DB instance can take the whole app down.

Health checks

Load balancers and orchestrators need a real health endpoint to know which copies to stop using.

Nines

99.9% uptime allows about 43 minutes of downtime a month; 99.99% allows about 4. Each nine costs more.

See it in code

Walk through the code

bash

1aws autoscaling create-auto-scaling-group \2  --auto-scaling-group-name web-asg \3  --launch-template LaunchTemplateName=web-lt,Version='$Latest' \4  --min-size 2 --max-size 6 --desired-capacity 2 \5  --vpc-zone-identifier "subnet-aaa111,subnet-bbb222" \6  --target-group-arns arn:aws:elasticloadbalancing:ap-south-1:123456789012:targetgroup/web/abc123 \7  --health-check-type ELB --health-check-grace-period 120

1/4Every instance is launched from the same template, so any copy can replace any other.

The two subnet IDs must be in different availability zones. That's what spreads the instances.

Save yourself the pain

Common mistakes

Oops

Running two servers, both in the same availability zone.

Do this instead

Two copies in one zone fail together. Spread across at least two AZs.

Oops

A health check that only returns 200 without checking anything.

Do this instead

Check what the app really needs, like the DB connection, but keep it fast and avoid cascading failures.

Your mission

Kill a server, keep the site

~45 min

Quick check

Your app has three servers across two AZs but one RDS instance with no standby. What's the weak point?

Go deeper

1Design a basic high-availability architecture with redundancy across at least 2 availability zones.
2Identify the single points of failure in a hypothetical simple architecture and fix them.
3Learn the difference between high availability (minimizing downtime) and fault tolerance (continuing to operate despite a failure).