Skip to content

AWS Updated 2026-07-04

What a real AWS cost audit covers (and what a free "assessment" skips)

A real AWS cost audit examines usage data, architecture, commitments, and governance — not just a Cost Explorer screenshot. Here is the full scope, and what free assessments leave out.

A real AWS cost audit works from your actual usage data — the Cost and Usage Report, CloudWatch utilization metrics, commitment coverage — and produces a ranked list of changes with the effort, risk, and expected saving attached to each. A free “assessment” typically runs an automated scan, flags the same six generic findings for everyone, and prices the fix as an engagement. The difference is not thoroughness for its own sake: the automated scan cannot see the findings that carry most of the money, because those live in architecture and workload context, not in a resource list.

What you are deciding

You are deciding whether to pay for depth. Automated tooling (Trusted Advisor, Compute Optimizer, third-party scanners) finds orphaned resources, idle instances, and missing commitments — real findings, worth acting on, and largely free to discover yourself. What tooling cannot find: a NAT Gateway carrying traffic that belongs on a VPC endpoint, a batch job that could run Spot, a database tier sized for a launch spike two years gone, log pipelines ingesting debug output at production volume, or an account structure that makes cost ownership impossible. Those findings require a person reading your architecture against your bill, and they are typically where the majority of the recoverable spend sits.

The honest framing: if your monthly bill is small, self-serve with the free tooling and a checklist. Past the point where a 15% saving pays for professional attention several times over, an audit that covers the full scope below earns its fee — and any audit that skips half the scope is a sales instrument.

What to check first

Before commissioning anything, establish what you can see yourself:

  • Is a detailed billing export configured? Without CUR/Data Exports history, any auditor starts partially blind.
  • What does Trusted Advisor already say? Cost checks beyond the basics require a Business or higher support plan — if you have one, harvest the free findings first.
  • What is your commitment coverage and utilization? Two CLI calls, below.
  • Can spend be attributed? If nothing is tagged, expect any audit to begin with attribution work.

How to verify

# Is a detailed export (CUR 2.0 via Data Exports) configured?
aws bcm-data-exports list-exports

# Savings Plans utilization — are existing commitments even being used?
aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-07-01

# Reservation coverage — how much usage runs uncovered at on-demand
aws ce get-reservation-coverage \
  --time-period Start=2026-06-01,End=2026-07-01

In the console: Billing and Cost Management > Data Exports for the export, Cost Explorer > Savings Plans > Utilization report for commitment health. Low utilization on existing commitments is itself a finding — you bought the wrong shape.

The approach

What a real audit covers, in the order the work happens:

  1. Baseline from the CUR, not Cost Explorer screenshots. Line-item data over at least three months, amortized view, separated into compute, storage, data transfer, and per-request charges. This is the map everything else pins to.
  2. Utilization against provisioned capacity. CloudWatch CPU, memory (where the agent reports it), IOPS, and connection counts against what is provisioned — the rightsizing evidence base, with the gating rules covered in Compute Optimizer right-sizing.
  3. Commitment portfolio review. Coverage, utilization, expiry schedule, and whether the commitment shape (compute vs instance family, term, payment option) matches the workload’s actual stability.
  4. Data-path analysis. NAT Gateway processing, inter-AZ transfer, egress, S3 request patterns. This is where audits find money that scanners miss, because it requires reading traffic flows against architecture.
  5. Storage lifecycle reality check. Snapshot chains, unattached volumes, S3 versioning without expiry, log retention, backup duplication. Cache and data-tier sizing belongs here too — the pattern is the same one described in ElastiCache cost levers.
  6. Governance and attribution. Tagging coverage, account structure, budget alerts, anomaly detection. An audit that fixes the number but not the governance decays within two quarters.
  7. A ranked remediation plan. Each finding with estimated saving, effort, risk, and owner. If the deliverable is a slide deck without this table, you bought marketing.

What a free assessment typically skips: items 4 through 7. It reports orphans and missing commitments — the findings a script can produce — and stops where the judgment starts.

When this is the wrong move

Skip the audit if you already know the answer. A team that just launched knows the bill is unoptimized; spend the money on shipping. Skip it mid-migration — audit the destination architecture, not the one being demolished. And do not commission an audit as a substitute for ownership: a report nobody executes is the most expensive document in the company.

Common mistakes

  • Accepting percentage-savings promises before anyone has seen your data. A number quoted before the CUR is read is a sales number.
  • Auditing the management account only. In an Organization, the spend and the waste live in member accounts.
  • Treating the audit as the fix. The audit is a diagnosis; the savings arrive when the remediation plan is executed and verified against the next invoice.
  • Letting the auditor sell the commitments. Whoever recommends Savings Plans purchases should have no margin on the recommendation.

Keeping it under control

  • Configure Data Exports now, even if the audit is months away — history cannot be backfilled.
  • Re-run the audit’s baseline queries monthly yourself; the deltas are the early-warning system.
  • Track remediation findings to closure like incident actions, with owners and dates.
  • Re-audit lightly every 12 months or after any major architecture change; the AWS Cost Management docs cover the tooling that keeps the baseline current.

A good audit pays for itself on the data-path and governance findings alone — the parts the free scan never touches. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.