The short answer

A cloud cost audit compares what you pay with what you run. Export the billing data, attribute every line to a team, service and environment, find resources that are idle or bigger than they need to be, check your commitments against steady usage, then rank each saving by size, risk and effort before changing anything. The audit itself needs only read-only access and changes nothing in production.

Step 1: get the data

Start from the bill, not from a list of servers. Export as many months as you have, ideally a full year so seasonal peaks show up:

  • AWS: Cost Explorer and the cost and usage report
  • Azure: Cost Management exports
  • Google Cloud: the billing export to BigQuery

Add read-only access to the accounts themselves, so you can see what each resource is and how busy it is.

Step 2: attribute every line

Group spend by team, service and environment using tags or labels. Spend you cannot attribute is your first finding: nobody can decide whether something is worth paying for if nobody knows what it is. Agree a short tagging policy before you go further.

Step 3: find the waste

  • Idle resources: unattached volumes, old snapshots, unused IP addresses and load balancers with no traffic
  • Test and staging environments running around the clock when they are used in working hours
  • Compute and databases sized well above what they use, judged over your busiest period, not the average
  • Storage in a more expensive class than how often it is read justifies
  • Data transfer between regions and out to the internet, which is often the line nobody can explain

Step 4: check commitments last

Reserved instances, savings plans and committed-use discounts lower the price of steady usage. Buy or renew them only after rightsizing, so you do not commit to capacity you are about to remove. Cover the baseline you are confident about, and match the term to your plans.

Step 5: rank the savings

Put every finding in one table. Estimate each saving from your own bill; this guide deliberately quotes no typical figures, because they vary too much between setups to be useful.

ItemCost nowEstimated savingRiskEffortTest first?
Delete unattached volumesFrom your billFrom your billLowLowCheck backups
Schedule staging off at nightFrom your billFrom your billLowLowNo
Rightsize the main databaseFrom your billFrom your billMediumMediumYes
Buy a savings planFrom your billFrom your billLowLowAfter rightsizing

Step 6: make changes safely

  • One change at a time, with monitoring compared before and after
  • A rollback ready for anything customers could notice
  • Changes made in infrastructure code where you have it, so they stick

Step 7: stop it creeping back

  • Budgets and alerts that reach someone who can act
  • Tagging enforced when resources are created
  • A monthly review with a named owner
Hypothetical example. A software team audits its bill and finds that its staging databases are the same size as production and run all night. Downsizing them and switching them off out of hours goes first: low risk, no customer impact. Rightsizing production waits until it has been tested.

When to get help

If you want the audit done for you, with read-only access and a ranked report, see our Cloud & DevOps consulting.

Sources

Want help implementing this?

Book a free 30-minute call about your business. No obligation.

Book a free 30-minute call