In Q2 2024, a SaaS client brought us in after their AWS bill hit $180K/month — a 3× increase in 14 months on roughly flat traffic growth. Ninety days later, it was $72K/month. We had not touched a single business feature. This is not unusual. Cloud cost sprawl is almost universally the result of a small set of recurring anti-patterns, and it is entirely fixable.
Phase 1: The Visibility Sprint (Week 1–2)
You cannot optimise what you cannot see. Before touching a single instance type or reserved capacity commitment, spend two weeks instrumenting your entire spend with AWS Cost Explorer, Linked Account tagging, and per-service budget alerts. Every resource in your account should carry four mandatory tags: Environment (prod/staging/dev), Service (the microservice or product area it belongs to), Team (the engineering team owning it), and CostCentre (the business unit paying for it).
Once tagged comprehensively, run a spend breakdown by tag for the last 90 days. In virtually every engagement, we discover 15–25% of spend attributed to 'untagged' resources — orphaned EC2 instances, forgotten RDS snapshots, NAT Gateway traffic for decommissioned services — none of which have a human owner keeping them accountable.
Warning
Never skip the tagging sprint to get to 'the real optimisation work'. Untagged resources are invisible resources, and invisible resources never get cleaned up. Mandatory tags + automated enforcement (via AWS Config rules) is the foundation of sustainable FinOps.
Phase 2: The Quick Wins (Week 3–6)
After the visibility sprint, four categories of waste become immediately obvious and actionable:
1. Right-sizing compute: The single largest saving in any engagement. We analyse CPU/memory utilisation across every EC2 instance and ECS task for 30 days. In over 80% of cases, average CPU utilisation is below 12% — indicating instances are 4–8× over-provisioned for their steady-state workload. Using AWS Compute Optimizer recommendations, we right-size every instance that has been running below 30% average utilisation for 30+ days.
2. Reserved Instance and Savings Plan coverage: On-demand pricing is the most expensive way to run steady-state workloads. Converting stable, long-running services to one-year no-upfront Savings Plans delivers an immediate 29–44% discount on EC2 and Fargate compute with zero operational change.
3. S3 intelligent tiering: Objects that have not been accessed in 30+ days should be in S3 Infrequent Access or Glacier Instant Retrieval, not Standard. Enable S3 Intelligent-Tiering on every bucket holding more than 100GB of objects and let AWS handle the tier transitions automatically.
4. Data transfer optimisation: Cross-AZ and cross-region data transfer is aggressively priced. In many architectures, a single chatty microservice calling peers in a different AZ accounts for 20–40% of total data transfer costs. Co-locate tightly coupled services in a single AZ and use VPC endpoints to eliminate NAT Gateway charges on calls to AWS services.
Phase 3: Architectural Optimisation (Week 7–12)
The bigger, structural savings come from architectural changes. The highest-value interventions we consistently see:
Horizontal Pod Autoscaler with KEDA for Kubernetes workloads: Most Kubernetes deployments we inherit are statically configured with min/max replica counts that assume peak traffic at all times. Combining HPA with KEDA event-driven autoscaling (scaling to zero during off-peak hours for background workers) typically reduces EKS node costs by 35–50%.
RDS Aurora Serverless v2: For databases with highly variable access patterns (common in B2B SaaS with business-hours-heavy traffic), Aurora Serverless v2 autoscales ACUs between 0.5 and your defined maximum. A database that previously cost $2,400/month on a fixed r6g.2xlarge often costs $600–900/month on Aurora Serverless v2 with identical performance during business hours.
Lambda for async workloads: Queued background processing — email sending, PDF generation, webhook delivery, report building — rarely needs persistent compute. Migrating these workflows from always-on ECS Fargate tasks to SQS-triggered Lambda functions typically reduces their infrastructure cost by 80–90%.
Conclusion
Cloud cost optimisation is not about being cheap — it is about eliminating waste so that every dollar of infrastructure spend is working at maximum efficiency. The 60% savings we achieve are not from gutting performance or accepting lower reliability. They come from applying systematic visibility, eliminating provable waste, and aligning architectural patterns with actual usage profiles. The result is a leaner, more resilient infrastructure that is also significantly cheaper.
Key Takeaways
- Start with a mandatory tagging sprint — untagged spend is invisible and never gets cleaned up
- Right-sizing compute is almost always the single largest saving opportunity
- Savings Plans and Reserved Instances should cover 70%+ of stable workloads
- HPA + KEDA autoscaling can cut Kubernetes compute costs by 35–50%
- Aurora Serverless v2 is transformative for variable-traffic databases