Calculator

Should you commit, and how much?

A commitment discount is a bet, and the bet can lose. Enter your baseline, coverage, discount, and utilization to see the blended cost, the savings, the break-even point, and the stranded spend if utilization comes in low. Everything computes live in your browser.

Reference table checked July 31, 2026 every figure is a published range, attributed — not a fixed fact, and not a substitute for your own quote

Model your bet

Run the numbers before you sign a term

Drag your real numbers in. Everything below computes in your browser — nothing you type here is sent anywhere.

Steady-state monthly spend eligible for commitment$30,000

Your on-demand compute floor: what runs every month regardless of traffic

Coverage — % of that baseline you commit to60%

How much of the floor you're covering with a commitment, not the peak

Discount the commitment buys30%

Typical for a 1-year, no-upfront Compute Savings Plan. Override with your own negotiated or published rate

Utilization — % of committed capacity you actually use95%

What share of what you committed to actually gets consumed

Commitment term

1 year3 years

Longer terms typically buy a deeper discount but lock in the bet for longer

Your commitment planUpdates live

Live

At these numbersYou save $4,500/mo vs. staying 100% on-demand.Room to commit deeper

All on-demand$29,100

Your plan$24,600

Effective discount achieved: 15.5%
Monthly savings vs. all on-demand: $4,500
Savings over the full term: $54,000
Stranded spend (paid, unused): $630/mo
Break-even utilization: 70%

Start free Read the glossary definition

Every rate above is a default you can override, not asserted fact — discounts vary by instance family, region, term, and payment option, and they change. See the source-linked reference table below for what each vendor actually publishes. Computes entirely in your browser — nothing typed here is sent anywhere.

Reference table

Every commitment instrument, compared

On-demand, Savings Plans, Reserved Instances, and Spot, plus the AWS/GCP/Azure database and AI-provider analogues. Every discount figure links to its primary vendor source — verify the current rate there before budgeting against it.

