I'm unhappy with our cloud bill as the SaaS grows; how do we cut infra cost?

Cutting infra cost in a growing SaaS usually means doing less waste, buying smarter, and changing architecture only where it pays back. The best approach is to attack it in layers.

1) Find the biggest spend first

Before optimizing anything, break down cost by:

• Service: compute, databases, storage, networking, logs, queues, CDN, etc.
• Workload: prod vs staging, customer-facing vs internal, batch vs always-on
• Team/product area: which features are driving usage and cost

Look for:

• Idle always-on servers
• Overprovisioned databases
• High egress/network transfer
• Expensive logs/metrics retention
• Zombie environments and test stacks
• Unused volumes, snapshots, IPs, load balancers

If you can’t attribute cost to a service or product area, you’ll struggle to reduce it sustainably.

2) Right-size compute

Common wins:

• Downsize instances after measuring CPU/memory peaks
• Set autoscaling with realistic min/max values
• Prefer burstable / general-purpose only where appropriate
• Eliminate overly high baselines on Kubernetes/node pools
• Use bin packing so workloads share machines efficiently
• Kill or schedule non-prod environments off-hours

A lot of SaaS infra is provisioned for peak, but traffic is often uneven.

3) Use managed services carefully

Managed services save engineering time, but they can be pricey. Check:

• Are you paying for too much HA or too many replicas?
• Do you need the current database tier?
• Can read replicas, caches, or search clusters be reduced?
• Are serverless functions triggering expensive downstream calls?

Sometimes the cheapest fix is simply a smaller managed plan or fewer replicas.

4) Reduce database cost

Databases are often one of the largest bills. Actions:

• Find slow queries and add proper indexes
• Reduce chatty query patterns
• Cache read-heavy data
• Remove unused indexes
• Lower retention of old records when possible
• Compress/archive cold data
• Consider connection pooling
• Split hot vs cold workloads if one DB is carrying everything

Also review backups and snapshots—those can quietly grow.

5) Control storage

Check:

• Old object versions and multipart upload leftovers
• Unused block volumes and snapshots
• Hot/cold data tiers
• Log retention periods
• Duplicate backups across regions/accounts

Common savings:

• Move infrequently accessed objects to colder tiers
• Shorten retention for debug logs
• Delete orphaned artifacts from CI/CD

6) Reduce networking and egress

Network charges can surprise people. Watch for:

• Cross-AZ traffic
• Cross-region replication
• Data transfer out to the internet
• Large payloads between microservices
• Excessive CDN miss rates

Fixes:

• Keep chatty services in the same region/AZ where possible
• Use CDN caching effectively
• Compress responses
• Avoid unnecessary service-to-service hops
• Batch requests where possible

7) Make logs and observability cheaper

Observability often balloons with scale. Do this:

• Lower log verbosity in prod
• Sample traces instead of recording everything
• Shorten log retention
• Separate audit logs from debug logs
• Filter noisy repetitive messages
• Review metric cardinality

High-cardinality labels can make metrics unexpectedly expensive.

8) Fix architecture hotspots

Once you’ve removed waste, optimize structural problems:

• Convert synchronous chains into async jobs where latency allows
• Introduce caching for repeat reads
• Batch background work
• Decouple heavy reporting/analytics from transactional systems
• Move cold paths out of expensive always-on services
• Consider serverless for spiky, low-duty-cycle workloads

Don’t rewrite architecture prematurely—only do this where cost savings are meaningful.

9) Use purchasing levers

If you’re on AWS/GCP/Azure:

• Commit to reserved instances / savings plans / committed use discounts for stable baseline usage
• Use spot/preemptible instances for fault-tolerant batch work
• Negotiate enterprise discounts if you have material spend
• Review support plans; many teams overpay relative to usage

Rule of thumb: commit only for the portion of spend you’re confident is durable.

10) Put FinOps into process

Cost control shouldn’t be a one-time cleanup. Set up:

• Monthly cost reviews
• Budget alerts and anomaly detection
• Cost allocation tags
• Per-team/showback or chargeback
• “Cost impact” review for new architecture changes
• A backlog of the top 10 cost initiatives

If engineers can’t see cost impact, cost creep will come back.

A practical 30-day plan

Week 1: visibility

• Break down spend by service and environment
• Tag resources properly
• Identify top 5 cost drivers
• Turn on anomaly alerts

Week 2: easy wins

• Remove idle resources
• Downsize obvious overprovisioned instances
• Cut log retention
• Delete old snapshots/volumes
• Shut down unused non-prod

Week 3: performance-to-cost fixes

• Optimize DB queries and indexes
• Add caching where reads are repetitive
• Reduce network chatter and cross-AZ traffic
• Tune autoscaling

Week 4: structural changes

• Move batch jobs to cheaper compute
• Adopt savings plans/reservations for steady baseline
• Rework any major cost hotspots

Biggest mistake to avoid

Don’t treat cloud cost as only an engineering problem. It’s a product + engineering + finance problem:

• Product influences usage patterns
• Engineering controls efficiency
• Finance ensures purchasing discipline

If you want, I can help you build a cost-cutting checklist for your exact stack (e.g. AWS + Kubernetes + Postgres + Redis), or help you design a top-10 savings audit.