Why Is My Google Cloud Bill So High? How to Find Out

Google Cloud bills differently from the other two, so the surprises are different as well. If you came from AWS or Azure, the habits you built there will not find these.

Here is where the money actually goes, and how to see yours.

First, read the bill the way Google wrote it

In the console, go to Billing, then Reports. The default view groups by service, which tells you Compute Engine is expensive and nothing more useful than that.

Change the grouping to SKU. That is the level where Google names the actual thing you are paying for, and it is where a vague line about networking turns into a specific charge with a specific cause.

Then set the time range to daily rather than monthly. A bill that stepped up on one specific day is a different problem from one that has been climbing since March, and the shape of the graph tells you which you have before you read a single number.

The IP address that costs more when you stop using it

This is the one that makes people read the sentence twice.

Google's own documentation: "If you reserve a static external IP address and do not assign it to a resource such as a VM instance or a forwarding rule, you are charged at a higher rate than for static and ephemeral external IP addresses that are in use."

A higher rate. The address sitting idle costs you more per hour than the same address attached to a running machine. It is deliberate, and the logic is sound once you see it: IPv4 addresses are genuinely scarce, so Google charges more for hoarding one than for using one.

The practical result is that every time somebody deletes a VM and keeps its reserved address "just in case", the cost of that address goes up rather than away.

Go and look: in the console, VPC network, then IP addresses. There is a column showing what each one is attached to. Anything marked as not in use is costing you at the worse rate, right now. Check the current per-hour figures on Google's network pricing page for your region, because rates change and a number I write today goes stale.

The stopped machine that still bills

Stopping a Compute Engine instance ends the charge for the vCPUs and the memory. It does not touch the disk.

Your boot disk and every persistent disk attached to that instance carry on billing at full price, because the storage is still allocated and your data is still sitting on it. That is correct behaviour, and it is also why a project full of "we turned those off months ago" machines is not as cheap as everyone believes.

The same applies to disks with no instance at all. Delete a VM and choose to keep the disk, and the disk stays, billing, attached to nothing.

The query that costs more than the server

This is the big one, and it is unique to how Google prices analytics.

On the default on-demand model, BigQuery charges you for the bytes your query reads, not for how long it runs and not for how many rows come back. A query that returns three rows can read a terabyte to find them, and you pay for the terabyte.

BigQuery stores data by column rather than by row. So when you write SELECT star, you are asking it to read every column in the table, including the enormous ones your question did not need. Naming the three columns you actually want can be the difference between cents and real money, on the same table, for the same answer.

If somebody has a dashboard refreshing a SELECT star against a large table every fifteen minutes, that is your bill. It does not look like a server, nobody thinks of it as infrastructure, and it runs ninety six times a day.

Two habits fix most of it. Name your columns. And use the query validator in the console, which tells you how many bytes a query will read before you run it. That estimate is free and it turns an invisible cost into a visible one.

Logging, which starts free and does not stay that way

Cloud Logging bills on how much you send it. There is a free allowance each month and then it is priced per unit of data ingested.

Nobody budgets for this because nobody decides to do it. You turn on more detailed logging during an incident, or a service starts logging every request because somebody set the level to debug and moved on. The volume scales with how talkative your infrastructure is, which is not a number anyone estimates correctly in advance.

If your bill is climbing steadily rather than jumping, check this before you check your machines.

One thing Google does in your favour

Worth knowing, because it changes what is worth optimising. Google applies sustained use discounts automatically on Compute Engine. Run an instance for a large share of the month and the price per hour drops on its own, with nothing to buy and nothing to commit to.

So a machine that runs all month is already discounted. The waste is not usually in the things running constantly. It is in the things that should not exist at all.

Before you close the tab

Set a budget alert. Billing, then Budgets and alerts, set the amount to roughly what you spend now and let it email you at fifty, ninety and a hundred percent.

It is free, it takes two minutes, and it is the difference between finding out in three days and finding out on the invoice.

Why this is harder than it should be

Nothing above is hidden. It is all in your console and Google documents every bit of it openly.

The difficulty is that the answer is spread across four unrelated screens, written in SKU names rather than in the names you gave things, and the rules are genuinely not the same rules as the other clouds. You are not bad at this. You are doing a translation job that nobody handed you a dictionary for.

Where we are with this

I should be straight with you here rather than sell you something.

Liberra is an AI that connects to your cloud, keeps an index of what is in it, and answers questions like this one in plain English. Today that runs on AWS and Azure, where it reads your real spend and tells you what is idle and what changed. Google Cloud is next, and I am not going to give you a date for it, because dates given before something ships are just guesses with confidence.

So if you are on Google Cloud today, use the list above. It is the same list I would be running for you, and it costs nothing.

If you also run AWS or Azure, that part works now, and it cannot delete anything in either of them. The delete commands are blocked in the code, and every change that writes waits for you to approve it first.

Founder, Liberra AI