SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company has a microservices application running on Amazon ECS with the EC2 launch type. Each service runs as an ECS service with a desired count of 4 tasks across two Availability Zones. The operations team wants to reduce cost during predictable low-traffic nights while maintaining availability. They also want to ensure that a sudden traffic spike during the day does not cause outages. Which solution should a solutions architect recommend?

⚠ Common exam trap

It's easy for candidates to confuse EC2 Auto Scaling of container instances with ECS Service Auto Scaling, assuming that adding instances automatically adjusts the number of running tasks.

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 ECS Service Auto Scaling with target tracking on CPU utilization, and schedule scaling actions to reduce the minimum capacity at night.

ECS Service Auto Scaling with target tracking plus scheduled scaling actions directly adjusts task count based on demand and predictable schedules. This reduces cost at night and scales out during spikes. Scaling only the EC2 instances, migrating to Fargate, or using multiple clusters do not provide the required responsive task-level scaling.

Answer analysis

Option-by-option breakdown

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

✓
Configure ECS Service Auto Scaling with target tracking on CPU utilization, and schedule scaling actions to reduce the minimum capacity at night.
Why this is correct
ECS Service Auto Scaling supports target tracking on metrics like CPU utilization and scheduled scaling actions. A scheduled action can lower the minimum task count at night, while target tracking scales out quickly during a daytime spike. This combination reduces cost during predictable low traffic and maintains availability during demand surges, meeting both requirements.
✗
Deploy the services on AWS Fargate and use scheduled scaling to set the desired count to 2 at night and 8 during the day.
Why it's wrong here
Migrating to Fargate is a significant change and the scenario does not require it. Scheduled scaling alone sets a fixed capacity for each period but does not react to unexpected spikes outside the schedule. A sudden traffic surge during the day could exceed the scheduled count, causing outages. This option does not provide the responsive scaling needed.
✗
Create a second ECS cluster for night-time traffic and use Amazon Route 53 weighted routing to shift traffic between clusters.
Why it's wrong here
Running two clusters adds operational complexity and does not automatically reduce task count at night or scale during spikes. Route 53 weighted routing distributes traffic but does not adjust ECS service capacity. This approach is not cost-effective for predictable low traffic and does not ensure availability during sudden demand increases.
✗
Use AWS Auto Scaling to scale the EC2 container instances in the cluster based on CPU, and set the ECS service desired count to a fixed value of 4.
Why it's wrong here
Scaling the EC2 container instances adjusts cluster capacity but does not change the number of running tasks. With a fixed desired count of 4, the service cannot scale out during a traffic spike, and it cannot scale in at night to save cost. This option fails both the cost reduction and spike handling requirements.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question