The AWS invoice is higher again, and somebody has said the words “just cut it by 20 percent”. Cuts like that are how checkout pages end up slow at 9 a.m. on a Monday. The bill can come down without anyone noticing, but only if you do the steps in a sensible order and measure after each one.
Start with waste, not with performance
The cheapest saving is capacity nobody is using. It carries the lowest risk to performance, because the thing you are removing was not performing anything.
Three places to look first:
- Environments that run all night. AWS’s Well-Architected guidance says development and test environments “are typically only used for eight hours a day during the work week”, and that stopping them when not in use gives “a potential cost savings of 75% (40 hours versus 168 hours)”. That is AWS’s example, not a promise about your account, but the arithmetic is hard to argue with.
- Old volume types. AWS says gp3 volumes cost 20 percent less per GiB than gp2, include a baseline of 3,000 IOPS and 125 MiB/s, and that you can convert existing volumes with Elastic Volumes “without interrupting your Amazon EC2 instances”. Check that your workload’s IOPS and throughput fit the gp3 baseline, or provision extra, before you switch.
- Resources with no owner. Stopped instances still have volumes attached, and test stacks outlive the people who built them. If a charge cannot be tied to a team, nobody will ever switch it off.
Rightsize from measurements, not hunches
Rightsizing means moving a resource to a size that matches what it really uses. The risk is in the word “really”.
AWS Compute Optimizer is the vendor’s own tool for this. It looks at configuration and utilisation metrics from CloudWatch over the last 14 days by default (up to 93 days if you pay for enhanced infrastructure metrics) and labels each EC2 instance as under-provisioned, over-provisioned or optimized. Three details decide whether you stay safe:
- Memory needs an agent. Compute Optimizer analyses memory utilisation “only for resources with the unified CloudWatch agent installed”. Without it, a recommendation is based on CPU, network and disk, and a memory-hungry database can look comfortably idle.
- It rates its own risk. Each recommendation carries a performance risk from very low to very high. AWS says a higher rating means you “should validate whether the instance type meets the performance requirements of your workload before migrating”.
- It looks at peaks. It uses the maximum utilisation point in each five-minute interval, not the average. That is the conservative choice, but 14 days can still miss month-end processing. If your workload has a monthly peak, extend the look-back or check by hand.
Resize one tier at a time, on the less critical systems first, and compare latency and error rates before and after. Moving a size down is a reversible change; a panic at 9 a.m. is not.
Then commit to what is left
Savings Plans trade a commitment for a lower rate. AWS describes them as a commitment to a consistent amount of compute usage, measured per hour, for one or three years. The discounts are real: Compute Savings Plans offer up to 66 percent off On-Demand and EC2 Instance Savings Plans up to 72 percent, according to AWS’s comparison with Reserved Instances.
Those are ceilings, not what you will get. The part to read twice is the note at the bottom of that page: Savings Plans “can’t be cancelled during the term”. Buy one against an oversized fleet and you have contracted to pay for the oversizing.
| Option | What it covers | Notes from AWS |
|---|---|---|
| Compute Savings Plans | EC2 any family, size, OS, tenancy or Region; Fargate; Lambda | Up to 66% off On-Demand |
| EC2 Instance Savings Plans | One instance family in a Region | Up to 72% off On-Demand |
| Convertible RIs | Exchangeable, manually | Up to 66% off On-Demand |
| Standard RIs | Fixed configuration | Up to 72% off On-Demand |
Savings Plans do not reserve capacity, and they do not apply to Spot usage. Compute Optimizer can also estimate savings with Savings Plans and RI discounts included, once you turn on its savings estimation mode, which helps you see how a resize and a commitment interact.
A prudent habit is to commit to the steady floor of your usage and leave the variable part on-demand. The floor is the part you are confident will still be there in a year.
Make it stick
A one-off clean-up works until the next release. The FinOps Foundation’s principles explain why: accountability for usage and cost should sit with the teams that make the decisions, and “technical teams must consider cost as a first class metric from the beginning of the software development lifecycle.”
In practice that means:
- Tags or accounts that map every charge to a team.
- A named owner for each large cost.
- A recurring review of the Compute Optimizer findings, not a single sweep.
- Performance dashboards watched during every change, with a rollback ready.
If saving money costs you reliability, you have not saved money. You have moved the cost to an outage.
Where Auris fits
Auris works with certified FinOps practitioners who handle this sequence for a company’s cloud estate: finding and removing waste, rightsizing against measured usage, choosing commitments last, and setting the budgets and alerts that keep savings in place. The FinOps page explains how an engagement runs.
The bottom line
Cut waste first, rightsize from measured data second, and buy commitments last, against the smaller fleet. Change one thing at a time and watch performance after each change, and the bill falls without anyone noticing, which is the only review you want.