Every Monday morning, the same Slack message lands in your team channel: "Did something run over the weekend? The bill looks high." In three years of managing cloud infrastructure for other companies, we've seen this pattern dozens of times. And in roughly 80% of cases, the culprit is one of three things.
1. Auto-scaling groups that forgot to scale down
Your Friday deployment triggered a scale-up event — perfectly normal. But the scale-in policy was either misconfigured or the cooldown period was set too conservatively. You entered the weekend at 4× capacity and stayed there until your first engineer logged in Monday morning.
The fix is almost never "set a more aggressive cooldown." It's scheduling-based scale-in for non-production environments, and alerts that fire within 2 hours of an unexpected capacity floor breach.
2. Orphaned development environments
Someone spun up an environment for a Friday demo. The demo happened. The environment did not get torn down. By Monday you've paid 60+ hours of compute, RDS, and data transfer for infrastructure serving zero traffic.
"Every EC2 instance without a TTL tag is a liability waiting to mature."
3. Batch jobs with missing cost ceilings
A weekly batch job kicked off Saturday night. It hit an unexpected data volume (maybe a client imported 10× more records than usual), scaled out to handle it, and ran until Sunday afternoon. No alerts were configured on spend, just on error rate.
The solution here is always the same: cost-based circuit breakers on long-running jobs, not just operational metrics. Your batch job can complete successfully and still be costing you 5× the expected amount.
What to do this week
Audit your auto-scaling groups for missing schedule-based policies. Tag every non-production resource with a TTL. Configure budget alerts at 80% and 100% of your weekly expected spend. None of these take more than an afternoon — and each one pays for itself the first time it fires.
