To cut AWS costs 25-40% in 90 days without hurting performance, run a week-one audit, kill obvious waste, rightsize EC2 and RDS, commit baseline compute to a 1- or 3-year Savings Plan, add S3 lifecycle policies, fix the CI/CD pipeline, then install a lightweight FinOps loop so the savings stay cut. The order matters more than the tooling.
Why do most AWS bills have 30-50% slack in them?
AWS bills grow organically. Every feature ships with a new service. Every traffic spike justifies a buffer that never gets retired. Every engineer who leaves takes the context of "why is this thing running" with them. Two or three years in, the account holds dozens of small inefficiencies, two or three big ones, and nobody has a complete map. The 30-50% number is not theoretical — it is the consistent finding across audits we have run for e-commerce, SaaS and fintech teams.
Cutting that slack is well-understood engineering work. It is not exciting, it does not need machine learning, and it does not require ripping out architecture. What it does need is a disciplined order of operations so you bank no-risk savings first, earn credibility, and only then touch the changes that need code or downtime.
For a worked example, see our NordShop AWS case study — same playbook, real numbers, 40% saving in 90 days.
How do you audit an AWS account in one week?
Do not skip this. Every wasted week of audit prevents months of chasing the wrong savings. A defensible audit covers six layers and produces one artefact: a ranked backlog of savings opportunities tagged by risk.
- Export the Cost and Usage Report (CUR) to S3, load 13 months into Athena. The console aggregates lie; the raw CUR is the only truth.
- Run Compute Optimizer on EC2, EBS, Lambda and RDS, then cross-check against 14 days of CloudWatch metrics — never trust a single source.
- Sweep Trusted Advisor for idle load balancers, unattached EIPs, orphaned snapshots, underutilised RIs and S3 buckets with no lifecycle.
- Score tag coverage per service. Anything under 90% tag coverage gets a remediation ticket before you touch its spend.
- Interview the engineers who actually run the system. Ask what is safe to delete, what looks idle but is critical, what runs only at month-end.
- Score FinOps maturity against the FinOps Foundation framework so you know which governance gaps you are about to inherit.
What are the six AWS cost cuts that move the bill, in order?
This is the order we run on every engagement. The earlier items carry little or no risk and bank quick savings; the later items touch architecture and need more care.
| Step | Change | Typical saving | Risk |
|---|---|---|---|
| 1 | Delete idle resources — ELBs, EIPs, snapshots, dev EC2 left running, unused EBS | 3-6% | None |
| 2 | Rightsize EC2 and EBS using Compute Optimizer + 14-day CloudWatch validation | 5-10% | Low |
| 3 | Commit baseline compute to a 1- or 3-year Compute Savings Plan | 10-17% | Low |
| 4 | RDS — rightsize, switch to Graviton, drop redundant writers, consider Aurora I/O-Optimized | 5-12% | Medium |
| 5 | S3 lifecycle — Intelligent-Tiering for live, Glacier IR/Deep Archive for cold | 3-7% | Low |
| 6 | CI/CD — ephemeral spot runners, layer caching, parallel test shards, OIDC auth | 3-8% | Medium |
Add the typical ranges and a healthy account lands at 30-50% reduction. NordShop hit exactly 40% on this playbook; the case study sits at the NordShop AWS case study.
How do you rightsize EC2 without breaking production?
Rightsizing is where teams hurt themselves. They downsize on CPU average alone, miss a memory spike at month-end, and trigger an outage that costs more than a year of savings. Three rules avoid that.
- 14-day metric window minimum. Anything shorter misses weekly cycles; anything covering a quarter-end or Black Friday is mandatory before touching that workload.
- Track P95, not average. A box averaging 20% CPU may be hitting 90% at the P95. Downsize on the P95 with a 25% safety margin.
- Drop one size, observe one week, drop again. Two small drops with monitoring in between beats one aggressive cut every time.
The same logic applies to RDS — but with one extra rule: never resize the primary writer during business hours, and always use blue-green deployments when AWS offers them for your engine.
When should you commit to a Savings Plan vs Spot vs On-Demand?
Commitment strategy is the single largest lever in the playbook, and the one most teams get wrong by either over-committing (a 3-year plan on a workload that will not exist in 12 months) or under-committing (paying on-demand for steady-state compute that has not moved in two years).
| Workload type | Best fit | Typical discount |
|---|---|---|
| Steady production baseline, 18+ months runway | 3-year Compute Savings Plan, no upfront | 40-55% |
| Predictable but business strategy could pivot | 1-year Compute Savings Plan, no upfront | 25-30% |
| Batch, CI, async workers, non-prod | Spot via ASG mixed instance policy or Karpenter | 60-85% |
| Bursty production spikes above baseline | On-Demand on top of Savings Plan baseline | 0% |
| GPU / specific instance family for ML | EC2 Instance Savings Plan (instance-family specific) | 35-60% |
The right answer for most accounts is a Compute Savings Plan sized to ~70-80% of baseline, On-Demand for the bursty top, and Spot for everything async. Aim for 85-95% Savings Plan utilisation; lower means you over-committed, 100% means you under-committed.
How do you keep the savings cut after the engagement ends?
Most savings creep back within six months because nothing structurally changed in how the team makes decisions. The fix is three lightweight rituals — they cost a couple of hours a month and prevent regression.
- Weekly anomaly digest. Automated email flagging any service whose spend moved more than 15% week-on-week. Investigate, do not act by default.
- Monthly FinOps stand-up. 30 minutes, engineering plus finance, one dashboard, one question — what surprised us and what do we do about it.
- Quarterly commitment review. Savings Plan coverage and utilisation, plus any architecture changes coming that will move the baseline.
If your team is too small to run this, RioCloud's managed FinOps service runs the loop for you and reports monthly. We also help teams running container-heavy estates make the right call between EKS, ECS and managed alternatives — see Kubernetes for small teams.
Frequently asked questions
- How quickly can a team realistically cut their AWS bill 40%?
- 90 days is realistic for most mid-market accounts. The first 30 days deliver around 20% from no-risk and low-risk changes; the next 60 days deliver the harder architectural cuts.
- Do I need Reserved Instances or Savings Plans in 2026?
- Compute Savings Plans are almost always the right answer over Reserved Instances now — same discount tier, far more flexibility across instance family, region and even compute service (EC2, Fargate, Lambda).
- Is Graviton actually worth the migration effort?
- For RDS, ElastiCache and managed services, almost always yes — it is an instance-family change with no code work and a 15-20% price/performance gain. For EC2 it depends on your container images and language runtime support.
- Should I move workloads off AWS to save money?
- Rarely. Most teams that "exit cloud" save less than expected once they price in operations, hardware refresh and network. The bigger wins are usually inside AWS — see our AWS vs GCP vs Azure comparison for when an alternative cloud is actually cheaper.
- What is the single highest-ROI change for most accounts?
- A Compute Savings Plan sized to baseline. It takes one hour to commit and immediately drops 15-25% off steady-state compute spend with no architectural risk.
- Will optimisation hurt application performance?
- Done properly it usually improves performance. Rightsizing exposes hot spots, Graviton is often faster, parallel CI shards cut feedback time, and CDN/S3 lifecycle cuts latency. The "performance vs cost" trade-off is mostly a myth at the optimisation tier.
- Can I run this playbook in-house?
- Yes — that is what the playbook is for. Most teams capture 60-70% of the available savings on the first attempt. A specialist FinOps engagement typically captures the remaining 30-40% plus the governance loop.
Next steps
If you want a sanity check on your current AWS spend, book a 30-minute call with RioCloud Solutions — bring your last 3 months of Cost Explorer screenshots and we will tell you which of the six steps will move your bill the most. For a real-world example of this exact playbook in action, read the NordShop AWS case study. If you are an e-commerce team specifically, the e-commerce cloud cost audit framework is the next read.
