Why startups waste the most
Startups move fast. Engineers spin up infrastructure to test an idea, validate a hypothesis, or demo to a potential customer. The experiment works (or does not), the team moves on to the next thing, and nobody goes back to clean up.
This is rational behavior. When you are racing to find product-market fit, spending 30 minutes cleaning up a $50/month dev database feels like a poor use of time. But those $50 instances accumulate. After six months of fast iteration, a 5-person startup can easily have $500-$1,000/month in pure waste — resources serving no purpose whatsoever.
For a startup burning $50,000/month, $1,000 in AWS waste is 2% of runway. Over 18 months, that is $18,000 — enough for another month of operation or a meaningful marketing budget.
The anatomy of startup AWS waste
Dev and staging environments running 24/7
Most startups have at least one staging environment that mirrors production. This environment runs 24/7 even though it is only used during business hours — roughly 40 hours out of 168 hours per week. That is 76% idle time on infrastructure that might cost $200-$500/month.
Some teams also maintain per-developer environments, feature branch environments, or QA environments. Each one adds to the bill whether anyone is using it or not.
Experiment infrastructure that outlives the experiment
A developer spins up a Redis cluster to benchmark a caching strategy. The benchmark takes two days. The Redis cluster runs for four months before someone notices it in the bill. This pattern repeats across every team member, every sprint.
The problem is not that people create resources — that is their job. The problem is that there is no system to detect when a resource has served its purpose and is now idle.
EBS snapshots accumulating silently
Every time someone creates an AMI, takes a manual snapshot, or has automated backups running, EBS snapshots accumulate. At $0.05/GB/month, a single 100GB snapshot costs $5/month. But snapshots compound — after a year of daily snapshots of a 100GB volume, you are paying $150/month in snapshot storage alone.
Most teams never audit their snapshots because they are invisible in day-to-day operations. They do not show up in the EC2 dashboard unless you specifically navigate to the Snapshots section.
Load balancers with no targets
Application Load Balancers cost $16-$22/month in fixed charges regardless of traffic. When a service is decommissioned, the ALB often survives because nobody remembers it exists. It sits there, costing money, routing traffic to nothing.
Why tagging alone does not solve this
The standard advice for cloud cost management is 'tag everything.' Tags are useful for cost allocation — knowing which team or project a resource belongs to. But tags tell you who owns a resource, not whether it is idle.
A perfectly tagged EC2 instance that has been stopped for 3 months is still waste. A tagged EBS volume in 'available' state is still costing money. Tags help you assign blame; they do not help you detect waste.
What you actually need is monitoring of resource utilization: CPU usage, network traffic, connection counts, last-accessed timestamps. These metrics tell you whether a resource is doing useful work, regardless of how well it is tagged.
What actually works
1. Automated idle detection
The only reliable way to catch waste is automated scanning. A system that checks CloudWatch metrics, connection counts, and resource states on a schedule — daily or hourly — and flags anything that looks idle.
This is not something you want to build in-house. The logic for detecting idle resources varies by resource type (EC2 uses CPU/network, RDS uses connections, EBS uses attachment state), and maintaining it across AWS API changes is ongoing work.
2. Escalating alerts
A Slack message that says 'you have idle resources' gets ignored after the third time. What works is escalation: a gentle notification on day 1, a louder one on day 3, and an email to the team lead on day 7. Problems get louder until someone acts.
3. Visibility into cumulative waste
Engineers respond to concrete numbers. 'You have idle resources' is abstract. 'Your team has $847 in idle resources this month' is actionable. A dashboard that shows cumulative waste over time creates accountability without blame.
How Driftak solves this for startups
Driftak connects to your AWS accounts with a read-only IAM Role (no credentials stored, open-source policy you can audit). It scans EC2, EBS, RDS, Elastic IPs, and Load Balancers on your schedule and sends escalating alerts through Slack, email, and Telegram.
The free tier covers one AWS account with email alerts — enough for most early-stage startups. As you grow, the Starter plan ($29/month) adds multi-account support and Slack/Telegram integration. The ROI is immediate: if Driftak catches even one forgotten db.r5.large ($175/month), it pays for itself six times over.
Setup takes 5 minutes. You create a read-only IAM Role, paste the ARN into Driftak, and get your first scan results immediately. No agents to install, no code changes, no ongoing maintenance.