The first FinOps mistake is asking “how do I cut my AWS bill?” The more useful question is “which part of this growth is buying product, and which part is buying mess?”
The bill doesn't tell the whole story
A more expensive month can mean more users, a migration or a successful campaign. It can also mean orphaned volumes, logs with no retention policy or a staging environment left running all weekend. The total doesn't tell you which is which.
If spend grows faster than the usage that justifies it, run an ownership review before you buy another tool.
The four signals I'd check first
EC2 with sustained low CPU, unattached EBS volumes, unused public IPs and clusters that outlive business hours.
A Savings Plan isn't savings if it leaves you overprovisioned. Cross-check utilization, commitment and expected growth.
NAT Gateway, RDS, data transfer and logs need a product explanation, not just a service label.
If the team that gets the alert can't change the cause, the alert is just operational noise.
The 30-minute ritual
Account, environment, service and owner. Don't optimize a total you can't explain.
Pick the three actions with the biggest savings and the lowest product risk.
Review the result the following month and document what changed.
The goal isn't the lowest possible bill. It's making sure every dollar of cloud spend has an operational reason someone can defend.
Want to size the range before opening Cost Explorer? Try the savings opportunity calculator