FinOps
How to investigate AWS waste without overstating savings
Turn a cost signal into a useful investigation: establish ownership, check usage and keep potential savings separate from proven results.
A large charge deserves attention. It does not, by itself, establish waste. A resource can be expensive because it supports valuable work; a small recurring charge can be avoidable. Start with a question that your team can investigate, rather than a savings number you cannot defend.
Start with the billing evidence
Choose a billing period and keep the original currency visible. Work down from service → region → resources or costs. Record which part of a charge can actually be attributed to a resource and which part remains shared or unallocated.
An inventory match is a lead. It is not proof that a particular resource incurred an entire service charge. Keep candidate associations separate from confirmed billing attribution.
Find the owner before proposing a change
Identify the team that understands the workload. Tags such as team=platform and environment=staging can help organize that conversation, but a tag alone cannot tell you whether a resource is safe to change.
Ask the owner about expected traffic, batch windows, recovery requirements and dependencies. A quiet observation window can miss a monthly job or a standby role.
Write down what is still unknown
An investigation should make missing evidence easy to see:
| Question | Evidence to collect |
|---|---|
| What is being charged? | Billing period, service, region and original currency |
| Who can assess the workload? | Owner and relevant key/value tags |
| Is the observed usage representative? | Utilization history and workload schedule |
| What would change? | Proposed configuration and dependencies |
| What costs would remain? | Retained storage, commitments and other applicable charges |
Until these inputs exist, potential savings are to be quantified. Missing data includes the attributable baseline cost, the proposed configuration's cost, the evaluation period and any implementation or retained costs. Do not present the current bill as guaranteed savings.
Estimate one change at a time
For a defined comparison period and currency, a useful starting formula is:
Potential net savings = attributable baseline cost
− estimated cost after the change
− additional costs in the same period
Record the source of each input and the assumptions about demand, pricing and commitments. Distinguish recurring costs from one-time costs. If two proposals affect the same charge, compare them as alternatives or model their combined effect; do not add their independent estimates.
Verify the result after implementation
Preserve the baseline before making a change. Afterwards, compare observed costs over aligned periods and review workload volume and service health. A lower bill may reflect lower demand or an unrelated change. It does not automatically prove the action caused the difference.
Keep the estimate, the implemented decision and the observed result as separate records. This makes a review useful even when the original hypothesis turns out to be wrong.
Bring the evidence into one conversation
Explore CloudYield to see how cost investigation and decision records fit together. Continue with the deployment review checklist when a release is the event you need to investigate.
