Cloud bills tend to grow faster than revenue in the early years of a SaaS product. Teams ship features quickly, infrastructure is provisioned generously to avoid outages, and nobody has time to audit what's actually being used. By the time a company notices, the monthly bill is a line item that raises eyebrows in board meetings.
Last year a client came to us with exactly this problem. Their AWS bill had reached $18,000/month for a product serving around 4,000 daily active users. After an eight-week engagement, we brought it to $10,800 — a 40% reduction — without touching a line of application code.
Step 1: Build a Cost Map
Before touching anything, we used AWS Cost Explorer and AWS Compute Optimizer to understand where the money was going. The breakdown was: EC2 (44%), RDS (22%), data transfer (18%), S3 (9%), and miscellaneous services (7%).
We also enabled CloudWatch detailed monitoring on every instance to correlate billing data with actual CPU and memory utilisation. Most instances were running below 15% average CPU utilisation.
Step 2: Right-Size EC2 Instances
The application ran on eight m5.xlarge instances (4 vCPU, 16 GB RAM each). Compute Optimizer recommended moving to m5.large (2 vCPU, 8 GB RAM) for six of them based on 90-day utilisation history. We ran one m5.large alongside the existing fleet for two weeks, confirmed the performance was identical under real traffic, then replaced all six. This alone saved $1,400/month.
Step 3: Move Stateless Workers to Spot
The product had four background worker instances processing asynchronous jobs. These were ideal Spot candidates: they were stateless, jobs could be retried on interruption, and they ran on a fixed instance family. We switched them to a Spot fleet with a mixed-instance policy (three compatible instance types) and an On-Demand base capacity of one. Workers dropped from $920/month to $290/month.
Step 4: Audit RDS
The database was a db.r5.2xlarge Multi-AZ instance ($3,960/month). Actual peak memory usage was 18 GB out of 64 GB available. We migrated to db.r5.xlarge Multi-AZ ($1,980/month) with a read replica for reporting queries. We also enabled RDS Proxy to reduce connection overhead, which improved p99 query latency by 12%.
Step 5: Cut Data Transfer Costs
The $3,240/month data transfer bill was the most surprising finding. The product was serving user-uploaded images directly from S3 in eu-west-1, then sending them to users across North America and Asia. We moved all static assets behind CloudFront with S3 as origin. Outbound transfer charges dropped by 80% because CloudFront edge locations cache assets regionally. Monthly data transfer cost fell to $640.
Step 6: Reserved Instances for the Core
After right-sizing, we committed to 1-year Reserved Instances for the two core application servers and the RDS primary. Reserved pricing on the remaining On-Demand instances saved another $840/month on a blended basis.
Final Numbers
- EC2 right-sizing: −$1,400/month
- Spot workers: −$630/month
- RDS right-sizing: −$1,980/month
- CloudFront for static assets: −$2,600/month
- Reserved Instance discounts: −$840/month
- Misc (unused EBS volumes, old snapshots, idle Elastic IPs): −$750/month
- Total: −$8,200/month (−40%)
What We Didn't Change
We deliberately left the application code, database schema, and deployment pipeline untouched. Infrastructure optimisation is lower-risk than code changes and often delivers faster results. If the client needs further savings — the next lever would be containerising the application with ECS Fargate or EKS, which would make per-request scaling more granular.
If your cloud bill has grown faster than your user base, the cause is almost always idle over-provisioning and data transfer charges. A structured audit typically identifies 20–40% in savings without any architectural changes. Contact us if you'd like us to run one for your infrastructure.