AWS Design Resilient Architectures 4 — Questions and Answers
Question 1: A financial services company runs a critical payment processing application on EC2 instances behind an Application Load Balancer. During peak transaction periods, the application experiences latency spikes. The team wants to implement auto scaling but must ensure that in-flight transactions are never dropped when instances are terminated. Which configuration achieves this?
- Enable connection draining (deregistration delay) on the target group and configure scale-in protection during transaction processing (Correct answer)
- Set the minimum capacity to match peak load so instances are never terminated
- Use a Network Load Balancer instead, which handles connection draining automatically without configuration
- Configure the Auto Scaling group to only scale out and never scale in during business hours
Correct answer: Enable connection draining (deregistration delay) on the target group and configure scale-in protection during transaction processing
Connection draining (deregistration delay) causes the load balancer to stop sending new requests to a deregistering instance while allowing in-flight requests to complete, up to the configured timeout. Combined with scale-in protection on instances processing active transactions, this ensures zero dropped transactions during scale-in events. The other options either waste resources, misattribute capabilities to NLB, or only partially address the problem.
Question 2: An e-commerce platform stores session data in a single ElastiCache Redis node. The team is concerned about session data loss if the node fails. They want a solution that provides automatic failover with minimal data loss and no application code changes. What should they implement?
- ElastiCache Redis with cluster mode disabled and Multi-AZ enabled with automatic failover (Correct answer)
- ElastiCache Redis with cluster mode enabled across 3 shards
- ElastiCache Memcached with multiple nodes in different Availability Zones
- Store session data in DynamoDB with DAX as a caching layer instead
Correct answer: ElastiCache Redis with cluster mode disabled and Multi-AZ enabled with automatic failover
ElastiCache Redis with cluster mode disabled and Multi-AZ enabled creates a primary node with a synchronous replica in a different AZ. If the primary fails, automatic failover promotes the replica to primary within seconds, with the same endpoint — requiring no application code changes. Cluster mode would require sharding logic changes. Memcached has no replication or failover capability. Switching to DynamoDB with DAX would require significant application refactoring.
Question 3: A company has a microservices architecture where Service A calls Service B synchronously via REST API. When Service B experiences high load and slows down, the slow responses cause thread pool exhaustion in Service A, eventually causing Service A to fail as well. This is an example of cascading failure. Which AWS-native approach best prevents this failure pattern?
- Implement Amazon SQS between Service A and Service B to decouple them asynchronously (Correct answer)
- Use AWS App Mesh with a circuit breaker policy configured on the virtual router
- Place an Application Load Balancer between Service A and Service B to distribute load
- Deploy Service B with larger EC2 instances to prevent it from slowing down
Correct answer: Implement Amazon SQS between Service A and Service B to decouple them asynchronously
Introducing SQS between the services converts the synchronous call to an asynchronous pattern, completely eliminating cascading failure. Service A publishes messages to SQS and returns immediately; Service B consumes at its own pace. Thread pool exhaustion in Service A is impossible because it no longer waits on Service B. App Mesh circuit breakers help but still require synchronous call patterns. An ALB only distributes load but doesn't prevent Service A from waiting. Larger instances delay but don't prevent the cascading failure under sufficient load.
Question 4: A multi-tier web application uses RDS MySQL with a single primary instance. A recent incident showed that a developer accidentally ran a DELETE without a WHERE clause, deleting critical data. Automated daily snapshots exist but restoring takes 45 minutes. The company's RPO is 5 minutes and RTO is 15 minutes. Which configuration meets both requirements?
- Enable RDS automated backups with a backup retention period and use Point-in-Time Recovery (PITR) to restore to just before the deletion (Correct answer)
- Enable Multi-AZ deployment, which provides synchronous replication to a standby instance that is unaffected by the DELETE
- Create a read replica and promote it immediately after the accidental deletion occurs
- Use AWS Backup with a 5-minute backup frequency to meet the RPO requirement
Correct answer: Enable RDS automated backups with a backup retention period and use Point-in-Time Recovery (PITR) to restore to just before the deletion
RDS Point-in-Time Recovery uses transaction logs captured every 5 minutes (combined with automated backups) to restore a DB to any second within the retention period, meeting the 5-minute RPO. Restoration to a new instance typically completes in 10-15 minutes, meeting the 15-minute RTO. Multi-AZ replicates all changes including the accidental DELETE synchronously — it provides HA for instance failures, not logical data errors. A read replica also receives the DELETE statement in near-real-time. AWS Backup does not support 5-minute backup intervals for RDS.
Question 5: A global SaaS application is deployed in us-east-1. The architecture team wants to implement a warm standby disaster recovery strategy in eu-west-1 with an RTO under 30 minutes. The application uses RDS PostgreSQL and S3. Which combination of services achieves warm standby for this data tier?
- RDS cross-region read replica in eu-west-1 promoted during failover, and S3 Cross-Region Replication for the S3 buckets (Correct answer)
- AWS Database Migration Service continuously replicating to eu-west-1, and S3 versioning enabled on the primary bucket
- RDS automated backup restoration to eu-west-1 triggered by CloudWatch alarms, and S3 Batch Replication run hourly
- Aurora Global Database with eu-west-1 as a secondary region and S3 Multi-Region Access Points
Correct answer: RDS cross-region read replica in eu-west-1 promoted during failover, and S3 Cross-Region Replication for the S3 buckets
A cross-region RDS read replica maintains a continuously updated copy in eu-west-1 with typical replication lag under 1 minute; promotion to standalone primary takes 5-10 minutes, well within the 30-minute RTO. S3 CRR asynchronously replicates objects to the target region, keeping the storage tier in sync. DMS adds unnecessary complexity and cost for this use case. S3 versioning alone provides no replication. Backup restoration can take hours, violating the RTO. Aurora Global Database is a valid and arguably better option, but the question asks specifically about RDS PostgreSQL, and option A is the correct warm standby pattern for standard RDS.
Question 6: An application writes large files to S3 and then immediately reads them in a subsequent Lambda invocation triggered by S3 event notifications. Occasionally, the Lambda function fails with a 404 Not Found error when trying to read the file. Retries eventually succeed. What is the most likely cause and the correct architectural fix?
- S3 delivers event notifications before the object is fully indexed; add an SQS queue between S3 events and Lambda with a visibility timeout to allow for S3 strong consistency propagation (Correct answer)
- The Lambda function's IAM role lacks s3:GetObject permissions intermittently due to IAM eventual consistency
- S3 has eventual consistency for new object PUTs; implement a retry loop with exponential backoff in the Lambda function
- The S3 bucket is in a different region than the Lambda function, causing cross-region replication delays
Correct answer: S3 delivers event notifications before the object is fully indexed; add an SQS queue between S3 events and Lambda with a visibility timeout to allow for S3 strong consistency propagation
Since December 2020, Amazon S3 provides strong read-after-write consistency for all operations. However, S3 event notifications can be delivered before the object metadata is fully propagated in edge cases at extreme scale, or the issue may stem from the notification arriving and Lambda starting before the multipart upload is 100% committed. Using SQS as a buffer adds a configurable delay (via visibility timeout or message delay) ensuring the object is fully available before Lambda processes it. Option C is incorrect because S3 strong consistency was introduced in 2020, making the old eventual consistency model obsolete. IAM permissions do not fluctuate at runtime. Single-region operations have no replication delays.
AWS Design Resilient Architectures 4
A financial services company runs a critical payment processing application on EC2 instances behind an Application Load Balancer.
During peak transaction periods, the application experiences latency spikes.
The team wants to implement auto scaling but must ensure that in-flight transactions are never dropped when instances are terminated.
Which configuration achieves this?