CTO and SVP Engineering at Xcitium, running production workloads across AWS and Google Cloud. Profile
Last reviewed 26 September 2026
AWS EC2 purchasing options determine what you pay for identical hardware. The instance is the same whichever you choose — same silicon, same performance, same launch process. Only the billing differs, and the gap between the cheapest and most expensive way to run the same workload is large enough to be an architectural decision rather than a finance one.
AWS currently presents three ways to buy compute, plus a separate set of options for reserving capacity.
The three AWS EC2 purchasing options
On-Demand
Pay by the second or hour with no commitment, no upfront payment and no minimum term. Start an instance, pay while it runs, stop paying when you terminate it.
It is the most expensive per hour and the right default for anything unpredictable: new workloads with no usage history, short-lived environments, spiky traffic you cannot forecast, and anything you may need to abandon. The premium buys optionality, and for genuinely uncertain workloads that is worth paying for.
Savings Plans
Commit to a consistent amount of compute spend per hour for one or three years, and receive a discount of up to 72% against On-Demand rates. Payment can be all upfront, partial upfront or no upfront, and the discount applies automatically to matching usage — there is nothing to attach or configure.
A Compute Savings Plan covers EC2 usage regardless of instance family, size, operating system, tenancy or region, and extends to AWS Fargate and AWS Lambda. That flexibility is the point: you can modernise onto newer instance generations, move regions or shift work to containers without losing the discount. AWS documents the mechanics in the Savings Plans user guide.
Spot
Bid on spare AWS capacity at a discount of up to 90% against On-Demand. The trade is that AWS can reclaim the instance with two minutes’ notice when it needs the capacity back.
That interruption is a hard constraint, not a risk to manage — but a great deal of real work tolerates it. Batch processing, CI builds, rendering, data transformation, containerised workers behind a queue and any horizontally scaled fleet that can lose a node are all natural fits. Spot instances covers how to architect for interruption.
Where Reserved Instances fit among AWS EC2 purchasing options
Reserved Instances were the primary commitment model on AWS for years, and a great deal of published guidance — including older articles on this site — still treats them as the default. They are no longer listed among the purchasing options on AWS’s own EC2 pricing page.
They still work, existing reservations are unaffected, and zonal reservations remain the mechanism that actually reserves capacity in a specific availability zone rather than merely discounting it. But for a new commitment, a Savings Plan covers the same usage with far fewer ways to strand the discount. Our guide to AWS EC2 Reserved Instances covers what to do if you hold some.
Capacity is separate from AWS EC2 purchasing options
A point that causes real confusion: Savings Plans and Spot are pricing mechanisms. Neither guarantees that capacity will be available when you ask for it. If your requirement is “this instance must launch in this availability zone at this moment,” that is a capacity problem with its own options — On-Demand Capacity Reservations, Capacity Blocks for machine learning workloads, and Dedicated Hosts.
Those combine with pricing rather than competing with it. You can hold a capacity reservation and have a Savings Plan discount apply to the usage. Teams that conflate the two end up buying commitments hoping for a capacity guarantee they never actually receive.
What each option actually costs you in flexibility
Price is the visible difference between the options. The one that matters more over a three-year horizon is what each locks you out of.
| On-Demand | Savings Plans | Spot | |
|---|---|---|---|
| Commitment | None | 1 or 3 years | None |
| Relative cost | Highest | Substantially lower | Lowest |
| Can be interrupted | No | No | Yes, 2 minutes notice |
| Survives an instance family change | n/a | Yes | n/a |
| Billed when unused | No | Yes | No |
| Best for | Unpredictable or short-lived work | Steady-state baseline | Interruption-tolerant work |
The row worth dwelling on is “billed when unused.” It is the only one where a purchasing decision can cost you more than doing nothing, and it is why the baseline calculation matters more than the headline discount percentage.
Choosing between AWS EC2 purchasing options
The useful framing is not “which option is cheapest” but “how much of this workload is predictable.” Most fleets want all three:
- Establish the baseline. Look at what you have run continuously for the past several months. That floor is what a Savings Plan should cover — and no more, because committing above the baseline means paying for compute you do not use.
- Put interruption-tolerant work on Spot. Batch and CI fleets are usually the largest unexploited saving, because they are priced as though they need guarantees they do not need.
- Leave the variable top layer On-Demand. Peaks, experiments and anything short-lived. Paying the premium on a small fraction of hours is cheaper than committing to capacity you rarely use.
- Right-size before committing. A three-year commitment on an oversized fleet locks in the waste for three years. Fix sizing first — see choosing EC2 instance types.
- Turn off what nobody uses. No purchasing option beats not running the instance. Scheduling non-production fleets to working hours typically removes around two thirds of their hours outright.
Common mistakes with AWS EC2 purchasing options
- Committing to peak instead of baseline. Commitments are billed whether used or not. Over-commitment is the one mistake that makes a cost-saving exercise increase costs.
- Treating Spot as unreliable rather than interruptible. These are different things. Spot is reliable at the fleet level if the architecture expects nodes to disappear.
- Renewing a Reserved Instance on autopilot. Expiry is the natural moment to reassess, and the answer has changed since the original purchase.
- Buying commitments before measuring. Cost Explorer shows actual steady-state usage. Guessing at the baseline is how teams end up committed to the wrong number.
- Assuming a discount guarantees capacity. It does not, and finding that out during an incident is expensive.
Estimate any combination before committing to it with the AWS EC2 calculator, which will model committed-use pricing alongside On-Demand so you can see the difference on your own numbers rather than on a headline percentage.