Most AWS cost optimisation articles show you the monthly "after" number and stop there. They skip the upfront commitment, the migration effort, and the trade-offs that made the savings possible.
I'm Kausik Das, Cloud & DevOps Engineer at Product Pursuit, and I recently led an infrastructure cost optimisation initiative for our US-based client, Shareplenti. We reduced annual AWS spending from ~$1,380 to ~$310 - a genuine 77% yearly reduction. Along the way, I'll show you exactly where the money went, including the ~$250 upfront cost that most write-ups quietly leave out.
What We Were Running (And What It Actually Cost)
Before optimisation, Shareplenti's infrastructure had three components:
• A production server on AWS EC2 (on-demand pricing)
• A development & testing environment on a second EC2 instance
• A Jenkins CI/CD server sharing that second instance
Monthly AWS bill: ~$100–$115/month
Annualised: ~$1,200–$1,380/year
For a large enterprise, this is a rounding error. For a product startup, it's a meaningful line item - especially when that infrastructure is running at roughly 1% of its actual traffic capacity, which is exactly what our monitoring showed. The infrastructure wasn't struggling. It was idling at full price.
Step 1: Measure Before You Touch Anything
This step isn't glamorous, but it's the one that made everything else possible.
Using AWS CloudWatch, I profiled the production environment over several weeks:
• CPU utilisation: consistently low• Memory usage: well within instance limits
• Network throughput: a fraction of what the instance could handle
• Traffic volume: ~1% of future projected capacity
Without this data, any "optimisation" would have been guesswork. With it, we could make confident decisions about right-sizing and commitment levels.
Step 2: Right-Size Production and Switch to a Savings Plan
The production server was overprovisioned for current workloads. Based on the monitoring data, I moved to a t3.medium — an instance that comfortably handles current traffic while still providing a clear upgrade path when volume grows.
One principle I held throughout: don't optimise so aggressively that scaling becomes painful. The t3.medium was chosen because it's the right size today and an easy step-up tomorrow, not because it was the cheapest option available.
Switching to a 1-Year EC2 Savings Plan - The Real Numbers
Here's where I need to be more transparent than most cost optimisation articles.
EC2 Savings Plans reduce your hourly rate by committing to a consistent usage level for 1 or 3 years. The savings are real - typically 30–40% versus on-demand - but they come with an upfront cost that must be factored into your actual savings calculation.
For our setup, the 1-Year Savings Plan costs approximately ~$250 upfront.
Here's what that means annually:
Cost Item Amount
EC2 Savings Plan (1-year, upfront) ~$250
Contabo VPS (12 × $5) ~$60
Total Year 1 cost ~$310
Previous annual AWS cost ~$1,380
Net annual saving $1,070 (77%)
Averaged monthly, the new infrastructure costs about ~$26/month, not $10. That's the honest number.
Is 77% still a strong result? Absolutely. But the difference between "77% annual savings" and "93% monthly savings" matters when you're making a business case or advising others. Upfront commitments are real costs.
When does a Savings Plan make sense? When your workload is predictable and will run continuously for 12+ months. Production servers almost always qualify. Jenkins and dev environments often don't - which is exactly why we handled them differently.
Step 3: The Jenkins Question
This is where the bigger architectural decision lived.
The question I asked was simple: Does Jenkins actually need to run on AWS? After reviewing the CI/CD pipeline patterns, the answer was no - and for clear reasons:
• Jenkins builds are bursty, not sustained. They spike during deploys and sit idle otherwise.
• The dev environment has no production SLA. Occasional slowness is acceptable.
• Testing workloads don't need AWS-grade availability or redundancy.
These workloads were on AWS because everything else was on AWS — not because they needed to be. That's a common and expensive default.
Step 4: Migrating Jenkins and Dev/Test to a VPS
I migrated Jenkins, the development environment, and testing infrastructure to a Contabo VPS at ~$5/month.
What the Migration Actually Involved
• Provisioned the VPS and configured the Linux environment
• Reinstalled Jenkins and restored pipeline configurations
• Updated webhook endpoints and agent configurations to point to the new host
• Ran a parallel period where both environments were live to validate stability
• Decommissioned the second EC2 instance after confirming everything worked
The engineering team noticed no disruption. Pipelines kept running. Build times were comparable.
What We Gained Beyond Cost Savings
Moving non-production workloads off AWS wasn't just cheaper, it was architecturally cleaner:
• Production and non-production are now fully isolated. A Jenkins issue can't affect production infrastructure, and vice versa.
• AWS resources are reserved for workloads that genuinely need them. Production gets the reliability and compliance posture of AWS. Dev/test gets affordable compute.
• Operational clarity improved. Costs are easier to attribute and review when environments are separated.
The Honest Results Summary
Scenario Monthly Avg Annual
Before optimization ~$115 ~$1,380
After optimisation (Year 1) ~$26 ~$310
Saving ~$89/month avg ~$1,070 (77%)
From Year 2 onward, costs stay around ~$310/year if you renew the Savings Plan at the same rate.
If you switch to a 3-year commitment, the upfront cost amortises even lower annually.
What stayed the same throughout:
• Zero production incidents
• CI/CD pipelines uninterrupted
• Development workflows unaffected
• Full scalability path intact
Cloud Cost Optimisation Lessons Worth Taking
1. Every workload needs its own question
The default is to put everything on AWS. The right approach is to ask what each workload actually needs: availability, compliance, latency, scale. Production often justifies AWS. CI/CD and dev environments usually don't.
2. You cannot optimise what you haven't measured
The 1% utilization finding was the entire foundation of this project. Without CloudWatch data to back it up, right-sizing the instance would have been a guess. Always monitor before you move.
3. Savings Plans work — but include the upfront cost in your math
A 1-Year Savings Plan is a genuine discount on EC2. But ~$250 upfront is a real expenditure. Factor it into your savings calculation and your payback period before committing.
4. Separation of environments is good engineering, not just cost management
Running production and non-production on the same infrastructure is a risk as much as a cost issue. This optimization removed both problems at once.
5. Cost optimization is a habit, not a project
AWS bills grow quietly. Workloads change. New services get added. The monitoring and review practices you build are worth more long-term than any single architecture change.
Conclusion
77% annual cost reduction. ~$1,070 saved per year. Zero production incidents.
Those are real numbers — including the ~$250 Savings Plan commitment that most similar articles leave out. The strategy wasn't complicated: measure your actual usage, commit only to infrastructure that warrants a long-term commitment, and stop paying AWS prices for workloads that don't need AWS.
If your infrastructure bill has been growing without a corresponding growth in traffic, the analysis phase alone is worth doing. You might find, as we did, that the biggest savings are sitting in plain
sight.