AWS Design Resilient Architectures 2 — Questions and Answers
Question 1: A financial services company runs a multi-tier application across two Availability Zones. The database tier uses Amazon RDS MySQL with a standby replica. During a planned maintenance window, the primary RDS instance fails over to the standby. Applications experience 30–60 seconds of connection errors. Which approach BEST minimizes this disruption for future failovers?
- Enable RDS Proxy to pool and proxy database connections, absorbing the failover transparently (Correct answer)
- Switch to Amazon DynamoDB to eliminate relational database failover delays entirely
- Add a second standby replica in a third Availability Zone to reduce failover time
- Increase the application's database connection retry interval to 90 seconds
Correct answer: Enable RDS Proxy to pool and proxy database connections, absorbing the failover transparently
RDS Proxy maintains a warm pool of connections to the database and handles failover transparently by routing connections to the new primary. Applications connect to the proxy endpoint, which dramatically reduces failover-related connection errors to just a few seconds rather than 30–60 seconds. DynamoDB is a different paradigm requiring application rewrites. A second standby doesn't reduce failover time. Increasing retry intervals just makes applications wait longer, not recover faster.
Question 2: An e-commerce platform uses Amazon SQS to decouple order processing. During a flash sale, order volume spikes 20x and the processing Lambda function starts throwing throttling errors. Messages pile up in the queue, and some orders are being processed multiple times. Which combination of settings addresses BOTH throttling and duplicate processing?
- Enable SQS FIFO queue with message deduplication ID and set Lambda reserved concurrency to match throughput
- Switch to an SNS topic with SQS fan-out and increase the Lambda timeout to 15 minutes
- Set the SQS visibility timeout higher than the Lambda function's maximum execution time and enable Lambda event source mapping with a batch size of 1 (Correct answer)
- Enable SQS long polling and add a Dead Letter Queue with a maxReceiveCount of 1
Correct answer: Set the SQS visibility timeout higher than the Lambda function's maximum execution time and enable Lambda event source mapping with a batch size of 1
Setting the SQS visibility timeout greater than the Lambda execution time prevents messages from becoming visible again while still being processed, which is the root cause of duplicate processing. When a Lambda function takes longer than the visibility timeout, SQS makes the message visible again, causing another invocation to pick it up. The visibility timeout must exceed the function's maximum runtime. A DLQ with maxReceiveCount of 1 would discard messages after one failure, not solve throttling. FIFO queues help with ordering but not inherently with throttle-caused duplicates. Increasing Lambda timeout alone doesn't fix the visibility/duplicate problem.
Question 3: A company's web application stores session data in a single Amazon ElastiCache Redis node. If the node fails, all active users are logged out. The team wants to maintain session continuity even during a node failure with minimal changes to the application code. What is the MOST resilient solution?
- Migrate session storage to Amazon DynamoDB with TTL-based session expiration
- Enable Redis cluster mode with automatic failover using a Multi-AZ replication group (Correct answer)
- Add a second independent Redis node and implement application-level session replication
- Store sessions in an Amazon RDS instance with read replicas across Availability Zones
Correct answer: Enable Redis cluster mode with automatic failover using a Multi-AZ replication group
A Multi-AZ ElastiCache Redis replication group with automatic failover maintains a standby replica. On primary failure, ElastiCache automatically promotes the replica and updates the DNS endpoint, typically within 1–2 minutes. The application continues to use the same endpoint with minimal code changes. DynamoDB is a valid architectural alternative but requires significant application refactoring. Application-level replication to a second independent node requires complex custom code. RDS is not optimized for session storage and introduces unnecessary latency.
Question 4: A microservices architecture on Amazon ECS uses an Application Load Balancer. One downstream service is intermittently slow, causing upstream services to exhaust their connection pools while waiting, eventually crashing them in a cascading failure. Which design pattern DIRECTLY addresses this cascade scenario?
- Enable ALB access logs and set up CloudWatch alarms to detect slow services
- Implement the Circuit Breaker pattern with a timeout and fallback response in the upstream services (Correct answer)
- Add an Amazon API Gateway in front of the ALB to rate-limit requests to the slow service
- Increase the ECS task memory and CPU limits for the downstream service
Correct answer: Implement the Circuit Breaker pattern with a timeout and fallback response in the upstream services
The Circuit Breaker pattern detects when a downstream service is failing or slow, and 'opens the circuit' to stop sending requests to it temporarily. This prevents upstream services from blocking on a slow dependency, exhausting their connection pools, and crashing — the classic cascading failure scenario. The circuit breaker provides fast failure and a fallback response, allowing the overall system to remain functional. CloudWatch alarms detect the problem but don't prevent the cascade. API Gateway rate limiting reduces load but doesn't protect upstream callers from blocking. Increasing resources may help the downstream service but doesn't protect upstreams during the slow period.
Question 5: A company runs a critical batch processing workload on EC2 Spot Instances inside an Auto Scaling group. Jobs take between 45 and 90 minutes to complete. Spot interruptions are terminating instances mid-job, losing all progress. Which strategy provides the BEST balance of cost savings and resilience?
- Switch entirely to On-Demand instances to eliminate interruption risk
- Use Spot Instances with a diversified instance type pool across multiple AZs, implement checkpointing to S3, and handle the 2-minute interruption notice to save state (Correct answer)
- Use Spot Instances with a Spot Fleet and set the allocation strategy to 'lowestPrice' in a single Availability Zone
- Use Reserved Instances for 50% of capacity and Spot for the remainder, without checkpointing
Correct answer: Use Spot Instances with a diversified instance type pool across multiple AZs, implement checkpointing to S3, and handle the 2-minute interruption notice to save state
The optimal approach combines multiple resilience mechanisms: instance type and AZ diversification reduces the probability of simultaneous interruptions; checkpointing to S3 means a job can resume from its last saved state rather than restart from scratch; and handling the 2-minute interruption notice allows graceful state saving before termination. This preserves cost savings while making the workload interruption-tolerant. On-Demand eliminates savings. 'lowestPrice' in a single AZ maximizes interruption risk. Reserved Instances without checkpointing still loses progress on the Spot portion when interrupted.
Question 6: A global SaaS application is deployed in us-east-1 and eu-west-1. The company uses Route 53 with a failover routing policy: us-east-1 is PRIMARY and eu-west-1 is SECONDARY. A network event degrades us-east-1 but does NOT fail the Route 53 health check endpoint, so traffic is never routed to eu-west-1. Users in North America experience high latency and errors. How should the health check be redesigned to catch this scenario?
- Switch from an HTTP health check to a TCP health check on the primary endpoint
- Use a Route 53 calculated health check that combines the HTTP endpoint check with a CloudWatch alarm monitoring application-level error rates and latency (Correct answer)
- Reduce the Route 53 health check interval from 30 seconds to 10 seconds
- Add a second independent health check endpoint in a different subnet of us-east-1
Correct answer: Use a Route 53 calculated health check that combines the HTTP endpoint check with a CloudWatch alarm monitoring application-level error rates and latency
A calculated health check lets you combine multiple health signals. By integrating a CloudWatch alarm that monitors application-level metrics (5xx error rates, p99 latency) with the basic HTTP endpoint check, the health check fails when the application is degraded even if the endpoint technically responds. This catches 'brown-out' scenarios where the service is reachable but performing poorly. TCP checks are simpler and less informative than HTTP. Reducing the check interval speeds detection but doesn't fix the fundamental problem that the check measures the wrong thing. A second subnet check still only measures reachability, not application quality.
AWS Design Resilient Architectures 2
A financial services company runs a multi-tier application across two Availability Zones.
The database tier uses Amazon RDS MySQL with a standby replica.
During a planned maintenance window, the primary RDS instance fails over to the standby.
Applications experience 30–60 seconds of connection errors.
Which approach BEST minimizes this disruption for future failovers?