Yes, you can use AWS without it costing half your profit. How we reduced cloud spend while improving reliability and release confidence.
Context
A growing SaaS product was seeing monthly AWS spend rise faster than customer growth. The platform was stable and shipping regularly, but infrastructure choices made during early growth were now creating avoidable cost pressure.
The team did not want a risky rewrite or a broad migration programme. They needed a practical path to trim spend, keep performance steady, and avoid slowing product delivery.
Challenge
The root issue was not one expensive service. It was many small inefficiencies across compute, data transfer, storage, and environment sprawl.
Some workloads were overprovisioned for peak load all day. Background jobs ran on larger instances than needed. A few data paths were crossing Availability Zones more than necessary. There were also old snapshots, logs, and artefacts being retained far longer than useful.
FinOps visibility was another gap. Cost alerts existed, but they were too high-level to drive technical decisions in weekly planning.
Approach
The work started with a focused cost map by workload, not just by AWS service. We tagged core paths, separated production from non-production spend, and identified where spend was tied to real user value versus operational drag.
From there, we made targeted architecture changes in sequence:
- Right-sized ECS tasks and moved selected bursty jobs to Lambda.
- Added autoscaling policies based on meaningful utilisation and queue depth, rather than static buffers.
- Reviewed RDS instance class and storage settings, then tuned backup and retention windows.
- Introduced S3 lifecycle policies for logs, exports, and media derivatives.
- Reduced unnecessary cross-AZ traffic on internal service paths.
- Added budget thresholds with service-level alerts that mapped to team ownership.
The principle was simple: optimise where it is safe, measurable, and reversible. No heroics, no gamble.
Outcome
Monthly cloud spend dropped materially while reliability stayed consistent. Response times remained within target ranges, and release cadence did not slow during the optimisation period.
The bigger gain was operational clarity. The team could now explain spend by product behaviour, spot drift earlier, and make cost-aware engineering decisions before issues compounded.
Yes, you can use AWS without it costing half your profit. You need clear workload boundaries, sensible defaults, and regular housekeeping built into delivery.
Key takeaway
Cost-effective cloud architecture is usually an operations discipline, not a single trick. Small, deliberate changes across scaling, storage, and observability compound into meaningful savings without compromising product quality.