SAA-C03 Design Cost-Optimized Architectures Practice Question

A company runs a containerized API on Amazon ECS with AWS Fargate. Traffic is highly variable: it peaks during business hours and drops to near zero overnight. The team wants to pay only for what they use while keeping the API responsive during peaks. Which approach BEST optimizes cost for this workload?

⚠ Common exam trap

The trap here is treating a cheaper capacity type like Fargate Spot as the primary lever, when the workload's need for uninterrupted responsiveness makes demand-based scaling the real cost optimizer.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure Application Auto Scaling on the ECS service using target tracking on a metric such as average CPU or requests per task, with a minimum task count of one.

Variable traffic that peaks in the day and falls to near zero at night is the classic case for elastic horizontal scaling. Application Auto Scaling with target tracking grows and shrinks the ECS task count to follow demand, and because Fargate charges per task-second, scaling in overnight removes the cost of idle capacity. A low minimum keeps the API warm and responsive for the first requests of the day.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Run the tasks on Fargate Spot capacity and configure the service to scale out on demand.
Why it's wrong here
Fargate Spot lowers the per-task price but tasks can be reclaimed with a two-minute warning, which risks dropping live API requests during business-hour peaks. For a customer-facing API that must stay responsive, capacity interruption is unacceptable unless the service is designed for graceful draining. It reduces cost but at the expense of the availability the scenario requires, so it is not the best fit.
✓
Configure Application Auto Scaling on the ECS service using target tracking on a metric such as average CPU or requests per task, with a minimum task count of one.
Why this is correct
Application Auto Scaling with target tracking adjusts the desired task count to match demand, so the service scales out during business-hour peaks and scales in overnight when traffic nears zero. Setting a low minimum keeps a task ready to absorb the first requests, preserving responsiveness. Because Fargate bills per task-second, scaling in directly reduces spend, making this the best cost-and-performance balance.
✗
Migrate the workload to a single large EC2 instance running the containers with a 3-year Reserved Instance.
Why it's wrong here
A single instance creates a capacity and availability bottleneck, and a 3-year commitment locks in spend for a workload whose demand is variable and unpredictable. It also abandons the serverless scaling model of Fargate. Committing long term to fixed capacity for spiky traffic is the opposite of paying only for what is used, so this option increases both risk and cost.
✗
Provision a fixed task count sized for the highest observed peak and leave it running continuously.
Why it's wrong here
Sizing permanently for peak capacity means paying for idle tasks overnight when traffic drops to near zero. Fargate bills for provisioned task resources for as long as the tasks run, so this approach wastes money during the long low-traffic window. It guarantees responsiveness but ignores the variable traffic pattern, directly contradicting the goal of paying only for what is used.

Go deeper

SAA-C03 Design Cost-Optimized Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question