How to read a cloud bill

The first serious cloud bill is usually a shock, and not because the total is wrong. It is because the document explains almost nothing about why the total is what it is. Hundreds of line items, opaque usage-type codes, and services you do not remember enabling.

The bill is organised for accounting. To understand it you have to regroup it, and there are three questions worth asking in order.

Question one: which services, and is the ranking a surprise?

Start by grouping total cost by service for the last full month. This takes one minute in any provider’s cost tool and immediately narrows the field, because cloud spend is almost always concentrated: three or four services typically account for eighty percent of the total.

What you are looking for is not the biggest number. It is the biggest number that surprises you.

Compute being the largest line is expected. Data transfer being the second largest is a finding. A logging or monitoring service in the top five is a finding. A managed database costing more than the application it serves is a finding.

Anything you cannot immediately explain is where the money is.

Question two: what is the shape of the biggest lines?

Service-level grouping tells you the charge came from compute, which you already knew. To act on it you need the next level down, and the useful dimension is usage type rather than service.

Usage type separates things that look identical at service level but behave completely differently. Within compute, it separates instance hours by family and size from the charges for attached storage, from the charges for public addresses, from data transfer. Within storage, it separates the storage itself from the requests made against it and from retrieval charges on colder tiers.

This is the level at which the cause becomes visible. “Compute is expensive” is not actionable. “Sixty percent of compute cost is a family we stopped using six months ago” is.

Question three: is it running, or is it forgotten?

Every cloud estate accumulates resources that nobody uses and nobody deletes. They are rarely individually large, which is precisely why they survive, and collectively they are frequently ten to twenty percent of a bill.

The usual suspects, in rough order of how often they appear:

• Unattached storage volumes left behind when instances were deleted. They keep billing at full rate.
• Old snapshots, often hundreds of them, created by a backup script nobody has reviewed.
• Idle load balancers billing by the hour with no healthy targets behind them.
• Reserved public IP addresses not attached to anything.
• NAT gateways in a subnet with nothing in it.
• Development environments created for a project that finished.
• Log groups with no retention policy, growing forever.
• Instances in a region nobody opens, which is why they were never noticed.

The last one deserves emphasis. Because consoles default to one region, resources in others become invisible. The billing view is global and will show them.

The four dimensions worth cutting by

Once you have the basics, four groupings answer most questions.

By service tells you where the money is.

By usage type tells you what specifically is being charged for.

By region finds forgotten resources and reveals whether a cheap region is being used for anything expensive.

By tag tells you which team, project or environment is responsible.

That last one only works if things are tagged, which is the argument for enforcing a small set of mandatory tags. Cost allocation without tags is archaeology.

Reading the trend rather than the total

A single month’s bill tells you the level. The trend tells you the story, and the story is what you can act on.

Look at daily cost over the last ninety days. Three patterns matter.

A step change means something was created or a configuration changed on a specific day. That is the easiest thing in the world to investigate, because you know the date.

A gradual climb usually means something is accumulating: storage growing, logs retained, snapshots piling up, or data transfer rising with traffic.

A sawtooth means something scheduled. Batch jobs, backups, or environments that start and stop. Worth confirming it is intentional.

Flat spend that is simply higher than you would like is the least urgent, because nothing is going wrong; it is a right-sizing question rather than an investigation.

The recurring habit that prevents surprises

Set a monthly recurring appointment of thirty minutes. In it:

1. Look at the daily trend for the last ninety days and investigate any step change.
2. Group by service and check the top five against last month.
3. Sweep for unattached volumes, old snapshots and idle load balancers.
4. Check that budget alerts still reflect current expectations.

Thirty minutes a month catches almost everything before it becomes a quarterly conversation.

Alerts, so you are told rather than finding out

Budget alerts on both actual and forecast spend are the minimum. Actual-spend alerts tell you after money is committed; forecast alerts tell you while there is still time.

An anomaly detection feature, where available, is more useful than a fixed threshold, because it catches a service that has quietly tripled while the total remains under budget.

Send the alerts somewhere a human reads. A cost alert delivered to an unmonitored mailbox is a log entry, not an alert.

The same reasoning applies across providers. The catalogue of cloud accounts sets out where each one fits, if you are still deciding which to build on.

For the vendor’s own reference on the services involved here, see the AWS documentation.

Putting any of this into practice needs an account to work in. We stock AWS accounts in sixteen configurations, and the cloud account catalogue sets them beside nine other providers.

Questions people ask