How we find waste in an AWS account, and what to do about it.
A plain walk-through of the problem types we look for, how we identify each one, the changes that usually save money, and the order to make them in. It follows one simulated company from first look to verified result.
Six kinds of problem show up in almost every account
They overlap, and one resource can fall into more than one. The report sorts each finding into one of these groups so the fix is clear.
Stale resources
Things nobody uses anymore but still get billed: old snapshots, unattached volumes, unused IPs, empty load balancers.
Non-required capacity
Resources that run more than the team needs: development systems left on at night, machines larger than their load, duplicate environments.
Security gaps
Open ports, unpatched hosts, outdated container images, and public storage that should be private.
Broken logic
Scheduled jobs and policies that look healthy but do not do what they should: failing silently, or contradicting each other.
Unexpected exposure
Services, buckets or databases reachable from places they should not be, which is both a security and a cost risk.
Over-provisioning
Capacity set for a peak that happens rarely, so most of the time the bill pays for empty machines.
From raw account data to a finding
We start with read-only data. Each source answers one question, and a finding is only written up when two or more sources agree.
One company, followed from start to finish
The company below is simulated. Its name, workloads and numbers are invented to show the method. They are not a customer and not a promise of any result.
Simulated company: a 40-person software team
One AWS account. A Kubernetes cluster for production, a development database, block storage, a NAT gateway, and object storage.
Where the case money went, before and after
After the approved changes, the case bill runs at a lower rate. Grey is the baseline; blue is the run rate after the changes. Values are invented for teaching.
NAT, S3, transfer, IPs
Three findings from the case, and the math behind each
Each saving is a formula you can apply to your own account. The numbers are the case's invented values.
The development database runs all day and night
What we saw: the instance is busy about 10 hours on weekdays and almost idle at weekends. Connection logs confirm no one uses it overnight.
How we checked: 60 days of connection and CPU metrics, plus the team's stated working hours.
Snapshots and volumes nobody owns
What we saw: 64 snapshots older than 90 days and 18 volumes not attached to anything. None carry an owner tag.
How we checked: the inventory showed no attachments; the snapshot dates were past the team's own retention rule.
An admin port open to the internet
What we saw: a management port reachable from every address on three hosts that only staff need.
How we checked: the security rules and the hosts' login logs. The risk is high even though the cost impact is small.
How the case's findings were grouped
The same six groups as above, with invented counts for the case.
Largest groups in the case
Counts are invented and shown for teaching only.
The order we change things in
Lowest risk first, and every change is approved and reversible before it is made.
Confirm owner
Find who uses each resource. No owner, no change.
Confirm usage
Check metrics over a full business cycle, not one quiet week.
Test in non-production
Apply the change to a copy first and watch it for a week.
Approve the change
Named approval, change ticket, and an agreed maintenance window.
Make it reversible
Backup, restore test and written rollback steps before the change.
Verify the bill
Compare a normalized cost against a comparable period, after the change.
Habits that keep waste from coming back
These are the practices that, when followed, stop most of the problem types above from returning.
- Tag every resource with an owner and an environment, and reject untagged resources at creation.
- Set retention rules for snapshots, logs and backups, and enforce them automatically.
- Schedule non-production to run only in the hours the team works.
- Right-size on evidence: change capacity only after 30 days or more of usage data.
- Restrict access by default: no public ports or buckets unless a named owner approves.
- Patch on a fixed cadence and rebuild base images regularly, not only after an incident.
- Make scheduled jobs fail loudly, with alerts when a job produces no output.
- Review the bill monthly, with a named person and a short list of changes.
What each part of the report answers
The report is written so your team can act on it, and finance can check the numbers.
How savings are estimated
For any account, the report uses the same steps: confirm the cost of each resource from billing data, confirm how much of that cost is unused or avoidable, then apply the change only after approval. The result is an estimate for your account, shown with its assumptions. It is not a promise.
See which of these apply to your account
Start with a free 20-minute call. We will tell you which of these problem types we would check first for your setup.