Practical guides for diagnosing AWS waste, cutting your bill, and getting more from Parsivex scans.
AWS bills rarely go up because of one big decision. They go up a few dollars at a time: a test instance nobody turned off, a NAT Gateway routing traffic that could have gone through a VPC endpoint, snapshots of volumes that were deleted two years ago, a Redis cluster serving nothing. Individually each one is too small to chase. Together they are usually a double-digit percentage of the bill.
The posts above work through those charges one at a time. Each one takes a question an engineer actually types into a search box — why is this service so expensive, how do I tell if this instance is idle, what does an unattached volume really cost — and answers it with the diagnosis first: which console screen or CLI command shows you the truth, which CloudWatch metrics separate genuinely idle from merely quiet, and what the resource costs while you decide. The fix comes after the diagnosis, along with the cases where the obvious fix is the wrong one.
They assume you have access to your own AWS account and are comfortable in the console or the CLI, and they are written to be useful whether or not you ever run a Parsivex scan; where our product would shorten the work, we say so once and move on. For product documentation — how scans work, what each finding type means, how alerts and remediation scripts behave — the help centre is the better starting point.