CostMonStart free

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. You see the blended cost, the savings, and the break-even point. You also see the stranded spend if utilization comes in low. Everything computes live in your browser.

Reference table checked every figure is a published range with a named source. It is not a fixed fact. It does not replace 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.

$30,000

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

60%

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

30%

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

95%

What share of what you committed to actually gets consumed

Commitment term

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 freeRead the glossary definition

Every rate above is a default you can override. It is 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 publishes. This tool computes entirely in your browser. Nothing you type 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. Check the current rate there before you budget against it.

Commitment instruments compared by what they lock, flexibility, term, published discount range, best fit, watch-out, and source
InstrumentLocks / flexibilityTermPublished discount rangeBest for / watch outSource
Compute Savings PlansAWS
A $/hour spend rate, not a specific instance shape
Applies automatically across EC2 (any family/size/OS/region), Fargate, and Lambda
1 or 3 years; All/Partial/No UpfrontUp to 66% off On-Demand, published
A footprint whose instance mix or region changes over time
Watch 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 region
Size and OS flex freely within the committed family/region; can't cross families or regions
1 or 3 years; All/Partial/No UpfrontUp to 72% off On-Demand, published
A stable instance family in a stable region, with sizes still expected to change
Watch 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 region
None; it cannot be exchanged for a different configuration
1 or 3 years; All/Partial/No UpfrontUp 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 touch
Watch 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 value
Can be exchanged mid-term for a different family/size, for a slightly smaller discount than Standard RIs
1 or 3 years; All/Partial/No UpfrontUp 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 discount
Watch 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 direction
Cancel anytime; AWS can also reclaim capacity with as little as ~2 minutes' notice
None: priced and billed like On-Demand, per secondUp to 90% off On-Demand, published
Stateless, interruption-tolerant work: batch jobs, CI runners, fault-tolerant worker fleets
Watch 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 UpfrontUp 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 continuously
Watch 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 series
None: tied to the committed machine series
1 or 3 yearsUp to 55% for most machine series, up to 70% for memory-optimized series, published
A stable machine-series footprint you're confident won't move
Watch 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 region
Flexes 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 coverage
Watch 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 region
Exchanges and cancellations are possible subject to Azure's reservation exchange policy
1 or 3 yearsUp 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 leave
Watch 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 services
Flexes across VM series, size, region, and OS, plus some container and App Service usage
1 or 3 yearsUp 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 rate
Watch 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 rate
None 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 volume
Watch 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 call
Use it request-by-request; no ongoing obligation of any kind
None: per-request, asynchronous, typically completes within 24 hours50% off both input and output tokens vs. standard synchronous pricing, published
Anything that doesn't need a synchronous response: evals, backfills, bulk classification, offline scoring
Watch 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 mode
Use it request-by-request; no ongoing obligation of any kind
None: per-request, asynchronous, completes within 24 hours50% cost discount vs. synchronous API pricing, published
Anything that doesn't need a synchronous response
Watch 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 discount
Opt in per-request with a single field; no ongoing obligation
Cache entries live 5 minutes or 1 hour per write, refreshed on each hitCache 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 calls
Watch 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 →

About commitment discounts

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 give a standing discount on spend that was never wasteful. The discount applies to every dollar of steady-state usage, 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 normalized, daily view of cloud and AI spend gives the team 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). It earns the deepest discount, because AWS knows what you commit to run. A Savings Plan locks a dollar-per-hour spend rate instead. That commitment applies automatically to the instance types, sizes, and even serverless usage you run. It's more flexible, at a slightly smaller discount. Spot has no commitment on either side. You buy no discount and take on no obligation. You get unused capacity at a low price, and the provider can reclaim it 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 no commitment 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 it still costs money when usage dips below it, and real usage does that often.

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. As the floor rises, you buy more coverage in steps. You add each step only when usage growth is confirmed. You do not commit 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 for a workload. Within months, the workload is replatformed, containerized, or moved to a different instance family. The commitment then has 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 without regard to the commitment, makes the commitment worthless.

The renewal cliff is the quiet one. A one- or three-year term ends, and the discount reverts to on-demand overnight. Nothing forces anyone to look. The bill jumps, and no incident explains 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. They have 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. If a prompt's context is never reused, the write premium is small and the cache expires on its own.

Provisioned Throughput on Amazon Bedrock is the one AI-side instrument that behaves like a real commitment. It gives guaranteed capacity for a fixed term, priced below the pay-as-you-go rate at higher tiers. It has the same stranding risk as an EC2 Reserved Instance if you leave the capacity 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, the answer for most workloads is: batch what can wait, and cache what repeats. Keep a real commitment (Provisioned Throughput) 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 commits against a floor that doesn't exist. Guess too low, and you leave real savings 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. CostMon shows the real, normalized baseline to size a commitment against. It also shows 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. It applies automatically across the instance types you run, at a slightly smaller discount. It is 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 it locks in the bet for three times as long. That gives an architecture change or a migration three times as long 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. The capacity you don't use 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. You can list AWS Standard and Convertible Reserved Instances on the AWS Reserved Instance Marketplace for resale. You can also exchange Convertible RIs 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 prepay instead of paying monthly installments. No-upfront earns the smallest discount but keeps your 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. Check each provider's eligibility list. It is 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. Add coverage in steps as growth is confirmed. Do not commit 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) and prompt caching. Batch processing discounts asynchronous requests by roughly 50%, with no term or minimum. Prompt caching 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. CostMon shows the real, normalized baseline to size a commitment against. It also shows the coverage gap once a commitment is in place. It does this continuously, instead of from 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.

Esc