FinOps Vocabulary: Cloud Cost Optimisation Terms Explained

FinOps — Financial Operations for cloud — is a practice that brings engineering, finance, and business together to understand and optimise cloud spending. Cloud architects and engineers who understand FinOps vocabulary can participate meaningfully in cost reviews, architect cost-efficient systems, and communicate clearly with finance stakeholders. Here are the 60 terms you need.

Core FinOps Concepts

FinOps

FinOps (Financial Operations) is a cloud financial management practice and cultural movement focused on enabling organisations to get maximum business value from cloud spending through collaboration between engineering, finance, and product teams.

“Our FinOps practice reduced cloud spend by 30% in the first quarter without reducing capacity.”

Cloud Cost Management

Cloud cost management is the process of understanding, monitoring, and optimising cloud costs. It involves tagging resources, analysing spend, identifying waste, and implementing savings mechanisms.

Unit Economics

Unit economics in cloud means understanding cost per unit of value delivered — cost per API call, cost per transaction, cost per active user, cost per gigabyte processed.

“Our unit economics are trending in the wrong direction — cost per transaction grew 40% this quarter as usage scaled.”

COGS (Cost of Goods Sold)

COGS in a software business often includes server costs. Cloud engineers who understand COGS can align infrastructure decisions with business margins.

Billing Fundamentals

On-Demand Pricing

On-demand pricing means paying for compute capacity by the hour or second with no long-term commitment. Maximum flexibility, highest unit cost.

Reserved Instances (RIs) / Savings Plans

Reserved Instances (AWS/Azure) and Savings Plans allow you to commit to a specific compute configuration for 1 or 3 years in exchange for discounts of 40–72% compared to on-demand pricing.

“We converted our baseline workload to 1-year Reserved Instances. It’s not as flexible, but it cut our compute bill in half.”

Spot Instances / Preemptible VMs

Spot Instances (AWS) / Preemptible VMs (GCP) / Azure Spot VMs provide access to spare cloud capacity at 60–90% discounts — but the cloud provider can reclaim them with little notice.

“Our batch ML training jobs run on Spot Instances — we save 80%, and if a node is reclaimed, the job just checkpoints and restarts.”

Committed Use Discounts (CUDs)

Committed Use Discounts (GCP) are similar to Reserved Instances — commitment to a resource level for 1 or 3 years in exchange for significant discounts.

Pay-Per-Use / Serverless Pricing

Pay-per-use pricing charges only for actual consumption — invocations, GB-seconds, or API calls — rather than for provisioned capacity.

Resource Management

Rightsizing

Rightsizing is aligning instance types and sizes to actual usage — removing over-provisioned resources that are paying for capacity that isn’t being used.

“Our monitoring showed 12 instances running at <5% CPU utilisation. We rightsized them to smaller instance types — 40% cost reduction on those workloads.”

Over-Provisioning

Over-provisioning is allocating more compute, memory, or storage than the workload actually needs. Common cause of cloud waste.

Idle Resources

Idle resources are provisioned cloud resources that aren’t being actively used — development environments left running after hours, unattached volumes, unused load balancers.

“Our idle resource audit found $14,000/month in unused resources — dev environments that developers weren’t shutting down.”

Auto-Scaling

Auto-scaling adjusts compute capacity automatically based on demand — scaling out during peaks, scaling in when demand drops — optimising both performance and cost.

Instance Family

An instance family groups instances with the same architecture profile. Choosing the right instance family (compute-optimised, memory-optimised, GPU) is the first step in rightsizing.

Cost Allocation & Visibility

Tagging

Tagging (or labelling in GCP) is applying key-value metadata to cloud resources — enabling cost allocation by team, product, environment, or customer.

“Every resource must be tagged with ‘team’, ‘environment’, and ‘cost-centre’. Untagged resources get flagged in our cost review.”

Cost Allocation

Cost allocation is the process of attributing cloud costs to specific teams, products, or business units — enabling accountability and informed decision-making.

