Your estate
| Where it leaks | Per month | Risk |
|---|
Get the itemised breakdown
Every figure above with the assumption behind it, the formula used, and a prioritised action list — as a file you can take to a planning meeting.
What this is. A model, not an audit. It applies published optimisation rates to the shape of estate you described — it has not seen your bill. Treat the output as a hypothesis worth testing against Cost Explorer and Compute Optimizer, not as a number to put in a budget. Every rate it uses is shown in the breakdown so you can argue with it.
How this calculator works
Most cost calculators produce a number and hide the reasoning, which makes the number useless the moment somebody senior asks where it came from. This one shows every rate it applies, and lets you change the inputs that drive them.
It estimates six categories of waste. Each has a different recovery rate, a different level of risk, and — importantly — a different amount of political difficulty attached to realising it.
The categories are applied in sequence, not in parallel. That matters more than it sounds. Most calculators compute each category against your whole bill and add them up, which double-counts: an instance you rightsize is no longer an instance you need a Savings Plan for, and a volume you delete is not a volume you tier. Here, each step runs against what the previous step left behind — which is also the order you would actually do the work.
| # | Category | Applied to | Why that rate |
|---|---|---|---|
| 1 | Idle and orphaned | Total spend × 4% | Unattached volumes, idle load balancers, unreleased elastic IPs, snapshots of instances that no longer exist. Deliberately conservative, and it comes first because deleting something removes it from every later calculation. |
| 2 | Oversized compute | Remaining compute × 5–18%, by rightsizing history | An estate that has never had a rightsizing pass carries materially more headroom than one reviewed in the last six months. |
| 3 | Non-prod out of hours | Remaining non-prod compute × 60% | A 10-hour day over five days leaves roughly 70% of the week idle; 60% allows for what has to stay up. Applied to compute only — storage does not stop costing when you stop the instance. |
| 4 | Commitment gap | Compute still running × shortfall against 70% coverage × 25% | 70% is a common target that leaves room for workload change; 25% approximates a typical Savings Plan discount. Comes last because you should not commit to capacity you are about to switch off. |
| 5 | Storage tiering | Remaining storage × 15% | Data sitting on Standard that lifecycle rules would move to Infrequent Access or Glacier. |
| 6 | Data transfer and NAT | Remaining transfer × 20% | Cross-AZ chatter and NAT gateway charges that architecture changes remove. The hardest category to realise. |
Step 4 is the one people get wrong most expensively in real life, not just in calculators. Buying a three-year commitment against an estate you are about to rightsize and schedule locks you into capacity you no longer need.
Tagging coverage does not change the estimate — it changes the range. With poor tagging the band widens, because you cannot attribute what you cannot see, and an estimate you cannot attribute is an estimate you cannot act on.
What to do first
The categories are not equal. Two things separate them: how much production risk realising them carries, and how much of someone else’s cooperation you need.
Start with the safe levers. Commitment coverage, idle cleanup, non-production scheduling and storage tiering carry almost no risk to running workloads, and three of the four need nobody’s permission but yours. They are also where most of the money usually is.
Then the ones needing care. Rightsizing changes the resources a running service has, so it needs the owning team involved and a maintenance window. Data transfer and NAT savings usually need an architecture change, which means a project rather than a task.
Doing it in that order is not just about safety. It is about credibility: a FinOps programme that opens by asking engineers to resize production instances gets a different reception than one that arrives having already removed 4% of the bill without touching anything they own.
Verifying the estimate against your real bill
Four free checks, in the order that takes least time:
- Cost Explorer, grouped by service, last 90 days. Confirms the shares you entered above. If your compute share is wildly different from what you guessed, re-run the calculator.
- Compute Optimizer. Gives real rightsizing recommendations from actual utilisation rather than a rate. Use the 93-day lookback if you have it — two weeks of data will recommend downsizing something that only gets busy at month end.
- Trusted Advisor, cost optimisation checks. Lists idle load balancers, unassociated elastic IPs and underutilised instances by name.
- Cost Explorer’s Savings Plans coverage report. Replaces the coverage figure you guessed with the real one, which is the single input this model is most sensitive to.
If the real numbers come in materially below the estimate, that is a good outcome — it means someone has already done this work. If they come in above, the gap is almost always the commitment line.
Questions about the calculator
How accurate is this AWS cost calculator?
It is a model applied to the estate shape you described, not an analysis of your bill. Treat the output as a hypothesis to test rather than a figure to forecast with. The breakdown shows every rate it used, so you can adjust any assumption you disagree with and see what it does to the total.
What counts as cloud waste?
Spend that could be removed without reducing what the estate delivers: resources nobody uses, compute provisioned larger than its workload needs, on-demand pricing for steady workloads that qualify for commitments, non-production environments running overnight, data on a storage tier more expensive than its access pattern requires, and avoidable data transfer.
How much do most AWS estates waste?
It varies enormously with maturity, which is why this tool asks about rightsizing history and commitment coverage rather than applying one industry figure. An estate that has never had a cost review and an estate with a mature FinOps practice are not the same problem, and a single percentage insults both.
Which savings are safe to act on immediately?
Commitment coverage, idle and orphaned resource cleanup, non-production scheduling, and storage lifecycle rules. None change the resources a running production workload has. Rightsizing and data transfer changes do, so they need the owning team and a window.
Do I need a FinOps tool to find this waste?
Not to start. Cost Explorer, Compute Optimizer, Trusted Advisor and Budgets are free and will surface a meaningful share of it. A tool becomes worth buying when you need allocation across shared resources, Kubernetes-level visibility, or the capacity to act on findings faster than your team can.
Does the calculator send my data anywhere?
The calculation runs entirely in your browser — nothing you type about your estate is transmitted. The breakdown is generated locally and downloads straight to your machine.
Where to go from here
Three places to go next:
Sources
- AWS Compute Optimizer — What is Compute Optimizer?, AWS documentation
- AWS Systems Manager — Using Systems Manager tools, AWS documentation
Finding the waste is the easy half
CloudOpsGPT turns findings into completed changes: it proposes an itemised plan, waits for your approval, executes inside your own AWS account through roles you connect, and logs every action.
No credit card required. Your trial clock starts when the Runtime connects.