Budget reviews: spotting what you no longer need

A budget review is a reconciliation, not a cost-cutting drive with a target attached. You take every recurring charge on the account and try to name the live, working thing it pays for. Lines you can name stay. Lines nobody can name become candidates. Run it on a fixed date, twice a year is enough for most estates, because a review triggered by an alarming invoice always cuts the wrong things in a hurry.

What usually turns up

Four leaks account for nearly all of it, and each has a different piece of evidence that settles it.

Working the list

1. Pull invoices rather than memory. Put the most recent full invoice beside one from twelve months earlier. The difference between them is where the year quietly added things.
2. Give every line four columns: the charge label, the thing it should be paying for, where you verified that thing exists, and the decision.
3. Verify against the running estate, never against your own documentation. Documentation is written when a thing is created and almost never edited when it is retired.
4. Attach an owner name to each line. Ownership failure is the strongest signal you will get. Anything nobody will put their name against is either dead or was never understood.
5. Mark one of four decisions: keep, resize, cancel, investigate. Investigate is legitimate, but it needs a return date or it becomes a permanent state.
6. Retire in stages. Detach or disable, wait a full billing cycle with monitoring on, then cancel. The gap between disabling and cancelling is where you discover what was actually depending on it.

Two habits make the next review cheaper. Record the reason for every purchase at the moment you make it, in the same place you record the charge, and set a review date on anything bought for a fixed-length piece of work.

The expensive half

The opposite error costs more than the leaks do, and it is easy to make because the evidence looks identical. Backups that have never been restored from, headroom that has never been consumed, secondary resolvers that have never been asked a question, monitoring that has never paged anyone: these produce exactly the usage graphs of a dead line. They are not dead. Their entire value is the absence of the event they exist for, and that absence is what the graph is showing you.

Before cutting anything in that category, price the failure instead of the line. Ask how many hours of work sit between you and a full recovery without it, whether the loss is recoverable at all, and how much of a traffic spike the remaining headroom absorbs before something queues. If the honest answer to any of those is uncomfortable, the line stays and the review moves on.

Addresses deserve one specific caution. Separate ranges are a footprint and blast-radius measure, not a ranking input, so releasing spares that serve no plan is reasonable housekeeping. Releasing addresses that a scheduled migration or an isolation boundary depends on is not, and reacquiring an equivalent arrangement later is slower than it sounds. Keep the plan written down with a date on it. If a line is genuinely ambiguous, ask before you cancel through contact, and sequence the rest of the work alongside the other routines in running your estate.