I read cloud bills, architecture diagrams, and CloudWatch dashboards for a living. Across 23 Series A-C SaaS environments last quarter — fintech, devtools, vertical SaaS, AWS and GCP — the same three patterns showed up every time. None of them are exotic. None require a migration. They're just the specific line items that grow in the shadow of a product roadmap and nobody has the time to look at.
Median finding across those 23 audits: $3,400 / month of addressable waste, with payback under 8 weeks. The highest we found was $28,000 / month at a 180-person Series C. The smallest was $780 / month at a 55-person Series A. It's almost never zero.
Here are the three, in order of how often we see them.
1. Savings Plan and Reserved Instance structures frozen at Series A
Most founders buy their first Savings Plan the day their CFO asks why AWS grew 3x last quarter. The plan is sized for the workload that month. Then the product ships, traffic patterns shift, instance families get swapped (m5 → m6i → m7g), and the Savings Plan just sits there — committing to yesterday's architecture.
What we find:
- Coverage under 40% of on-demand eligible spend (the math only works past ~70%).
- Compute Savings Plans bought when EC2 Instance Savings Plans would have been cheaper (or vice versa).
- A 3-year all-upfront commitment from 18 months ago that is now 2x oversized because the team migrated half the workload to Fargate.
Typical fix: sell back the underused portion on the Marketplace if you bought 1-year no-upfront; layer a hybrid of 1-year Compute SP plus EC2 Instance SP sized to the stable baseline; leave 20–25% uncommitted for peak. Re-measure quarterly.
Typical impact: 12–22% reduction on compute line items. Payback: under 6 weeks.
2. Orphaned EBS volumes and cross-region data transfer
EBS is the cost line that grows while nobody is looking. Every CI/CD pipeline that spins up a testbed with a 100 GB gp3 root volume, every debug snapshot, every terminated-instance-whose-volume-was-not-terminated-with-it — it all accumulates on the monthly bill at $0.08/GB for gp3 or $0.125/GB for io1/io2. A 50-engineer team can easily ship 4–6 TB of orphaned volumes per year.
Cross-region data transfer is worse because it does not show up in Cost Explorer's default view. It lives under DataTransfer which most teams filter out as "infrastructure noise." It is not noise:
- RDS replica in us-east-1, application in us-west-2 — every query pays inter-region egress.
- S3 bucket in ap-south-1, ECS tasks in ap-southeast-1 — every object read pays $0.02/GB.
- CloudWatch Logs cross-account export — charged both at source and target.
Typical fix: a 30-day lifecycle policy that auto-deletes volumes unattached > 7 days; VPC endpoints for S3 and DynamoDB (they are free and eliminate NAT gateway charges); move stateful dependencies into the same region as their consumers; put a weekly cross-region egress diff in the engineering stand-up.
Typical impact: $400–$4,500 / month recovered. Payback: 1–3 weeks.
3. Observability that scaled past $5k/month without a decision
This is the one nobody wants to talk about because the whole team uses the dashboards. But when observability tooling grows faster than product revenue — which it does almost by default — something is off.
The specific patterns:
- Datadog / New Relic ingesting every container log at $0.10/GB, when 70% of those logs are ALB access patterns that nobody reads and that already live in S3 for 10% of the cost.
-
Custom metric cardinality explosions — a metric with a
customer_idtag has 15,000x the billing footprint of the same metric with atenant_tiertag. We have seen single metrics costing $1,800/month. - APM covering every service including the 40% of the stack that is stable, stateless, and already tested.
Typical fix: ship high-volume logs to S3 first, let the observability vendor rehydrate on demand (every major vendor supports this now); audit custom metric cardinality quarterly; APM only on services where the p95 latency directly affects user experience.
Typical impact: 30–55% reduction in observability spend without losing a single actionable signal. We have taken one team from $14k/month to $5.2k/month on Datadog without turning anything material off.
Why nobody catches these internally
These three patterns share one property: they do not break anything. Nothing alerts. Nothing degrades. Nothing is urgent. So they live in the "review next quarter" column of an engineering backlog forever.
Cloud bills are an attention problem before they are a finance problem. If nobody's whole job is to sit with the billing console for a few hours and write down what is there, it does not get written down. Most teams cannot justify a headcount for that; the spending curve has not hurt enough yet.
Where to start if you want to look yourself
- Cost Explorer, group by Usage Type, filter last 30 days, sort descending. The top 10 rows explain 85% of the bill. Anything you cannot instantly justify in one sentence is a candidate.
- AWS Compute Optimizer — free, underused. It flags instances running at under 40% utilization over 14 days.
- Trusted Advisor "Cost Optimization" checks — also free, surfaces low-utilization EC2, unassociated Elastic IPs, idle load balancers.
- For GCP: Cloud Billing → Reports → group by SKU, then by Project, last 90 days. Sort descending. Look for any SKU whose monthly growth exceeds your user growth.
If any of the line items surprise you, the audit is worth doing.
Or skip the hunt
We wrote a 24-hour written audit exactly for this. Four fields, no call required, delivered as a short PDF with 3–5 ranked findings and dollar impact. Free tier, or a ₹2,000 / ~$25 Priority tier (12-hour turnaround, credited against any follow-on engagement) — whichever fits. aicloudstrategist.com/audit.
The only reason to skip is if you already know these patterns in your own stack. Most teams don't.
Anushka B is the founder of AICloudStrategist, a written-first cloud consultancy for Series A-C SaaS. Seven years of cloud architecture work across AWS and GCP. Writes at aicloudstrategist.com/blog. Reach her at contact@aicloudstrategist.com.
Top comments (0)