DEV Community

Cover image for Why your cloud bill keeps increasing
binadit
binadit

Posted on • Originally published at binadit.com

Why your cloud bill keeps increasing

#cloudcosts #costoptimization #awsbilling #infrastructureefficiency

The hidden costs eating your cloud budget

Your infrastructure bill just hit $20K this month. Last year it was $10K. Your traffic grew 30%, but your costs doubled.

Sound familiar? You're not alone. Most engineering teams are overpaying for cloud infrastructure by 40-60%. That extra money isn't buying better performance, it's funding inefficiency.

Let me show you where your budget is disappearing and how to get it back.

The sneaky ways costs spiral

Your instances never get smaller

You started with a t3.medium for safety. Traffic grew, so you bumped to t3.large, then m5.xlarge. But did you ever scale back down?

Most apps need peak capacity for maybe 4 hours daily. You're paying for Black Friday traffic levels on a random Tuesday in March.

# Instead of this static config
resources:
  requests:
    cpu: "2000m"
    memory: "4Gi"
  limits:
    cpu: "4000m"
    memory: "8Gi"

# Use dynamic scaling
autoscaling:
  targetCPU: 70
  targetMemory: 80
  minReplicas: 2
  maxReplicas: 20
Enter fullscreen mode Exit fullscreen mode

Dev environments run 24/7

Your staging cluster mirrors production specs. It runs all weekend while your team is offline. You're paying 168 hours for 40 hours of actual usage.

Quick math: If production costs $5K monthly, idle dev environments probably cost another $3K.

Data transfer charges sneak up

Put your API in us-east-1 and database in us-west-2? Every query generates transfer costs. Health checks, logs, monitoring, it all adds up.

I've seen teams pay $1,500 monthly in transfer fees that could be eliminated by moving services to the same AZ.

The worst auto-scaling mistake

Auto-scaling should save money, right? Wrong, if configured badly.

Most teams set aggressive scale-up (respond to load in 2 minutes) but conservative scale-down (wait 15 minutes before reducing capacity). Your infrastructure scales to handle peak traffic, then stays there.

# Broken scaling policy
scaleUp:
  stabilizationWindowSeconds: 60
  policies:
  - periodSeconds: 60
    value: 100%

scaleDown:
  stabilizationWindowSeconds: 900  # 15 minutes!
  policies:
  - periodSeconds: 300
    value: 10%
Enter fullscreen mode Exit fullscreen mode

This configuration scales up fast but barely scales down. Fix the scale-down window:

scaleDown:
  stabilizationWindowSeconds: 300  # 5 minutes
  policies:
  - periodSeconds: 60
    value: 50%
Enter fullscreen mode Exit fullscreen mode

Quick wins that cut costs immediately

Schedule non-production environments 

# Stop dev environments at 8 PM
0 20 * * * kubectl scale deployment --replicas=0 --all -n development

# Start them at 8 AM
0 8 * * 1-5 kubectl scale deployment --replicas=3 --all -n development
Enter fullscreen mode Exit fullscreen mode

This alone can reduce non-prod costs by 70%.

Right-size based on actual metrics

Look at your monitoring. If CPU averages 20% and memory stays under 40%, you're overpaying.

Don't guess, measure:

# Get actual resource usage
kubectl top pods --containers=true

# Check utilization over time
prometheus_query='rate(cpu_usage_seconds_total[5m]) * 100'
Enter fullscreen mode Exit fullscreen mode

Fix data transfer architecture

  • Keep database and app servers in the same AZ
  • Use CDNs for static assets
  • Compress API responses
  • Cache frequently accessed data

Real example: $28K to $11K monthly

A client came to me spending $28K monthly on AWS. Here's what we found:

  • Database: db.r5.4xlarge running at 15% utilization
  • Six dev environments: Running 24/7, costing $8,400/month
  • Cross-region traffic: $1,200/month in transfer fees
  • Log storage: 2TB kept for 2 years

The fixes:

  • Downsized database: Saved $2,100/month
  • Scheduled dev environments: Saved $5,900/month
  • Moved DB to same region: Eliminated transfer costs
  • Reduced log retention: Saved $400/month

Result: 59% cost reduction, better performance, happier developers.

Your action plan

  1. Tag everything - You can't optimize what you can't measure
  2. Start with the biggest costs - Focus on compute and storage first
  3. Automate scheduling - Dev environments off nights/weekends
  4. Monitor utilization - Right-size based on real data
  5. Review quarterly - Requirements change, resources should too

Don't try to fix everything at once. Pick your largest cost center and optimize that first. A 10% reduction in your biggest expense beats a 50% reduction in something small.

Your cloud bill doesn't have to keep growing. These optimizations typically take 2-3 weeks to implement and save 40-60% monthly. Your CFO will thank you.

Originally published on binadit.com

Top comments (0)