A Cloud Cost Audit Playbook That Finds Real Savings

Most cloud cost advice is worthless. “Buy reserved instances.” “Right-size your servers.” “Turn off what you’re not using.” True, generic, and completely unactionable when you are staring at a bill with four hundred line items and no idea where the money actually goes.

This is a playbook, not a lecture. It is the sequence we work through when we audit an AWS bill, ordered so that you find the biggest savings first and stop before the effort outweighs the return. The goal is not a lower number for its own sake—it is to cut waste without touching the spend that is genuinely earning its keep.

Work these steps in order. The early ones routinely find more money than the later ones.

Step 1: Get Cost Allocated Before You Get Clever

You cannot cut what you cannot see. The first step is not optimisation—it is visibility. Before touching a single resource, make sure your spend is attributed: tag resources by service, environment, and team, and turn on cost allocation so the bill breaks down along lines that mean something to your business.

Almost every audit reveals that a large slice of the bill is simply “untagged” or dumped into one account with no breakdown. Until you fix that, every optimisation is a guess. An afternoon spent on tagging and cost tooling pays for itself immediately, because it turns a wall of line items into a map of where the money goes.

Step 2: Hunt the Obvious Waste

Before anything sophisticated, sweep for pure waste—resources costing money and doing nothing. This is where the fastest wins live.

Look for storage volumes not attached to any server, still being billed. Load balancers with no traffic. Old snapshots and backups from machines that no longer exist, accumulating for years. Idle databases nobody remembers provisioning. Development and staging environments running twenty-four hours a day when they are used eight hours on weekdays. Elastic IPs reserved and unused. None of this requires architectural change—it requires someone to actually look, and it is astonishing how much of it accumulates when nobody is looking.

Step 3: Right-Size Against Real Usage, Not Fear

Now examine what is running. Servers and databases are routinely provisioned two or three sizes larger than the workload needs, because someone sized for a peak that never comes or simply guessed high to be safe.

The discipline here is to size against measured usage over a representative period, not against anxiety. Pull the actual CPU, memory, and throughput data. A server sitting at five per cent utilisation is not “headroom”—it is money on fire. Right-sizing the handful of largest, most over-provisioned resources typically recovers far more than fiddling with the long tail, so start at the top of the bill and work down.

Step 4: Attack the Storage and Data Transfer You’re Ignoring

Two categories quietly balloon and almost nobody audits them: storage lifecycle and data transfer.

Storage is often kept in expensive, instantly-accessible tiers when most of it is old data that is never read. Moving ageing data to cheaper archival tiers, on an automated lifecycle policy, can cut storage cost dramatically with no downside. Data transfer is even more insidious—charges for moving data between zones, out to the internet, or through the wrong architecture. A surprising share of a bill can be traffic flowing across boundaries it never needed to cross, and fixing it is often a configuration change rather than a rewrite.

Step 5: Commit Only to What You’ve Proven Stable

Reserved instances and savings plans are the headline advice, and they genuinely work—but only after the previous steps. Committing to a discount for a server you should have shut off or shrunk just locks in your waste at a discount. That is why this step comes last, not first.

Once you have removed the waste and right-sized what remains, look at your steady-state, always-on baseline—the workloads you are confident you will run for the next year. Commit to those and take the substantial discount. Leave the variable, uncertain, or soon-to-change workloads on flexible pricing. The mistake is committing early, before you know what your real baseline is; the discipline is committing only to spend you have proven is durable.

Step 6: Make It Stick

An audit is a snapshot. Costs creep back the moment attention moves on, because new resources get created, environments get left running, and nobody is watching. The final step turns the one-time cleanup into an ongoing habit.

Set budgets with alerts so a runaway cost surfaces in days, not at the end of the month. Put cost visibility in front of the engineers who create resources, so the person spinning up infrastructure sees what it costs. And schedule a lightweight review on a regular cadence. The teams that keep their bills sane are not the ones that audit once—they are the ones that made cost a standing part of how they operate.

What “Real Savings” Means

Run this playbook and it is common to remove a meaningful fraction of a cloud bill without degrading anything, because so much cloud spend is genuine waste rather than genuine capacity. But the point is not to chase the lowest possible number—an underprovisioned system that falls over under load is far more expensive than the money it saved. Real savings means cutting the spend that buys you nothing while protecting the spend that keeps you reliable. The judgement is knowing which is which, and that is exactly where a careful audit earns its keep.

---