CloudCostCompare
DE

Diese Seite ist noch nicht auf Deutsch verfügbar, daher ist der Text darunter auf Englisch. Englische Seite öffnen

Ratgeber

Reserved instances and savings plans: what you commit to

Von Rohit Athaide · Veröffentlicht am 3. Nov. 2026

A commitment discount trades flexibility for a lower rate. You tell the vendor you will use a certain amount for a fixed term, and it charges less for that amount. Every cloud has one, and the details differ enough that two offers with similar names can behave very differently.

What you can commit to

There are two broad shapes.

A specific resource. You commit to a particular instance type, family or size in a region. The discount is usually larger, and it only applies when you actually run that resource. AWS reserved instances and Azure reservations work this way.

A spend per hour. You commit to spending a set amount each hour on compute, and the discount applies to whatever you run, within the plan’s rules. This is more flexible when your instance types change. AWS savings plans, Azure savings plans for compute and Google’s spend-based committed use discounts are of this kind.

Oracle’s model is a commitment of funds under a contract, with usage drawing it down. Read its own pricing pages for the terms, because they are set per customer.

The terms that matter

  • Length. Typically one or three years. A longer term usually means a lower rate and a longer bet.
  • Payment. Some plans let you pay all upfront, partly upfront or monthly with nothing upfront. The rate often differs by option.
  • Scope. A region, a family, or any compute. Narrow scope means a better rate and less room to move.
  • Changes. Whether you can exchange, resize or sell the commitment varies by vendor and by plan type.
  • What it covers. Usually compute hours. Storage, data transfer and managed database storage are often outside it, so check before assuming a commitment lowers the whole bill.

When it pays off

A commitment pays off when the usage it covers would have run anyway. The test is simple: look at the lowest point your compute usage reaches in a normal month. That floor is a reasonable amount to commit. Anything above it is variable and stays on-demand.

Commitments go wrong in three ways: sizing the commitment to your peak instead of your floor, moving to a different architecture and leaving the commitment unused, and committing before the workload is stable. A new product with unknown traffic is a poor candidate for a three-year term.

Why our estimates do not include them

Our estimates use on-demand list prices, as explained in how we calculate monthly costs. Commitment rates depend on your term, payment choice and scope, and some are negotiated. If you plan to commit, treat our figure as the upper bound for the covered part and check the vendor’s own calculator for the rate.

See also cloud pricing models explained and list prices versus negotiated discounts.