You opened the AWS billing console and the number made you wince. You did not launch anything big. Nobody remembers changing anything. Yet the bill is up 20, 30 or 40 percent.
High AWS bills are rarely caused by one dramatic mistake. They are usually caused by many small, quiet leaks. Here are the nine we find most often when we review AWS accounts, and what to do about each.
High AWS bills are rarely caused by one dramatic mistake.
How do I find out what is driving my AWS bill?
Start with AWS Cost Explorer. Group costs by Service, then by Usage Type, and compare the last three months. That shows you which service grew and exactly which usage type (for example, DataTransfer-Out-Bytes or NatGateway-Bytes) is responsible.

If costs are spread across many accounts, use AWS Organizations consolidated billing and the Cost and Usage Report (CUR) for line-item detail. Without tags, you will see *what* is expensive but not *who* owns it, so fix tagging early.
The 9 most common causes of a high AWS bill
1. Idle and oversized EC2 instances
Instances launched for a test, a demo or a migration often keep running for months. Others are sized for peak load that never comes. Use AWS Compute Optimizer and CloudWatch CPU and memory metrics to find instances running consistently below 20–30% utilisation, then downsize or stop them.
2. No Savings Plans or Reserved Instances
Running steady workloads on On-Demand pricing is the most expensive way to use AWS. Compute Savings Plans and Reserved Instances offer significant discounts for a 1- or 3-year commitment. Compare options in our guide to Reserved Instances vs Savings Plans.
3. Unattached EBS volumes and old snapshots
When an instance is terminated, its EBS volumes are not always deleted. Snapshots also pile up from automated backups with no retention policy. Both are billed every month, silently.
4. NAT Gateway data processing charges
NAT Gateways charge per hour and per gigabyte processed. Workloads in private subnets that pull large volumes from S3 or ECR through a NAT Gateway can generate large bills. VPC gateway endpoints for S3 and DynamoDB route that traffic privately and avoid the NAT processing fee.

5. Data transfer between regions and to the internet
Data leaving AWS, and data moving between Availability Zones or Regions, is charged. Chatty microservices spread across AZs, cross-region replication and unoptimised CDN setups all add up. Use CloudFront for public content and keep high-traffic services in the same AZ where resilience allows.
6. Storage on the wrong tier
S3 Standard for data nobody reads, and gp2 volumes that could be gp3, both cost more than necessary. Use S3 Intelligent-Tiering or lifecycle rules to move cold data, and migrate gp2 volumes to gp3, which is cheaper per GB and lets you provision performance separately.
7. CloudWatch Logs with no retention
By default, CloudWatch Log Groups keep data forever. Verbose application logs at scale can become one of the fastest-growing costs in an account. Set retention periods and reduce debug-level logging in production.
8. Non-production environments running 24/7
Development, QA and staging environments rarely need to run nights and weekends. Scheduling them to stop outside working hours can cut their compute cost by more than half.
9. Forgotten managed services
Unused RDS instances, idle load balancers, Elastic IPs not attached to running instances, and abandoned OpenSearch domains are all billed whether anyone uses them or not.
Quick-reference: cause, signal and fix
| Cause | Where you see it | Fix |
|---|---|---|
| Idle/oversized EC2 | Compute Optimizer, low CPU | Rightsize, stop, schedule |
| No commitments | High On-Demand share | Savings Plans after rightsizing |
| Orphaned EBS/snapshots | EC2 > Volumes "available" | Delete, set retention |
| NAT Gateway | NatGateway-Bytes usage type | VPC endpoints |
| Data transfer | DataTransfer usage types | CloudFront, AZ affinity |
| Wrong storage tier | S3 Standard, gp2 | Lifecycle rules, gp3 |
| Log retention | CloudWatch Logs growth | Retention policies |
| 24/7 non-prod | Steady non-prod spend | Instance Scheduler |
| Forgotten services | Low-traffic RDS, ELB, EIPs | Decommission |
How do I stop my AWS bill from rising again?
One cleanup is not enough. Costs creep back unless you change how decisions are made:
- Enforce tagging with AWS Organizations tag policies or Service Control Policies.
- Turn on AWS Cost Anomaly Detection and route alerts to the owning team, not a shared inbox.
- Set AWS Budgets per team or product with alerts at 80% and 100%.
- Review weekly. Fifteen minutes per team, looking at top movers.
- Show engineers the cost of what they build, in the tools they already use.
These are the foundations of a FinOps practice. Our guide What Is FinOps? explains the full model.
How Crozaint approaches high AWS bills
Crozaint is an AWS Select Consulting Partner. Our FinOps engagements begin by consolidating billing data, often across many accounts, into one view. From there, our AI Cost Optimization Agent monitors spend continuously and flags anomalies, idle resources and rightsizing opportunities as they appear, rather than at month-end.
Malabar Gold & Diamonds came to us with a complex AWS billing structure. Their IT Manager described Crozaint as "really helpful in consolidating our complex AWS billing structure." Across our FinOps engagements, clients see an average 27% reduction in cloud spend within 60–90 days.
Common mistakes to avoid
- Buying 3-year Reserved Instances before rightsizing
- Deleting snapshots without checking backup and compliance requirements
- Sending all cost alerts to one person who cannot act on them
- Optimising one big account while dozens of small ones grow unnoticed
- Treating data transfer as "unavoidable" without checking architecture
Conclusion
A high AWS bill is almost always a collection of fixable leaks. Find them with Cost Explorer, fix the obvious ones this week, and put tagging, anomaly alerts and reviews in place so they do not return.
Want a second pair of eyes on your AWS bill? Talk through your cloud bill with a senior Crozaint engineer in a 30-minute call.




