Cloud & AI Cost Glossary

Committed use discountCUD

A discount a provider gives in exchange for committing to a minimum spend or usage level for a fixed term.

A committed use discount trades flexibility for a lower rate: you commit to a baseline of usage (or spend) for one to three years, and the provider prices that baseline well below its on-demand rate. Reserved instances and savings plans are AWS's two flavors of this idea; most major clouds offer some equivalent.

The risk isn't the discount — it's sizing it wrong. A commitment bought against last year's footprint can sit partially unused as workloads shift, which is why coverage and utilization need to be checked on a cadence, not just at purchase time.

Reserved instanceRI

A commitment to a specific instance type in a specific region or zone, discounted versus on-demand pricing.

A reserved instance is the older, more rigid form of committed use discount: you commit to a specific instance family and size, and in exchange pay a lower hourly (or fully upfront) rate than on-demand for the term of the reservation. Because it's tied to a specific shape, it earns a deeper discount than a savings plan but doesn't flex if your instance mix changes.

RIs are worth revisiting whenever an architecture shifts — a reservation for an instance type you've since migrated away from stops paying for itself and just becomes stranded commitment.

Savings planSP

A commitment to a dollar-per-hour spend level, applied automatically across compute regardless of instance family.

Where a reserved instance locks in a specific instance shape, a savings plan locks in a spend rate — you commit to, say, $10/hour of compute usage for one or three years, and the discount applies automatically to whatever instance types and sizes you actually run, up to that commitment. That flexibility usually comes at a slightly smaller discount than an equivalently-sized reserved instance.

Savings plans are the better fit for teams whose instance mix changes over time; reserved instances suit a genuinely stable, predictable footprint.

On-demand vs. spot instances

On-demand pricing charges the full published rate with no commitment; spot pricing sells unused capacity at a steep discount but can be reclaimed with little notice.

On-demand is the default, most-expensive-per-hour way to pay for compute: no commitment, no discount, billed for exactly what you use. Spot capacity is the provider's unused inventory, sold at a discount that can reach 70–90% off on-demand — the tradeoff is that the provider can reclaim a spot instance with as little as a couple minutes' warning when it needs the capacity back.

Spot fits stateless, interruption-tolerant workloads (batch jobs, CI runners, fault-tolerant worker fleets) extremely well and is a poor fit for anything that can't gracefully checkpoint or restart.

Data egress

The fee a cloud provider charges for data leaving its network — including, on most providers, transfer between availability zones.

Data egress is billed per gigabyte for traffic leaving the provider's network toward the public internet, another cloud, or (on most providers) even a different availability zone within the same region. It's one of the least visible line items on a bill because it scales with application behavior — a chatty microservice architecture or an unoptimized data pipeline can rack up meaningful egress with no single obvious cause.

Cross-AZ transfer specifically catches teams off guard: traffic that never leaves the provider's network still crosses a per-GB charge the moment it crosses an availability-zone boundary, which is easy to miss when architecting for high availability across zones.

Amortized, blended, and unblended cost

Three different bases for reporting the same underlying spend — unblended is the raw per-resource rate, blended averages a rate across an account, and amortized spreads upfront commitment costs evenly across the term they cover.

Unblended cost is the simplest: the actual rate charged for each individual resource, with no averaging. Blended cost averages a rate across all usage of a resource type within a consolidated billing family — useful for a single effective per-unit rate across accounts, but it can mask which specific account or team is actually driving spend.

Amortized cost solves a different problem: a one-time or upfront commitment payment (buying a reserved instance for cash upfront, say) gets spread evenly across every day of the term it covers, so a single normalized daily number reflects the discount's ongoing value instead of showing one enormous spike on the purchase date and zero afterward. Most cost-monitoring tools default to amortized because it's the view that actually matches how the discount pays off over time.

Rightsizing

Matching a resource's provisioned size to its actual, observed utilization instead of the peak it was originally sized for.

Rightsizing means comparing what an instance, volume, or database is provisioned for against what it actually uses — CPU, memory, IOPS, throughput — over a representative window, then resizing down (or, occasionally, up) to match. Most fleets carry meaningful oversizing simply because instances get sized once, for a traffic peak or a worst-case estimate, and are rarely revisited once the peak passes or the workload matures.

It's a recurring practice, not a one-time project: utilization drifts as code, traffic, and dependencies change, so a resource that was correctly sized six months ago can easily be oversized today.

