Glossary

A way to limit what each person can see or do in a tool based on their role. For example, Finance can view chargeback reports, while Engineering can view service level costs.

A deployment that runs without direct internet connectivity. Used in regulated environments where systems must stay isolated.

The process of mapping shared cloud costs to the teams, products, environments, or customers that caused them.

A label you allocate by, such as team, product, business unit, environment, or customer.

Spend that happens continuously because something is running 24/7, even when usage is low (for example, a NAT Gateway or an always-on instance).

A spend pattern that is unusual compared to normal behavior, like a sudden daily spike or a steady climb that does not match expected usage.

Finding abnormal spend patterns automatically and alerting the right team early.

Pulling billing and usage data directly from a provider's APIs instead of uploading files.

A target spend limit for a team, product, or environment over a time period.

The gap between planned spend and actual spend.

Billing internal teams for the costs they create. It is used when Finance wants teams to be accountable like they would be with a real invoice.

The operating practice of understanding cloud spend, assigning ownership, forecasting, and reducing waste in a repeatable way.

Discount programs like Reserved Instances and Savings Plans where you commit to usage to get lower rates.

Shared costs that are not naturally tied to one team or service, like shared networking, shared platforms, or central tooling.

The main reason spend is rising, such as a specific service, region, workload, or configuration change.

A change that increases cost compared to the previous baseline. DevX focuses on catching these before they hit production.

Tags you define and apply to resources so you can group and allocate spend consistently.

Sharing cost reports with teams without billing them. It is used to build awareness before moving to chargeback.

Costs from platforms like Databricks and Snowflake, often tied to compute time, warehouse usage, or credits.

Different ways to slice the same spend data, for example by team, environment, product, region, or service.

A high level score that summarizes how efficiently spend is being used, based on waste signals and coverage gaps found in the snapshot.

A read-only analysis created from a single invoice upload. It is meant to give teams a starting baseline before they set up full integrations.

A grouping like production, staging, or development. Cost issues often look different in non-production versus production.

Estimating future spend based on current usage, trend patterns, and planned changes.

A graphics processing unit used for AI training and inference. GPU costs often move quickly with demand and scaling.

Rules that prevent risky cost behavior, such as stopping an always-on resource in non-production or flagging a large instance type increase.

Running a model to generate output, for example answering a question or producing text. Inference is often a large part of ongoing AI cost.

Connections that bring billing, usage, and ownership signals into CloudVerse or DevX. Examples include cloud providers, Kubernetes, OpenAI, identity systems, and ticketing tools.

Uploading billing files like PDF, CSV, or XLSX so the tool can parse costs without needing direct cloud access.

Mapping cluster costs to namespaces, services, or workloads so teams know who is responsible for the spend.

Granting only the minimum access needed to do the job. CloudVerse integrations are typically scoped and read-only by default.

A model that generates text or other outputs. LLM costs are commonly tied to token usage and request volume.

Helping Finance reconcile cloud spend for accounting close, including allocation, variance explanation, and reporting.

Using more than one cloud provider, such as AWS, Azure, and GCP. This increases reporting and allocation complexity.

Separating data and controls across multiple business units, subsidiaries, or customers inside one platform.

Environments used for testing and development. A common cost issue is running production-like resources in non-prod all the time.

A consistent model that standardizes billing, usage, tags, and ownership across sources so reporting and automation behave the same way everywhere.

Applying an optimization action directly from a recommendation, usually with tracking and audit logging.

Reducing waste and improving efficiency by changing how resources are provisioned or used. Examples include rightsizing, cleaning up idle resources, and improving commitment coverage.

A clear mapping between spend and the team or product responsible for it.

Applying cost rules consistently across repos and teams, such as requiring approval for high-impact infrastructure changes.

Estimating and reviewing cost impact before a change ships, usually during pull request review or CI.

A request to merge code changes. DevX adds cost checks and cost comments directly into PR workflows.

See "Access control".

An integration mode that can read billing and usage data but cannot change resources.

Alerts based on current usage patterns rather than waiting for end-of-month billing.

Savings that are actually achieved and tracked, not just estimated.

A commitment discount model, commonly used in AWS and other clouds, where you reserve capacity or usage to reduce cost.

Changing resource sizes to match real usage, for example moving from a larger instance to a smaller one if utilization is consistently low.

A commitment discount model where you commit to a spend level or usage level to get reduced rates.

Access granted to only the required accounts, projects, or billing scopes, often with tenant boundaries.

How much spend changed compared to a prior period or compared to a budget.

How much of your spend is properly tagged. Poor tag coverage often blocks accurate allocation and chargeback.

Keeping one business unit's or customer's data separate from another's in the same platform.

Units used to measure LLM usage. Costs are often tied to tokens processed or generated.

A single consolidated view of spend across multiple clouds and accounts.

Cost measured in a way the business understands, like cost per customer, cost per product, cost per feature, or cost per transaction.

Pricing where cost depends on how much you use, not just what you provision.

A sign that money is being spent without value, such as idle resources, always-on non-prod infrastructure, low utilization, or poor commitment coverage.

Managing cost based on what workloads are doing, not just what the invoice says later. This typically requires linking spend to services, features, environments, and runtime signals.