Cloud Infrastructure
The first time you open a cloud provider's billing console, it looks less like a bill and more like a ransom note written by an accountant. There are line items for things you have never heard of, charges measured in units you cannot pronounce, and a total that seems to have been calculated by a random number generator. The good news is that most of the confusion comes from a small number of recurring patterns, and once you recognize them, the bill becomes readable.
The goal here is not to become a cloud economist. It is to be able to look at your bill, understand roughly where the money is going, and spot the charges that are obviously wrong or obviously avoidable. That is enough for most indie projects.
Start by grouping charges into a few buckets: compute, storage, network, and everything else. Compute is your servers, containers, or functions. Storage is disks, object storage, and snapshots. Network is data transfer in and out, plus things like load balancers and NAT gateways. Everything else includes managed databases, queues, logging, and the long tail of services you enabled once and forgot about.
For most small projects, network charges are the most surprising. Data transfer out to the internet is often billed per gigabyte, and it can quietly grow as your app gets more popular. NAT gateways, which many providers charge for by the hour and by the gigabyte, are a classic source of unexpected cost, especially in Kubernetes clusters. If you see a line item that scales with traffic and you did not plan for it, that is worth investigating.
Storage charges have their own traps. Snapshots of old disks accumulate silently. Object storage has retrieval fees that only apply when you actually read the data, which means a backup you never restore costs almost nothing, but the day you need it you might get a surprise. Logging services often charge for ingestion and retention separately, and verbose logs from a misconfigured app can generate real money over a month.
The everything-else bucket is where the truly forgotten charges live. An old load balancer you stopped using. A managed database you spun up for a test and never deleted. A static IP address that is not attached to anything. These are small individually, but they add up, and they are the easiest wins when you are trying to cut costs.
Set a recurring calendar reminder for the day after your bill is generated. Spend fifteen minutes doing three things. First, compare the total to last month. If it jumped, find out why before you do anything else. Second, sort line items by cost and look at the top five. Do you recognize all of them? Can you explain what each one is for? If not, that is a lead worth chasing. Third, scan for anything that looks like a duplicate or an orphan. Two similar charges for the same service often mean you have two resources where you thought you had one.
Most providers offer cost allocation tags or labels. If you tag your resources consistently, even with something as simple as a project name, you can filter the bill by tag and see exactly what each project costs. This is especially useful if you run multiple side projects on one account. It takes a bit of discipline to tag everything, but the payoff is a bill you can actually reason about.
Finally, do not be afraid to ask support. If a charge is genuinely confusing, open a ticket. Providers are usually happy to explain, and occasionally they will credit you for something that was clearly a mistake. You will not get a refund for forgetting to delete a server, but you might for a billing bug or a misconfigured service. It costs nothing to ask.
