Your Cloud Bill Is Not an Infrastructure Problem
When a cloud bill gets uncomfortable, the reflex is to go looking for waste — idle instances, oversized databases, forgotten volumes. That work is real and it is worth doing once.
It is also not why the bill is high.
The bill is high because nobody can answer a simpler question: what does one unit of your business cost to serve? One customer, one order, one tenant, one job. Until that number exists, every cost conversation is an argument about whether $40,000 a month is a lot, and that argument has no answer.
The split that creates the problem
In most organisations, the people who create cost and the people who see cost are different people.
An engineer picks an instance size on a Tuesday. That decision shows up in a bill six weeks later, aggregated with a thousand other decisions, on a line item that says EC2-Other. Finance sees a number going up. Engineering sees a system that works.
Neither has the information to act. Finance cannot tell which decision caused it. Engineering has no feedback loop — nothing about their Tuesday told them what it would cost.
That is the actual defect, and it is organisational rather than technical. It is why rightsizing exercises produce a saving that erodes within two quarters: you cut the fat without changing the process that grew it.
The unit metric
Pick the thing your business counts. Then divide.
- A SaaS product: cost per active tenant per month
- An e-commerce operation: cost per order
- A services business with a portal: cost per client
- A media platform: cost per hour delivered
Now you can have a real conversation. “We spend $3.10 to serve a customer who pays $29” is a sentence a business can act on. “AWS was $41,000 last month” is not.
It also changes what growth means. If your bill rises 30% and your unit cost falls 12%, that is a healthy month. Absolute-bill thinking would call it a problem and go looking for something to cut.
This is the single highest-leverage change, and it requires no new tooling. It requires tagging discipline and a denominator.
Why tagging is the boring prerequisite
Every unit-cost model depends on being able to attribute spend. That means tags, consistently applied, enforced rather than requested.
The three that matter:
- Owner — which team or person is accountable
- Environment — production, staging, development
- Product or customer — the thing your unit metric counts
The usual failure is that tagging is a policy nobody enforces, so it holds for the resources created in the month after the policy and decays after. Enforce it at creation: a resource without required tags does not get created. Both major clouds support this, and it is the difference between a cost model that works and one that is 60% untagged.
Expect the first attribution pass to be ugly. That is not a reason to delay — an 80%-attributed bill is enormously more useful than an unattributed one.
Where the tools fit
FinOps platforms — Vantage, CloudZero, Cast AI and the rest — are good at what the native billing consoles are bad at: cross-account roll-ups, per-unit reporting, anomaly alerts, and automated commitment management.
Two things to understand about the market before you buy.
They price on a percentage of your cloud spend, or per-account, or both. At small scale the tool can be a meaningful fraction of the saving. Model that before signing, because a platform costing 3% of spend to save 8% is a different deal from one costing 3% to save 40%.
Most run partner and MSP channels rather than affiliate programmes, and few publish rates publicly. If your provider recommends one, it is reasonable to ask what their relationship is. We think that question should be easy to answer, which is why we say plainly: we hold no commercial relationship with the platforms named above.
The autoscaling caveat
Scaling to demand is the right default, and it is not free — cold starts, minimum viable capacity, and the engineering time to make workloads genuinely scalable. That is a separate discussion and we have written it up separately.
The short version: autoscaling saves money on workloads with real variance. On steady-state workloads it adds complexity and sometimes cost, and the honest recommendation there is a commitment discount, not an autoscaler.
The order we would work in
- Tag enforcement at creation. Nothing works without it.
- Define the unit metric. One number, agreed by both finance and engineering.
- Kill the obvious waste — unattached volumes, idle load balancers, forgotten environments. One pass.
- Commitments for steady-state. Reserved capacity and savings plans are the largest single lever for most SMBs, and the least glamorous.
- Autoscaling for variable workloads, once 1–4 are done.
- Buy a platform if the reporting burden justifies it. Not first.
Most vendors sell you step 6. Steps 1 and 2 are free, and they are where the result comes from.
The uncomfortable part
A cloud cost problem is usually a visibility problem wearing a technical costume.
The engineering fixes are real but they are second-order — you can rightsize a fleet and still be back in twelve months, because the process that produced the fleet is unchanged.
The teams that hold a lower bill are the ones where the person choosing the instance size can see what it costs.
If your bill is going the wrong way
We manage cloud for Australian businesses and this is the conversation we have most often. If you want a straight read on whether yours is a waste problem or a visibility problem, send us a month of billing data — we will tell you which, and if the answer is “turn on tagging and buy nothing”, that is what we will say.