2.1 - Highly available and resilient architectures
AWS Solutions Architect Associate objective 2.1 covers designing highly available and fault-tolerant systems. Making a web tier highly available across a Region means running instances in multiple Availability Zones behind an Elastic Load Balancer, so the loss of one AZ does not take the app down. Disaster recovery strategies trade cost against recovery speed: backup and restore is cheapest but recreates the environment slowly, suitable when hours of downtime and data loss are acceptable; pilot light keeps only core pieces running; warm standby keeps a scaled-down but fully functional copy running for faster failover; and multi-site active-active is fastest and priciest. You should also know Auto Scaling, health checks and decoupling. Expect scenario questions that describe an availability target or a recovery-time and cost trade-off, and ask which HA design or DR strategy fits.
HA web tier = instances across multiple AZs behind a load balancer. DR cheapest/slowest = backup and restore. Scaled-down but running copy = warm standby. Fastest/priciest = multi-site active-active.
Practice questions
1. Which design makes a web tier highly available across an AWS Region?
- A single large instance with a scheduled nightly reboot and manual recovery
- Two instances placed in the same single Availability Zone
- Instances in multiple Availability Zones behind a load balancer (correct answer)
- One instance with a daily AMI backup
Spreading instances across multiple AZs behind an Elastic Load Balancer survives the failure of an entire AZ. Single-AZ or single-instance designs share a failure domain.
2. To decouple a spiky front end from slower back-end workers so no requests are lost, which service should sit between them?
- Amazon CloudFront
- AWS Direct Connect
- Amazon Route 53
- Amazon SQS (correct answer)
An SQS queue buffers requests so producers and consumers scale independently; messages persist until a worker processes them, absorbing spikes without loss.
3. Which Route 53 routing policy sends users to a healthy secondary site only when the primary fails its health check?
- Failover routing (correct answer)
- Weighted routing
- Latency-based routing
- Geolocation routing
Failover routing pairs a primary and secondary record with health checks; traffic goes to the secondary only when the primary is unhealthy. Ideal for active-passive DR.
4. Which Auto Scaling feature keeps a group's average CPU close to a chosen value automatically?
- Scheduled scaling on a fixed calendar
- Target tracking scaling (correct answer)
- Manual scaling by an operator
- Standby instance state
Target tracking adds or removes instances to hold a metric (e.g., 50% average CPU) at a target. Scheduled scaling acts on a fixed calendar instead.
5. An application needs a DynamoDB table with active-active, multi-Region, low-latency read and write access for a global user base. Which feature provides this?
- DynamoDB Accelerator (DAX) clusters deployed in each Region
- A DynamoDB read replica configured in every target Region
- DynamoDB global tables replicating across the chosen Regions (correct answer)
- Cross-Region automated backups restored into each Region nightly
DynamoDB global tables provide a fully managed, multi-Region, multi-active replication so users read and write to the nearest Region with low latency and automatic conflict resolution (last-writer-wins).
6. Messages that repeatedly fail processing keep returning to an SQS queue and block healthy messages. What should be configured to isolate them?
- A dead-letter queue with a maximum receive count on the source queue (correct answer)
- A longer visibility timeout so failing messages are hidden permanently
- A second consumer fleet dedicated to reprocessing every failed message
- FIFO ordering on the queue so poison messages are delivered last
A dead-letter queue with a maxReceiveCount moves a message aside after it fails processing that many times, keeping poison messages from blocking the main queue and enabling later analysis.