Idle and orphaned resources

Resources still running (and billing) despite doing no meaningful work — idle resources are underused, orphaned resources have no owner or purpose left at all.

An idle resource is running well below any reasonable utilization threshold — a NAT gateway or load balancer left up after a migration, a staging environment nobody tore down. An orphaned resource has gone a step further: the thing it existed to support (an instance, a deployment, a project) is already gone, leaving a volume, snapshot, or elastic IP with no remaining reason to exist, still billing every month.

Both are the single most reliably reclaimable category of cloud waste, because — unlike rightsizing — there's no performance tradeoff to weigh. The only reason they persist is that nobody's looking; a recurring sweep against a normalized cost view is usually all it takes to find them.

Cost allocation tags

Key-value labels applied to cloud resources so spend can be grouped by team, project, environment, or customer instead of showing up as one undifferentiated total.

Without tags, a bill is just a flat total per service — there's no way to answer "how much did the checkout team's infrastructure cost last month" without manually cross-referencing resource names. Tags applied consistently at creation time (team, project, environment, and — for usage-based products — customer) let every downstream report slice spend along the lines the business actually cares about.

The practical failure mode is inconsistency: tags applied by convention rather than enforcement drift within a quarter, as new resources get created without them. Enforcing required tags at provisioning time (or a tag-compliance sweep) is what keeps allocation reporting trustworthy.

Showback vs. chargeback

Showback reports each team's cloud spend for visibility only; chargeback actually bills that spend back to the team's budget.

Showback is the lighter-weight, more common practice: each team sees a report of what its tagged resources cost, with no accounting entry attached — the goal is awareness and behavior change, not a budget transfer. Chargeback goes further, moving the actual dollar amount into the consuming team's cost center, which creates real financial accountability but also real organizational friction if the underlying tagging and allocation isn't accurate.

Most teams that aren't already running a mature FinOps practice get most of the behavioral benefit from showback alone, and save chargeback for cost centers large enough that the accounting overhead is worth it.

Unit economics

Infrastructure cost expressed per customer, per request, or per transaction, instead of as a single company-wide total.

A total monthly cloud bill tells you almost nothing about whether the business is getting more efficient or less — it just grows with usage. Dividing that same spend by an active-customer count, a request count, or a completed transaction count turns it into a number you can actually compare over time: is it costing more or less to serve the same unit of value as the product and its usage evolve?

This is where cloud and AI cost measurement converge, since per-request cost (the AI/LLM equivalent) is exactly the same idea applied to a metered API call instead of an infrastructure footprint.

A per-unit cost view is also exportable as a report — save it once and it can generate a CSV or PDF export on demand, or be delivered to a channel on a recurring schedule for whoever owns the metric.

RI/SP coverage and utilization

Coverage measures what share of eligible usage is discounted by a commitment; utilization measures what share of the commitment you actually purchased is being used.

Coverage answers "of everything we could be running at a discount, how much actually is" — low coverage means you're overpaying on-demand for usage a commitment could have discounted. Utilization answers the opposite question, "of the commitment we bought, how much are we using" — low utilization means you paid for capacity that's sitting unused.

The two numbers should be reviewed together on a fixed cadence, because they point to opposite fixes: low coverage means buy more commitment, low utilization means you've already bought too much (or the wrong shape) for your current footprint.

FinOps

The operating practice of managing cloud (and increasingly AI) spend as a shared responsibility between finance and engineering, on an ongoing cadence.

FinOps treats cost the way SRE treats reliability: a discipline with its own metrics, review cadence, and shared ownership between the people who spend (engineering) and the people who account for it (finance), rather than a once-a-quarter finance-only audit. Its core loop is simple — normalize spend into one view everyone trusts, review it on a fixed cadence, act on what's drifting — and it scales down to a single rotating owner just as well as it scales up to a dedicated platform team.

The discipline originated around cloud infrastructure spend but applies just as directly to AI/LLM API spend, which is usage-based in the same way and needs the same visibility-plus-cadence treatment, just at a faster tempo given how quickly it can move.

Cost anomaly detection

Automatically flagging spend that deviates meaningfully from a service or workload's own historical baseline, instead of waiting for a human to notice on the invoice.

