Cloud cost reduction diagnostic checklist · 2026

A total tells you nothing about what moved. Put last month and this month side by side by account and by service, and rank the lines by how much they grew. Three or four lines usually account for most of the increase. Go down one level into those lines and find which resource grew, and from what date. Check whether that date lines up with a release, a marketing event, or a feature launch, and the list of candidate causes gets short. Count the items with no owner separately. Nobody proposes cutting a resource when no tag says whose it is, so it will still be there next month. Without this first table every check that follows runs on instinct.

One month on its own mixes seasonal or event-driven growth with structural growth. Line up at least three or four months in the same format and mark which items stepped up once and stayed there and which climb a little every month. The first kind usually traces to a specific change; the second traces to resources piling up. Overlay release history and infrastructure change records on the same calendar while narrowing the cause.

A higher bill is not by itself a problem. If the business doubled and the bill went up by half, that was a good month. So keep one business-denominated figure next to the total: cost per order, cost per active user, cost per million requests — whichever describes your service best — and count it the same way every month. When that figure holds or falls, a rising total has an explanation. When it rises, something is wrong regardless of volume. The sentence you need in a review meeting comes from here too. Pick a denominator finance already uses. A metric invented for infrastructure alone stops being read by the next quarter.

The first thing to check is whether development and test environments stay on at night and over weekends. Turning off an environment used only in business hours is easy to reverse and never touches production. Size comes next. List the instances that spent weeks at a low peak, the ones left on an old generation, and the autoscaling groups whose minimum count sits higher than needed. Size down against the peak, not the average. Cut on averages and the trouble shows up at month-end or during batch windows. In the same pass, check for targets behind a load balancer that receive no traffic and for stopped instances still billing for their disks. Reserved addresses attached to nothing, idle load balancers, and old deployment environments that only exist as names surface here as well.

The usual items are unattached volumes, snapshots left by deleted servers, backups piling up with no expiry, and object storage without a lifecycle rule. Snapshots are small enough one at a time to escape notice, and generations of them end up larger than the source. Setting a retention period and letting it delete on its own is more reliable than clearing them by hand each month. Logs are storage too. Decide how long each log stays, check what the audit requirement actually asks for, and move or delete the rest. Before deleting, ask the owner once what it was kept for. Delete something kept for disaster recovery because it looked like cost, and the price arrives with the incident. Object storage sometimes bills more for requests and tier transitions than for stored volume, so expand the billing detail.

Transfer charges do not appear as a line in the resource list, which makes the cause hard to find. Separate traffic leaving for the internet, internal traffic crossing availability zones and regions, and requests passing through a NAT gateway. When the database and the application sit in different availability zones, every ordinary query becomes a transfer charge. If images and static files still leave from the origin server, putting a cache in front reduces what goes out. Even with a cache in place, a low hit ratio means paying twice. If logs and backups replicate to another region, confirm whether that replication is a regulatory requirement or a habit.

Managed databases, search, queues, and caches cost money simply by being on. A cluster built for a development task often keeps running long after the project ends. Check whether multi-AZ configurations and read replicas were copied into development environments as they stand. Where a commercial software license is billed by instance hour, the license can exceed the instance charge. Put what leaves outside the cloud bill on the same table. When monitoring, log collection, alerting, and deployment tool subscriptions scale with usage, shrinking infrastructure can leave the total unchanged.

To avoid repeating this exercise next quarter, make the numbers split themselves. Separate accounts and projects by environment and development spend stops mixing into production; separate them by team and the bill becomes the allocation table. Tags hold better when you enforce three or four than when you define many. Owning team, environment, service, and planned end date answer most questions. Block creation of untagged resources, and leave already-untagged ones on the list until an owner is found. An end-date field is what stops a resource spun up for a trial from still running six months later. Once this is in place, next month's bill becomes a document you confirm rather than investigate.

Commitments and reserved purchases carry the largest discount rates, so they attract attention first. Reverse the order and you lock in the waste along with the usage. Commit to one or three years before confirming the current size and the chance to reduce is sealed for that term. After the checks above, cover only the floor of usage that continues whatever the business does, and leave everything above it on demand. Before setting a term, look at the calendar for reorganizations, service shutdowns, and large migrations that fall inside it. Confirm before signing whether a commitment can be transferred or exchanged mid-term, and whether the discount follows when accounts are split.

Once the list exists, sort it by risk rather than by savings. Split it into what can be turned off and back on, what needs a release to reverse, and what cannot be reversed. Finish the first group that week; run the last group with owner confirmation inside a change window. Record a revert condition and a named owner for every item. Without a record of what was turned off and why, a failure investigation months later spends its time rediscovering it. A cleaned account drifts back if left alone. Enforced tags on new resources, the order of notification when a budget threshold is passed, and a cost review on a standing meeting all belong in the same checklist. Keep completed items rather than deleting them, with the date and the action. When the same resource appears on the list next quarter, the judgement does not have to be made twice.

When nobody has time to look, the diagnosis goes to a supplier. Compare fee structure before headline savings. A share-of-savings model gets action moving quickly, and it also leans toward recommending items that lock you in for years. If the supplier resells your cloud usage, factor in that their revenue falls when your usage does. Settle what remains before signing. Tag rules, budget alerts, the action list, and the revert conditions have to end up inside your account, or the same diagnosis gets bought again next quarter. A list cut from utilization alone, by people who do not know the workload, creates incidents at month-end and in batch windows. Check that the proposal includes asking each owner which business cycle a resource exists for. Starting with a short contract also works: hand over the diagnosis and the low-risk actions once, then decide the next scope from the documents left behind and the items that actually came down.