Resilience is the ability to handle a failure with no or little effect on users. Disks, networks, and power can fail, so a resilient service must be designed to deal with failures rather than assume they will not happen. section 16.0
High availability and fault tolerance set different expectations. A highly available service can recover automatically after a short interruption. A fault-tolerant service continues serving users without interruption when a component fails. section 13.0
For an application running on EC2 virtual machines, address failure at several layers:
- Remove single points of failure: run multiple instances in different Availability Zones. An Auto Scaling group replaces failed instances. section 16.1.2
- Decouple work: use a load balancer to send requests to healthy instances, or an SQS queue to separate message producers from workers. section 16.1.2
- Keep state off individual EC2 instances, retry after failures, and make operations idempotent where possible so retries do not depend on an instance surviving. section 16.2 section 16.4
When one web server fails
A load balancer stops sending requests to the failed EC2 instance. Other instances continue serving requests while an Auto Scaling group replaces it. Placing instances in two Availability Zones also leaves capacity if one zone has an outage. section 16.1.2
The diagram shows how a load balancer and Auto Scaling group work together around redundant EC2 instances. section 16.1.2
Check each AWS service’s resilience documentation and service-level agreement before relying on it: services offer different failure guarantees. EC2 is not fault tolerant by default, though some managed services are. Redundancy is more affordable under pay-per-use pricing, but it still requires deliberate architecture. section 13.3.2 section 1.4.3
