Scaling EC2 Based on SQS Queue Depth

SAA-C03 By islever Editorial Last updated

Design scalable and loosely coupled architectures.

Short answer

D Use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier instances. Use the ApproximateNumberOfMessages attribute to determine when to scale.

Question

A company has a three-tier web application that processes orders from customers. The web tier consists of Amazon EC2 instances behind an Application Load Balancer. The processing tier consists of EC2 instances. The company decoupled the web tier and processing tier by using Amazon Simple Queue Service (Amazon SQS). The storage layer uses Amazon DynamoDB. At peak times, some users report order processing delays and halls. The company has noticed that during these delays, the EC2 instances are running at 100% CPU usage, and the SQS queue fills up. The peak times are variable and unpredictable. The company needs to improve the performance of the application. Which solution will meet these requirements?
  1. Use scheduled scaling for Amazon EC2 Auto Scaling to scale out the processing tier instances for the duration of peak usage times. Use the CPU Utilization metric to determine when to scale.
  2. Use Amazon ElastiCache for Redis in front of the DynamoDB backend tier. Use target utilization as a metric to determine when to scale.
  3. Add an Amazon CloudFront distribution to cache the responses for the web tier. Use HTTP latency as a metric to determine when to scale.
  4. Use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier instances. Use the ApproximateNumberOfMessages attribute to determine when to scale. Correct Answer

Key Takeaways

The question tests the ability to identify the correct Auto Scaling metric for an SQS-decoupled system, specifically avoiding static CPU metrics when queue depth is the true bottleneck indicator.

This question addresses how to scale EC2 instances in a decoupled architecture using Amazon SQS as a buffer. The correct solution leverages target tracking scaling policies based on queue metrics to handle unpredictable traffic spikes.

Common mistake: Many learners choose Option A (scheduled scaling or CPU-based scaling) because they assume predictable patterns or focus on the symptom (high CPU) rather than the cause (queue backlog). Scheduled scaling fails due to unpredictability, and CPU scaling doesn't account for variable processing times per message.

Expert Analysis

Why the Answer Is Correct

The application bottleneck is in the processing tier, indicated by 100% CPU usage and a filling SQS queue. Since peak times are variable and unpredictable, scheduled scaling (Option A) is ineffective. Option D uses a target tracking policy with the ApproximateNumberOfMessagesVisible metric, which directly correlates the number of pending tasks with the required compute capacity. This ensures that instances scale out exactly when work accumulates, preventing delays.

Why the Other Options Are Wrong

Option A relies on scheduled scaling, which cannot adapt to unpredictable peaks, and CPU utilization, which may not reflect the actual workload if messages vary in complexity. Option B suggests adding ElastiCache, but this only helps with read-heavy database operations, not the processing bottleneck causing queue buildup. Option C adds CloudFront for the web tier, which does nothing to address the processing tier's inability to keep up with incoming orders.

Community Comment Notes

Community consensus strongly supports Option D. As user LeonSauveterre noted, "CPU utilization is not an accurate metric... There could be just one task but it takes quite a while to process." User FlyingHawk emphasized that since peaks are unpredictable, scheduled scaling is incorrect. Most users identified the processing tier as the clear bottleneck, dismissing caching solutions as irrelevant to the specific failure mode described.

Official Reference

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always look for the decoupling mechanism in the architecture. If SQS is present, the primary scaling trigger should often be related to queue depth (ApproximateNumberOfMessages), especially when the problem describes backlogs or delays in processing.

Frequently Asked Questions

Why not use CPU utilization to scale?

CPU utilization might remain high even if there are no messages, or low if a single message is complex. Queue depth directly reflects the backlog needing processing.

Can ElastiCache solve this delay issue?

No. ElastiCache speeds up database reads. It does not help the processing tier consume messages from SQS faster, which is the stated bottleneck.

More SAA-C03 FAQ →

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 6

  1. EllenLiu 👍 3 Answered D
    The bottleneck is from the processing tier.
  2. FlyingHawk 👍 2 Answered D
    The bottleneck is at the processing tier, B and C are incorrect, processing tier instances are running at 100% CPU usage, and the SQS queue fills up. Because the peak times are variable and unpredictable, we should use the EC2 Auto Scaling target tracking policy to scale out the processing tier instances based on the size of the queue, A uses scheduled scaling for Amazon EC2 Auto Scaling is incorrect.
  3. LeonSauveterre 👍 2 Answered D
    Just scale base on how many tasks left in the queue. CPU utilization is not an accurate metric. There could be just one task but it takes quite a while to process, in which case scaling is unnecessary.
  4. dragossky 👍 1 Answered B
    Yes, ElastiCache can be used with DynamoDB to improve the performance and scalability of read-heavy or frequently accessed workloads. Amazon ElastiCache is a fully managed in-memory data store that supports popular caching engines such as Memcached and Redis.
  5. GOTJ 👍 1 Answered D
    Check this out: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
Show 1 more comment
  1. aragon_saa 👍 2 Answered D
    Answer is D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide