Cloud cost optimization is not a one-time cleanup you do before a board meeting. It is a habit most SaaS teams skip until the bill doubles in a quarter and someone finally asks why. The uncomfortable number: industry FinOps research this year puts average cloud waste at roughly 27-29% of spend across companies of every size, and startups under $1M in annual cloud spend are not exempt - they waste close to that same share, just on a smaller base.
That means a team paying $8,000 a month for infrastructure is very likely burning over $2,000 of it on resources nobody is using. Multiply that across a year and it is often the cost of a mid-level engineer. This post is a working checklist for where that waste actually hides, based on the patterns we see rebuilding and running backend systems for clients.
Why cloud cost optimization gets skipped
Most founding teams treat infrastructure spend as fixed overhead, like rent. It is not. Cloud bills are usage-based and elastic, which means they grow quietly with every new feature, every staging environment someone forgot to tear down, and every "just in case" instance size bump before a launch.
The other reason it gets skipped is ownership. In a five-person engineering team, nobody's job title says "cloud cost." It falls between whoever set up the AWS account originally and whoever pays the invoice, and neither has the bandwidth to audit line items every month. So the bill just climbs, and by the time it is a board-level line item, six months of waste has already compounded.
The checklist: where the waste actually sits
Idle and oversized compute
This is the single biggest category, and it is almost always avoidable. Staging and QA environments running 24/7 when they are only used during business hours. Instances sized for a traffic spike from a launch eight months ago that never got resized down. Old feature-branch preview deployments nobody remembers to delete.
A quick audit: pull CPU and memory utilization for every running instance over the last 30 days. Anything averaging under 15-20% utilization is a resize or shutdown-schedule candidate, not a "maybe later."
Storage that outlived its purpose
Snapshots, old database backups, logs kept at debug verbosity in production, and orphaned volumes from terminated instances all sit quietly on the bill. None of this shows up when you glance at the dashboard's compute chart, because storage costs are usually a smaller line item individually - but they compound across dozens of forgotten resources.
Reserved capacity and commitment mismatches
Teams either buy zero reserved capacity and pay full on-demand rates for steady-state workloads, or they buy reservations sized for last year's traffic and now sit on unused commitment. Both are expensive. The fix is a quarterly review, not a one-time purchase: look at your actual steady-state usage over the past 90 days and match commitments to that, with on-demand covering the variable top of the curve.
Data transfer and cross-region traffic
Cross-availability-zone and cross-region data transfer fees are one of the most common surprises we find in a cost review. A service architecture that grew organically often ends up chatting across zones far more than it needs to. Consolidating services that talk to each other constantly into the same zone, and caching aggressively at the edge, routinely trims this without touching the product at all.
Third-party SaaS-on-SaaS sprawl
This is not strictly cloud infrastructure, but it belongs in the same audit. Monitoring tools, log aggregators, and managed database add-ons get provisioned per-project and rarely get consolidated. A team of 15 engineers can easily be paying for four overlapping observability tools because each squad picked its own during a different sprint.
What a healthy baseline looks like
For context, a reasonably efficient SaaS company keeps total infrastructure spend at roughly 8-15% of revenue, and somewhere between $0.50 and $5 per active user per month depending on how compute-heavy the product is. If your number is meaningfully outside that range, it is worth a real audit rather than an assumption that "SaaS is just expensive."
The other useful check is trend, not just level: if cloud spend is growing faster than active users or revenue for more than two consecutive quarters, that gap is very rarely explained by legitimate scale-up. It is almost always the waste categories above compounding unnoticed.
Making cloud cost optimization a habit, not a project
The teams that keep this under control do three things differently. First, someone owns it explicitly, even if it is 20% of one engineer's time rather than a dedicated hire. Second, cost data sits next to usage data in the same dashboard, so a spike in spend gets connected to its cause within days, not discovered at month-end reconciliation. Third, teardown is automated for anything temporary - staging environments, preview branches, test databases - so "forgot to delete it" stops being a category of cost at all.
None of this requires a rewrite or a migration. It is closer to preventive maintenance: a recurring review cadence, sensible defaults on new resources, and alerts before a bill triples rather than after. For teams that already have us managing hosting and operational support, this audit is usually the first thing we run before touching anything else, because it tends to free up budget that can go straight back into the product. If your infrastructure has grown past what one person can eyeball in a spreadsheet, it is worth pairing this checklist with a proper services review rather than waiting for the next renewal to force the conversation.
Cloud bills rarely shrink on their own, and they never shrink by accident. But for most SaaS teams, the first pass through this checklist finds real, recoverable money within a week - not a hypothetical saving buried in a consultant's slide deck.