Table of Contents
- The Cost Reduction Treadmill
- Total Spend Is Not a Useful Number
- Choosing a Unit That Reflects the Business
- Allocation Is the Prerequisite
- Where Untagged Cost Hides
- Commitment Discounts Without the Trap
- Making Engineers Cost-Aware
- An Operating Rhythm
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: A rising cloud bill is not a problem if cost per unit of business value is falling. Without unit economics you cannot distinguish growth from waste, which means every cost conversation is an argument rather than an analysis.
The Cost Reduction Treadmill
An organisation notices the cloud bill has grown. A cost reduction initiative launches. Idle resources are deleted, instances are right-sized, a commitment discount is negotiated. Spend drops fifteen percent.
Six months later the bill is higher than before the initiative, and nobody can say whether that is good or bad.
The reason the cycle repeats is that the effort addressed the symptom without establishing the measurement that would make the situation interpretable. Total spend went down and then up, and neither movement was connected to what the business received in return.
Consider two organisations whose bills both grew forty percent. In the first, customer count doubled, so cost per customer fell substantially. In the second, customer count was flat and inefficiency accumulated. These are opposite situations that look identical in the only number being tracked.
The distinguishing capability is unit economics: knowing what a unit of your business costs to serve. With it, cost decisions become analysis. Without it, they are cost-cutting exercises that recur indefinitely because nobody can tell whether the underlying trend is improving.
Total Spend Is Not a Useful Number
Total cloud spend answers no question anyone actually has.
The questions that matter are different in kind. What does it cost to serve one customer, and is that improving? Which product lines are profitable at the infrastructure level? Can we afford to onboard this large customer at the price we quoted? Which team’s spend is growing faster than its output? Where is spend growing without corresponding value?
None of these are answerable from a total. All of them require spend attributed to something the business recognises.
This has an important consequence for how cost work is framed. Presented as cost reduction, it is a constraint on engineering — a demand to do the same with less, which teams reasonably resent. Presented as unit economics, it is a business intelligence capability that happens to enable better cost decisions. The second framing produces cooperation because it produces information engineers can use.
It also changes what success looks like. A team whose total spend grew thirty percent while cost per transaction fell twenty percent has done well. Under total-spend accounting they look like a problem.
Choosing a Unit That Reflects the Business
The unit must be something the business already cares about, and the choice depends on what drives your costs.
| Business model | Useful unit |
|---|---|
| SaaS, per-seat pricing | Cost per active user per month |
| SaaS, usage-based pricing | Cost per API call or per operation |
| E-commerce | Cost per order, cost per session |
| Data platform | Cost per gigabyte ingested, per query |
| Media | Cost per stream hour, per transcode |
| AI product | Cost per generation, per conversation |
Properties of a unit that works: it correlates with what customers pay for, it is already measured somewhere in the business, it is understood without explanation, and it can be tracked over time consistently.
Several units are usually needed rather than one. An overall cost per customer for the business view, plus per-service unit costs for engineering ownership. The overall number tells you whether the business is improving; the per-service numbers tell you where to look.
The measurement discipline that matters is consistency. A unit definition that changes quarterly produces a trend line that means nothing. Fixing the definition and tolerating its imperfections is better than refining it continuously.
Allocation Is the Prerequisite
Attributing cost requires knowing which resources belong to what. This is mundane and it is the foundation everything else depends on.
Tagging enforced at creation. Team, service, environment, and cost centre as mandatory tags, enforced by policy so untagged resources cannot be created. Retroactive tagging is a project that never finishes; enforcement at creation is a configuration change.
Account or project separation by team. The strongest allocation boundary available, because it requires no tagging discipline. Cost is attributable by construction.
Shared cost distribution rules. Some costs genuinely cannot be attributed directly — the observability platform, the networking layer, the security tooling. Distribute them by a defensible key such as usage or headcount, document the method, and apply it consistently.
Kubernetes cost allocation. Clusters share nodes across teams, so cloud billing shows one large compute line. Namespace-level attribution requires dedicated tooling that maps resource consumption to workloads.
Allocation completeness is worth measuring explicitly. If thirty percent of spend is unallocated, unit economics computed from the remaining seventy percent understate every unit cost by a variable amount. Getting allocation above ninety percent is a precondition for the numbers being trustworthy.
Where Untagged Cost Hides
The categories that consistently escape attribution and accumulate:
Orphaned storage. Volumes whose instances were terminated, snapshots of deleted systems, and old backups past any useful retention. These bill indefinitely and appear in no team’s budget.
Idle load balancers and reserved addresses. Provisioned for something that no longer exists.
Data transfer. Frequently the largest untagged category and the hardest to attribute, because it is a property of traffic between resources rather than of a resource itself. Cross-zone and cross-region transfer accumulates quietly.
Non-production environments running continuously. Development and staging environments idle outside working hours, which is roughly seventy percent of the week.
Logging and observability volume. Ingestion cost scales with traffic and is rarely attributed to the service producing the data, which removes the incentive to log less.
Old container images and artefacts. Registry storage grows monotonically without a lifecycle policy.
Abandoned experiments. Resources created for an evaluation, never deleted, owned by someone who has moved on.
Two of these deserve specific attention because they are both large and straightforwardly fixable. Scheduled shutdown of non-production environments outside working hours reduces their cost substantially with no engineering impact. And lifecycle policies on storage, snapshots, and registries prevent monotonic accumulation without any ongoing effort.
Commitment Discounts Without the Trap
Committing to sustained usage in exchange for a discount is genuine savings and carries a specific risk.
The risk is committing to your current inefficiency. A discount on an overprovisioned footprint locks in the waste at a reduced rate, and the commitment then discourages the architectural changes that would reduce usage — because reducing usage below the commitment means paying for capacity you no longer consume.
The sequencing that avoids this: right-size first, so the commitment covers what you actually need. Then commit to a baseline conservatively — typically well below current usage, covering only the portion you are confident will persist. Prefer flexible commitment types that apply across instance families and regions where available, since they survive architectural change. Ladder commitment expiry across time rather than having everything renew simultaneously. And review coverage regularly, since both usage and available discount structures change.
A further consideration that is easy to miss: commitments should be sized against forecast, not against current usage. A commitment made just before a planned migration to a different compute model is a commitment to the thing you are leaving.
Making Engineers Cost-Aware
Cost decisions are made by engineers choosing instance types, retention periods, and architectures. Cost information that does not reach them cannot influence those decisions.
What works:
Cost visible in the tools engineers already use. A weekly summary in the team’s channel, or cost annotations in the deployment interface. Requiring a visit to a finance dashboard means it will not happen.
Cost estimates on infrastructure changes. A pull request adding resources showing the monthly cost delta makes the trade-off visible at the decision point, which is the only moment it can influence the outcome.
Showback before chargeback. Showing teams their spend without billing them internally produces most of the behaviour change with none of the political difficulty. Chargeback adds accounting overhead and adversarial dynamics.
Unit cost as a team metric. Cost per transaction for the services a team owns, tracked alongside their other metrics. This rewards efficiency rather than penalising growth.
Anomaly alerts routed to the owning team. A spend spike detected by finance a month later is history. The same spike alerted to the team that caused it within a day is actionable.
What does not work: cost as a punitive measure, spend targets without context about growth, and finance-owned dashboards nobody outside finance opens.
An Operating Rhythm
A cadence that keeps cost management functioning rather than episodic:
Daily. Automated anomaly detection on spend, alerting the owning team.
Weekly. Per-team spend and unit cost summary, delivered where teams already work.
Monthly. Unit economics review — the trend in cost per unit, by service and overall. Allocation completeness. Progress on identified optimisations.
Quarterly. Commitment coverage review, forecast against actual, and architectural cost review for the largest spend concentrations.
Continuously. Tagging enforcement, lifecycle policies, and scheduled shutdown of non-production environments running as automation rather than as tasks.
The monthly unit economics review is the meeting that matters. It is the one where the question “is our infrastructure efficiency improving?” gets a numerical answer, and it is the one that converts cost management from periodic cutting into a tracked trend.
Common Pitfalls
Optimising total spend without unit economics. You cannot distinguish growth from waste.
Committing to discounts before right-sizing. Locks in the inefficiency at a lower rate.
Cost data only in a finance dashboard. Never reaches the people making the decisions.
Chargeback before showback. Adds political cost for marginal additional behaviour change.
Ignoring data transfer. Frequently large, usually untagged, and genuinely difficult to attribute.
Non-production running continuously. A substantial and easily recovered cost.
Retroactive tagging projects. Enforce at creation instead; retroactive efforts do not complete.
Conclusion
Cloud cost management fails when it is framed as reducing a total. The number that matters is cost per unit of business value, because that is the only figure that distinguishes efficient growth from accumulating waste.
Establish allocation first — tags enforced at creation, account separation by team, documented rules for genuinely shared costs — because unit economics computed on partially allocated spend is not trustworthy. Define a small number of units that the business already understands, fix the definitions, and track them monthly.
Then get the information to the people making the decisions. Cost deltas on infrastructure changes, weekly summaries where teams already work, and anomaly alerts routed to the owning team rather than discovered by finance a month later.
And clean up the categories that accumulate without anyone’s attention: orphaned storage, non-production environments running through the night, and registries without lifecycle policies. That work is unglamorous, requires no trade-off, and is usually the largest immediately available reduction.
Frequently Asked Questions
What is a good cost allocation target? Above ninety percent attributed to a team or service. Below that, unit economics are distorted by a variable amount and comparisons over time become unreliable.
Should teams be charged internally for their cloud spend? Showback first — visibility without billing. It produces most of the behaviour change. Chargeback adds accounting overhead and adversarial dynamics, and is worth it mainly where budgets are genuinely devolved.
How are shared costs handled? Distribute by a defensible key — usage, request volume, or headcount — document the method, and apply it consistently. The method matters less than the consistency, since trends are what you are tracking.
When should commitment discounts be purchased? After right-sizing, sized against forecast rather than current usage, covering a conservative baseline. Prefer flexible commitment types that survive architectural change.
Is a dedicated FinOps function necessary? Past a certain spend, yes — someone must own allocation, tooling, and the operating rhythm. Below that, a part-time owner with engineering support is usually sufficient. It should not be purely a finance function, since the decisions are engineering ones.
How much cloud spend is typically waste? Reported estimates commonly land between twenty and thirty percent, concentrated in overprovisioned resources, idle non-production environments, and orphaned storage. The specific figure matters less than the observation that the categories are consistent and identifiable.
What is the fastest available reduction? Deleting orphaned resources and scheduling non-production environments to shut down outside working hours. Both are pure waste elimination with no performance trade-off, and both are usually achievable in days.
