Service guide
How to reduce AWS EC2 costs
EC2 is usually the biggest line on the bill and the biggest source of recoverable waste. The good news: EC2 waste follows the same six patterns in almost every account, and most fixes are operational, not architectural.
The free scan runs all six checks across every region with 14 days of CloudWatch evidence per instance.
Run the free scanThe six EC2 checks, in order of typical payoff
- →1. Find the idle. Instances under 5% average CPU over two weeks are usually forgotten experiments and retired workers. Stopping one recovers ~100% of its cost. Check CloudWatch CPUUtilization before touching anything — averages per instance, not per fleet.
- →2. Rightsize the quiet. Every instance size step is exactly 2x the price. Anything under 20% CPU is a candidate to drop one size for a 50% saving; AWS Compute Optimizer (free) gives per-instance recommendations from your real usage.
- →3. Schedule non-production. Dev and staging used 40 hours a week bill for 168. Off nights and weekends saves ~70% per environment — an EventBridge schedule or Instance Scheduler does it without touching the instances themselves.
- →4. Modernise previous generations. m3, c3, r3, t2 cost 10–20% more than current m7g/c7g/t4g equivalents — and run slower. Graviton (ARM) types add another ~20% saving where the workload supports it, which for most Linux services it does.
- →5. Cover the baseline with Savings Plans. Whatever survives steps 1–4 is your real baseline — commit it to a Compute Savings Plan for 20% (1-year, no upfront) to ~50% (3-year). Order matters: commit after cleanup, never before.
- →6. Sweep the edges. Unattached EBS volumes from terminated instances, idle Elastic IPs at $3.60/month, stopped instances still paying for storage. Small individually; a habit collectively.
Put numbers on it
Frequently asked questions
What is the fastest EC2 saving with zero risk?
Scheduling non-production environments. It changes no architecture, touches no production, and saves ~70% of every scheduled environment’s compute immediately. Second fastest: stopping instances under 5% CPU — with a stop-first-terminate-later policy so anything missed can be restarted in minutes.
Is low CPU always a safe signal to downsize?
No — memory-bound services (databases, JVMs, caches) can be genuinely busy at 10% CPU, and burstable t-family instances idle by design. That is why our audit reads network and memory signals alongside CPU and flags burstables separately rather than blanket-recommending downsizes.
£499 fixed. Free scan first. 20%+ found or it’s free.
The scan is read-only — a role you create and delete, no keys shared — and shows your estimated monthly saving before anyone talks about money.