When a client asks us to look at their AWS bill, they usually expect the answer to be 'buy more Reserved Instances'. It rarely is. Commitment coverage is a financial lever applied after the structural work, and applying it first locks in the cost of an architecture you were about to change.
Why the obvious answer is the wrong one first
Savings Plans and Reserved Instances reduce the unit price of consumption you have already decided to have. They do nothing about consumption that should not exist. Buy commitments before the structural work and you have locked in a discount on waste for one to three years.
So we start structural. In practice, four categories account for most of what can be removed.
1. Data transfer
The most consistently underestimated line on Australian bills, and the hardest to see because it is spread across services rather than appearing as one item. Three patterns dominate:
- Cross-AZ traffic between application tiers that could be zone-aware but are not
- NAT Gateway processing charges for traffic that should use a VPC endpoint
- Egress to the internet for data that could be served from CloudFront
The NAT Gateway one is particularly common. Every S3, DynamoDB or ECR call routed through a NAT Gateway instead of a VPC endpoint pays a processing charge per gigabyte for traffic that never needed to leave the AWS network.
Enable VPC Flow Logs, query them in Athena grouped by source and destination availability zone, and separately pull NAT Gateway processed bytes from CloudWatch. Those two numbers give you the addressable amount before you change anything.
2. Non-production running 168 hours a week
Development, test, UAT and staging environments used during business hours and billed around the clock. A five-day, ten-hour usage pattern is fifty hours out of one hundred and sixty-eight — meaning roughly seventy per cent of non-production compute spend is idle.
The reason it persists is rarely ignorance. It is that someone once shut down an environment at 6pm and broke an overnight test run, and nobody wanted to be that person again. The fix is a scheduler with an opt-out tag and a clear owner, not a policy announcement.
Non-production scheduling is the highest-return FinOps work available and the most likely to be blocked by one bad memory.
3. Databases sized for a load test nobody remembers
RDS and Aurora instances provisioned during a performance test two years ago, never revisited because resizing a database feels risky and nobody owns the decision. We routinely find production databases running at under ten per cent sustained CPU on instance classes chosen for a peak that never materialised.
The genuine constraints are connection limits, memory-resident working set and IOPS — not CPU. Sizing on CPU alone is what produced the oversizing in the first place, so any rightsizing recommendation should show all four.
| Signal | What it usually means | Action |
|---|---|---|
| Sustained CPU < 15% | Oversized instance class | Step down one class, observe two weeks |
| Freeable memory stable and high | Working set fits comfortably | Memory-optimised class not required |
| Burst balance never depleted | gp2 volume oversized for IOPS | Move to gp3 with provisioned IOPS |
| Connections near limit | Genuine constraint | Add connection pooling before resizing |
Observe over a period that includes month-end and any known peak.
4. Storage nobody is watching
Orphaned EBS snapshots, unattached volumes, old AMIs and S3 buckets with no lifecycle policy. Individually trivial, collectively significant — and they grow monotonically because nothing in the system ever deletes them.
Snapshots are the worst offender because backup automation creates them faithfully and retention policies are frequently set once and never reviewed. We have found accounts with seven years of daily snapshots for instances terminated in 2021.
What a week of this actually looks like
- Day 1–2: Cost and Usage Report into Athena, tag coverage assessment, spend attributed by team and environment
- Day 3: Data transfer analysis from VPC Flow Logs and NAT Gateway metrics
- Day 4: Compute and database rightsizing candidates with the four signals above
- Day 5: Storage sweep, then a ranked list by annualised saving against implementation effort
The output is not a list of recommendations. It is a backlog with owners, because the difference between a cost assessment and cost reduction is entirely in who picks up the tickets afterwards.
Savings that survive twelve months come from showback and anomaly alerting routed to the team that caused the change. Without that, spend returns to trend within two quarters — we have watched it happen.
Want the addressable number for your account?
A one-week cost assessment gives you the four categories quantified, ranked by annualised saving against effort.