SOA-C02 Cost and Performance Optimization Practice Question

A company runs a web application on EC2 instances behind an Application Load Balancer. The application experiences unpredictable traffic spikes. Which AWS service should be used to automatically adjust the number of EC2 instances based on demand, optimizing cost and performance?

⚠ Common exam trap

Many candidates confuse the monitoring service (CloudWatch) with the scaling service, or assume Elastic Load Balancing can handle scaling by itself, but neither directly adjusts instance count—only AWS Auto Scaling performs the actual scaling actions.

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

✓

AWS Auto Scaling

AWS Auto Scaling is the correct service because it automatically adjusts the number of EC2 instances in response to demand, using scaling policies based on metrics like CPU utilization or request count. This ensures that the application can handle traffic spikes without manual intervention, optimizing both cost (by scaling down during low demand) and performance (by scaling up during spikes). The service integrates directly with the Application Load Balancer to register and deregister instances as needed.

Answer analysis

Option-by-option breakdown

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

✓
AWS Auto Scaling
Why this is correct
AWS Auto Scaling is the correct service because it directly manages the size of an EC2 Auto Scaling group by launching or terminating instances in response to conditions you define. It uses scaling policies (e.g., step, target tracking, or scheduled scaling) that rely on CloudWatch metrics, such as CPU utilization or request count, to automatically adjust capacity. This is the only option here that actually performs the act of scaling EC2 instances, maintaining both performance and cost efficiency.
✗
Amazon CloudWatch
Why it's wrong here
Amazon CloudWatch is a monitoring and observability service that collects metrics, logs, and events from AWS resources and can trigger alarms based on thresholds. While CloudWatch provides the metric data and alarm notifications that Auto Scaling uses as input for scaling decisions, it does not itself launch or terminate EC2 instances. It is the data plane and alarm engine, not the execution mechanism for scaling, so it is incorrect as the service that automatically adjusts instance counts.
✗
Elastic Load Balancing
Why it's wrong here
Elastic Load Balancing distributes incoming application traffic across multiple EC2 instances and performs health checks to route requests only to healthy targets. It improves fault tolerance and availability but does not modify the number of instances; its role is to route traffic to whatever instances exist. Although ELB can expose metrics (e.g., RequestCount) that Auto Scaling can use, it is not the component that performs scaling actions, making it an incorrect answer for auto-scaling EC2 instances.
✗
AWS Lambda
Why it's wrong here
AWS Lambda is a serverless compute service that runs code in response to events and automatically manages its own execution environment, but it is completely unrelated to managing EC2 instance capacity. It cannot add or remove instances in an EC2 Auto Scaling group natively; any integration would require custom code using AWS SDKs to call Auto Scaling APIs, which is not the purpose of Lambda. Therefore, it is incorrect because it does not provide native EC2 instance scaling capabilities.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question