The safest way to reduce SaaS infrastructure costs is in this order: make costs visible, remove what nobody uses, stop paying for idle time, make the application do less work per request (better queries, caching, fewer logs), and only then resize the resources that remain, with performance measured before and after each change. Waste is usually safe to cut. Capacity your users depend on is not. The difference is only visible if you measure.
Key takeaways
- Visibility comes first. You cannot cut what you cannot attribute to a service, environment or feature.
- Waste before capacity. Unused and idle resources are the low-risk savings.
- Efficiency often beats bigger servers. Slow queries and missing caches drive many bills.
- Guard performance with a baseline. Change one thing, compare latency and errors, then continue.
1. Make costs visible
Start by breaking the bill down by service, environment and, where possible, product feature or customer. Tag or label resources consistently so production, staging and experiments are distinguishable. The AWS Well-Architected Cost Optimization Pillar frames this as cloud financial management: shared ownership of cost between engineering and finance, with budgets and forecasts. For a startup that can be as simple as a monthly review and budget alerts that notify someone when spending jumps.
2. Remove what nobody uses
- Old preview, demo and feature environments that were never deleted.
- Unattached storage volumes, orphaned load balancers and unused static IP addresses.
- Database snapshots and backups beyond your retention policy.
- Storage buckets full of logs, exports or uploads nobody reads, without lifecycle rules.
- Third-party SaaS subscriptions and seats for tools the team stopped using.
This is the lowest-risk category, but check ownership before deleting: an “unused” environment can be a client’s staging site.
3. Stop paying for idle time
Non-production environments rarely need to run nights and weekends. AWS’s cost guidance gives the example of stopping resources outside a 40-hour working week, which uses 40 of the week’s 168 hours and can save up to 75 percent on those resources. Scale-to-zero platforms, scheduled shutdowns and on-demand preview environments all achieve this. For production, autoscaling lets capacity follow demand instead of being sized for the busiest hour all day.
4. Make each request cheaper
Database queries
Inefficient queries are one of the most common reasons teams buy bigger databases than they need. Look at the slowest and most frequent queries: missing indexes, N+1 patterns that run a query per item in a list, and queries that fetch whole tables to show a page. Indexes help reads, but the PostgreSQL documentation notes they add overhead too, so remove the ones nothing uses. Our article on database design before your SaaS scales goes deeper.
Caching
Serve static assets from a CDN with long cache lifetimes, cache public pages at the edge where possible, and cache expensive results in your application. MDN’s HTTP caching guide covers the headers. Caching usually improves both cost and speed, which makes it one of the few changes that helps both at once; see also our guide on why websites are slow.
Logging and observability volume
Logs and metrics are often billed by volume ingested and retained. Debug-level logging left on in production, logging full request bodies, and keeping everything for a year can cost more than the servers being logged. Log what you need to investigate problems, sample high-volume events, and set retention by log type.
Background jobs
Batch work where you can, avoid polling loops that run constantly, and make jobs idempotent so retries do not repeat expensive work. Move heavy processing out of web requests so web servers can stay small.
AI and third-party API usage
Usage-based APIs scale with customers. Cache responses that do not change, send the smallest context that works, choose the smallest model that meets your quality bar, and set per-customer limits so one heavy user cannot create a surprise bill.
5. Right-size what remains
Once waste and inefficiency are gone, look at utilisation. Resources consistently using a small fraction of CPU and memory are candidates for a smaller size. AWS’s guidance makes a useful point here: the cheapest option is not always the smallest, because a smaller instance that takes longer to finish a job can cost more overall. Judge right-sizing by total cost for the work done, not hourly price alone.
Commitment discounts such as reserved capacity or savings plans make sense only for steady, predictable workloads. If your usage is still changing month to month, flexibility is often worth more than the discount.
Track cost per customer, not just the total
A growing bill is not a problem if revenue grows faster. The more useful number is cost per active customer, or per unit of work your product does, such as per order processed or per report generated. Divide monthly infrastructure spend by that unit and watch the trend. If it rises as you grow, something scales worse than linearly and is worth investigating. If it falls, growth is making you more efficient, which is what investors and your own margins want to see.
Usage-based features deserve their own line. AI calls, file processing, email and SMS sending all scale with what customers do, and a single heavy account can change the picture. Knowing your cost per customer also tells you whether your pricing tiers cover what each tier actually costs to serve.
Common traps on managed platforms
Serverless and managed platforms remove a lot of operational work, but their pricing rewards some patterns and punishes others. Watch for:
- Data transfer. Serving large files or video from application servers instead of a CDN or object storage with caching.
- Function invocations and duration. Chatty frontends that make many small requests, or functions that wait on slow APIs while billed time runs.
- Database connections. Serverless functions opening a new connection each time can push you to a larger database tier; connection pooling avoids this.
- Preview environments. Every branch with its own database or services adds up if old ones are never cleaned away.
- Add-ons billed separately. Monitoring, logging, analytics and image optimisation often sit on different meters from the main plan.
A monthly review that takes an hour
- Compare this month’s bill with last month’s, by service.
- Explain every line that grew by more than you expected.
- Check cost per customer against the previous months.
- Delete anything created for an experiment that has finished.
- Pick one improvement for next month and note its expected effect.
Protecting performance while you cut
- Record a baseline: p95 response times for key pages and APIs, error rates, and database load.
- Change one thing at a time, ideally in staging first.
- Compare against the baseline for long enough to cover busy periods.
- Roll back immediately if latency or errors rise, and investigate before trying again.
- Write down what you changed and what it saved, so the next review starts from facts.
Where to look first
| Area | Risk to performance | Typical effort |
|---|---|---|
| Unused resources and old environments | Very low | Hours |
| Scheduling non-production | Very low | Hours to a day |
| Log volume and retention | Low | Hours to a day |
| Caching and CDN | Low, often improves speed | Days |
| Query and index fixes | Low, often improves speed | Days |
| Right-sizing busy resources | Medium, needs measurement | Days, with monitoring |
| Commitment discounts | None, but reduces flexibility | Hours, after analysis |