How a State E-Governance Platform Cut Its AWS Bill by 59% - Validated Against Peak-Load, Not Holiday Lows

The unchecked spend was on a trajectory that threatened the programme's operating budget. The lack of cost attribution meant that individual teams were optimising for performance and reliability, rightly, but with no feedback loop on the cost of their decisions.

The infrastructure drift problem illustrated the risk clearly: a stale configuration change had silently provisioned a second PostgreSQL database for the profession module. It was live, billable, and completely unknown until a targeted cost audit surfaced it. A separate queued database upsize, a change that had been staged but never deployed, had been sitting in the state file ready to apply on the next CI run. Neither had any detection mechanism in the existing workflow.

Without FinOps discipline, every infrastructure change carried hidden cost risk, and there was no systematic way to surface it.

Edstem ran a six-week FinOps programme to reduce the AWS costs. The programme was delivered by an Edstem team comprising a Senior Solution Architect, DevOps engineers, and senior backend engineers, working alongside the platform's engineering team. Every optimisation decision was validated against March busy-hour baselines, not April readings which were distorted by holiday low-traffic, to ensure no reliability regression was introduced alongside the cost reduction.

Compute right-sizing:

• Resource requests and limits defined on 12 EKS deployments that had none, and right-sized across all 55 services
• With accurate scheduling data, the cluster autoscaler compacted workloads onto fewer nodes
• ASG minimum reduced from 24 to 12 r7g.4xlarge Graviton nodes, a 50% reduction in baseline node count

Compute right-sizing was the largest single lever in the programme, with no change to the underlying workload.

Database right-sizing via RDS Proxy:

• Five RDS Proxy instances deployed before any database downsizes were attempted, separating connection count from actual query concurrency
• Six databases safely downsized from 4xlarge to 2xlarge instances, delivering meaningful monthly savings net of proxy costs
• Three proposed downsizes deliberately blocked after metrics showed genuine memory and query parallelism constraints the proxy could not resolve

Right-sizing decisions were grounded in real concurrency data, not connection counts inflated by pod churn.

Lambda and Athena optimisation:

• Report query lambda memory footprint reduced from 10 GB to 2 GB, reflecting its actual working set
• Athena results cache extended from 5 to 60 minutes
• Exponential backoff added to the polling loop

Lambda report costs fell by 87% with no change to query results or user experience

Automated RDS scheduling:

• A new scheduling Lambda deployed with EventBridge rules to scale 10 production databases down at 20:30 IST and back up at 07:00 IST, Monday through Saturday
• Implemented with strict guardrails: no manual invocation path, no immediate-apply flag, and a documented runbook informed by a previous 22-minute production outage

Automated scheduling delivers recurring monthly savings, with the guardrails preventing a repeat of the incident that had caused the prior outage.

Governance and cleanup:

• CloudTrail Insights disabled, eliminating the feature that had been driving the entirety of the CloudTrail bill
• 17 RDS and 5 Aurora snapshots totalling 17.2 TB deleted after confirming no active restore dependencies
• Four stopped EC2 instances, one log instance, six unused AMIs, and seven orphaned snapshots deregistered
• Duplicate profession RDS instance removed

Data service right-sizing:

• ElastiCache Redis migrated from m6g.2xlarge to m7g.xlarge, a smaller instance class that provides a higher network baseline (1.875 Gbps vs 0.75 Gbps), which is the binding constraint at the platform's traffic volumes
• MSK Kafka brokers migrated from m5.2xlarge to m7g.xlarge, delivering approximately 20% price/performance improvement on Graviton

Rejected optimisations are a core output of a FinOps programme. They document where cost reduction was considered and found to carry unacceptable reliability risk.

If you're responsible for cloud infrastructure costs, this engagement's experience shows that significant savings are available in most cloud-native environments without accepting reliability trade-offs. The key is validating every optimisation against real peak-load data, and being as disciplined about the changes you choose not to make as those you do.