Showback

Showback means reporting cloud costs to teams so they can see what they’re spending — without actually charging them. Increases visibility without requiring financial process changes.

Chargeback

Chargeback goes further than showback — teams are actually charged for their cloud usage (internal billing). Requires robust tagging and cost allocation infrastructure.

“We’ve moved from showback to chargeback — teams now see cloud costs on their P&L, which has significantly changed their behaviour.”

Shared Services Allocation

Shared services allocation is the methodology for distributing costs of shared infrastructure (networking, logging, monitoring) across consuming teams.

Cost Centre

A cost centre is a financial unit within an organisation that incurs costs. Mapping cloud resources to cost centres enables finance reporting.

Waste Reduction

Cloud Waste

Cloud waste refers to spend on resources that don’t deliver business value — idle instances, unattached volumes, over-provisioned databases, unused Elastic IPs.

Zombie Resources

Zombie resources are provisioned resources that no one owns and no one is using — often created for testing and forgotten.

“The zombie resource cleanup freed up $8,000/month. Some of these instances had been running for two years with no owner.”

Orphaned Resources

Orphaned resources are resources no longer connected to any active workload — detached EBS volumes, unattached Elastic IPs, unused snapshots.

Cloud Waste Rate

Cloud waste rate is the percentage of cloud spend attributed to waste. Industry average is estimated at 30–35%.

Storage Costs

Storage Tiering / Intelligent Tiering

Storage tiering moves data between storage classes based on access frequency — e.g., hot tier for frequently accessed data, cold tier (Glacier, Archive) for rarely accessed data.

“We moved 3TB of compliance logs to Glacier — access latency increased from milliseconds to minutes, but monthly cost dropped by 97%.”

Egress Costs

Egress (data transfer out) is a significant and often-overlooked cloud cost. Moving data out of the cloud — to the internet, to another cloud, or to another region — is charged per GB.

“Our egress costs tripled after we enabled cross-region replication for all buckets. We now only replicate critical buckets.”

Data Transfer

Data transfer costs include:

Intra-region (AZ to AZ): typically small
Inter-region: higher
Internet egress: highest

FinOps Team Roles

FinOps Practitioner

A FinOps practitioner works across engineering and finance to optimise cloud costs — analysing spend, running rightsizing initiatives, and building cost visibility tooling.

Cloud Cost Champion

A cloud cost champion is an engineer (often a cloud architect or SRE) embedded in or coordinating with engineering teams to advocate for cost-efficient design decisions.

Tools & Reporting

Cost Explorer

Cost Explorer (AWS) is a visualisation tool for analysing AWS spending by service, region, tag, or usage type over time.

Billing Dashboard / Cost Management (Azure / GCP)

Azure Cost Management and GCP’s billing dashboards provide similar cost analysis and reporting capabilities.

Cloud Cost Anomaly Detection

Anomaly detection automatically flags unusual spending patterns — a sudden 5× spike in EC2 costs, for example — enabling rapid investigation before costs spiral.

“Anomaly detection caught a misconfigured auto-scaling group that was spinning up hundreds of instances. It saved us a $50,000 bill.”

Budget Alerts

Budget alerts trigger notifications when cloud spend approaches or exceeds a defined threshold — preventing bill shock.

Useful Phrases

In cost review meetings:

“Our cost per unit metric has increased — we need to investigate whether this is a scaling inefficiency or a pricing change.”
“We have significant idle resources in the dev environment. Can we schedule an auto-shutdown after business hours?”

When discussing commitments:

“Our baseline compute usage is stable enough to justify converting to Reserved Instances — the 3-year commitment saves 60% versus on-demand.”

When explaining showback/chargeback:

“We’re implementing showback first — teams can see their costs, learn, and build accountability before we switch to actual chargeback.”

Practice

Deepen your FinOps vocabulary with the Cloud FinOps exercise set and the Cloud Architect learning path.