AWS Design Resilient Architectures 6 — Questions and Answers
Question 1: A media streaming company experiences unpredictable traffic spikes during live events. Their application tier runs on EC2 instances behind an Application Load Balancer. During a recent event, the Auto Scaling group took 8 minutes to provision new instances, causing degraded performance. Which combination of strategies would BEST reduce scale-out latency?
- Use predictive scaling with warm pools to pre-initialize instances before anticipated spikes (Correct answer)
- Increase the cooldown period and use step scaling policies for faster reactions
- Switch to a Network Load Balancer and use scheduled scaling based on historical patterns
- Enable detailed monitoring and reduce the Auto Scaling evaluation period to 10 seconds
Correct answer: Use predictive scaling with warm pools to pre-initialize instances before anticipated spikes
Predictive scaling uses machine learning to forecast demand and proactively scales capacity before it's needed. Warm pools keep pre-initialized EC2 instances in a stopped or running state, dramatically reducing scale-out time from minutes to seconds since instances are already bootstrapped. This combination addresses both anticipating the spike (predictive scaling) and eliminating instance initialization delay (warm pools). Increasing cooldown periods would make scaling slower, not faster. NLB doesn't reduce provisioning time. Reducing the evaluation period to 10 seconds isn't a supported CloudWatch configuration for Auto Scaling.
Question 2: An e-commerce platform uses DynamoDB for its product catalog. During flash sales, a small subset of popular items receives 90% of read traffic, causing hot partition issues and throttling. The application uses eventually consistent reads. Which solution eliminates the hot partition problem with the LEAST operational overhead?
- Implement DynamoDB Accelerator (DAX) as a caching layer in front of DynamoDB (Correct answer)
- Add a random suffix to partition keys and aggregate results in the application layer
- Enable DynamoDB auto-scaling and increase the provisioned read capacity units
- Distribute reads across multiple global tables replicas in different AWS regions
Correct answer: Implement DynamoDB Accelerator (DAX) as a caching layer in front of DynamoDB
DAX is a fully managed, highly available, in-memory cache specifically for DynamoDB that delivers microsecond read performance. Hot partition issues occur because the same partition key is read repeatedly — DAX absorbs these repetitive reads at the cache layer before they ever reach DynamoDB, eliminating throttling with minimal operational overhead and no application-side key sharding logic. Adding random suffixes requires scatter-gather queries and significant application changes. Auto-scaling with provisioned capacity still doesn't prevent hot partition throttling since the problem is partition-level, not table-level. Global tables add cross-region replication complexity and don't solve hot partitions within a region.
Question 3: A financial services company runs a critical payment processing application across two Availability Zones. They want to achieve a Recovery Time Objective (RTO) of less than 1 minute and a Recovery Point Objective (RPO) of zero for their RDS database. Which configuration meets BOTH objectives?
- Enable RDS Multi-AZ with automatic failover and use Amazon Aurora with read replicas
- Configure RDS Multi-AZ deployment — the standby replica is synchronously replicated and failover is automatic (Correct answer)
- Create daily RDS snapshots and use AWS Backup to replicate them cross-region within 1 minute
- Deploy RDS with read replicas in both AZs and promote a read replica during failure
Correct answer: Configure RDS Multi-AZ deployment — the standby replica is synchronously replicated and failover is automatic
RDS Multi-AZ uses synchronous replication to a standby instance in a different AZ, ensuring RPO of zero (no data loss since every write is confirmed on the standby before acknowledging to the application). Automatic failover typically completes in 60-120 seconds, meeting an RTO under 2 minutes — and AWS SLA targets sub-60-second DNS failover for most engines. Read replicas use asynchronous replication (non-zero RPO) and require manual promotion (longer RTO). Daily snapshots have RPO of up to 24 hours and cannot restore in 1 minute. Aurora is excellent but the question specifically asks about RDS Multi-AZ which already achieves the stated objectives without adding Aurora complexity.
Question 4: A SaaS company's microservices architecture uses SQS queues between services. During downstream service outages, unprocessed messages accumulate and eventually expire, causing permanent data loss. What is the MOST resilient pattern to prevent message loss without modifying the upstream producer services?
- Increase the SQS message retention period to 14 days and enable long polling on consumers
- Configure a Dead Letter Queue (DLQ) with a redrive policy and set up alerting to replay messages after recovery (Correct answer)
- Switch from SQS Standard to SQS FIFO queues to guarantee message ordering during recovery
- Enable SQS server-side encryption and configure VPC endpoints for more reliable delivery
Correct answer: Configure a Dead Letter Queue (DLQ) with a redrive policy and set up alerting to replay messages after recovery
A Dead Letter Queue with a redrive policy captures messages that fail processing after a configured number of attempts, preventing them from expiring in the main queue. After the downstream service recovers, messages can be replayed from the DLQ back to the source queue using the SQS console or StartMessageMoveTask API. This requires no changes to upstream producers and provides a durable safety net for all failed/unprocessed messages. Increasing retention alone doesn't prevent loss if the outage exceeds the retention period or if maxReceiveCount is reached. FIFO queues address ordering, not durability during outages. SSE and VPC endpoints address security and network routing, not message durability.
Question 5: An organization runs a multi-tier web application in a single AWS Region. They need to design for regional disaster recovery with an RTO of 4 hours and RPO of 1 hour, while minimizing costs. Which DR strategy BEST fits these requirements?
- Multi-site active/active with identical infrastructure in two regions behind Route 53 latency routing
- Warm standby with a scaled-down but functional environment in a secondary region, with hourly RDS snapshots copied cross-region
- Pilot light with core components (database replication) running in a secondary region and AMIs pre-built for rapid scale-out (Correct answer)
- Backup and restore using AWS Backup with cross-region copy, restoring EC2 instances from AMIs within the RTO window
Correct answer: Pilot light with core components (database replication) running in a secondary region and AMIs pre-built for rapid scale-out
Pilot light keeps only the most critical core components running in the secondary region (typically the database, replicating continuously for sub-1-hour RPO), with application tier AMIs pre-built and ready to launch. This achieves RPO of under 1 hour via continuous DB replication and RTO of 4 hours since instances can be launched from pre-built AMIs and scaled out — all at significantly lower cost than warm standby or multi-site. Warm standby would meet the requirements but costs more than needed since it maintains a scaled-down running fleet. Multi-site active/active is the most expensive option and overkill for a 4-hour RTO. Backup and restore typically cannot reliably achieve 4-hour RTO for multi-tier applications at scale.
Question 6: A global retail application uses an Application Load Balancer with EC2 instances. The security team requires that the application remain available even if AWS experiences an Availability Zone failure AND if a single EC2 instance becomes unhealthy due to application errors (not infrastructure failure). Which combination of ALB features addresses BOTH failure scenarios?
- Enable cross-zone load balancing and configure ALB access logs to detect unhealthy instances
- Deploy instances across at least 3 AZs and configure health checks with appropriate thresholds to detect application-level failures (Correct answer)
- Use ALB with sticky sessions enabled and configure Auto Scaling to replace terminated instances
- Enable ALB deletion protection and configure AWS Shield Standard for DDoS resilience
Correct answer: Deploy instances across at least 3 AZs and configure health checks with appropriate thresholds to detect application-level failures
Deploying across 3+ AZs means losing one entire AZ still leaves 2 AZs serving traffic — the ALB automatically stops routing to the failed AZ once instances there fail health checks. ALB health checks configured to probe an application endpoint (not just TCP) with appropriate healthy/unhealthy thresholds detect application-level failures (e.g., returning 5xx errors) and stop routing to those specific instances, even if the underlying EC2 instance is running. Together these address both the AZ-level and instance-level failure scenarios. Cross-zone load balancing affects distribution evenly but doesn't by itself address AZ failure resilience. Sticky sessions can reduce availability since users are tied to specific instances. Deletion protection and Shield address accidental deletion and DDoS, not the described failure modes.
AWS Design Resilient Architectures 6
A media streaming company experiences unpredictable traffic spikes during live events.
Their application tier runs on EC2 instances behind an Application Load Balancer.
During a recent event, the Auto Scaling group took 8 minutes to provision new instances, causing degraded performance.
Which combination of strategies would BEST reduce scale-out latency?