Anomaly detection compares current spend against what a specific service or workload has typically cost, rather than against total spend — which is the key distinction, since total spend absorbs normal week-to-week variance and can hide a large localized runaway underneath it. A good anomaly signal fires on a service crossing its own baseline by an unusual margin, not on the account-wide total moving at all.

The signal is only as good as what it's compared against: it needs a normalized, same-schedule view across every provider to have a reliable baseline to deviate from in the first place.

Budget and budget alert

A budget is a target spend ceiling for a scope of cost; a budget alert notifies an owner when actual or forecasted spend approaches or crosses it.

A budget sets an explicit ceiling — for an account, a team, a project, a connector — against which actual spend is tracked. A budget alert is the notification layer on top: a threshold (50% of budget consumed, forecasted to exceed 100% by month-end) that pages the right owner while there's still time to act, rather than a ceiling that's only checked when someone happens to look.

Budgets work best paired with anomaly detection rather than instead of it — a budget alert catches gradual overshoot against a known target, while an anomaly alert catches a sudden spike a static budget threshold might not cross until it's already large.

Cost forecasting

Projecting future spend from historical trend and known upcoming changes, used to catch a budget overrun before it happens rather than after.

Forecasting extends a spend trend forward — typically to the end of the current billing period — so a team can see whether current behavior is on track to land within budget well before the period closes. A simple run-rate projection (current daily average × remaining days) is often good enough; more sophisticated forecasts account for known seasonality or planned changes like a new feature launch or a committed-use purchase.

Forecast accuracy depends entirely on how normalized and current the underlying data is — a forecast built on stale or unreconciled numbers is confidently wrong, which is worse than no forecast at all.

A forecast is only useful if the people who need it actually see it: saved as a scheduled report, it can be delivered as a CSV or PDF on a weekly or monthly cadence instead of relying on someone to remember to check the dashboard.

Run-rate

Current spend annualized (or projected to month-end) as if the recent pace continued unchanged — a quick, if naive, forward-looking number.

Run-rate takes a recent, representative period of spend and extrapolates it forward at the same pace — a common shorthand is "current monthly spend × 12" for an annualized figure. It's useful precisely because it's fast to compute and easy to communicate, which makes it the default starting point for forecasting and budget conversations.

Its weakness is the same as its strength: it assumes the recent pace is representative, which breaks down around known step-changes — a new commitment kicking in, a planned feature launch, seasonal usage swings — that a naive run-rate can't see coming.

Total cost of ownershipTCO

The full cost of a system or vendor decision over its useful life, including costs beyond the sticker price — migration, integration, ongoing operation, and eventual replacement.

A vendor's list price or a cloud service's published rate is only ever part of the real cost. TCO adds in what the sticker price leaves out: migration and integration effort, ongoing operational overhead, training, support, and — for anything priced as a percentage of spend or savings — the fact that the bill grows as you grow, regardless of the nominal rate quoted at signup.

TCO is the right lens for exactly the comparisons that look deceptively simple otherwise: a percentage-of-savings cost tool that looks cheap at your current spend can have a much higher TCO than a flat-rate alternative once modeled at 2x or 5x your current scale.

Bill shock

The experience of an invoice arriving dramatically higher than expected, with no earlier warning that it was building.

Bill shock isn't really about the invoice — it's a symptom of a monitoring gap. Cloud and AI invoices are lagging indicators by construction (most bill monthly), so if the only signal a team has is the invoice itself, any cost that grew during the billing period arrives as a surprise no matter how gradually or suddenly it actually built.

The fix isn't a smaller invoice — it's a daily, normalized view with anomaly alerts sitting in front of it, so the same growth in spend gets caught while it's still small enough to be routine, instead of being discovered all at once, already large, weeks later.

Percentage-of-savings pricing

A cost-tool pricing model that charges a cut of the spend it manages or the savings it identifies, rather than a flat fee.

Under percentage-of-savings (or percentage-of-managed-spend) pricing, a vendor's revenue rises directly with your cloud bill or with the savings it can claim credit for finding — which means the vendor's incentive is not quite the same as yours. A tool priced this way benefits from your spend staying high or from claiming ever-larger savings, not from making itself unnecessary by helping you actually spend less.

Flat, plan-based pricing removes that misalignment: the fee stays constant regardless of spend or savings, so the vendor's only real incentive is for the product to stay useful enough that you keep paying for it — the same incentive any other software runs on.