Cloud Commitments: Cost Optimization or Just Lower Rates?

Updated 7 November 2026 · Standard formula, shown below

Cloud commitments (like AWS Savings Plans and Azure Reservations) can genuinely optimize costs, but only when they match your actual, steady usage—otherwise they just lower the rate on a bill you might not even need. The key difference is that a commitment is a financial contract, not a magic discount: you pay for a certain amount of compute in exchange for a lower per-hour price, and the savings come from using that reserved capacity consistently, not from simply signing up.

Background: Why Cloud Providers Offer Commitments

Cloud providers have massive data centers with fixed costs—servers, power, cooling, networking. They want predictable revenue to justify those investments. Commitments give them that predictability: you promise to spend X dollars per hour (or per month) for 1 or 3 years, and in return, they give you a significant discount (often 30-60% off on-demand prices). This is similar to how a gym sells annual memberships or how a phone carrier discounts a plan if you sign a two-year contract. The provider reduces its financial risk, and you get a lower rate—but only if you would have used that capacity anyway.

How Cloud Commitments Work

There are two main types of cloud commitments:

Reserved Instances (RIs) – You reserve a specific instance type (e.g., a VM with 4 vCPUs and 16 GB RAM) in a specific region (e.g., US East) for 1 or 3 years. You pay upfront (partially or fully) or monthly, and you get a discounted hourly rate. If you stop using that exact instance, you still pay for it.
Savings Plans (SPs) – You commit to a specific hourly spend (e.g., $10/hour) for 1 or 3 years. This covers any instance within a certain family (e.g., all EC2 instances in the US) and automatically applies to the instances you run, as long as their combined cost doesn’t exceed your commitment. This is more flexible than RIs because you can change instance sizes or even switch between compute services (like from EC2 to Lambda) and still get the discount.

The discount is applied to your on-demand rate. For example, if an on-demand instance costs $0.50/hour, a 3-year Savings Plan might drop that to $0.25/hour. You are billed the discounted rate for all usage that falls within your commitment, and you pay on-demand rates for anything above it.

Formula and Worked Example

The core calculation is simple: Total cost = (Committed hourly rate × hours in period) + (On-demand usage beyond commitment × on-demand rate). The savings come from the difference between the on-demand rate and the committed rate.

Worked example: Suppose you commit to $1.00/hour for a 1-year Savings Plan (8,760 hours). Your on-demand usage is $2.00/hour for 4,000 hours, and you have no other usage. Without a commitment, you’d pay $2.00 × 4,000 = $8,000. With the commitment, you pay $1.00 × 8,760 = $8,760 (since you pay for the full year regardless of usage). That’s actually more expensive! But if your usage is $2.00/hour for 6,000 hours, on-demand would be $12,000, while the commitment costs $8,760—saving $3,240. The break-even point is when your on-demand usage equals your commitment amount: $1.00 × 8,760 = $8,760, which is 4,380 hours at $2.00/hour. So you need to use more than 4,380 hours to save money.

When Do Commitments Actually Optimize Costs?

Commitments optimize costs when they cover baseline usage—the workloads that run 24/7, like production databases, web servers, or CI/CD pipelines. They are not suitable for spiky or experimental workloads. Here are the factors that determine whether a commitment is a good idea:

Utilization rate: If you run an instance 24/7 for a year, that’s 8,760 hours. A commitment makes sense if your utilization is above the break-even point (typically around 60-70% for a 1-year plan).
Predictability: If your usage is stable week-to-week, you can confidently commit. If it varies wildly (e.g., a marketing site that gets 10x traffic during a campaign), a commitment might not cover the spikes, and you’ll pay on-demand for the excess.
Future plans: If you plan to migrate to a different cloud or change instance families, a commitment can lock you in. Some providers allow selling unused RIs on a marketplace, but that’s not guaranteed.

Common Problems and Misconceptions

The biggest mistake is treating a commitment as a blanket discount. It’s not. Here are common pitfalls:

Over-committing: You commit to more than you actually use, and you pay for idle capacity. This is the most common error.
Under-committing: You commit to too little, and you still pay on-demand for the rest—missing out on potential savings.
Ignoring regional differences: A Savings Plan in one region doesn’t cover another region. If you move workloads, you lose the discount.
Forgetting about expirations: When a commitment ends, the discount disappears, and your bill jumps back to on-demand rates. You need to renew or adjust.

A common misconception is that a 3-year commitment is always better than a 1-year because the discount is higher. But the longer term locks you in for 3 years—if your usage drops, you’re stuck paying for unused capacity. The total cost might be lower per hour, but the total wasted spend could be higher.

How to Choose the Right Commitment

To decide whether and how much to commit, follow these steps:

Analyze your current usage: Use your cloud provider’s cost explorer to see your compute spend over the last 3-6 months. Identify which instances run 24/7 and which are intermittent.
Calculate your baseline: For each instance family, find the average hourly cost you incur. This is your baseline spend.
Start small: Commit to 50-70% of your baseline first. You can always increase later, but you can’t easily decrease.
Choose the right term: If your workloads are stable for 3+ years, a 3-year plan gives the biggest discount. If you’re unsure, a 1-year plan is safer.
Review regularly: Re-evaluate every quarter. If your usage grows, you can buy additional commitments. If it shrinks, you might have wasted money.

Alternatives to Commitments

If commitments seem too risky, there are other ways to reduce cloud costs:

Spot instances: These are spare compute capacity offered at a steep discount (up to 90% off) but can be terminated at any time with a 2-minute warning. Ideal for fault-tolerant, batch workloads.
Autoscaling: Automatically scale down during off-peak hours. This reduces on-demand usage without any commitment.
Rightsizing: Choose smaller instance types that still meet your performance needs. Many workloads are over-provisioned.
Using serverless: Services like Lambda or Azure Functions charge only for actual execution time, which can be cheaper for sporadic workloads.

Frequently Asked Questions

Q: Can I get a refund if I don’t use my commitment?
A: Generally, no. Cloud providers do not offer refunds for unused commitments. Some allow you to sell unused Reserved Instances on a marketplace, but that’s not a guarantee and often at a loss. Savings Plans are not transferable or refundable.

Q: Do commitments apply to all services (e.g., storage, databases)?
A: No. Most commitments cover compute services (virtual machines, containers, serverless functions). Storage, networking, and most database services (like managed databases) are not covered, though some providers have separate reserved capacity for databases.

Q: What happens if I exceed my committed hourly rate?
A: Everything above your commitment is billed at the on-demand rate. For example, if you commit to $10/hour and run $15/hour of usage, you pay $10 at the discounted rate plus $5 at the on-demand rate.

Q: Is a 3-year commitment always cheaper than a 1-year?
A: The hourly rate is lower, but the total cost can be higher if you don’t use the full term. For example, a 1-year plan at $0.30/hour costs $2,628/year. A 3-year plan at $0.20/hour costs $5,256 over 3 years—but if you only need 1 year, you’ve paid $2,628 extra. Always compare total cost over the actual period you’ll use it.

Q: Can I change my commitment after purchase?
A: For Savings Plans, you can increase your commitment (up to a limit) but not decrease it. For Reserved Instances, you can modify some attributes (like instance size) within the same family, but you cannot change the family or region. You cannot cancel.

Q: Do commitments cover development/test environments?
A: They can, but it’s usually not worth it if those environments run only during business hours. A 9-to-5 dev server runs about 2,080 hours/year (40 hours × 52 weeks), which is only 24% utilization—far below the break-even point. You’d likely pay more with a commitment than on-demand.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.