A reserved instance is a billing commitment in which a cloud customer agrees to pay for a specific type of compute capacity for a one-year or three-year term in exchange for a significant discount compared with on-demand pricing. In cloud economics, it is one of the main commitment-based discounts, alongside savings plans and committed use discounts, and a central tool of FinOps practice.
Despite the name, a reserved instance is usually not a separate virtual machine. It is a pricing construct that the provider applies automatically to matching running instances on the bill. The term originates from Amazon EC2; Microsoft Azure uses reservations and Google Cloud uses committed use discounts for comparable mechanisms.
How a reserved instance discount is applied
When a reserved instance is purchased, the provider records a commitment defined by instance attributes: instance family and size, region, operating system and tenancy. Every billing hour, the provider looks for running instances that match these attributes and charges them at the reserved rate instead of the on-demand rate.
The commitment is paid whether or not matching instances run. An hour in which no matching capacity is used is wasted reservation, which is why utilization is the decisive metric. Regional reservations on Linux usually offer instance size flexibility: the discount can cover, for example, two smaller instances of the same family instead of one larger one, based on normalized size units.
| Attribute | Example | Effect on matching |
|---|---|---|
| Instance family and size | General-purpose, 4 vCPUs | Must match, with size flexibility in some cases |
| Region or zone | One region or one availability zone | Zonal scope can also reserve capacity |
| Operating system | Linux or Windows with license | Different prices per platform |
| Tenancy | Shared or dedicated hardware | Must match exactly |
| Term | One year or three years | Longer terms give larger discounts |
Payment options and reservation types
Reserved instances combine a payment option with a flexibility class. Paying more up front and accepting less flexibility both increase the discount, which can reach roughly 70% or more for three-year terms in some configurations, while one-year terms with no upfront payment typically save considerably less.
| Option | How it works | Discount level | Flexibility |
|---|---|---|---|
| All upfront | Entire term paid at purchase | Highest | Same as the chosen class |
| Partial upfront | Part paid at purchase, rest monthly | Middle | Same as the chosen class |
| No upfront | Monthly payments over the term | Lowest | Same as the chosen class |
| Standard class | Fixed instance family | Higher | Can often be resold on a marketplace |
| Convertible class | Exchangeable for other families | Lower | Adapts to changing workloads |
The choice of payment option is partly a finance question: paying all upfront ties up cash and is treated differently in accounting than monthly charges, so finance teams often take part in the decision.
Reserved instances compared with other pricing models
Reserved instances sit between on-demand flexibility and the deep but interruptible discounts of spot capacity. Newer commitment models trade some discount for broader applicability.
| Model | Commitment | Typical saving | Main risk |
|---|---|---|---|
| On-demand | None | Baseline price | Highest unit cost |
| Reserved instance | Specific attributes for 1 or 3 years | Large | Unused reservation if workloads change |
| Savings plan | Hourly spend amount for 1 or 3 years | Large, slightly lower in some cases | Spend commitment not fully used |
| Spot instance | None | Very large | Interruption at short notice |
Because savings plans apply across instance families, regions and even serverless compute, many organizations now prefer them for general compute. Reserved instances remain common for managed databases, caches and search clusters, where reservations are often the only commitment discount available, and where zonal capacity reservation matters.
Planning a reservation portfolio
Effective reservation planning starts from the steady baseline of usage, the capacity that runs around the clock regardless of traffic peaks. Peaks are better handled with autoscaling on on-demand or spot capacity. Teams usually analyze several months of usage history before buying, and purchase in staggered tranches rather than all at once.
| Situation | Recommended approach | Reason |
|---|---|---|
| Stable 24/7 production database | Three-year reservation | Predictable use maximizes the discount |
| Workload likely to be redesigned | One-year or convertible term | Limits the cost of changing direction |
| Mixed instance families | Savings plan instead of reservations | Discount follows changing families |
| Seasonal peaks | No reservation for peak capacity | Idle months would waste the commitment |
| Several business units | Central purchase with cost allocation | Shared discounts reduce waste |
Two metrics guide the portfolio: coverage, the share of eligible usage billed at reserved rates, and utilization, the share of purchased reservations actually used. A common target keeps utilization close to 100% while raising coverage gradually toward 70-90% of the steady baseline.
Common mistakes with reserved instances
Most reservation losses come from commitments that outlive the workload. The following mistakes appear regularly in cost reviews:
- Buying for current peak usage instead of the long-term baseline.
- Committing for three years to an architecture that is planned for migration.
- Forgetting expiry dates, so workloads silently return to on-demand prices.
- Ignoring operating system and tenancy, which leaves reservations matching nothing.
- Allocating costs poorly, so teams cannot see whose usage the discount covers.
Unused standard reservations can sometimes be resold on a provider marketplace, and convertible ones can be exchanged, but neither option recovers the full value. The safer habit is a quarterly reservation review that compares upcoming expiries, planned migrations and current utilization before any new purchase.
Put simply
A reserved instance is like a yearly pass for a server. Instead of paying the full hourly price whenever a server runs, a company promises to use a certain kind of server for one or three years and receives a much lower price in return.
The catch is that the promise must be paid even if the server is not needed later. It works best for systems that run all day, every day, such as a company’s main database.
In practice
A software company runs a customer platform on about 40 application servers and 6 database servers. Usage analysis over nine months shows that at least 28 application servers run continuously, while the rest scale up only during business hours. The database servers run at constant size around the clock.
The FinOps team buys a three-year reservation for the database servers and a one-year convertible reservation for 28 application servers, leaving peak capacity on demand. Monthly reports track utilization near 100% and coverage of the baseline. The company lowers its compute bill significantly while keeping the flexibility to change instance families when the application is modernized the following year.