SQS Queue Depth Auto Scaling for Stateless Applications

SAA-C03 By islever Editorial Last updated

Design scalable and loosely coupled architectures.

Short answer

C Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on the number of items in the SQS queue.

Question

A solutions architect is designing the cloud architecture for a new stateless application that will be deployed on AWS. The solutions architect created an Amazon Machine Image (AMI) and launch template for the application. Based on the number of jobs that need to be processed, the processing must run in parallel while adding and removing application Amazon EC2 instances as needed. The application must be loosely coupled. The job items must be durably stored. Which solution will meet these requirements?
  1. Create an Amazon Simple Notification Service (Amazon SNS) topic to send the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on CPU usage.
  2. Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on network usage.
  3. Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on the number of items in the SQS queue. Correct Answer
  4. Create an Amazon Simple Notification Service (Amazon SNS) topic to send the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on the number of messages published to the SNS topic.

Key Takeaways

The exam tests the ability to match scaling triggers to workload characteristics; the common trap is choosing CPU or network metrics instead of the actual workload indicator (queue depth).

This question tests designing loosely coupled, scalable architectures using Amazon SQS and EC2 Auto Scaling. The correct solution uses queue depth metrics to dynamically adjust instance count based on job volume.

Common mistake: Option A is often chosen by candidates who confuse notification services with queuing, while Option B is selected by those who fail to link scaling policies directly to the job count metric.

Expert Analysis

Why the Answer Is Correct

To meet the requirement for durable storage and parallel processing, Amazon SQS is the appropriate service because it queues messages for later consumption, ensuring jobs are not lost if instances are unavailable. Amazon SNS is a pub/sub service that delivers messages immediately to subscribers, which does not provide the same level of durability or backpressure for stateless workers. Furthermore, the requirement to add/remove instances "based on the number of jobs" directly maps to scaling the Auto Scaling group based on the ApproximateNumberOfMessagesVisible metric from the SQS queue. This ensures the infrastructure scales precisely in proportion to the work load.

Why the Other Options Are Wrong

Option A uses SNS, which is not suitable for durable job storage as it pushes messages to all subscribers simultaneously without a built-in retry/dead-letter mechanism for individual job processing in this context. It also relies on CPU usage, which may not correlate linearly with job volume if jobs vary in complexity. Option B uses SQS but scales based on network usage; network traffic is an indirect and potentially noisy metric that doesn't accurately reflect the backlog size. Option D uses SNS again, failing the durability and decoupling requirements, and attempts to scale based on published messages, which measures input rate rather than processing load/backlog.

Community Comment Notes

Community consensus strongly supports Option C, with users noting that "SQS is your first cue then scaling based on the number of requests." One user highlighted that scaling based on network usage (Option B) could lead to "burst-caused downtime or other poor scaling decisions," emphasizing the need for direct correlation between the metric and the job count.

Official Reference

https://docs.aws.amazon.com/autoscaling/ec2/userguide/policy-criteria.html

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

Exam Strategy

Always look for keywords like 'durably stored' or 'queued' when deciding between SNS and SQS. When scaling requirements specify reacting to 'number of items' or 'jobs', prioritize custom metrics or queue depth over generic system metrics like CPU or Network.

Frequently Asked Questions

Why can't we use SNS topics for durable job storage?

SNS is a pub/sub messaging service that delivers messages to multiple subscribers instantly. It does not store messages for later retrieval or handle retries for failed consumers, making it unsuitable for durable job queuing.

Is CPU usage ever a good metric for scaling based on job count?

CPU usage is only a good proxy if each job has a consistent and predictable computational cost. If job complexity varies, queue depth (backlog) is a much more accurate indicator of the required compute capacity.

More SAA-C03 FAQ →

Community Votes

C
100%

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

Discussion 3 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 3

  1. dhewa 👍 3
    Answer is C: SQS is your first cue then scaling based on the number of requests
  2. LeonSauveterre 👍 2 Answered C
    SQS for sure, but I actually swaying between B and C. After a while, I can say now I'm sure that scaling based on network usage doesn't directly have anything to do with the number of jobs in the queue. Or worse, this could result in burst-caused downtime or other poor scaling decisions.
  3. [Removed] 👍 2 Answered C
    "Based on the number of jobs that need to be processed"

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