Design Resilient Architectures
What you will learn
In this domain, you learn how to design scalable and loosely coupled architectures (Amazon SQS, Amazon SNS, AWS Step Functions, Amazon EC2 Auto Scaling, and Elastic Load Balancing) and highly available and fault-tolerant architectures (Multi-AZ, multi-Region, and backup and disaster recovery strategies). Most questions ask you to choose, based on the required RTO, RPO, and cost, an architecture in which the whole system keeps running no matter which part stops.
Key points
- Loose coupling - If you place an SQS queue between processing steps, one side does not stop even if the other stops or falls behind
- Fan-out - To deliver one event to multiple systems, send it from an SNS topic to multiple SQS queues
- High availability - Spread Auto Scaling groups and ALBs across two or more AZs, and replace unhealthy instances based on health checks
- Databases - RDS Multi-AZ deployments fail over automatically, and read replicas distribute reads (failover requires a promotion operation)
- Multi-Region - Aurora Global Database, DynamoDB global tables, and S3 Cross-Region Replication
- The four disaster recovery strategies - In the order backup and restore, pilot light, warm standby, and multi-site, RTO and RPO become shorter and costs become higher
Terms and concepts
Amazon SQS and Amazon SNS
SQS is a queue that holds messages, and the processing side retrieves them at its own pace. Each message is received by one consumer. SNS is a mechanism that immediately delivers incoming messages to all subscribed destinations. When you combine the two, multiple systems can each receive one event in their own queues.
→ Amazon SQS Glossary / → Amazon SNS Glossary / → SQS message queuing
Auto Scaling and Elastic Load Balancing
Amazon EC2 Auto Scaling maintains a set number of instances and increases or decreases the number to match the load. If you specify subnets in multiple AZs, it keeps instances running in the other AZs even during an AZ failure. Elastic Load Balancing distributes traffic only to healthy instances, and its health check results can be used by Auto Scaling to replace instances.
→ Auto Scaling Glossary / → Elastic Load Balancing Glossary / → Auto Scaling strategies
RDS Multi-AZ and read replicas
A Multi-AZ deployment replicates data synchronously to a standby in another AZ and fails over automatically during a failure. A read replica is a mechanism that distributes the read load with asynchronous replication. It can also be created in another Region, but failover requires a promotion operation. Choose based on whether the goal is availability or read performance.
Multi-Region replication
To prepare for a failure of an entire Region, replicate data to another Region. The standard methods are Aurora Global Database for Aurora, global tables for DynamoDB, and Cross-Region Replication for S3. Because they have lower operational overhead than custom replication mechanisms, they are often the correct answer on the exam.
The four disaster recovery strategies and RTO and RPO
The recovery time objective (RTO) is the time from an outage until service resumes, and the recovery point objective (RPO) is the span of time of data that you can afford to lose. Backup and restore is low cost but slow to recover, pilot light replicates only the data and starts servers during a disaster, warm standby always runs a scaled-down environment, and multi-site always handles processing in both locations.
Route 53 routing policies
Failover switches between primary and secondary based on health check results, weighted distributes traffic at set ratios, latency returns the Region closest to the user, and geolocation decides the destination by the location of the user. Use failover for switching over during a failure.