Start with four separate questions
Architecture questions often mix pricing, capacity and availability language. Untangle them before selecting an answer. On-Demand is the flexible baseline with no long-term commitment. Savings Plans and Reserved Instances are commitment-based billing models. Spot Instances use spare EC2 capacity and can be interrupted by AWS.
1. Is the usage steady?
A long-running baseline may justify a one- or three-year commitment. A temporary project or uncertain migration may need On-Demand flexibility.
2. Will the compute shape change?
If teams may change instance family, Region, operating system or move from EC2 to Fargate or Lambda, Compute Savings Plans provide broader flexibility.
3. Can the work be interrupted?
Fault-tolerant batch processing, render farms and distributed workers can use Spot when they checkpoint, retry and diversify capacity.
4. Is capacity guaranteed?
A discount does not automatically reserve capacity. Treat pricing benefits and the need to launch in a specific Availability Zone as separate decisions.
SAA-C03 anchor: choose the pricing model from workload behavior. Do not infer high availability, disaster recovery or guaranteed capacity from the word “reserved.”
Compare what each option actually changes
Compute Savings Plans
A Compute Savings Plan is based on a dollar-per-hour commitment rather than a specific instance configuration. AWS applies eligible discounts automatically. This makes the model useful when a predictable compute baseline remains but the implementation may change—for example, moving from one EC2 family to another, changing Region or modernizing part of the workload to Fargate or Lambda.
EC2 Instance Savings Plans
This plan applies to a chosen EC2 instance family in a Region. It allows size, operating system and tenancy changes within the eligible family, but it is less portable than a Compute Savings Plan. The tradeoff is commonly a stronger discount for a more specific commitment.
EC2 Reserved Instances
An EC2 Reserved Instance is a billing discount, not a separate virtual machine. Standard RIs suit stable configurations; Convertible RIs permit exchanges under AWS rules but generally trade some discount for flexibility. Regional and zonal scope also matter. Do not assume every RI automatically solves a capacity requirement.
Spot Instances
Spot uses spare capacity. AWS can interrupt an instance when that capacity is needed, normally providing an interruption notice two minutes beforehand; a rebalance recommendation may arrive earlier when interruption risk rises. Design the application to checkpoint progress, retry work and spread requests across instance types and Availability Zones. Spot is not covered by Savings Plans.
Architecture scenarios and defensible answers
Steady web baseline with unpredictable traffic peaks
Cover a conservative baseline with a Savings Plan and use On-Demand or suitably designed Spot capacity for bursts. Do not commit to the maximum observed peak: an unused hourly commitment can erase expected savings.
Company may move EC2 workloads between Regions and adopt Fargate
A Compute Savings Plan matches the modernization requirement better than a configuration-specific EC2 commitment because eligible pricing can follow the supported compute changes.
Nightly image processing can restart individual tasks
Use Spot workers across multiple suitable instance types and Availability Zones. Store job state outside the instance, make tasks idempotent and allow the queue to retry interrupted work.
Critical launch must obtain EC2 capacity in one Availability Zone
Evaluate an On-Demand Capacity Reservation for the capacity requirement. Apply an eligible Savings Plan separately for the billing discount. This is the classic distinction between capacity assurance and price reduction.
Short proof of concept ends in eight weeks
Use On-Demand unless another existing organization-level commitment already covers the usage. A new one- or three-year purchase would conflict with the short and uncertain requirement.
Real-world cost issue: the commitment is high but savings are low
A team buys a large Compute Savings Plan based on a temporary peak. Two months later the workload is rightsized and part of it moves to Spot. The bill still includes the hourly Savings Plans commitment, while Spot spend neither receives the Savings Plans discount nor consumes that commitment.
The lesson is architectural as well as financial: a commitment purchase should follow workload stabilization, not substitute for rightsizing, scheduling or an interruption-tolerant Spot design.
Translate SAA-C03 wording into the right choice
- “Steady compute usage, instance family may change” points toward a Compute Savings Plan.
- “Stable EC2 family in one Region” can point toward an EC2 Instance Savings Plan.
- “Fault-tolerant, flexible start time, lowest compute cost” points toward Spot.
- “Must launch in this Availability Zone” introduces a capacity reservation requirement, not merely a billing discount.
- “No long-term commitment” points toward On-Demand.
- “Move between EC2, Fargate and Lambda” favors Compute Savings Plans over EC2-only options.
Fast decision rule
Predictable baseline: evaluate a Savings Plan or RI. Changing compute architecture: prefer the flexibility of a Compute Savings Plan. Interruptible work: use Spot with retries and diversification. Short or uncertain use: stay On-Demand. Capacity assurance: solve it separately.
Official AWS references
Frequently asked questions
Do Savings Plans reserve EC2 capacity?
No. Savings Plans provide a billing discount, not a capacity reservation. If a workload must launch in a particular Availability Zone, evaluate an On-Demand Capacity Reservation separately; eligible usage can still receive Savings Plans pricing.
Can a Savings Plan discount Spot Instance usage?
No. Spot usage is already priced separately. AWS states that Savings Plans do not apply to Spot usage, and Spot spend does not consume a Compute Savings Plans commitment.
When is an EC2 Reserved Instance preferable to a Compute Savings Plan?
An EC2 Reserved Instance can fit when the organization requires RI-specific features or has a stable, well-understood EC2 configuration. A Compute Savings Plan is generally more flexible across instance families, Regions, operating systems, tenancy, Fargate and Lambda.
Should every steady workload be covered by a long-term commitment?
Not automatically. Review historical usage, business certainty, utilization and modernization plans. Commit only to a conservative baseline that is likely to remain in use; usage above the commitment can continue at On-Demand rates.