Cutting a FinTech lender's cloud bill by 38% without touching throughput
A lending platform's AWS spend had tripled in eighteen months while transaction volume merely doubled. A four-week FinOps engagement found the gap and closed it.
-38%
Monthly cloud spend
Sustained across the two quarters following the engagement.
Unchanged
p99 API latency
Right-sizing was validated against load tests before every production change.
-65%
Non-production runtime
Environments now scale to zero outside working hours.
97%
Cost attribution coverage
Spend traceable to a product line, up from an untagged baseline.
What was actually going wrong
- Industry
- FinTech
- Services
- Cloud, DevOps
- Technologies
- AWSKubernetesTerraformPrometheusKarpenter
- 1
Monthly AWS spend had grown to a level that threatened the unit economics of each loan disbursed.
- 2
Nobody could attribute cost to a product line because tagging was inconsistent across five accounts.
- 3
Non-production environments ran at production sizing, around the clock, including weekends.
- 4
An earlier cost-cutting attempt had caused a latency incident, so the team had stopped touching infrastructure.
What we did, and why in that order
Sequence mattered here as much as the individual decisions. Each step below made the next one safe.
- 01
Establish attribution before touching anything
We enforced a tagging policy in Terraform and backfilled tags across five accounts, so every rupee could be traced to a product line and environment before a single change was proposed.
- 02
Right-size against observed load, not assumptions
Two weeks of Prometheus data showed the fleet was provisioned for a peak that occurred twice a quarter. We resized against the actual p99 and introduced autoscaling with a deliberately conservative headroom.
- 03
Schedule non-production environments
Development and staging now scale to zero outside working hours and on weekends, recovering roughly 65% of their runtime with no impact on developer experience.
- 04
Commit only what the baseline justified
After right-sizing, we modelled the stable baseline and purchased Savings Plans against that floor rather than against inflated pre-optimization usage.
- 05
Make cost a standing review item
A monthly FinOps dashboard and a quarterly review with engineering leadership turned cost from an annual panic into a routine metric.
Target architecture after the optimization engagement
- CloudFront CDN
- Application Load Balancer
- EKS with Karpenter autoscaling
- Aurora PostgreSQL with read replicas
- S3 with intelligent tiering
- Prometheus and Grafana observability
What changed, measured
Each figure below was measured after the engagement, not projected during it.
38%
reduction in monthly cloud spend
Monthly cloud spend
Sustained across the two quarters following the engagement.
-38%
p99 API latency
Right-sizing was validated against load tests before every production change.
Unchanged
Non-production runtime
Environments now scale to zero outside working hours.
-65%
Cost attribution coverage
Spend traceable to a product line, up from an untagged baseline.
97%
PLACEHOLDER: client quote pending written approval. The engagement gave us a number we could defend to the board and a process that keeps it there.
The capabilities behind this engagement
Facing something similar?
We will tell you what we would repeat from this engagement, what we would change, and what it is likely to take.