Multi-cloud waste audit playbook: a hand-on-keyboard pass for AWS, GCP and Azure

A multi-cloud waste audit is the discrete, time-boxed pass a FinOps team runs against a live estate to recover money already lost to idle, oversize, untagged, or orphaned resources. The pass produces a written report, a signed evidence map, and a queue of pull requests your engineering team can either merge or close. This playbook is the on-page version of the runbook we use at Tallywyrm when one of our customers hands us the keys to a real estate we have never seen before. It is the second pillar in our FinOps series — it builds on the framework, vocabulary and four cost levers established in the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook). If the terms in this guide (idle-resource hygiene, rightsizing, reservations, savings plans, allocation map) are new, start with that pillar first. This one is the worked example. What a waste audit actually delivers A waste audit is not a recommendation list. The audit is the end-to-end artifact that goes from raw cloud data to a signed report your finance team can file. Concretely, a multi-cloud waste audit delivers three things, in this order: A scored queue of savings candidates. Every candidate carries a projected dollar saving, a blast radius, a rollback path and a verification window. The queue is a queue, not a list — items above the score threshold are surfaced; items below are deliberately dropped. An audit-ready evidence map. Every surfaced item is mapped one-to-one to: the resource ID and account/region, the native cloud recommendation it came from, the trailing-usage data that backs it, the IaC diff that would land the change, and the verification re-read that will run a week after deploy. A one-week report finance signs off on. The report is a CSV with a signed manifest. It is the same artifact your SOC 2 auditor, your CSRD reporter and your internal finance team all sign off on. The auditor's question "what is this row" gets answered with a PR URL, a deploy timestamp and a measurement timestamp — not a screenshot from last quarter. The result is the contract. The implementation detail (which score thresholds, which tools, which cloud-native signals) is whatever produces that contract consistently across AWS, GCP and Azure. Pre-flight: the four data sources you cannot audit without A waste audit fails if the underlying data is incomplete. Before the queue gets scored, four data sources have to be hydrated. Each is available natively; the audit does not invent its own: Cloud cost and usage data. AWS Cost Explorer, Azure Cost Management, GCP Billing export into BigQuery. This is the dollar side; nothing else is a substitute. If a trial account has fewer than thirty days of history, queue it as "pre-baseline" and do not score. Resource inventory. AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory. This is the resource-side. The native inventory each cloud exposes is the only one that survives an audit — derived inventories (third-party scrapes, datastore snapshots) drift and lose their chain of custody. Utilization telemetry. CloudWatch (AWS), Azure Monitor, Cloud Monitoring (GCP). The audit needs at least one trailing usage signal per workload. Trailing 14 days is the floor; trailing 30 days is the default; trailing 90 days costs the most in pipeline time but reveals slow-cycle workloads (analytics, batch, weekly ETL). Tag coverage map. A purpose-built read of the inventory against the cost-allocation taxonomy finance owns. This is the only derivable signal in the pre-flight; it is also the most fragile, because the taxonomy itself can drift. Pin the taxonomy version of the read timestamp. If any one of the four is missing or stale, the audit is downgraded to "indicative" rather than "verified". This is the right degradation — a partial audit that overstates its own certainty is worse than no audit. The scoring threshold, in dollars and in blast radius Every recommendation enters the queue under a score. The score is a function of two things: projected dollar saving and blast radius. The threshold for a candidate to survive the filter and become a row in the report is computed as projected monthly saving (in dollars), divided by blast radius tier times rollback complexity, against a calibrated team-level threshold (a sensible default is sixty). Below the threshold, the candidate gets dropped into the long tail CSV for re-review next cycle. Above the threshold, the candidate becomes a row in the report. Concretely, the blast radius buckets The score only works if the blast radius buckets are fixed. We use four: Tier 1. A single resource in a single account. NAT gateway with no traffic. Orphan EBS volume. Idle Pub/Sub topic. Score cost = 1. Tier 2. A small fleet, fan-out known. Two to ten RDS instances of the same family. A small Cosmos DB account. Score cost = 2. Tier 3. A fleet spanning multiple accounts or regions. A multi-region active-active deployment. Score cost = 4. Tier 4. Platform-tier or controlled by another team. A shared VPC, a transit gateway, a control-plane service. Score cost = 8. We default to drop these from the report unless the customer has explicitly approved the cross-team review path. The blast radius is set by the on-call platform team before the audit starts, in writing, on the audit kickoff doc. Eng teams that disagree with a candidate's tier challenge that specific tier before the report lands; the audit does not relitigate blast radius after the report. Rollback complexity, also bucketed Three buckets, in increasing order: Reversible on a single API call. Stop plus delete a resource; Terraform in reverse; recreate from snapshot. Score add = 0. Reversible on a one-line code change. A family change; a tag purge; a config swap. Score add = 1. Destructive or stateful. A destructive delete that requires restore-from-backup; a schema migration; anything that requires data backfill. Score add = 3. The two numbers compose; the total denominator is the blast radius tier multiplied by (1 plus rollback complexity). The audit's worked example: a real-shaped bill Below is a worked example, run against an anonymized production-shaped multi-cloud bill. The numbers are realistic but normalized; the structure is identical to what an audit produces. Every line is a row in the eventual CSV. Idle-resource hygiene, scored AWS NAT gateway prod-1a — 30 days of zero egress traffic per VPC Flow Logs (https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html). Projected saving: $1,480/month. Tier 1. Rollback: stop plus delete (score add 0). Score = 1480 divided by (1 multiplied by 1) = 1480 — survives. AWS RDS orders-prod — trailing 30 days CPU at 8% (CloudWatch). Projected saving (instance family T4g over T3, with the workload's tail-latency budget honored): $960/month. Tier 1. Rollback: family change, one-line IaC edit (score add 1). Score = 960 divided by (1 multiplied by 2) = 480 — survives. GCP Pub/Sub topic analytics-events — no subscriber for trailing 30 days. Projected saving (drop the topic and its DLQ): $428/month. Tier 1. Rollback: stop plus delete (score add 0). Score = 428 — survives. Azure VM internal-app-01 — trailing 30 days CPU at 4%, B-series burst credits never exhausted. Projected saving (downsize B4ms to B2ms): $340/month. Tier 1. Rollback: family change (score add 1). Score = 170 — survives. A practical note: an audit that scores dozens of idle-resource rows is normal. Many of the rows are under fifty dollars a month. The audit keeps them in the report; finance prefers the completeness. What gets dropped is the long tail under thirty-five dollars — the triage cost of opening a one-line PR for $8/month exceeds the saving. Reserved capacity, scored Azure VM internal-app-01 — confirmed stable for trailing 90 days at 70% utilization. A one-year Compute Reservation (B4ms) covers 80% of the baseline. Projected saving: $115/month. Tier 1. Rollback: cancel reservation, fall back to on-demand (score add 0). Score = 115 — survives. Reservation audits compose across the three clouds: AWS Savings Plans, GCP Committed Use Discounts and Azure Reservations are three independent commitments in one portfolio. The portfolio rules are spelled out in the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) — anchor sixty-to-seventy percent of baseline, refresh against the trailing-usage audit trail, and surface under-utilised reservations the same way you surface idle resources. The "survives" tag Every "survives" row is a row of the report. Every "drops" row is a row of the long-tail CSV. The CSV is what the audit produces; the long-tail CSV is what next quarter's audit starts from. The audit-ready evidence map Every row of the report maps one-to-one to six fields. The map is what your auditor will sign off on; it is also what your finance team uses to reconcile the report to the next month's invoice. The fields are: Resource identity. Account, provider, region, resource-id, owning IaC module (if any). Pin the IaC module to the PR that introduced the resource. Native cloud signal. Which platform-native recommendation (AWS Config compliance, Azure Advisor, Active Assist) surfaced the resource. The signal alone is not sufficient — it is necessary but not sufficient — but it has to be there. Trailing-usage data. The CloudWatch, Azure Monitor, or Cloud Monitoring time series that backs the candidate. The audit pins the time window explicitly so the trail is auditable. IaC diff. The one-line diff (or multi-line for Tier 2/3 candidates) that would land the change. Pinned to the repo, branch and PR that the audit-prepared PR points at. Verification window. The trailing window (default: one week after deploy) during which the verification re-read runs. The verification either confirms the projected saving or marks the row as regression — in which case the row is removed from the next invoice. Invoice entry. The line of the next monthly invoice that the verified saving lands on. The auditor's question "show me where this saving is" gets answered here. The map exists once per audit cycle. It is the audit's durable artifact. The one-week report: the artifact finance signs off on The report is a CSV with a signed manifest. The CSV's columns are the six evidence-map fields above, plus a projected saving in dollars per month and a verification status (which moves from pending to verified or regression one week after deploy). The signed manifest binds the CSV to: The audit run that generated it (timestamp, run-id, runner identity). The version of the cost-allocation taxonomy in use at audit time. The version of the scoring thresholds (the database that holds the team-level threshold and the four-tier table). Signing is HMAC-SHA256 over the CSV's bytes plus the manifest; the secret is the app's audit signing key, rotated annually. The signature is what your SOC 2 auditor will inspect. It is the artifact that separates a draft report from a finance-grade report. When the report lands mid-month Most audits do not run on a calendar boundary. A natural cadence is every Sunday at 05:00 UTC — the seed script's seed-demo-data cron hits that cadence with the recommendation sync. An audit that completes on Wednesday still produces a report; verification re-reads run a week after the deploys land, not a week after the report. The cadence between the report and the verification re-read never stretches past the seasonal budget review. Common audit-time traps Tag drift at the IaC layer The most common audit failure mode is tag drift at the IaC layer. Resources are created in IaC modules; the modules enforce tags at PR time. If a team's modules drift away from enforcing tags (deleting the validation hook, replacing a typed tag with a string), the next audit finds the allocations unmappable. The fix is forward-looking infrastructure: tag enforcement is a validator on the IaC repo, not a retrospective cleanup. The audit then reads what already exists and fixes the drift, but the forward-looking guarantee holds. Streaming from the wrong source Doing the audit from a third-party cost tool's snapshot, instead of from each cloud's native cost and usage export, breaks the audit chain of custody. The third-party tool is a layer on top of the cloud's signal; the layer adds an out-of-band risk that auditors will flag. Native or nothing. The audit pulls directly from AWS Cost Explorer, GCP Billing export into BigQuery, and Azure Cost Management. The on-page UI is the audit's own; not a third-party sprawl. Scoring thresholds that drift Scoring thresholds drift when teams change them per-cycle to fit last quarter's recommendations. This is the worst failure mode: each audit produces a different report shape, and finance cannot reconcile audit-to-audit. Fix: pin the thresholds in a database; every change to the threshold gets a PR, a deploy, and a manifest update. The auditor reads the manifest and immediately sees the threshold-version of each row. From audit back to the agent loop A waste audit is a high-touch, time-boxed pass. The agent loop is the 24/7 version of the same work: scoring, scoring thresholds, evidence map, signed manifest — but running every hour. The audit is the on-ramp to the agent. Teams that have run one well-formed audit usually want the loop afterwards, because the audit itself takes three days of one human's attention, and the loop removes most of that. We cover the deployment pattern in the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) — the agent loop, the IaC write-back, the verification re-read, the manifest signature. The audit is the on-page runbook; the agent is the 24/7 of the same work. FAQs from FinOps leads running audits How long does a waste audit actually take? A first audit on a previously-uninstrumented estate: three to five working days for one engineer plus one platform reviewer, end to end. The first day is the pre-flight (the four data sources). The second and third days are the scoring pass. The fourth day is the report. The fifth day is finance review. Subsequent audits, on the same estate, with the same scoring thresholds: half a day. What does the auditor want to see? The evidence map, in CSV form, signed. The auditor's question "what is this $4,200 line" gets answered with the six fields, the manifest signature, and the version-pinned scoring thresholds. Frameworks most multi-cloud teams have to align with in 2026 — SOC 2 Type II (https://www.aicpa-cima.com/topic/assurance-services/soc-2), ISO 27001 (https://www.iso.org/standard/27001), EU CSRD (https://www.efrag.org/csrd) — all accept the same artifact. What is the smallest audit that produces a real saving? A focused audit against a single AWS account with one hundred resources and a clean tag taxonomy produces a real saving in the first report. The smallest saving we have seen signed off on is $280/month from a single orphan NAT gateway. The largest is five figures from a multi-region deployment with trailing-usage evidence backing a dozen rightsizing candidates. Does the audit interact with the production estate? No. The audit is a read. The pull requests the audit produces open against your existing IaC repo, but the reviewer's review, the approver's sign-off and the merge are all yours. The audit never holds a merge token and never bypasses a required approver. What is the smallest footprint for a first audit? One AWS account, one GCP project, one Azure subscription — twelve days of native cost and usage data, fourteen days of utilization telemetry, a finance-owned taxonomy. That footprint runs the playbook end to end. Scale-up is per-account onboarding into the same loop. From audit to recurring reporting A successful first waste audit is the on-ramp to a recurring cadence. The natural cadence — Sunday 05:00 UTC — produces a weekly report; the Sunday cron seed-demo-data is the orchestration point that materialises it. Once the cadence is live, the audit-shaped report becomes the weekly management surface: this is what finance looks at, this is what engineering reviews, this is what the platform team reconciles against the next invoice. The artifact is the artifact. The cadence is what makes the saving persistent instead of one-off. The agent loop, post-onboarding, replaces the read-side of the audit with an hourly loop. The write-side (the IaC pull request, the verification re-read, the signed manifest) is the same shape. Cross-link to the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) for the deployment pattern. --- This is pillar 2 of the Tallywyrm field guides series on FinOps practice for multi-cloud teams. The cluster is pillar 1: FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) then this audit runbook, with upcoming pillars in the same series on the way. Start with the FAQ (/faq) for the security, credential scope and percentage-of-savings pricing questions, then talk to the team (mailto:tallywyrm@polsia.app) about a real audit on one of your own accounts. The forthcoming pillars land here as the practice evolves — bookmark this one and watch the cluster.

Multi-cloud waste audit playbook: a hand-on-keyboard pass for AWS, GCP and Azure

Send us your last month’s bill. We’ll show you what the agent finds.

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide

Azure rightsizing with Terraform: a practical 2026 guide

Multi-cloud waste audit playbook: a hand-on-keyboard pass for AWS, GCP and Azure

Send us your last month’s bill. We’ll show you what the agent finds.

Related posts

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide

Azure rightsizing with Terraform: a practical 2026 guide