Commitment Plans
A commitment plan prepays for compute over a fixed term in exchange for a discounted rate. Nothing changes about how your team submits work, because eligible workloads are discounted automatically after they have run.
Committing to capacity does not reserve hardware for you. If the cloud provider has no instances of your coretype available, your job waits exactly as it would have done without a commitment in place.
You are buying a discount, not a guarantee. Capacity behaves the same as always: see why a job is queued.
Committing to a rate of spend, or to a number of cores
Rescale offers two kinds of commitment plan, and the difference between them is what you commit to.
A Rescale Savings Plan commits you to a level of spend, expressed in dollars per hour. Any eligible workload counts towards it, whatever coretype it runs on and whichever region it runs in. You are buying a discount on a quantity of money.
A Coretype Plan commits you to a number of cores of one specific coretype, in one region, on one operating system. Only workloads matching that description draw on it. You are buying a discount on a quantity of hardware.
Everything else follows from that distinction:
The Savings Plan is the better default for most organizations, because it places no regional condition on your work and tolerates a workload mix that changes over time. A Coretype Plan pays off where you reliably run the same coretype in the same region, which is a narrower situation but a common one.
You can hold both at once. Where you do, the Coretype Plan is applied first because it is the narrower of the two, and the Savings Plan then covers whatever eligible usage is left. That combination suits an organization with one dominant coretype and a varied tail of everything else.
Which workloads a commitment covers
A commitment applies to jobs, workstations and High-Performance Storage running at On-Demand Priority, which is the standard priority and what most work uses.
Workloads running at On-Demand Economy are excluded entirely. Economy capacity is interruptible and already sold at a discount, so a commitment discount does not stack on top of it. If you move work to Economy to save money, that work stops drawing on your commitment, and your utilization falls accordingly. See job priority.
How savings appear
Nothing is discounted at the point of submission. Every workload bills at standard On-Demand Priority rates first, and a credit is then applied retroactively against each one. Three columns on the workload's billing detail show that happening.
This means the price shown against a coretype when you set up a job is always the standard ODP price, even when the job will be fully covered by a commitment. The coretype list has no discounted figure to show, because the discount has not been calculated yet. You see it afterwards, on the workload's billing detail.
Savings are computed hourly. A workload starting mid-hour gets the committed rate for the whole hour, capped by the commitment's value.
Partial coverage is normal. An 80-core job against a 54-core Coretype Plan gets 54 cores covered and 26 at ODP, visible in the workload's billing detail.
Whichever kind of plan you hold, remaining capacity is allocated first in, first out by submission time. If a Savings Plan covers $10/hour and running workloads already consume $6/hour, the remaining $4/hour goes to whatever was submitted earliest, and the same applies to the cores left on a Coretype Plan.
Where two workloads compete for the same headroom, the earlier submission is covered and the later one runs at ODP rates, even if it is the smaller or shorter of the two.
Idle committed capacity doesn't incur platform license charges, you're only billed for what actually runs. Unused commitment, however, is use-it-or-lose-it per hour with no rollover.
Burst policy, what happens when the commitment is full
A commitment covers a fixed amount of capacity, so at some point a job will be submitted when that capacity is already in use. The burst policy decides what happens to that job, and an admin sets it on each commitment.
This is the setting your engineers will notice, because it determines whether a job waits, launches at full price, or is canceled.
Choosing between them is a trade between deadline and cost:
- Immediate when the work is deadline-driven and paying full price is acceptable.
- Economy when the work can tolerate interruption. This is the cheapest overflow, but note that Economy workloads are not covered by the commitment at all, so the burst portion neither draws on your commitment nor counts towards its utilization.
- Balanced for most teams. A short wait often finds capacity, and the job launches either way.
- Savings Required only where cost discipline matters more than finishing. Jobs under it can be canceled, so it is the wrong choice for anything somebody is waiting on.
A job under Savings Required can run on partial commitment plus partial ODP. It cancels only if zero commitment capacity opens within 24 hours.
So it's not a guarantee that you'll never pay ODP. It's a guarantee you won't pay entirely ODP.
The burst policy applies only to jobs, and only at the moment they launch. High-Performance Storage always launches immediately regardless of the policy, and workstations are unaffected by it whether they are being launched or resumed.
Seeing it at job setup
When a coretype is covered by a commitment, a commitment plan badge replaces the usual On-Demand Priority indicator against it in the coretype list. The badge reports how much committed capacity is left, such as 108 / 324 cores available, and hovering it explains what the active burst policy will do if that capacity runs out.
Tracking utilization
The Utilization Dashboard at Financials > Commitment Plans > Utilization Dashboard reports your utilization rate for a chosen period, plots hourly and daily usage against the commitment ceiling, and filters by month and by individual commitment.
Low utilization means you are paying for commitment you are not using, which is worth reviewing before renewal. The Utilization Dashboard shows the coretype mix driving it.
Managing jobs against a commitment
The Jobs dashboard offers a By Commitment Plan view, which groups active and pending jobs under the commitment each is drawing on and reports the remaining cores and pending count for each one.
Two things about that view are easy to misread. A pending job is not guaranteed coverage, because it may yet burst to On-Demand Priority rates depending on the burst policy in force. And a job eligible for more than one plan appears under each of them, so the counts across plans are not mutually exclusive and should not be added together.
Workspace scope
A commitment can either apply across every workspace in the organization or be restricted to a named set of them. Where it is restricted, only workloads from those workspaces are eligible to consume the committed capacity, and everything else bills at standard On-Demand Priority rates. The setting lives in the commitment's detail view.
Where the work has to run
A Savings Plan places no regional condition on your workloads. Work running in any cloud region draws on it, and there is nothing to configure.
A Coretype Plan is pinned to the region you bought it in. A workload matching the coretype but running elsewhere is not covered and bills at standard ODP rates, which is the most common reason a Coretype Plan shows lower utilization than expected.
A Region Lock setting on the commitment decides what happens when the committed region has no capacity left. It does not change how much of your commitment gets used, and coverage inside the committed region is identical either way.
Workloads that run outside the committed region are never covered by the commitment and always bill at ODP rates. So turn Region Lock off when regional capacity shortages are blocking your engineers more than the extra cost concerns you, and leave it on to keep every workload inside the committed region whether it is covered or bursting.
Getting started
Commitment plans are not self-service. Start by talking to your account executive about your workload profile and the sizing that suits it, and Rescale then configures the commitment on your behalf. Your teams carry on working exactly as before, so there is nothing to roll out to them.
Terms run for either one or three years, and a longer term carries a deeper discount. The size, term, coretype and region are all fixed once the commitment is purchased, with one exception: a Savings Plan's list of eligible coretypes can be updated without a new contract.
Discount percentages and eligible coretype lists are not published here. An admin can see the figures that apply to the active term in the commitment's own details.
Related
- Job priority — why ODE is excluded
- Why a job is queued — what burst policies interact with
- Billing & reports — where Applied Commitment appears
- Utilization Dashboard — the coretype mix behind your utilization
- Budgets & deposits — prepaid funds, a separate mechanism