← Articles

April 4, 2026 · Tim Fraser, Cloud Operations Lead

Keeping SaaS Infrastructure Costs Proportional to Revenue

There's a pattern that repeats across almost every SaaS company on AWS. In the early stages, infrastructure costs are negligible — a few hundred dollars a month. Revenue grows, so the team focuses on product and sales. Nobody worries about infrastructure costs because they're small relative to everything else.

Then one quarter, someone looks at the numbers and realises AWS is the third-largest expense after payroll and office space. Infrastructure costs grew 4x while revenue grew 2x. The unit economics that worked at $5K/month in AWS spend don't work at $20K/month.

This happens because cloud infrastructure doesn't right-size itself.

The cost-per-customer problem

The metric that matters is cost-per-customer. When you're small, this number is high because fixed infrastructure supports few customers. As you grow, it should drop — that's SaaS economics.

But if you're not watching, it goes the other way. Each new customer adds load, so you bump instance sizes, add replicas, increase cache capacity. Each decision is reasonable in isolation. Collectively, cost-per-customer stays flat or increases, and the scale advantages never materialise.

Calculate this quarterly. If it's not trending down, your scaling approach has a problem.

Right-sizing: when and how

Right-sizing means matching resource capacity to actual usage. It rarely happens because under-provisioning causes outages while over-provisioning just costs money.

EC2 instances. If average CPU is under 20% and peak under 50%, the instance is at least one size too large. An m6i.xlarge at 15% CPU could be an m6i.large at 30% — same headroom, half the cost. RDS databases. A db.r6g.xlarge at 10% CPU with 12GB RAM used out of 32GB available is paying for capacity it doesn't need. Downsize during a maintenance window. ECS services. If tasks consistently use 30% of allocated CPU and 40% of memory, reduce the task definition. This directly reduces your Fargate bill.

Reserved Instances and Savings Plans

Once you know your baseline, consider Savings Plans: 30-40% savings for 1-year, 50-60% for 3 years.

The common mistake is buying reservations before right-sizing. If you buy a 1-year reservation for a db.r6g.xlarge then realise you only need a db.r6g.large, you're locked in. Right-size first, run for a month to confirm, then commit.

The staging environment problem

Almost every SaaS company has a staging environment that costs nearly as much as production. Staging was set up as a copy of prod, which made sense. But prod got scaled up, staging was scaled to match, and now it runs 24/7 at production instance sizes for three developers.

Options: scale staging down (most testing doesn't need prod-equivalent capacity), schedule it to shut down outside business hours (saves 65%), or use a minimal environment for CI/CD and keep full staging for manual testing only.

This is often the single biggest cost saving available, and the easiest — zero production risk.

What to track monthly

How plainfra gives visibility

plainfra connects to your AWS account and answers cost questions directly. Ask "what are our biggest cost drivers?" or "which resources are oversized?" and get a prioritised answer with dollar amounts — not a dashboard you have to interpret.

The weekly report tracks cost trends automatically. If spend jumps 15% week-over-week, the next report identifies the specific resources responsible. If a staging database is running a production-size instance, it shows up as a right-sizing recommendation.

The goal is infrastructure costs growing slower than revenue. That requires checking regularly. plainfra handles the checking.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.