AWS cost optimization — cut spend without cutting reliability.
A pragmatic FinOps review of your AWS bill: right-sizing, Savings Plans, storage lifecycle, NAT and data-transfer waste, and tagging you can actually govern. Reductions that stick, from a CISA + AWS Solutions Architect Professional who runs these systems in production.
Book a free 30-min callEmail meWhat you get
Compute & right-sizing
- Right-size EC2/EKS, Graviton migration where it fits
- Savings Plans / Reserved Instances modeling and commitment strategy
- Spot for safe workloads, autoscaling tuned to real demand
Storage & data transfer
- S3 lifecycle + Intelligent-Tiering, EBS gp3 migration, snapshot cleanup
- Kill NAT and cross-AZ data-transfer waste with VPC endpoints
- RDS/Aurora right-sizing and storage tuning
Visibility & governance
- Tagging strategy + Cost Explorer / CUR dashboards
- Per-team / per-service cost allocation and budgets/alerts
- Anomaly detection so bill spikes surface early
Sustainable savings
- Changes implemented as code so savings don't regress
- Prioritized by effort vs. impact — quick wins first
- No reliability trade-offs; security controls preserved
Proof
Where the money actually goes
AWS bills are rarely high because of one dramatic mistake. They are high because of six or seven unremarkable ones compounding. This is the order I usually find them in, and the order worth fixing them in.
| Source of waste | Typical cause | Effort |
|---|---|---|
| Oversized EC2 / RDS | Sized from a guess at launch, never revisited | Low |
| NAT gateway and cross-AZ transfer | No VPC endpoints; chatty services split across AZs | Low to medium |
| Unattached EBS and stale snapshots | Nothing owns cleanup | Low |
| S3 with no lifecycle policy | Everything stays in Standard forever | Low |
| On-demand where Graviton or Spot fits | Migration never scheduled | Medium |
| Idle non-production environments | Running 168 hours a week to be used for 40 | Low |
| No commitment coverage | Savings Plans feel risky, so nobody commits | Medium |
Notice that most of the high-impact items are low effort. That is typical, and it is why the first two weeks usually deliver most of the saving.
Right-size before you commit
The most expensive mistake I see is buying Savings Plans or Reserved Instances first, because the discount is visible and satisfying. Committing to a spend level before right-sizing locks in your current waste for one to three years.
The correct sequence is: eliminate obvious waste, right-size against real utilisation, establish the genuine baseline, and only then commit — at a coverage level below your trough, not your average. Getting this order wrong is the difference between a discount and a liability.
How an engagement runs
Measure. Cost and Usage Report analysis against actual utilisation, not averages. Averages hide the spiky workloads that make right-sizing risky.
Prioritise. A ranked list by effort against impact, with an estimated saving per item, so you can decide what is worth doing rather than accepting a wall of recommendations.
Implement. Changes as code, so a saving cannot quietly regress the next time something is provisioned by hand.
Govern. Tagging, per-team allocation, budgets and anomaly detection, so the next spike surfaces in days rather than at month-end.
Savings that do not come back
Most cost engagements deliver a spreadsheet. Six months later the spend has crept back, because the changes were manual and the next deployment did not know about them. Implementing reductions as Terraform or CloudFormation is what makes them durable — the optimisation becomes the default rather than a one-time correction. See Terraform vs CloudFormation for how I approach that, and Terraform consulting if the IaC itself needs work.
One caveat I will always raise: cost optimisation must not quietly remove security controls. Deleting flow logs, shrinking retention below your compliance requirement or dropping multi-AZ to save money is a saving you will regret at the next audit. Related: AWS DevOps consulting · EKS vs ECS.
FAQ
How much can I save?
Most environments I review land at 15 to 20 percent without reliability trade-offs. The honest answer is that it depends entirely on current waste: an estate that has never been right-sized has more headroom than one already running Savings Plans and Graviton. I will tell you roughly where you sit after the first call, before you commit to anything.
Is this a one-off or ongoing?
Both work. A one-off sprint finds and fixes the visible waste. Ongoing FinOps governance keeps it from returning, which matters because cost creeps back the moment nobody is watching. Most clients do a sprint first, then decide whether the governance layer is worth it.
Will optimization risk stability?
No, because I sequence for it. Changes are safe, reversible and implemented as code, prioritised by effort against impact, with security controls preserved throughout. Anyone who proposes deleting resources on day one before understanding traffic patterns is selling you an incident.
Do you cover Graviton and Spot?
Yes. Graviton migration where the workload is compatible, which is most things now, and Spot for genuinely fault-tolerant workloads with autoscaling tuned to real demand. Spot is not free money: it needs interruption handling, and I will say so if your workload is not a fit.
What is usually the single biggest win?
Right-sizing, almost every time, because most instances were sized from a guess at launch and never revisited. After that it is usually data transfer, specifically NAT gateway charges and cross-AZ traffic, which are invisible on most dashboards until someone goes looking. I removed $1,800 a month of NAT cost from one EKS platform with VPC endpoints.
Should I buy Savings Plans first?
No, and this is the most common expensive mistake. Committing to a spend level before right-sizing locks in your current waste for one to three years. Right-size first, establish the real baseline, then commit. Doing it the other way round is how teams end up paying for capacity they have already stopped needing.
Do I need tagging before any of this works?
For a one-off sprint, no; I can work from the Cost and Usage Report. For ongoing governance, yes, because without tags you cannot attribute cost to a team or service, and unattributed cost is nobody's problem to reduce. Tagging is usually the least glamorous and highest-leverage part of the engagement.
Find the waste in your AWS bill.
Free 30-minute call — I'll point to the biggest quick wins.
Book a callAll AWS DevOps services →