AWS Design Resilient Architectures 5 — Questions and Answers
Question 1: A company runs a multi-tier web application on AWS. The application database is a single Amazon RDS MySQL instance. During a recent DR drill, the team discovered that restoring from automated backups took 45 minutes, exceeding their RTO of 15 minutes. Which solution best meets the RTO requirement with minimal cost increase?
- Enable RDS Multi-AZ deployment and use the standby instance for failover (Correct answer)
- Increase the backup retention period and use faster instance storage
- Create a read replica in the same AZ and promote it during failures
- Use AWS Database Migration Service to continuously replicate data to a second RDS instance
Correct answer: Enable RDS Multi-AZ deployment and use the standby instance for failover
RDS Multi-AZ maintains a synchronous standby replica in a different AZ. Failover is automatic and typically completes in 1–2 minutes, well within the 15-minute RTO. The standby is not used for reads, keeping costs lower than a full read replica in a separate region. Read replicas use asynchronous replication and require manual promotion, which adds time. DMS is designed for migrations, not HA failover.
Question 2: An e-commerce platform processes orders through an Amazon SQS queue consumed by an Auto Scaling group of EC2 workers. During peak sales events, messages accumulate faster than workers can process them. After scaling out, some orders are processed twice, causing duplicate charges. What is the root cause and the correct fix?
- The SQS visibility timeout is shorter than the order processing time; increase the visibility timeout to match the maximum processing duration (Correct answer)
- The Auto Scaling cooldown period is too short; increase it so new instances stabilize before consuming messages
- Standard SQS queues deliver messages at least once; migrate to FIFO queues with exactly-once processing
- The workers are not deleting messages after processing; add explicit DeleteMessage calls in the consumer code
Correct answer: The SQS visibility timeout is shorter than the order processing time; increase the visibility timeout to match the maximum processing duration
When the visibility timeout expires before a worker finishes processing, SQS makes the message visible again, allowing another worker to pick it up and causing duplicate processing. Increasing the visibility timeout to exceed the maximum processing time prevents this. FIFO queues help with ordering and deduplication but the core issue here is timeout expiry during scale-out, not queue type. Workers should already be deleting messages, and cooldown periods affect scaling speed, not duplicate delivery.
Question 3: A financial services company needs a globally distributed application that can survive the complete loss of an entire AWS Region. Data must be consistent across Regions and writes must succeed even during a regional outage. Which database approach satisfies both requirements?
- Amazon Aurora Global Database with write forwarding disabled and application-level failover to a secondary Region
- Amazon DynamoDB Global Tables with multi-active writes enabled across all Regions (Correct answer)
- Amazon RDS for PostgreSQL with cross-Region read replicas promoted manually during a failover
- Amazon ElastiCache Global Datastore replicating cache data across Regions
Correct answer: Amazon DynamoDB Global Tables with multi-active writes enabled across all Regions
DynamoDB Global Tables provide a multi-active (active-active) architecture where writes can be accepted in any Region and are replicated globally with eventual consistency. This satisfies both the regional-failure survivability and the requirement that writes succeed during an outage. Aurora Global Database has a single primary Region for writes; a failover requires promoting a secondary (adding RTO). RDS cross-Region read replicas require manual promotion. ElastiCache is a caching layer, not a durable transactional database.
Question 4: A company hosts a REST API on Amazon API Gateway backed by AWS Lambda. During a major product launch, Lambda concurrency limits are hit and customers receive 429 throttling errors. The team wants to smooth traffic spikes without losing requests. Which architectural change best addresses this?
- Enable API Gateway caching on all GET endpoints to reduce Lambda invocations
- Place an Amazon SQS queue between API Gateway and Lambda using a Lambda trigger, and return a 202 Accepted response to clients (Correct answer)
- Increase the Lambda reserved concurrency limit to match peak expected traffic
- Deploy the API behind an Application Load Balancer to distribute requests across multiple Lambda functions
Correct answer: Place an Amazon SQS queue between API Gateway and Lambda using a Lambda trigger, and return a 202 Accepted response to clients
Inserting an SQS queue decouples the API from Lambda processing. API Gateway writes requests to SQS immediately and returns 202 Accepted, so no requests are lost. Lambda then processes messages at its own pace. Increasing reserved concurrency helps but still has account-level limits and cannot absorb instantaneous spikes above those limits. API Gateway caching only helps for identical GET requests. ALB does not remove the Lambda concurrency constraint.
Question 5: A startup runs its entire workload in a single AWS Availability Zone to minimize data transfer costs. An AZ outage causes a 4-hour service disruption. Management now requires an architecture that tolerates AZ failures with an RTO under 5 minutes and no data loss (RPO = 0). Which combination meets these requirements at the lowest additional cost?
- Deploy EC2 instances in two AZs behind an Application Load Balancer; use Amazon RDS Multi-AZ for the database (Correct answer)
- Deploy EC2 instances in two AZs behind a Network Load Balancer; use RDS read replicas in each AZ
- Replicate the single-AZ EC2 instances using AWS Backup and restore them to a second AZ when an outage occurs
- Use AWS Elastic Disaster Recovery to continuously replicate servers to a second AZ for rapid failover
Correct answer: Deploy EC2 instances in two AZs behind an Application Load Balancer; use Amazon RDS Multi-AZ for the database
An ALB distributes traffic across EC2 instances in multiple AZs and automatically routes around a failed AZ within seconds, satisfying the 5-minute RTO. RDS Multi-AZ maintains a synchronous standby with automatic failover in 1–2 minutes and zero data loss (RPO = 0). Read replicas use asynchronous replication and require manual promotion, so they cannot guarantee RPO = 0. AWS Backup restore takes tens of minutes. Elastic Disaster Recovery adds cost for continuous replication and is designed for Region-level DR.
Question 6: A microservices application on Amazon ECS (Fargate) uses synchronous HTTP calls between services. When the payment service becomes slow, connection pools in upstream services fill up and the entire application degrades. Which resilience pattern, implemented in AWS, directly prevents this cascading failure?
- Add an Amazon CloudFront distribution in front of the payment service to cache responses
- Implement a circuit breaker in AWS App Mesh using outlier detection on the payment service virtual node (Correct answer)
- Increase the Fargate task CPU and memory limits on the payment service to reduce latency
- Use Amazon SQS between all services to convert synchronous calls to asynchronous messaging
Correct answer: Implement a circuit breaker in AWS App Mesh using outlier detection on the payment service virtual node
AWS App Mesh supports outlier detection (circuit breaker behavior) on virtual nodes. When the payment service exceeds error or latency thresholds, App Mesh automatically stops routing traffic to unhealthy endpoints, preventing upstream services from blocking on slow connections. CloudFront caches content but does not implement circuit breaking for backend failures. Increasing Fargate resources may reduce latency but does not prevent cascading failures if the service is still slow. Converting to SQS would change the fundamental synchronous contract, which may not be feasible for payment flows requiring immediate responses.
A company runs a multi-tier web application on AWS.
The application database is a single Amazon RDS MySQL instance.
During a recent DR drill, the team discovered that restoring from automated backups took 45 minutes, exceeding their RTO of 15 minutes.
Which solution best meets the RTO requirement with minimal cost increase?