The AWS Cost and Usage Report is the source of truth for your bill, not the console dashboard. Each row carries a usage type that names precisely what was charged, a service, an account, a region, and the amortized cost of any commitment, and once you can read those fields the bill becomes legible. The fastest path is to group the report by service to find the largest spenders, then within the top services group by usage type to see whether the cost is instance hours, data transfer, storage, or requests. The lines where AWS overspend reliably hides are on demand instance hours that should sit under a Savings Plan, NAT gateway and cross zone data transfer, unattached volumes and stale snapshots, and idle load balancers. Reading the report is the first hour of any serious AWS cost program.
Here is how to decode the report, what the key usage types mean, and the lines to check first.
Why is the Cost and Usage Report the source of truth?
Cost Explorer is a helpful visual layer, but it groups and rounds, and it cannot show you every resource. The Cost and Usage Report is the raw, hourly or daily, line item level export that AWS itself bills from. It includes the unblended, blended, and amortized cost columns, which matter because amortized cost spreads a commitment evenly across the hours it covers, giving you the true economic cost of a workload rather than the lumpy moment a Reservation was purchased. It also carries the resource identifier on most lines, so you can attribute a charge to a specific instance, volume, or function. For any work beyond a glance, export the report to storage and query it; the detail is the difference between guessing and knowing.
What do the key usage types mean?
Usage types are the vocabulary of the bill. A handful account for most spend, and knowing them lets you read a row at a glance. The table decodes the ones you will meet first.
| Usage type pattern | What it means | What to check |
|---|---|---|
| BoxUsage and similar instance hours | Compute time for an instance type in a region | Is it steady enough to cover with a Savings Plan, and is it the right size |
| DataTransfer and Region to Region | Bytes moving across zones, regions, or to the internet | Cross zone chatter and internet egress that could be cached or colocated |
| NatGateway processing | Bytes processed by a NAT gateway, billed on top of transfer | Whether endpoints could replace the gateway for traffic to AWS services |
| EBS volume and snapshot | Provisioned storage and point in time copies | Unattached volumes and snapshots that outlived the resource they backed |
| LoadBalancer hours and capacity units | Running balancers and the capacity they consume | Idle balancers fronting nothing, and over scaled capacity units |
The pattern across all of these is that the usage type tells you which lever applies. Instance hours point to rightsizing and commitments, transfer points to architecture, storage points to lifecycle cleanup, and idle resources point to deletion. Reading the type is reading the fix.
How do you find the overspend fast?
Work top down. Group the report by service and sort by cost; the top three or four services are almost always compute, a database, storage, and data transfer. Inside the top service, group by usage type to see what is actually driving it. If the biggest line is on demand instance hours running around the clock, you have a commitment gap and probably a rightsizing candidate. If it is NAT gateway or cross zone transfer, you have an architecture cost. Then scan for the classic waste signatures: volumes with no attached instance, snapshots older than your retention policy, load balancers with no healthy targets, and databases provisioned for a peak that never comes. Each of these is a row you can act on without a meeting.
Open one month of the Cost and Usage Report, group by service then usage type, and look at your single largest line. If it is on demand BoxUsage on a steady instance, you have found both a Savings Plan opportunity and a rightsizing check in one row, and the recovery is usually material.
How does amortized cost change what you see?
Unblended cost shows the charge as it hit the account, which makes a Reservation purchase look like a spike in one hour and free hours afterward. Amortized cost spreads that purchase across the term, so each covered hour carries its true economic cost. For optimization you almost always want the amortized view, because it tells you what a workload really costs to run rather than where a payment happened to land. It also reveals coverage gaps clearly: hours running at full on demand amortized cost next to hours running at a discounted committed rate show you exactly where commitment coverage is missing. Reading the report in amortized terms is what turns it from an accounting artifact into an optimization tool.
A Fortune 500 retailer believed its AWS bill was mostly unavoidable production compute. We exported the Cost and Usage Report and grouped by service then usage type in amortized terms. The largest line was on demand instance hours for a steady fleet that had never been placed under a Savings Plan, the second was NAT gateway processing from a chatty architecture, and a long tail of unattached volumes and old snapshots filled the storage line. None had been visible in the console summary. Acting on them in order of size was part of the work that left the AWS estate materially lighter. Figures are verified against billing data and anonymized.
Where this fits in your AWS cost program
Reading the bill is the foundation of every other AWS lever. For the full estate picture, read the AWS cost optimization guide. To turn steady instance hours into savings, read on demand versus commitment on AWS, and for the surprises that catch buyers off guard, read common AWS billing surprises. The cross cloud view sits in the cloud cost optimization guide.
Frequently asked questions
What is the source of truth for an AWS bill?
What is a usage type on an AWS bill?
Where does AWS overspend usually hide?
Turn your bill into a recovery plan
We read your Cost and Usage Report in amortized terms and convert it into a prioritised AWS recovery plan, independent of any provider and taking zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. Start with our playbook.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.