TL;DR: Most teams treat a cloud audit as a one-time cleanup: find the waste, delete it, move on. Run it instead as a four-stage pipeline, discover, analyze, act, govern, and the two stages that matter most for whether the savings last are the bookends: automated tagging/inventory at the start, automated budgets and alerts at the end. The middle two stages (analyze, act) are where the dollar amounts live, but the bookends are where the durability lives. A real six-week audit on a US SaaS company's cloud footprint cut the monthly bill 38%, and the line item nobody expects, data transfer, was a hidden top-five cost until the pipeline's analyze stage mapped it.
A cloud audit run as a cleanup sprint has a predictable failure mode: someone finds $50k/year of waste, deletes it, the bill drops, everyone moves on, and six months later the bill has quietly crept most of the way back. That's not because the cleanup was wrong, it's because a sprint has a start and an end, and waste doesn't. Run the same audit as a pipeline instead, with discovery and governance as permanent, automated stages rather than a kickoff meeting and a final report, and the savings behave differently.
The pipeline, stage by stage
| Stage | What it does | Automatable? |
|---|---|---|
| Discover | Inventory every resource, tag what's untagged, map where spend goes | Yes, run continuously |
| Analyze | Score savings opportunities across five technical areas by effort and impact | Partially, tooling surfaces candidates, a human prioritizes |
| Act | Apply right-sizing, deletions, and commitments, safest first | No, each change needs a human sign-off |
| Govern | Budgets, alerts, and a review rhythm that catch drift | Yes, run continuously |
Notice the shape: discover and govern are the two stages you can fully automate and leave running, while analyze and act are inherently a human-in-the-loop exercise, you don't want a script auto-deleting a disk or auto-buying a three-year commitment. The practical implication: build discover and govern as always-on tooling from day one, and treat analyze/act as a recurring but bounded project that tooling feeds into.
The five technical areas analyze actually scans
| # | Area | What it checks | Where the tooling gap usually is |
|---|---|---|---|
| 1 | Right-sizing | Real CPU/memory vs. provisioned size | Usually covered by the provider's own recommender |
| 2 | Idle/orphaned resources | Disks, snapshots, IPs nothing depends on | Needs a dependency graph, not just a resource list |
| 3 | Pricing and commitments | On-demand vs. reserved/savings-plan/spot fit | Needs usage predictability scoring, not just usage volume |
| 4 | Storage tiers and data transfer | Lifecycle rules, cross-region/egress traffic | Most commonly missed, see below |
| 5 | Architecture and licensing | Autoscaling vs. fixed fleet, managed vs. self-managed, unused seats | Rarely automated at all, needs architectural judgment |
Area 4 deserves the callout. Right-sizing and idle-resource tooling are mature, most providers ship a version of it. Data transfer is different: it's billed per gigabyte across a path (cross-region call, egress to the internet) rather than per resource, so a resource-centric audit tool simply doesn't see it as a line item to flag. It shows up only when something explicitly traces where data actually flows, and because almost no team builds that tracing by default, it routinely turns out to be a top-five cost that nobody budgeted for.
Case study: the audit that mapped data flow and found the untagged 71%
A US B2B SaaS company's cloud bill had outgrown its revenue, and the team suspected waste but couldn't act on the suspicion, resources were untagged, so there was no owner to call about any specific dollar. We ran the pipeline's discover and analyze stages across all five areas over six weeks, then act over three months:
| Finding | Pipeline stage that caught it | Outcome |
|---|---|---|
| Oversized fleet | Analyze (area 1) | 29% off compute |
| Idle/orphaned resources | Analyze (area 2), tooling-driven | $0.21M/yr of pure waste removed |
| Everything on-demand | Analyze (area 3) | Commitment coverage 9% → 71% |
| No cost ownership | Discover (tagging) + Govern (budgets/alerts) | Waste stays visible and owned going forward |
Monthly bill down 38%. The detail worth isolating for an engineering audience specifically: the 9%-to-71% commitment-coverage jump and the $0.21M in deleted waste are one-time, project-shaped wins, exactly the kind a cleanup sprint also would have found. What a sprint wouldn't have left behind is the discover/govern automation, the tagging that makes next quarter's drift visible the moment it happens instead of at the next scheduled audit.
FAQ
If our provider already has a cost recommender, do we still need a separate audit?
A recommender covers right-sizing well (area 1) and sometimes idle resources (area 2). It won't touch data transfer mapping, commitment-fit scoring, or architecture-level changes, areas 3-5 need a broader pass, usually annually or when the environment changes significantly.
What's the single highest-leverage thing to automate first if we're starting from nothing?
Tagging enforcement at resource-creation time (policy that blocks untagged resources from deploying). It's the discover-stage piece that every later stage, including governance, depends on, and it's useless to add after the fact since you'd still have to backfill the existing untagged fleet.
Is data transfer really worth a dedicated tracing effort, or is it a minor line item?
In this case study it was a hidden top-five cost, and that's typical, not exceptional, because almost nobody traces it by default. A basic version (checking for cross-region traffic between tightly coupled services) catches most of the easy wins without building full network-flow tooling.
Originally published on the Sherdil Cloud blog, the full piece (with the complete audit areas table and four-stage process) is here. For the pricing-commitment side in depth, see right-sizing your cloud; for the ROI framing this feeds into, maximizing cloud ROI.
About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.
Top comments (0)