Reading a Cloud Invoice: The Line Items That Matter

A cloud invoice is organised for the provider’s convenience, not yours. It
groups charges by service, which means a single project’s costs are scattered
across half a dozen headings, and one heading may contain charges from several
unrelated projects. Reading one properly is a skill, and it takes about twenty
minutes to acquire.

The structure

Nearly every provider’s bill has the same three layers, whatever they are
called.

At the top, a summary showing total charges, credits applied
and tax. This is the number you remember and the least useful for diagnosis.

In the middle, a breakdown by service: compute, storage,
data transfer, databases, and so on. This tells you which category your money
went to.

Underneath, usage detail, where each service is broken into
specific meters with quantities and rates. This is the layer that answers
questions, and the one most people never open.

Read the usage detail, not the summary

The summary tells you the bill went up. The usage detail tells you that your
outbound transfer went from eight gigabytes to four hundred, which is a
different kind of fact. Any real investigation starts at the bottom layer.

What you are looking for in that layer is a quantity that changed. Rates
rarely change without notice. Quantities change constantly, and a quantity that
roughly doubled between two months is the thread worth pulling.

The line items worth checking every month

• Compute hours by instance type. If the hours exceed roughly
  seven hundred and thirty per instance per month, you are running more instances
  than you think.
• Storage, separated from compute. Storage that grows while
  compute stays flat usually means snapshots accumulating.
• Outbound data transfer. The most volatile line on most
  bills and the one most likely to reflect something you did not intend.
• Idle resource charges. Unattached IP addresses, volumes
  with no instance, and load balancers with no backends. These are small
  individually and embarrassing collectively.
• Anything in a region you do not use. A charge in a region
  you have never deliberately deployed to is worth investigating immediately,
  because the benign explanation is a forgotten test and the other explanation is
  compromised credentials.
• Credits applied. Knowing how much credit absorbed this
  month’s bill tells you what next month looks like when it runs out.

Tracing a charge to its cause

Work from the meter back to the resource:

1. Identify the exact meter name and the region from the usage detail.
2. Open the corresponding service in the console, filtered to that region.
3. Match the quantity to a specific resource. If the meter says seven hundred
   and thirty hours and you see one instance, that is your answer.
4. If nothing in the console accounts for it, look at deleted resources. A
   machine that ran for three weeks and was destroyed still appears on the invoice
   for the month in which it ran.

This is considerably easier if your resources carry tags identifying their
project and environment. If they do not, now is the moment to start, because the
next investigation will be exactly as tedious as this one.

Comparing month to month

Most consoles offer a cost explorer or analysis view that charts spend over
time and lets you group it by service, region or tag. This is a better tool than
the invoice for answering “what changed”, because it shows you the shape of the
change rather than two static totals.

Look at the daily view rather than the monthly one. A charge that appears as
a modest monthly increase is often a step change on a specific day, and that day
usually corresponds to something you did. Knowing the date turns a mystery into
a memory.

Two habits that make this easy

Check the bill mid-month, not only at the end. Half a month of data is enough
to spot a trend while there is still time to act on it.

And when you do find something, write down what it was. The same forgotten
test environment is discovered independently about three times by most teams
before anybody records that it exists.