The Cloud Bill Nobody Owns

The line on the invoice nobody recognises

The monthly cloud invoice arrives, and someone in finance asks a simple question: what is this server, and do we still need it? Nobody is sure. It was set up for a demo, or a load test, or a developer who has since moved to another project. It is still running, and nobody wants to be the person who switches it off and breaks something.

So it stays. Next month there are two of them.

This is rarely a technical problem. The cloud does exactly what it was asked to do. The gap is that nobody was asked to own what it is doing now.

Why cloud spend grows without anyone deciding

Starting a resource takes a minute and needs no meeting. Stopping one needs someone who knows what it is for. Over time that difference adds up.

Test environments that outlive the test

A staging copy for one feature, a database restored to debug one issue, a branch preview that was never cleaned up. Each one made sense on the day it was created.

Storage that only grows

Logs, backups and uploaded files are written every day and rarely deleted. Without a rule for how long each kind is kept, the answer becomes "forever" by default.

Sizes that were never revisited

A server sized for launch week, or for a peak that never came, keeps that size long after the traffic settles.

Give every resource an owner

The fix that works best is also the least technical: every resource has a named owner. Not a team, a person. That person can answer three questions about it: what is it for, who uses it, and when can it go.

Make this part of how resources are created rather than a clean-up project later. Most cloud providers let you attach labels, often called tags, to servers, databases and storage. Agree on a few required ones and treat a resource without them as unfinished work.

When infrastructure is defined in code and deployed automatically, these labels can live in the same files and get checked in code review, like any other change. That turns ownership from a memory into a written decision.

Build a review habit, not a clean-up day

One big clean-up feels productive and then the drift starts again. A short, regular review keeps it from coming back.

Pick a fixed day each month. The owner of each environment looks at the list of what is running, checks it against its labels and decides: keep, resize or stop. Anything without an owner gets one assigned in that meeting, or a date to be switched off.

Stopping is less risky than it feels. Take a backup or snapshot first, stop the resource rather than deleting it, and wait to see if anyone notices. If someone does, you have just found its owner.

A checklist you can copy

1. Owner: every server, database and storage bucket has a named person.

2. Purpose: a one-line reason it exists, written on the resource itself.

3. End date: test and demo environments carry the date they can go.

4. Retention: logs and backups have a written rule for how long they are kept.

5. Size: sizes are checked against real use, not the launch-week guess.

6. Review: a fixed monthly slot to keep, resize or stop each item.

7. Safe stop: back up first, stop before you delete, and note who agreed.

What changes when someone owns it

The bill stops being a surprise, because the people who create resources are the same people who see them in the review. Questions from finance get an answer in minutes. And engineers feel safer cleaning up, because the rules for what can go are written down rather than guessed.

None of this needs a new tool. It needs a label, a name and a slot in the calendar.

We build cloud infrastructure that deploys automatically and scales on demand, and you keep the code, the infrastructure accounts and the documentation. If your cloud bill has lines nobody can explain, [tell us about it](/contact).