Most Cost-Effective Way to Scale a Stateless EC2 Analytics App?

SAA-C03 By islever Editorial Last updated Oct 13, 2026

Design high-performing and elastic compute solutions. Design cost-optimized compute solutions.

Short answer

D Create an Auto Scaling group from a launch template with a Spot Fleet and attach an Application Load Balancer for seamless, lowest-cost scaling.

Question

A company hosts a website analytics application on a single Amazon EC2 On-Demand Instance. The analytics application is highly resilient and is designed to run in stateless mode. The company notices that the application is showing signs of performance degradation during busy times and is presenting 5xx errors. The company needs to make the application scale seamlessly. Which solution will meet these requirements MOST cost-effectively?

Create an Amazon Machine Image (AMI) of the web application. Use the AMI to launch a second EC2 On-Demand Instance. Use an Application Load Balancer to distribute the load across the two EC2 instances.
Create an Amazon Machine Image (AMI) of the web application. Use the AMI to launch a second EC2 On-Demand Instance. Use Amazon Route 53 weighted routing to distribute the load across the two EC2 instances.
Create an AWS Lambda function to stop the EC2 instance and change the instance type. Create an Amazon CloudWatch alarm to invoke the Lambda function when CPU utilization is more than 75%.
Create an Amazon Machine Image (AMI) of the web application. Apply the AMI to a launch template. Create an Auto Scaling group that includes the launch template. Configure the launch template to use a Spot Fleet. Attach an Application Load Balancer to the Auto Scaling group. Correct Answer

Key Takeaways

This question tests whether you choose automatic horizontal elasticity with discounted Spot capacity over a fixed pair of instances or a vertical resize; the trap is option A, which looks resilient because of the ALB but can never scale beyond two On-Demand instances.

A stateless analytics application on a single EC2 On-Demand Instance is degrading and returning 5xx errors at peak load, and the company needs seamless, lowest-cost scaling. The answer is an Auto Scaling group built from a launch template and backed by a Spot Fleet, fronted by an Application Load Balancer.

Common mistake: Most candidates choose A — an AMI-launched second On-Demand Instance behind an Application Load Balancer — because it adds a load balancer and redundancy. It fails anyway: capacity is capped at two instances, scaling requires manual work, and nothing scales down when traffic drops, so it is neither seamless nor the most cost-effective.

Expert Analysis

Why the Answer Is Correct

Option D is the only choice that delivers both automatic elasticity and lower compute cost. The workload is explicitly stateless and highly resilient, which is exactly the precondition for spreading it across multiple instances and for tolerating Spot interruptions. An Auto Scaling group driven by a launch template adds and removes instances automatically as demand rises and falls, so the 5xx errors caused by a single saturated instance disappear without human intervention. The Spot Fleet supplies that extra capacity from spare EC2 capacity at a steep discount versus On-Demand, and the Application Load Balancer distributes traffic across healthy targets and health-checks them, absorbing any instance that is reclaimed. Together this satisfies 'scale seamlessly' and 'MOST cost-effectively' in one design.

Why the Other Options Are Wrong

Option A creates a second fixed On-Demand Instance behind an ALB; it doubles cost immediately, requires a manual AMI-and-launch operation to grow, and never releases capacity during quiet periods. Option B replaces the ALB with Route 53 weighted routing, which still relies on manually adjusted weights (and DNS TTL delays) to shift traffic, so it cannot react to a traffic spike and offers no cost benefit over A. Option C is vertical scaling: a CloudWatch alarm triggers a Lambda function that stops the instance and changes its type, which means downtime during the restart, a hard ceiling on how large the instance can get, and no reduction in cost or improvement in availability. None of A, B or C scales automatically or takes advantage of discounted capacity.

Community Comment Notes

All recorded voters selected option D. Razvan_C highlighted the often-missed half of elasticity, noting that with an Auto Scaling group capacity can also be scaled down on low demand so costs are saved. LeonSauveterre walked through each distractor, observing of option A that it "can't scale automatically during peak times" and that weighted routing in option B demands manual intervention to adjust weights or add instances. JA2018 listed three supporting reasons, including that statelessness makes the design work and that a Spot Fleet lets you use unused EC2 capacity at significantly lower cost than On-Demand.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a scenario pairs 'scale seamlessly' with 'MOST cost-effectively', shortlist options that combine a managed auto scaling service with a discounted capacity model such as Spot, and treat any option that fixes the instance count as a distractor. Check the wording for 'stateless' or 'highly resilient' — that phrase is the exam's permission slip for using Spot capacity.

Frequently Asked Questions

Why is a second On-Demand instance behind an ALB (option A) not the best answer?

It fixes capacity at two instances that must be scaled by hand, so it cannot react seamlessly to busy periods and never scales back down to save cost.

Does a Spot Fleet risk availability for this analytics application?

No — the app is stateless and highly resilient, and the Auto Scaling group plus ALB health checks replace reclaimed Spot capacity with new Spot or On-Demand instances.

More SAA-C03 FAQ →

Community Votes

100%

100% of anonymous learners picked answer D. 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

Razvan_C 👍 4 Answered D

With auto scalling group it can also scale down on low demand (costs saved)
LeonSauveterre 👍 3 Answered D

A - This can't scale automatically during peak times. B - Weighted routing is not ideal for seamless scaling because it requires manual intervention to adjust weights or add new instances. C - It introduces downtime during instance type changes, let alone scaling. D - (1) ASG dynamically adjusts the number of instances based on demand. (2) Spot Instances reduces costs significantly compared to On-Demand Instances. (3) ALB + ASG ensures efficient traffic routing to healthy instances.
JA2018 👍 2 Answered D

3 reasons why I will choose Option D: 1. Scalability: Auto Scaling groups are designed to automatically scale up or down the number of instances based on demand, which is ideal for handling fluctuating traffic during busy periods. 2. Cost-effectiveness: Using a Spot Fleet allows you to leverage unused EC2 capacity at significantly lower costs compared to On-Demand instances. 3. Stateless Application: Since the application is stateless, it can easily be scaled horizontally with multiple instances behind an Application Load Balancer without any data consistency issues

Reader comments & corrections

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

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