a good chunk of my infrastructure work over the years has been one job wearing different titles: make this bill smaller.
it sounds like an architecture problem. people expect a redesign, a migration, something with a diagram. it almost never is. the money is sitting in things nobody turned off and things nobody sized correctly, and the work is mostly the discipline to go look.
where the money actually is
things that are running for nobody. the staging environment for a project that shipped last year. the ec2 instance somebody spun up to test something in march. load balancers with no healthy targets behind them. nat gateways sitting in subnets nothing uses, which is one of the more expensive ways to do nothing in aws.
storage nobody claims. unattached ebs volumes are the classic. a machine gets terminated, the volume it was using survives, and it bills forever with nothing reading it. snapshots too, in generations, going back years because a script created them and no script ever deleted them.
wrong size, not wrong service. an instance provisioned for a load projection that never arrived. a database at a tier chosen on the first day of a project and never revisited. these are boring and they are usually the biggest single line.
logs. retention set to forever, on everything, because forever is the default nobody changed. log storage is quiet and cumulative and it never triggers an alert.
the part that takes judgement
anyone can find idle resources. a script can do it. the actual skill is knowing what your steady state floor is before you commit to anything long term.
savings plans and reserved commitments are where this gets expensive if you get it wrong. you commit to a level of spend for one or three years in exchange for a discount. if you commit at or below the amount you will genuinely always be spending, it is free money. if you commit above it, you are now paying for capacity you do not use and you cannot undo it.
so the order matters, and people get it backwards. they buy the commitment first because it is the visible win, and then they clean up, and now their real usage is below the floor they locked in.
clean first. measure the floor for a few weeks. then commit, and commit conservatively, under the floor and not at it. the discount on the last few percent is not worth locking yourself to a number you might drop below.
why nobody does this internally
not incompetence. incentives.
deleting a resource carries risk and produces no feature. if you delete the wrong volume, that is your name on the incident. if you leave it, it costs the company a small amount every month and costs you nothing at all.
so it accumulates, quietly, until somebody looks at the invoice and asks a question. which is usually the point where somebody like me gets a message.
the outside position helps here for one reason only: i have no history with any of it. i do not remember why that instance exists, so i ask, and asking is the entire job.
how i actually run it
inventory before opinions. what exists, what is attached to what, what has received traffic in thirty days.
tag ownership or accept you cannot delete safely. an untagged resource with no owner is either critical or abandoned and you cannot tell from outside. the honest answer is to ask, in writing, and get a yes.
stop before delete. for anything ambiguous, stop it and wait a week. if nothing broke and nobody complained, it goes. this converts a scary irreversible action into a reversible one, and it is the single thing that makes clients comfortable saying yes.
snapshot before delete, delete the snapshot on a schedule. otherwise you have just moved the problem into a slower billing line.
write down what you removed and what it saved. partly for the client. mostly because six months later somebody will ask why the thing is gone and you want the answer in a document, not in your memory.
the uncomfortable part
this is the highest value per hour work i do and it is nearly impossible to sell as a project on its own, because it sounds like a chore rather than engineering.
it is also the work most likely to make a client trust you with the interesting stuff afterwards. you saved them real money in a week, with receipts. that buys more credibility than any architecture diagram i have ever drawn.