AWS Design Resilient Architectures 3 — Questions and Answers
Question 1: A financial services company runs a critical order-processing application on EC2 instances behind an Application Load Balancer. During peak trading hours, the application experiences sudden traffic spikes that cause latency issues. The architecture must handle these spikes automatically while keeping costs low during off-peak hours. Which combination of services best addresses this requirement?
- Auto Scaling group with target tracking scaling policy based on ALB RequestCountPerTarget, with a minimum of 2 instances across multiple AZs (Correct answer)
- Reserved Instances in a single AZ with manual scaling triggered by CloudWatch alarms
- A fixed fleet of On-Demand instances sized for peak load, distributed across multiple AZs
- Spot Instances managed by an Auto Scaling group with a simple scaling policy based on CPU utilization
Correct answer: Auto Scaling group with target tracking scaling policy based on ALB RequestCountPerTarget, with a minimum of 2 instances across multiple AZs
Target tracking scaling based on ALB RequestCountPerTarget is the most precise signal for an order-processing application tied to an ALB — it scales instances in proportion to actual incoming requests. A minimum of 2 instances across multiple AZs ensures high availability and fault tolerance. This combination automatically adds capacity during spikes and reduces it during off-peak hours, optimizing cost. Simple CPU-based scaling (option D) reacts slower and Spot Instances risk interruption for critical workloads. A fixed fleet (option C) wastes money off-peak.
Question 2: A company stores customer data in an Amazon RDS MySQL Multi-AZ instance. Their RPO is 1 hour and RTO is 15 minutes. A database administrator discovers that automated backups are disabled and only manual snapshots taken weekly exist. Which action should be taken FIRST to meet the recovery objectives?
- Enable automated backups with a retention period of at least 1 day and set the backup window to a low-traffic period (Correct answer)
- Switch from Multi-AZ to a read replica to allow point-in-time recovery
- Migrate to Aurora to leverage continuous backups to S3
- Increase the manual snapshot frequency to daily and rely on Multi-AZ for the RTO requirement
Correct answer: Enable automated backups with a retention period of at least 1 day and set the backup window to a low-traffic period
Enabling automated backups on RDS is the most direct fix. Automated backups enable point-in-time recovery (PITR), which allows restoration to any second within the retention period — directly satisfying the 1-hour RPO. Multi-AZ already handles the 15-minute RTO for AZ-level failures via automatic failover. Read replicas (option B) do not replace automated backups and don't enable PITR. Option D with daily manual snapshots still leaves up to a 24-hour data loss window, violating the 1-hour RPO. Aurora migration (option C) is not the first step when the immediate fix is simply enabling a native RDS feature.
Question 3: A global e-commerce platform serves customers across North America, Europe, and Asia. Static assets (images, CSS, JavaScript) account for 70% of page load time for users in Asia. The company wants to reduce latency for these users without changing the origin infrastructure hosted in us-east-1. What is the MOST effective solution?
- Deploy the application to EC2 instances in ap-southeast-1 and use Route 53 latency-based routing
- Configure Amazon CloudFront with edge locations and set appropriate cache behaviors with long TTLs for static assets (Correct answer)
- Use S3 Transfer Acceleration to serve static assets directly from S3 to Asian users
- Enable Amazon Global Accelerator for the ALB in us-east-1 to route traffic over AWS's private network
Correct answer: Configure Amazon CloudFront with edge locations and set appropriate cache behaviors with long TTLs for static assets
CloudFront is a Content Delivery Network (CDN) that caches static assets at edge locations geographically close to end users, including those in Asia. By setting long TTLs for static assets (images, CSS, JS), content is served from nearby edge locations rather than traveling to us-east-1, dramatically reducing latency. S3 Transfer Acceleration (option C) speeds up uploads to S3, not downloads to users. Global Accelerator (option D) improves routing for dynamic/TCP traffic but does not cache content at the edge — it still must reach us-east-1 for every request. Deploying to ap-southeast-1 (option A) changes the origin infrastructure, which the question explicitly prohibits.
Question 4: An application uses Amazon SQS to decouple a web frontend from a backend processing tier. The backend processes messages by calling a third-party API that occasionally times out after 25 seconds. Messages that fail processing must be retried up to 3 times before being moved to a dead-letter queue. What is the MINIMUM SQS visibility timeout that should be configured?
- 25 seconds
- 30 seconds
- 100 seconds (Correct answer)
- 75 seconds
Correct answer: 100 seconds
The visibility timeout must be long enough for the consumer to finish processing and delete the message before it becomes visible again (causing a duplicate). The third-party API can take up to 25 seconds, so processing takes at least 25 seconds. AWS recommends setting the visibility timeout to at least 6x the processing time to account for retries and overhead. More critically: with up to 3 retries, a message could be in flight for up to 4 attempts × 25 seconds = 100 seconds in a worst-case retry scenario. Setting the visibility timeout to 100 seconds ensures a message being processed in any retry attempt does not become visible to other consumers prematurely. A timeout of 25 or 30 seconds (options A/B) is too short and will cause duplicate processing. 75 seconds (option D) still risks duplicate delivery on the third retry.
Question 5: A startup's web application is deployed on a single EC2 instance with an attached EBS volume storing user uploads. The startup has a very limited budget but needs to ensure the application can recover from an EC2 instance failure within 30 minutes with no more than 24 hours of data loss. Which is the MOST cost-effective architecture meeting these requirements?
- Enable EC2 Auto Recovery using a CloudWatch alarm on StatusCheckFailed_System and take daily EBS snapshots (Correct answer)
- Deploy two EC2 instances in an Auto Scaling group across two AZs with shared EFS storage
- Use RDS Multi-AZ for the database and store uploads in S3 with versioning enabled
- Configure an AMI-based backup using AWS Backup daily and launch a new instance from AMI on failure
Correct answer: Enable EC2 Auto Recovery using a CloudWatch alarm on StatusCheckFailed_System and take daily EBS snapshots
EC2 Auto Recovery (triggered by a StatusCheckFailed_System alarm) automatically recovers the instance on the same underlying hardware or a new host, preserving the instance's public/private IP, Elastic IP, instance metadata, and EBS volumes — typically completing in minutes, well within the 30-minute RTO. Daily EBS snapshots satisfy the 24-hour RPO. This is the most cost-effective approach because it requires no additional instances, no EFS, and no architectural changes. Auto Scaling with EFS (option B) adds cost with a second instance running continuously. Option C changes the storage architecture significantly and adds RDS costs. AMI-based backup with manual launch (option D) would meet RTO but is more complex and slower than Auto Recovery.
Question 6: A company runs a microservices application where Service A calls Service B synchronously. Service B is experiencing intermittent failures, causing Service A to queue up requests and eventually run out of threads, taking down Service A as well. Which pattern BEST prevents this cascading failure?
- Implement a retry mechanism with exponential backoff in Service A when calling Service B
- Deploy Service B as a Lambda function to benefit from automatic scaling
- Implement the Circuit Breaker pattern in Service A so it stops calling Service B after a threshold of failures and returns a fallback response (Correct answer)
- Add an SQS queue between Service A and Service B to make the communication asynchronous
Correct answer: Implement the Circuit Breaker pattern in Service A so it stops calling Service B after a threshold of failures and returns a fallback response
The Circuit Breaker pattern is designed specifically to prevent cascading failures. When Service B failure rate exceeds a threshold, the circuit 'opens' and Service A immediately returns a fallback response instead of calling Service B — preventing thread exhaustion. Once Service B recovers, the circuit closes and normal operation resumes. Retries with exponential backoff (option A) actually worsen the problem by keeping threads busy longer and increasing load on a struggling Service B. Moving Service B to Lambda (option B) may help with scaling but doesn't protect Service A from cascading failures if Lambda is still failing. An SQS queue (option D) changes the communication model to async — which could help but may not be acceptable if Service A needs a synchronous response; it also doesn't address the current synchronous architecture's failure mode.
AWS Design Resilient Architectures 3
A financial services company runs a critical order-processing application on EC2 instances behind an Application Load Balancer.
During peak trading hours, the application experiences sudden traffic spikes that cause latency issues.
The architecture must handle these spikes automatically while keeping costs low during off-peak hours.
Which combination of services best addresses this requirement?