The AWS billing spike pattern
If your AWS bill spikes every month, you are not alone. Flexera's 2025 State of the Cloud report found that 82% of enterprises consider cloud cost management a top challenge — and the most common complaint is unpredictable AWS billing that climbs month over month.
The frustrating part: AWS billing spikes rarely come from a single big decision. They come from dozens of small ones — a developer spins up an RDS instance for a load test, a staging environment runs over a long weekend, an Elastic IP gets allocated and forgotten. Each one is a few dollars. Together, they compound into a surprise at month-end.
This guide breaks down the five most common causes of AWS bill spikes and gives you a concrete action for each one.
Cause 1: Idle EC2 instances accumulating EBS and Elastic IP charges
Stopped EC2 instances are the most misunderstood source of AWS billing spikes. When you stop an instance, the compute cost stops — but AWS continues billing for attached EBS volumes at full rate, any associated Elastic IPs ($3.60/month each), and EBS snapshots.
A stopped m5.large with a 100GB gp3 volume and one Elastic IP costs roughly $12/month doing nothing. Ten forgotten instances across a team is $120/month — and that number grows every sprint as new instances get created and old ones get forgotten.
How to fix it
- ✓Go to EC2 > Instances, filter by State = stopped, sort by Launch Time
- ✓Any instance stopped for more than 7 days is a candidate for termination
- ✓Create an AMI if you might need the configuration, then terminate
- ✓Release any unassociated Elastic IPs under EC2 > Elastic IPs
Cause 2: Dev and staging environments running 24/7
Most teams have at least one staging environment that mirrors production. This environment runs 24/7 even though it is only used during business hours — roughly 50 hours out of 168 hours per week. That is 70% idle time on infrastructure that might cost $300-$600/month.
AWS billing for non-production environments is pure waste outside working hours. A staging environment with two m5.large instances, an RDS db.t3.medium, and a load balancer costs about $400/month running continuously. Scheduled shutdowns during nights and weekends reduce that to $120/month — a 70% reduction with zero impact on developer productivity.
How to fix it
Use AWS Instance Scheduler or a simple Lambda function to stop non-production EC2 and RDS instances outside business hours. Set a schedule like 8am-7pm Monday-Friday. The instances start automatically in the morning and stop at night. AWS billing drops immediately.
Cause 3: RDS instances that nobody is using
RDS is one of the most expensive AWS services and one of the most common sources of billing spikes. A db.r5.large costs about $175/month, and unlike EC2, you cannot stop an RDS instance indefinitely — AWS automatically restarts stopped RDS instances after 7 days and resumes full billing.
Common sources of RDS waste: dev databases created for a feature that shipped months ago, read replicas from a load test that was never cleaned up, and databases for deprecated services that nobody turned off. Each one adds to your AWS bill every month.
How to identify idle RDS
- ✓Check DatabaseConnections in CloudWatch — zero connections for 7+ days means nobody is using it
- ✓Check CPUUtilization — sustained under 5% suggests the instance is idle or massively oversized
- ✓Check FreeStorageSpace — if it has not changed in weeks, no data is being written
How to fix it
Take a final snapshot (costs pennies), then delete the instance. The snapshot lets you restore in minutes if you need it. For dev databases that are only needed during business hours, consider migrating to Aurora Serverless v2, which scales to zero and eliminates the idle AWS billing entirely.
Cause 4: Data transfer charges you did not expect
Data transfer is one of the most confusing parts of AWS billing. The rules are complex: traffic within the same Availability Zone is free, traffic between AZs costs $0.01/GB each way, traffic out to the internet costs $0.09/GB, and NAT Gateway processing costs $0.045/GB on top of that.
A common AWS billing spike pattern: a service starts sending data across AZs (maybe a new feature, maybe a configuration change), and the data transfer charges compound silently. A service processing 10TB/month across AZs adds $200/month in charges that do not show up until the bill arrives.
How to fix it
- ✓Check Cost Explorer, group by Usage Type, filter for DataTransfer to find the source
- ✓Ensure services in the same AZ communicate directly rather than through a load balancer in another AZ
- ✓Use VPC endpoints for S3 and DynamoDB to eliminate NAT Gateway data transfer charges
- ✓Consider S3 Transfer Acceleration only when the speed benefit justifies the cost
Cause 5: Unmonitored resource sprawl
The root cause behind most AWS billing spikes is not any single resource — it is the absence of monitoring. When nobody is watching, resources accumulate. A team of 10 engineers each creating 2-3 resources per sprint generates 20-30 new resources every two weeks. Without automated detection, the only time anyone notices is when the AWS bill arrives.
By then, the waste has been running for weeks. A forgotten db.r5.large running for 6 weeks before discovery costs $262 — more than a month of a Starter plan subscription to a monitoring tool that would have caught it on day 3.
How to fix it
Automated AWS cost alerts are the only reliable solution. Manual audits work once; waste accumulates continuously. You need a system that scans your AWS accounts on a schedule, detects idle resources by checking actual utilization metrics (not just tags), and sends escalating alerts before the waste compounds.
This is exactly what Driftak does. It connects to your AWS accounts with read-only access, monitors EC2, EBS, RDS, Elastic IPs, and Load Balancers, and sends AWS cost alerts through Slack, email, and Telegram. The first alert is gentle; if nobody acts, it escalates. Problems do not stay hidden until month-end.
The compounding effect
AWS billing spikes feel sudden, but they are almost always the result of gradual accumulation. Each month, a few more idle resources get added to the pile. Each month, the spike is a little higher than the last. The teams that stop the pattern are the ones that catch waste in hours, not at month-end.
Set up automated AWS cost alerts. Schedule your non-production environments. Audit your stopped instances and unattached EBS volumes this week. These three actions alone will flatten most AWS billing spikes — and keep them flat.