Why cost creep is hard to catch
AWS pricing is granular by design: you're billed per resource, per hour, per gigabyte. That makes small inefficiencies individually invisible and collectively expensive. A team rarely notices when a $40 monthly line item becomes $60; they notice when the total bill has doubled over a year and nobody can point to why.
The usual suspects
In most cost reviews, the growth traces back to a handful of repeat offenders:
- Oversized EC2 instances chosen once at launch and never revisited as actual usage patterns became clear
- Unattached EBS volumes and old snapshots that outlived the instances they were created for
- S3 buckets with no lifecycle policy, quietly accumulating logs, backups or uploads in standard storage instead of moving to cheaper tiers
- NAT gateway data transfer charges, which are easy to underestimate and add up fast for chatty applications
- RDS instances provisioned for peak load that run oversized 24/7 instead of using read replicas or scaling
- Idle load balancers and unused Elastic IPs, both billed even when doing nothing
- Cross-region or cross-AZ data transfer that wasn't accounted for in the original architecture
What a useful cost review actually checks
A cost review that just looks at the total bill won't find much. One that goes resource by resource, cross-referenced against actual utilization metrics (CPU, memory, network, connection counts), finds the gap between what you're paying for and what you're using. Right-sizing instances based on real usage instead of the original guess is usually the single largest saving.
Cost control isn't a one-time fix
The uncomfortable truth is that cost creep comes back. New resources get provisioned, old ones don't get cleaned up, and six months after a cost review the bill starts climbing again for the same reasons. Treating it as a recurring check, quarterly is reasonable for most setups, catches it while it's still a small correction instead of a large one.