Cutting Cloud Bills by 40%: What We Actually Did (Not Theory)

A client brought us in to audit a SaaS platform that had grown organically over four years. Monthly AWS spend was ₹8.4 lakh and climbing. After an 8-week optimisation project, we brought it to ₹5.1 lakh — a 39% reduction — without degrading performance. Here is exactly what we did.

Step 1: Instrument Before You Cut

The first two weeks were pure observability. We added Cost Explorer tags to every resource by feature and team, set up CloudWatch dashboards for actual utilisation, and ran a week of baseline measurement. The results confirmed what we suspected: 60% of spend was on resources running at under 15% CPU utilisation.

Where the Savings Actually Came From

• RDS right-sizing: Production DB on db.r5.2xlarge (8 vCPU, 64 GB). Peak utilisation: 22% CPU, 18 GB RAM. Moved to db.r6g.xlarge with Multi-AZ. Saved ₹1.2L/month.
• EC2 reserved instances: Converted stable baseline instances from on-demand to 1-year reserved. Saved ₹82K/month.
• S3 Intelligent-Tiering: 4 TB of objects, 80% untouched for 90+ days. Intelligent-Tiering moved them to Glacier. Saved ₹34K/month.
• Eliminated NAT Gateway waste: 12 dev environments routing through a production NAT Gateway. Added VPC endpoints for S3/DynamoDB. Saved ₹28K/month.
• Lambda consolidation: 47 Lambda functions with overlapping triggers consolidated to 19. Reduced invocation costs and cold start issues. Saved ₹18K/month.

What Did Not Work

We tried to move a batch processing workload to Spot Instances and had two interruptions in the first week that caused user-facing delays. The saving was real but the engineering cost to make the workload interruption-tolerant was not worth it for this client's risk tolerance. Not every optimisation is worth the complexity.

“Cloud cost optimisation is 20% about the cloud and 80% about understanding which parts of your system actually matter.”