Google Cloud is a great place to host a website, an API or a side project. It's also a place where a forgotten VM or a badly configured bucket can quietly cost more than your domain, your theme and your coffee budget combined.
Most surprise cloud bills don't come from complicated setups. They come from simple ones where nobody set up billing properly at the start. Here's how to get it right, ideally before you deploy anything.
Table of Contents
The free trial and the free tier are not the same thing
New accounts usually get trial credit to use within the first 90 days. Separately, Google Cloud has an Always Free tier, which includes things like a small e2-micro VM in certain US regions and a limited amount of Cloud Storage.
The trap is assuming that something covered by the trial stays free once the credit runs out. It doesn't. Before the trial ends, go through everything you've created and check what falls inside the free tier limits. Delete or downsize the rest.
One project per site or app
It's tempting to throw everything into a single project. Don't. Separate projects keep resources, permissions and costs apart, so when your bill jumps you can see straight away which site caused it. Projects are free to create, and they make cleanup much easier when a side project quietly dies.
Add labels as well, such as env:prod or client:acme. They take seconds to apply and make cost reports far more readable.
Set budgets and alerts on day one
In the Billing section, create a budget for each project and set alerts at 50, 90 and 100 percent. Make sure the alerts go to an inbox you actually read.
One thing a lot of people miss: a budget in Google Cloud doesn't stop spending. It only notifies you. If you want a hard stop, you have to automate it, for example with a Cloud Function that listens for budget notifications and disables billing on the project. For hobby projects, that's usually worth the half hour it takes.
Watch the usual suspects
A handful of things cause most unexpected charges on small sites:
- VMs left running after a test, especially the bigger machine types;
- persistent disks and snapshots that outlive the VM they belonged to;
- static IP addresses you reserved and then stopped using;
- network egress, if a site suddenly gets popular or someone hotlinks your images.
Check these once a month, even when the bill looks normal.
Sort out the payment method
Google Cloud charges the card on your billing account, and if payment fails, services can be suspended after a grace period. For a live site that's a real risk, and a few ordinary situations make it more likely: a card that expires mid-year, a bank that blocks recurring foreign charges, or a shared card that maxes out because of something unrelated.
A tidy fix is to give cloud billing its own card. A dedicated virtual card for Google Cloud keeps hosting costs separate from your other spending, shows you exactly what your infrastructure costs each month and lets you put a ceiling on what can be charged. It's especially handy if you host sites for clients and need clean numbers to bill them.
Export billing data once you get serious
When you're running more than a couple of projects, turn on billing export to BigQuery. You get detailed cost data you can query, and a simple dashboard on top of it will tell you more than the default reports ever will.
Quick checklist
Separate projects, labels, budgets with alerts, a monthly sweep for idle resources and a payment method you control. None of it is hard, and all of it is easier to do before launch than after your first unpleasant invoice.