SAA-C03 Design Cost-Optimized Architectures Practice Question

A team runs a containerized API on Amazon ECS on Fargate in a single Region. Traffic is steady during business hours but drops to near zero overnight, and the team wants to reduce cost without rewriting the application. The team already uses Application Load Balancer and CloudWatch. Which two actions will reduce cost while keeping the API available? (Choose two.)

⚠ Common exam trap

The trap here is assuming Fargate has no Spot option or that scaling only adjusts tasks, when in fact Fargate Spot and Application Auto Scaling target tracking both reduce cost while keeping the service available.

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

✓

Use Fargate Spot capacity for a portion of the ECS tasks and keep a baseline of on-demand Fargate tasks behind the load balancer.

Combining Fargate Spot for part of the fleet with a small on-demand baseline lowers the hourly compute rate while preserving availability, and target tracking on ALB request count per target shrinks the task count overnight so the service pays only for needed capacity. Together they reduce cost without rewriting the application and keep the API reachable through the load balancer.

Answer analysis

Option-by-option breakdown

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

✗
Reduce the Fargate task CPU and memory to the minimum supported values for all tasks regardless of load.
Why it's wrong here
Fargate pricing is based on the vCPU and memory configured for the task, so undersizing tasks can reduce cost, but setting the minimum for all tasks regardless of load risks CPU throttling and application errors during business hours. It is not a safe way to preserve availability and does not adapt to the overnight drop in traffic.
✓
Use Fargate Spot capacity for a portion of the ECS tasks and keep a baseline of on-demand Fargate tasks behind the load balancer.
Why this is correct
Fargate Spot offers up to 70% lower cost for interruptible tasks, and mixing it with a small on-demand baseline preserves availability when Spot capacity is reclaimed. Because the API runs behind an ALB with multiple tasks, a reclaimed Spot task is replaced and traffic continues, making this a valid cost reduction.
✗
Switch the ECS service launch type to EC2 and purchase 3-year All Upfront Reserved Instances for the cluster.
Why it's wrong here
Moving to EC2 requires managing instances and paying for capacity around the clock, and a 3-year All Upfront reservation for overnight-idle capacity is a poor fit for a workload that drops to near zero. It adds operational overhead and does not reduce cost for the actual usage pattern.
✓
Configure ECS Service Auto Scaling with a target tracking policy on ALB request count per target to scale tasks down overnight.
Why this is correct
Target tracking on ALB request count per target scales the task count to match demand, so overnight the service runs fewer Fargate tasks and pays only for what is needed. This directly reduces cost while keeping at least the minimum task count to serve traffic, and it is a supported Application Auto Scaling policy.
✗
Enable ECS Exec on all tasks and remove the Application Load Balancer to save on ALB hourly charges.
Why it's wrong here
ECS Exec is a debugging feature for running commands in containers and has no cost-optimization effect. Removing the ALB would eliminate the entry point that distributes traffic and enables health checks, so the API would lose availability and scaling signals, which violates the requirement to keep the API available.

Go deeper

SAA-C03 Design Cost-Optimized Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question