1
1 Comment

I accidentally increased my AWS bill by 43% — here's how I fixed it and saved $529/month

I'm building a container hosting platform as a solo founder. It runs on AWS — ECS Fargate, DynamoDB, the usual.

Two weeks ago I enabled DynamoDB auto-scaling. It seemed like a best practice. AWS recommends it. Every blog post says do it. So I did.

Three days later I checked my bill and almost choked.

The damage

My dev account went from $13.68/day to $19.52/day (+43%). Production went from $6.69/day to $11.13/day (+66%).

That's an extra ~$300/month I didn't budget for. As a bootstrapped solo founder, that hurts.

What actually happened

DynamoDB auto-scaling was "working" — but my traffic is bursty, not steady. The deployments table was scaling up and down every 5-10 minutes:

82 RCU → 46 → 55 → 28 → 37 → 55 → 28 → 37 → 54 → 45...

50+ scaling events per day. Each time it scales up, you're charged for the peak capacity. Scale-down has a cooldown. So you're paying peak prices for average usage.

But here's the part that really surprised me.

The hidden cost nobody warns you about

Auto-scaling silently created 430+ CloudWatch alarms across my two accounts. About 4 alarms per scaling target. Each alarm costs $0.10/month.

  • Dev account: 192 alarms = $19.20/month

  • Production: 232 alarms = $23.20/month

That's $42/month in alarm costs I didn't even know existed. My CloudWatch costs jumped 2,873% overnight.

The fix (embarrassingly simple)

One command per table. Switched all 33 DynamoDB tables from Provisioned to On-Demand:

aws dynamodb update-table --table-name my-table --billing-mode PAY_PER_REQUEST

Then removed all auto-scaling targets. The 430+ alarms disappeared automatically.

Before and after

  • Monthly AWS bill: $743 → $214 (71% reduction)

  • DynamoDB cost: ~$14/day → ~$0.03/day

  • CloudWatch alarms: 430+ → 6

  • Scaling events per day: 50+ → 0

Dev account: $19/day → $3/day. Production: $11/day → $4/day.

Total monthly savings: $529.

What I learned

1. Auto-scaling isn't free. The scaling itself costs money and it silently creates hundreds of CloudWatch alarms. Nobody mentions this in the "how to set up DynamoDB" tutorials.

2. On-demand wins for bursty workloads. If your traffic is unpredictable (i.e., you're a startup), on-demand is almost always cheaper than provisioned + auto-scaling.

3. Check your CloudWatch alarm count right now.
Seriously.
Run this:

aws cloudwatch describe-alarms --query 'MetricAlarms | length'

You might be surprised.

Bonus: shutdown scripts

I also wrote scripts that scale my dev environment to zero when I'm not working — ECS services to 0, EC2 instances stopped. Takes 2-3 minutes to bring back up. Dev environment now costs ~$3/day when idle.

If you're running DynamoDB with auto-scaling and your workload is bursty, check your costs. You might be bleeding money the same way I was.

Happy to share the scripts or answer questions about the specifics.

posted toAvatar for product SnapDeploy
SnapDeploy
  1. 1
    great writeup — the 430 auto-created CloudWatch alarms thing is exactly the kind of silent leak most people never see on their bill. I built a free browser-only scanner that reads your cost csv locally (no aws creds) and spits a safe-delete list — found a bunch of these in similar setups. getcloudsaver.com if useful. either way, on-demand dynamodb tip is gold.