Why Your Cloud Bill Keeps Growing

Your bill grows because starting something takes a minute and ending it takes a decision. Anybody with access can create a machine, a database, a bucket or a load balancer, and it begins charging the moment it exists. Removing one means being certain that nothing depends on it. That takes an afternoon, it carries a small risk of breaking something, and nobody has ever been praised for doing it.

So the account accumulates. Every project adds. Almost nothing subtracts. Two years of ordinary competent work, with no carelessness anywhere in it, leaves you with an environment where a fair share of the spend belongs to things that have already finished.

The growth is invisible because it arrives in small monthly steps. Each one is too small to trigger a question, and the comparison people make is always against last month rather than against two years ago. By the time the total is uncomfortable, the reason is spread across hundreds of line items and several years of decisions.

There is a second half to the mechanism. The bill arrives as one number, broken down by service rather than by the team who asked for it. Compute, storage, network, database. Those are useful words for the provider and useless words for you, because none of them names a person you could go and ask.

Compute is usually the largest line and the easiest to misread. Look for machines running around the clock for a job that runs at night, environments sized for a launch that happened last spring, and the instance somebody doubled during an incident and never brought back down. That last one is common enough to check for by name. Emergency resizing is a good instinct. Remembering to undo it is not an instinct at all.

Databases are the line that surprises people. A managed database is priced well above a plain machine of the same size, and it is very often the largest single item in an account. The size was usually copied from the specification of the server it replaced, which was itself sized for a peak somebody guessed at years earlier. Test and staging copies frequently run on the same tier as the live one, because that is what the template said.

Storage only ever grows, which we will come back to. Then there is the quiet group that appears in nobody's business case. Data leaving the platform. Gateways charged by the byte. Load balancers with nothing behind them, reserved addresses attached to nothing, machine images from every build you have made. And log retention set to keep everything for ever, because no one wanted to choose a number.

Add the support plan on top. It is charged as a share of what you spend, so every wasted item costs slightly more than its own line suggests.

Here is the shape of it. A project to replace the ordering system ran last year. It needed somewhere to work, so somebody built one: two application servers, a database restored from a copy of the live one, a load balancer so the testers could reach it from the office, and a bucket for the files they uploaded. The project delivered. Everyone moved on to the next thing.

Nobody switched the environment off, because switching it off was not on anyone's list. The engineer who built it had rolled onto another project. The manager who signed for it saw a total rather than a line. The database has taken a snapshot every night since, and every one of those snapshots has been kept, because retention was never set and the default was to keep them.

This is the most common single finding when we look at an account for the first time. It is usually four small ones rather than one large one, each cheap enough on its own that raising it would feel like fussing, and expensive enough together to pay for a real piece of work.

You can find them without any special tooling. Look for resources created in a burst on one date and untouched since. Look for tags naming a project that is no longer in the plan. Look for databases with no connections, and for machines whose processor use has been flat and low for months. Anything you cannot attribute to a living team is a candidate.

Object storage is cheap for each unit and effectively unlimited, which is exactly what makes it the easiest thing to stop thinking about. Then somebody turns on versioning, usually for a good reason, and from that day every overwrite keeps the previous copy as well. A pipeline that rewrites the same file every few minutes will build a quiet mountain out of one small file.

Snapshots and backups behave the same way. A nightly snapshot with no retention rule is a pile that only ever gets taller. Disks stay behind when their machine is deleted and keep charging while attached to nothing. Machine images accumulate from every release, each one holding a full copy of the disk it was built from.

Logs are the awkward one. Application logs and platform audit trails written to storage with no lifecycle rule are frequently the biggest bucket in the account, and they are genuinely useful, which is why nobody wants to be the one who deletes them. What that needs is a retention period chosen by somebody who can defend it, plus a rule that moves older data to cheaper storage automatically.

The honest caveat is that storage is seldom the largest line on the bill, and cleaning it by hand can burn more engineering time than it returns. Do it once with lifecycle rules that keep working, then leave it alone.

Moving data into a cloud platform is usually free. Moving it out is not. That asymmetry catches nearly everybody in the first few months after a move, because no business case ever included a line for it.

The usual culprits are worth naming. An application split across availability zones for resilience, chatting constantly between them, pays for every one of those round trips. A database replica in another region pays for everything it copies. Backups written out to a third party pay on the way out. A reporting tool that pulls an entire table every hour rather than only the rows that changed pays for the whole table, every hour, for ever. And images served straight out of storage to the public pay every time somebody loads the page.

Gateways for outbound traffic deserve their own paragraph. They are charged by the hour and again for every byte they process, so a fleet of private machines pulling operating system updates and container images through one of them all day generates a real bill out of activity that feels like housekeeping.

Most of the fixes are ordinary engineering. Put a cache in front of anything the public downloads. Keep two systems that talk constantly in the same zone. Move the query to the data instead of hauling the data to the query. And check what your monitoring and logging agents are shipping out of the platform, because that traffic runs every minute of every day and appears in nobody's design review.

Open the cost report, group by service, sort largest first, and look only at the top handful. That is where your money is. The long tail can wait for a second pass, and on the first pass it will only distract you.

Then group the same period by account or subscription, and then by tag. If the tag view shows most of the spend as untagged, you have found something more important than any individual line: there is currently no way to send a cost back to the team that caused it.

Now compare two months that sit either side of the last significant change. A step means something was created. A slope means something is growing, and that needs a different fix. Storage and log retention produce slopes. A forgotten environment produces a step you can date, and a date gives you somebody to ask.

Finish with an inventory of the inert. Databases with no connections. Disks attached to nothing. Addresses assigned to nothing. Load balancers with no healthy targets behind them. Snapshots older than any retention period anybody in the room can defend. None of that requires a tool you have to buy.

Tagging at creation, enforced rather than requested, is the single change that does the most. Two tags will carry you a long way: who owns this, and when should it be reviewed. A resource that cannot be created without an owner is a resource somebody can be asked about later.

Put non production environments on a schedule and make running overnight the exception that somebody asks for. Development and test environments are used during office hours by people who go home. Nothing about that is controversial until you propose it, at which point you will hear that a build sometimes runs late. That argues for a longer window, not for leaving everything on all year.

Hold a monthly review with the person who signs for the bill, and show the numbers grouped by team rather than by service. A finance director cannot act on a line called managed database. They can act on a line that says which department it belongs to and what it is for.

Set a budget and an alert on every account, and alert on the rate of change as well as on the total. A total that crosses a threshold tells you the money has already gone. A jump in the daily run rate tells you on the second day, while somebody still remembers what they created.

Do not begin with a commitment purchase. Reserved capacity and savings plans genuinely reduce what you pay, and buying them before a clean up means committing money to running the waste you have not found yet. Clean first, size second, commit third.

Do not chase the small items in the first month either. An engineer spending a week to remove a handful of trivial lines has cost you more than the lines did. Sort by size, work down the list, and stop when the next item is worth less than the time it takes.

Make deletion feel safe, or people will avoid it. Agree a holding pattern: stop the resource, wait a fortnight, then remove it. If nothing broke and nobody complained, the deletion is boring. That one habit clears more forgotten environments than any amount of encouragement.

And accept that a single clean up does not hold. An account with nobody accountable for cost drifts back to where it started within a year, because the same asymmetry is still in place. Somebody has to hold the job, and it should take a few hours a month rather than a project every two years.