Commitment instruments compared by what they lock, flexibility, term, published discount range, best fit, watch-out, and source
Instrument	Locks / flexibility	Term	Published discount range	Best for / watch out	Source
Compute Savings PlansAWS	A $/hour spend rate, not a specific instance shapeApplies automatically across EC2 (any family/size/OS/region), Fargate, and Lambda	1 or 3 years; All/Partial/No Upfront	Up to 66% off On-Demand, published	A footprint whose instance mix or region changes over timeWatch out: The most flexible option also earns the smallest discount of the three EC2 commitment types	AWS docs →
EC2 Instance Savings PlansAWS	A $/hour spend rate within one instance family in one regionSize and OS flex freely within the committed family/region; can't cross families or regions	1 or 3 years; All/Partial/No Upfront	Up to 72% off On-Demand, published	A stable instance family in a stable region, with sizes still expected to changeWatch out: A planned migration off the committed instance family strands the whole commitment	AWS docs →
Standard Reserved InstancesAWS	A specific instance family, size, and Availability Zone or regionNone; it cannot be exchanged for a different configuration	1 or 3 years; All/Partial/No Upfront	Up to 72% off On-Demand (AWS-published averages: ~40% at 1 year, ~60% at 3 years)	A genuinely fixed, predictable workload you're not planning to touchWatch out: Zero flexibility means the deepest discount of the three EC2 options, and the easiest to strand	AWS docs →
Convertible Reserved InstancesAWS	An instance family and region, but exchangeable for another of equal or greater valueCan be exchanged mid-term for a different family/size, for a slightly smaller discount than Standard RIs	1 or 3 years; All/Partial/No Upfront	Up to 66% off On-Demand (AWS-published averages: ~31% at 1 year, ~54% at 3 years)	A workload you expect to reshape, where you still want an RI-style discountWatch out: The exchange right isn't free: it costs several points of discount versus a Standard RI	AWS docs →
Spot InstancesAWS	Nothing: no commitment at all, in either directionCancel anytime; AWS can also reclaim capacity with as little as ~2 minutes' notice	None: priced and billed like On-Demand, per second	Up to 90% off On-Demand, published	Stateless, interruption-tolerant work: batch jobs, CI runners, fault-tolerant worker fleetsWatch out: Not a substitute for a commitment decision; it's a different risk trade entirely (capacity risk instead of usage risk)	AWS docs →
RDS Reserved InstancesAWS	A specific database engine, instance class, and Deployment (single-AZ / Multi-AZ)Can modify within some limits; no cross-engine exchange	1 or 3 years; All/Partial/No Upfront	Up to 69% off On-Demand in steady state (AWS-published: up to 30% No Upfront, up to 63% All Upfront at 3 years)	A database tier that runs the same shape continuouslyWatch out: ElastiCache and OpenSearch offer the same reserved-node model, so check each service's own pricing page before assuming RDS's rate carries over	AWS docs →
Resource-based Committed Use DiscountsGoogle Cloud	A specific vCPU/memory shape by machine seriesNone: tied to the committed machine series	1 or 3 years	Up to 55% for most machine series, up to 70% for memory-optimized series, published	A stable machine-series footprint you're confident won't moveWatch out: Discount varies materially by machine series; the headline number isn't the same for every shape	Google Cloud docs →
Flexible (spend-based) Committed Use DiscountsGoogle Cloud	A $/hour spend rate, applied automatically across eligible machine types in a regionFlexes across machine series/size within the commitment, similar in spirit to an AWS Compute Savings Plan	1 or 3 years	~28% (1-year) to ~46% (3-year) for general-purpose machines, published; varies by series	A footprint whose machine mix shifts, where you still want automatic coverageWatch out: Meaningfully lower discount than resource-based CUDs; flexibility again costs discount depth	Google Cloud docs →
Reserved VM InstancesAzure	A specific VM size/series in a specific regionExchanges and cancellations are possible subject to Azure's reservation exchange policy	1 or 3 years	Up to 72% vs. pay-as-you-go, published (Microsoft's own footnote: actual savings vary by location, instance type, and usage)	A fixed VM footprint in a region you're not planning to leaveWatch out: Microsoft's headline figure is a specific scenario, not a guaranteed rate for every VM/region combination	Azure docs →
Savings Plan for ComputeAzure	A $/hour spend rate, applied automatically across eligible compute servicesFlexes across VM series, size, region, and OS, plus some container and App Service usage	1 or 3 years	Up to 65% vs. pay-as-you-go, published (Microsoft's own footnote: real-world savings observed between 11% and 65%)	A shifting compute footprint where automatic, hands-off coverage matters more than the deepest possible rateWatch out: The 11–65% real-world range is wide, so don't plan a budget off the 65% headline alone	Azure docs →
Provisioned ThroughputAmazon Bedrock	A guaranteed inference capacity level (model units/hour) instead of a per-token rateNone once purchased for the term; a no-commitment hourly rate also exists as a fallback, at a premium	1 month or 6 months (per-model; some model providers require contacting AWS directly)	6-month commitment prices meaningfully below 1-month for the model families that publish self-serve rates. It varies by model, with no single site-wide percentage	Latency-sensitive, high and predictable-volume inference where on-demand token pricing would cost more at that volumeWatch out: This buys guaranteed capacity, not a discount on token price. Model it against your actual token volume, not against the sticker discount	Amazon Bedrock docs →
Message Batches APIAnthropic	Nothing: no term, no minimum volume, an asynchronous processing mode instead of a real-time callUse it request-by-request; no ongoing obligation of any kind	None: per-request, asynchronous, typically completes within 24 hours	50% off both input and output tokens vs. standard synchronous pricing, published	Anything that doesn't need a synchronous response: evals, backfills, bulk classification, offline scoringWatch out: No SLA for when a batch completes within the window, so it's not a fit for anything latency-sensitive	Anthropic docs →
Batch APIOpenAI	Nothing: same commitment-free shape as Anthropic's batch modeUse it request-by-request; no ongoing obligation of any kind	None: per-request, asynchronous, completes within 24 hours	50% cost discount vs. synchronous API pricing, published	Anything that doesn't need a synchronous responseWatch out: Same latency trade as Anthropic's batch mode, so don't route anything user-facing through it	OpenAI docs →
Prompt cachingAnthropic	Nothing: no term, no commitment; a cache write/read mechanic, not a purchased discountOpt in per-request with a single field; no ongoing obligation	Cache entries live 5 minutes or 1 hour per write, refreshed on each hit	Cache reads cost 0.1x base input price; writes cost 1.25x (5-min) or 2x (1-hour) base input price, published	Repeated system prompts, long reference documents, or conversation history reused across callsWatch out: This is the AI-side analogue of a commitment discount that carries zero downside risk. There's no version of this page's break-even math for it, because there's nothing to strand	Anthropic docs →

Why commitment discounts are the biggest lever you're not pulling

Rightsizing and cleaning up idle resources reclaim real money, but they're bounded by how much waste exists in a bill. Once it's gone, it's gone. Commitment discounts are different: they're a standing discount on spend that was never wasteful in the first place, available on every dollar of steady-state usage a team runs, every month, for as long as the commitment lasts. On a stable floor, that's routinely 30–70% off: a bigger number, applied to a bigger base, than almost any cleanup project touches.

It's also the decision that comes right after visibility, not before it. A team that can't see its baseline can't size a commitment against it; a team that just got a normalized, daily view of its cloud and AI spend finally has the one input a commitment decision needs. That's the moment this page is for.

Savings Plans vs. Reserved Instances vs. Spot: what each one actually locks

These three answer different questions, not the same question at different discounts. A Reserved Instance locks a specific capacity shape (an instance family, size, and region) in exchange for the deepest discount, because AWS knows what you're committing to run. A Savings Plan locks a dollar-per-hour spend rate instead, and lets that commitment apply automatically to whatever instance types, sizes, and even serverless usage you actually run. It's more flexible, at a slightly smaller discount. Spot has no commitment on either side: no discount purchased, no obligation taken on, just unused capacity sold cheap that the provider can reclaim on short notice.

The practical filter is how confident you are in the shape of your usage, not just its volume. Confident in the instance family and region for the next year or three? A Reserved Instance earns the deepest discount. Confident in the dollar amount but not the shape? A Savings Plan. Not confident in either, or running something that tolerates interruption? Spot, or plain on-demand, and revisit the question once there's a real baseline to commit against.

The break-even nobody shows you

Every commitment discount is a bet with a break-even point, and almost nobody publishes it: below a certain utilization of what you committed to, the commitment costs more than never committing at all. The math is short: a d% discount breaks even at (100 − d)% utilization of the committed capacity. A 30% discount needs 70% utilization just to match on-demand; anything below that, and the commitment is actively losing money relative to doing nothing.

Worked example: commit to $18,000/month (60% of a $30,000 baseline) at a 30% discount. You pay $12,600/month for that commitment regardless of use. At 95% utilization, you've consumed $17,100 of on-demand-equivalent value for $12,600. That's a real win. At 50% utilization, you've consumed $9,000 of value for that same $12,600. You paid $3,600/month more than on-demand would have cost for what you actually used. Same commitment, same discount, opposite outcome. Utilization is what decides which one you get.

How much coverage is right

Commit to the floor, not the average and never the peak. A traffic peak is, by definition, not what runs every month. Committing against it guarantees stranded capacity the moment traffic normalizes. The average is safer than the peak but still gets it wrong in the direction that costs money the moment usage dips below it, which real usage does constantly.

The steady-state floor (the level usage doesn't drop below across a normal week or month) is the number a commitment should be sized against. Coverage above that floor is a bet on stability you haven't observed yet; the standard hedge is laddering commitments over time as the floor itself rises, buying additional coverage in increments as usage growth is confirmed rather than committing to next year's guessed total today.

The three ways commitments go wrong

Over-committing right before a migration is the most common: a team buys a multi-year Reserved Instance against a workload that gets replatformed, containerized, or moved to a different instance family within months, and the commitment strands itself with nothing left to apply to.

Committing to an instance family or region you're about to leave is the same failure with a different trigger: an architecture decision made independently of the commitment that ends up making the commitment worthless.

The renewal cliff is the quiet one: a one- or three-year term ends, the discount reverts to on-demand overnight, and because nothing forced anyone to look at it, the bill jumps with no accompanying incident to explain why. All three share the same root cause: a commitment sized once and never revisited against the footprint that actually exists later.

What this looks like on the AI side

Most token-metered AI APIs don't offer a true commitment discount the way cloud compute does. There's no multi-year reservation for Claude or GPT tokens at a locked discount. The analogues that exist are shaped differently: batch APIs (Anthropic's Message Batches, OpenAI's Batch API) trade a real-time response for roughly 50% off, with zero term and zero minimum volume. That's closer to Spot's risk-free discount than to a Reserved Instance's locked-in bet. Prompt caching goes further: it carries no term, no minimum, and no downside at all. A cache hit costs a fraction of the base input rate, and if a prompt's context never gets reused, the write premium is small and the cache expires on its own.

Provisioned Throughput on Amazon Bedrock is the one instrument on the AI side that behaves like a real commitment: guaranteed capacity for a fixed term, priced below the pay-as-you-go rate at higher tiers, with the same stranding risk as an EC2 Reserved Instance if the guaranteed capacity goes underused. The practical playbook flips as a result: on the cloud-compute side, the question is how much to commit; on the AI-API side, for most workloads it's really 'batch what can wait, cache what repeats,' with a real commitment (Provisioned Throughput) reserved for the rare workload with predictable, high, latency-sensitive volume.

What you need before you commit

Every number this calculator produces depends on one input nobody can just guess accurately: the steady-state baseline. Guess too high and the coverage slider is committing against a floor that doesn't exist; guess too low and real savings get left on the table month after month. A single month's bill doesn't reveal a floor either. It reveals one point on a trend that could be rising, falling, or seasonal.

That's the input a trustworthy 90-day, daily-synced view of actual spend answers directly, without a guess. CostMon doesn't buy or manage commitments (that decision, and the negotiation behind it, is still yours), but it's built to show the real, normalized baseline a commitment decision should be sized against, and the coverage gap once a commitment is in place.

FAQ

Common questions about commitment discounts

Should I choose a Savings Plan or a Reserved Instance?

It depends on how confident you are in the shape of your usage, more than its size. A Reserved Instance earns a deeper discount but locks a specific instance family, size, and region: the right choice for a stable, unchanging footprint. A Savings Plan locks a dollar-per-hour spend rate instead and applies it automatically across whatever instance types you run, at a slightly smaller discount: the right choice for a footprint you expect to keep reshaping.

Should I commit for 1 year or 3 years?

A 3-year term buys a deeper discount but locks in the bet for three times as long, which is exactly three times as long for an architecture change or a migration to strand it. Match the term to how confident you are the workload runs steady for the whole window. A shorter or convertible commitment is the safer default whenever that confidence isn't there yet.

What happens if my usage drops after I commit?

You keep paying the full commitment bill regardless (that's what "committed" means), but the capacity you're not using becomes stranded spend: money paid for capacity that sits idle. This calculator's stranded-spend and break-even figures exist specifically to show that cost before it happens, not after.

Can I cancel or sell a commitment I no longer need?

Not directly in most cases. AWS Standard and Convertible Reserved Instances can be listed on the AWS Reserved Instance Marketplace for resale (Convertible RIs can also be exchanged for a different configuration); Savings Plans generally cannot be canceled, sold, or exchanged once purchased. Check the specific instrument's terms before assuming an exit exists.

Is all-upfront or no-upfront the better payment option?

All-upfront earns the deepest discount for the same term because you're prepaying instead of financing the commitment across monthly installments; no-upfront earns the smallest discount but preserves cash flow. Neither choice changes the break-even utilization math on this page. That's driven by the discount rate itself, not by when you paid for it.

Does a commitment cover usage in a different region or instance family than what I committed to?

Usually not, or only partially. Instance-family-scoped commitments (Standard RIs, EC2 Instance Savings Plans, GCP resource-based CUDs) generally don't cross regions or families at all. Spend-based commitments (Compute Savings Plans, GCP flexible CUDs, Azure's Savings Plan for Compute) flex further, but check each provider's specific eligibility list; it's rarely "everything, everywhere."

How much coverage should I target?

Size the commitment to your steady-state floor (the level usage reliably stays above), not to your average and never to your peak. A common approach is laddering: commit to the confirmed floor today, and add coverage in increments as growth is confirmed rather than committing to a guessed future total all at once.

Are there commitment discounts on Claude, GPT, or other model API usage?

Not in the cloud-compute sense of a multi-year reservation. The closest analogues are batch processing (Anthropic's Message Batches API, OpenAI's Batch API), which discount asynchronous requests by roughly 50% with no term or minimum, and prompt caching, which discounts reused context with no commitment at all. Amazon Bedrock's Provisioned Throughput is the one AI-side instrument that behaves like a true commitment, with the same stranding risk as an EC2 Reserved Instance.

Does CostMon buy or manage commitments for me?

No. That decision and the negotiation behind it stay yours. What CostMon does is show the real, normalized baseline a commitment should be sized against and the coverage gap once one's in place, continuously, instead of off a single month's guess.

The meter you don't watch still grows.

Waste rarely hides in the service you check every week. CostMon watches every meter on your stack, including the ones you forgot were running.

Start free See idle and orphaned resources

Should you commit, and how much?

Run the numbers before you sign a term

Every commitment instrument, compared

About commitment discounts

Why commitment discounts are the biggest lever you're not pulling

Savings Plans vs. Reserved Instances vs. Spot: what each one actually locks

The break-even nobody shows you

How much coverage is right

The three ways commitments go wrong

What this looks like on the AI side

What you need before you commit

Common questions about commitment discounts

Keep going with a sibling calculator

AWS Data Transfer & Egress Cost Calculator

Kubernetes Cost Allocation Calculator

Flat vs. Percentage Pricing Calculator

Cloud & AI Price Change Log

FOCUS: the FinOps Cost & Usage Standard, Explained

FOCUS Export Analyzer

The meter you don't watch still grows.