Most removable AWS spend sits in five categories. Oversized compute, EC2 and managed services provisioned with headroom that real utilization never uses, is usually the largest pool. Idle non production resources running nights and weekends are the easiest to cut because turning them off is reversible. Storage waste, gp2 volumes that should be gp3, orphaned volumes and snapshots no one owns, and cold data left in standard S3, grows without limit because nothing deletes it. NAT gateway processing and data transfer, cross zone, cross region, and internet egress, are the quietest, buried in the bill as usage types rather than resources. And a steady baseline still running on demand leaves a Savings Plans discount on the table. The biggest is oversizing, the easiest is idle, and the most overlooked is transfer, and you remove them in that order of safety, reversible first, with engineering signoff on anything that touches a running workload.
Here is each category, how to find it, and how to remove it without breaking production.
Why is oversized compute the biggest pool?
EC2 instances, RDS databases, and most managed services are sized by humans who err toward headroom, because being too small risks an incident and being too large only costs money no one is watching. Multiply that bias across an estate and the gap between provisioned capacity and used capacity becomes the single largest waste pool. The lever is rightsizing against observed utilization, dropping each resource to the smallest size that comfortably carries its real peak, with engineering signoff so nothing is starved. AWS Compute Optimizer surfaces candidates, but treat its output as a signal to verify, not an instruction, as argued in AWS Compute Optimizer trust but verify. The discipline of doing it so engineers accept it is in EC2 rightsizing that engineers accept.
Where exactly does AWS spend leak?
The five categories differ in size, in how fast they grow, and in how safe they are to remove. The table ranks them by where to look first.
| Category | Where it shows in the bill | The lever |
|---|---|---|
| Oversized compute | EC2 and RDS hours larger than utilization needs | Rightsizing against real usage with engineering signoff |
| Idle non production | Instances running outside working hours | Scheduling off, idle detection and cleanup |
| Storage waste | gp2 volumes, orphaned volumes and snapshots, cold S3 in standard | gp3 migration, lifecycle policy, tiering |
| NAT and transfer | NAT gateway processing, cross zone and egress usage types | Architecture review, keeping traffic local |
| Uncovered baseline | Steady usage billed at on demand rates | Savings Plans coverage against a forecast |
Two of these are standing, low risk wins almost everywhere: migrating gp2 volumes to gp3, which is cheaper at the same or better performance, covered in EBS volume rightsizing and gp3 migration, and scheduling non production fleets off out of hours, in idle EC2 detection and cleanup.
Why is data transfer the most overlooked?
Data transfer and NAT gateway charges are invisible in the way that matters: they do not appear as a resource you can point at and delete, only as usage types accumulating in the bill. A service that chats across availability zones pays cross zone transfer on every exchange, a private subnet routing internet traffic through a NAT gateway pays a processing fee per gigabyte, and anything serving data to users pays egress. None of it shows up when you look at your instance list, so it grows until someone queries the Cost and Usage Report by usage type and finds it. The lever is architectural, keeping traffic within a zone, using gateway endpoints instead of NAT where possible, and removing needless cross region copies, detailed in data transfer costs on AWS explained.
Group your Cost and Usage Report by usage type and sort by cost. If transfer, NAT processing, or old generation instance hours appear near the top, you have found waste that no one was watching, because none of it is visible in the resource consoles.
What does removing it look like in order?
Sequence matters because the safe wins should fund and de risk the rest, and because commitments must come last so you never cover a bloated estate.
A European SaaS company on AWS assumed its bill tracked growth. We mapped the Cost and Usage Report to the five categories. Oversized EC2 and RDS were the largest pool, a fleet of non production instances ran around the clock, hundreds of gp2 volumes had never moved to gp3, orphaned snapshots had accumulated for years, and a chatty service was running a meaningful cross zone transfer line. We scheduled non production off, migrated volumes to gp3, deleted orphaned storage, rightsized with engineering signoff, fixed the transfer pattern, and only then sized Savings Plans to the lower steady state. The program reached a reduction in line with our 31 percent median in the first 90 days, with no production impact. Figures are verified against billing data and anonymized.
Frequently asked questions
What is the biggest source of AWS waste?
How do you find waste in an AWS account?
Is data transfer a big AWS cost?
Find your biggest AWS waste pools
We map your Cost and Usage Report to these categories, quantify each pool, and turn it into a safe removal plan with engineering signoff, independent of any provider and taking zero provider commissions. Start with our playbook, then bring us your bill.
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.