Reserved Instances: How AWS and Azure Reservations Work

A reserved instance is not a server. AWS describes Reserved Instances as “a billing discount applied to the use of On-Demand Instances in your account”, and those instances must match attributes such as instance type and Region to receive it. Azure Reservations work the same way: Microsoft states that a reservation “provides a billing discount and doesn’t affect the runtime state of your resources.” You commit to a one-year or three-year term, and the provider lowers the rate on matching usage in return.

That framing matters because it explains every trap below. The discount follows usage, but the charge follows the calendar.

What you are actually buying on AWS

On AWS, four attributes set the price of an EC2 Reserved Instance: instance type, Region, tenancy and platform (operating system). Beyond that you choose:

• Term: one year (defined as 31,536,000 seconds) or three years. The three-year term carries the bigger discount.
• Offering class: a Standard RI gives a larger discount but cannot be exchanged; a Convertible RI can be exchanged for a different configuration.
• Payment option: All Upfront, Partial Upfront or No Upfront.

The payment options read like financing choices, but AWS’s own definitions show they are all the same commitment. With All Upfront there are no further charges “regardless of hours used”. With Partial Upfront the remaining hours are billed at a discounted hourly rate “regardless of whether the Reserved Instance is being used”. With No Upfront “you are billed a discounted hourly rate for every hour within the term, regardless of whether the Reserved Instance is being used.” You also cannot cancel an RI after purchase, although AWS notes you might be able to modify, exchange or sell it.

AWS itself now recommends Savings Plans over Reserved Instances for most compute, because a Savings Plan commits to a dollar amount per hour rather than a specific configuration. See Savings Plans for how that differs.

How Azure applies a reservation

Azure reservations cover a range of products and, per Microsoft, can reduce resource costs “by up to 72% from pay-as-you-go prices.” The discount is applied hourly (Azure Databricks is the documented exception) and Microsoft is explicit about unused hours: a reservation discount is “use-it-or-lose-it”. If no matching resource runs in an hour, that hour’s reserved quantity is lost and cannot be carried forward. When you shut a resource down, the discount moves automatically to another matching resource in the reservation’s scope; if none exists, the reserved hours are lost.

Why stopping reserved capacity does not save money

Because the reservation bills every hour of the term, stopping the instance it covers does not reduce what you pay for the reservation. It only lowers your utilisation. The instance’s own compute charge was already covered by the discount, so switching it off at night turns reserved hours into wasted hours.

This is the core interaction between reservations and scheduling. They are not competing tactics applied to the same machine. They cover different slices of your estate:

1. Schedule first. Put anything that does not need to run around the clock (development, test, demo, training environments) on an off-hours schedule.
2. Measure what is left. The capacity still running every hour after scheduling is your always-on baseline.
3. Reserve the baseline only. Size the reservation to that floor, not to peak usage and not to capacity you intend to stop.

The comparison of these two approaches, with the arithmetic of when a commitment breaks even, is in Scheduling vs Reserved Instances.

Monitoring a reservation after you buy it

Reservations drift out of fit as workloads change. The signals to watch are utilisation (how many of the reserved hours were consumed) and coverage (how much of your eligible usage ran at the reserved rate). Azure’s amortized cost dataset lists unused reservation hours explicitly, and AWS Cost Explorer lets you group amortized costs by purchase option to see how much of a reservation went unused. The mechanics of that view are covered in amortized vs unblended cost.

Where ZopNight helps

ZopNight’s commitment recommendations are advisory: it never buys a reservation for you. It prices one-year and three-year No-Upfront terms from the providers’ published rates, bases the saving on the instance’s measured uptime rather than assuming it runs 24/7, and suppresses the suggestion when the projected run cost does not clear the commitment with a margin. Where uptime has not been measured it reports the saving as unknown, and capacity already covered by an existing reservation does not trigger a new suggestion. Existing AWS reservations are also discovered as inventory, see AWS reservations.