Choose compute pricing from the workload's behaviour, not the size of the company. A small team may have a stable production baseline. A large enterprise may have an experiment that should stay flexible. Both need to know what can stop, what must remain available, and what is likely to change before a commitment expires.
This guide covers AWS compute purchasing choices. Storage, database, network, and software charges need their own analysis. Establish cost ownership and a usage baseline before choosing a discount.
Write down the workload constraints first
- Demand: separate the minimum capacity needed across normal operating periods from peaks and temporary environments.
- Interruption: decide whether a job can checkpoint, retry, or wait for replacement capacity without breaking its deadline.
- Change: record likely region, instance family, platform, or architecture changes during the commitment term.
- Finance: agree the currency, payment timing, and acceptable unused-commitment exposure.
Reduce unused capacity before pricing the remainder. A commitment purchased against an oversized estate can make subsequent rightsizing less valuable because the payment obligation remains.
Compare the purchasing options
| Model | Useful when | Main constraint |
|---|---|---|
| On-Demand | Usage is uncertain, temporary, or changing. | You pay the applicable usage rate without a long-term compute commitment. |
| Savings Plans | A measured baseline of eligible usage will persist. | A spending commitment applies for one or three years; eligible usage depends on plan type. |
| EC2 Reserved Instances | Expected EC2 usage matches the reservation attributes. | The billing discount depends on matching usage and reservation terms. |
| EC2 Spot | Work can tolerate interruption and variable capacity. | Capacity can be reclaimed; retry and fallback must be designed. |
Savings Plans exchange a one- or three-year hourly spending commitment for reduced rates on eligible usage. Compare the plan's eligibility and flexibility with expected architecture changes. A compute discount does not cover every charge on the account.
EC2 Reserved Instances are primarily a billing discount on matching usage, not a way to schedule an instance for office hours. Their term is one or three years. Do not assume that a discounted rate removes the cost of hours you do not use.
EC2 Spot prices are set by AWS, rather than by a bidding contest. Spot suits work that can tolerate capacity loss, such as retryable batch jobs. A lower rate alone is not enough to place an irreplaceable stateful workload on interruptible capacity.
Test commitment risk before buying
Use representative usage history and include low-demand periods. Compare existing coverage, expected changes, and the cost if the workload shrinks or moves. Keep burst demand separate from the stable baseline. Revisit the calculation after rightsizing or migration.
For a simplified hypothetical comparison, assume identical eligible compute costs 1.00 currency unit per hour On-Demand or 0.70 per hour under a commitment paid for every hour. Over an illustrative 720-hour month, the commitment costs 504. On-Demand costs less below 504 used hours and more above that point. At 360 used hours it costs 360; at 600 it costs 600. These are invented rates for arithmetic, not AWS prices or a savings forecast.
The comparison excludes storage, licences, taxes, other discounts, and operational differences. An actual decision must use current rates for the region, configuration, plan, and term. Include the engineering cost of making a workload interruption-tolerant before comparing it with Spot.
Use a mix when the workload has several demand patterns
A hypothetical service could keep an uncertain baseline On-Demand while collecting evidence, later commit only the portion expected to remain, and use interruptible capacity for retryable background jobs. The mix follows workload constraints; it should not be an organisation-wide rule that every resource must use one purchasing model.
Review commitment utilisation and coverage, expiry dates, and planned platform changes. Schedule stoppable development environments independently of discount purchasing. Use the AWS workload cost review to assess the rest of the architecture, and check charges beyond compute before approving a projected saving. For a planned move to AWS, include the pricing assumptions in the migration assessment.