SAA-C03 Design Cost-Optimized Architectures Practice Question
A SaaS company runs a production API on an EC2 Auto Scaling group with steady demand 24/7. The team uses multiple instance types over time (they switch types during tuning) but the overall compute hours are stable. They want a cost reduction without committing to a specific instance type or size. Which AWS pricing option best meets the requirement?
⚠ Common exam trap
Candidates often confuse Compute Savings Plans with Reserved Instances, assuming that any savings plan requires a specific instance type, but Compute Savings Plans offer full flexibility across instance families and sizes within a region.
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
✓
Purchase a Compute Savings Plan for the region and commit to a dollar-per-hour amount
B is correct because a Compute Savings Plan provides the flexibility to change instance types, sizes, and even compute services (e.g., EC2, Fargate, Lambda) within a region while still receiving discounted rates (up to 66% vs. on-demand). This matches the requirement of reducing costs without committing to a specific instance type or size, as the plan is based on a dollar-per-hour commitment rather than instance family or tenancy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Buy EC2 Spot Instances for the Auto Scaling group to maximize savings
Why it's wrong here
Spot Instances can deliver substantial discounts, often 60-90% off on-demand, but AWS can reclaim them with a two-minute warning when it needs the capacity elsewhere. A production API with steady 24/7 demand is not fault-tolerant to interruption, and relying exclusively on Spot would create serious availability risk. Even with a diversified Spot allocation strategy, the workload still needs a reliable baseline, so this option is wrong for maximizing savings on a critical always-on service.
- ✓
Purchase a Compute Savings Plan for the region and commit to a dollar-per-hour amount
Why this is correct
A Compute Savings Plan lets you commit to a specific dollar-per-hour amount for a one- or three-year term in a given region, and the discount automatically applies to any EC2 instance family or size in that region. This is ideal for an Auto Scaling group with steady 24/7 API traffic because it captures predictable usage while preserving the flexibility to scale or change instance families without renegotiating the commitment. Usage above the committed amount simply runs at normal on-demand rates, so you still receive the lower rate on the bulk of your steady baseline.
- ✗
Purchase Reserved Instances that are limited to a single specific instance type in the Auto Scaling group
Why it's wrong here
A standard Reserved Instance commits you to a specific instance family and can provide strong discounts, but the benefit only applies when the Auto Scaling group launches instances that exactly match that family, size, and scope. If the group uses different instance families or you later change the launch template to a newer generation, the reservation becomes idle and loses value. For a region-based ASG that may rebalance across multiple instance types, this rigidity is the wrong contrast to the flexible, dollar-per-hour compute pricing of a Compute Savings Plan.
- ✗
Use on-demand only, and rely on Auto Scaling to reduce cost during low utilization
Why it's wrong here
Running entirely on on-demand instances is the most expensive option for predictable, high-utilization workloads because there is no lower tier for committed usage. Auto Scaling only reduces spend when there is low utilization, but a production API with steady 24/7 demand never experiences that contraction, so you would be paying the full on-demand price around the clock. A Savings Plan or Reserved Instance is designed specifically to lower the hourly cost of that always-on baseline, making this approach weak for cost optimization.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.