Inside a Real $11,871/mo AWS Waste Scan

Most cost-optimization content shows you a screenshot of a dashboard and asks you to trust the number. So instead, here's an actual scan CloudWise runs internally as a demo profile — a mid-size SaaS company's AWS account, $28,500/mo in total spend, run through all 191 detectors. It came back with $11,871/mo in identified savings across 18 findings.

I want to walk through what's actually in that list, because the shape of it surprised me even after building the detectors.

Where the 18 findings live

Split by category, not dollar amount:

• Database — 9 findings. By far the largest bucket. A mix of idle RDS instances, an oversized analytics database running at 12% CPU, stale manual snapshots, and a cluster of ElastiCache-specific findings (idle replicas, an engine migration opportunity, a serverless-fit opportunity, and one very large data-tiering opportunity — more on that below).
• Compute — 2 findings. An idle bastion host nobody SSHs into anymore, and one oversized EC2 fleet running at 15% CPU.
• Storage — 2 findings. An unattached EBS volume left over from a migration, and a batch of aging EBS snapshots.
• Commitment Management — 2 findings. A Savings Plan expiring in 52 days, and a Convertible Reserved Instance sitting on previous-generation hardware with a free exchange available.
• Network — 2 findings. Two idle Global Accelerators — one genuinely idle, one just disabled but still billing.
• Purchase Optimization — 1 finding. Production RDS instances that have been running on-demand, 24/7, for 90+ days with no Reserved Instance covering them.

Nine of eighteen findings sitting in "Database" isn't a coincidence — it's the category where the widest range of waste patterns overlap: idle instances, oversized instances, stale snapshots, and now a whole sub-family of ElastiCache-specific checks (engine choice, replication topology, traffic shape, data tiering) that didn't exist as separate detectors a year ago.

The one number that matters most

Of the $11,871/mo total, one single finding accounts for 68% of it: $8,057/mo, from an ElastiCache data-tiering opportunity.

The cluster in question runs 4× cache.r6g.16xlarge nodes — memory-only, no local SSD — for 1,676 GiB of total cache capacity. ElastiCache's R6gd family adds local NVMe storage and tiers data between RAM and SSD automatically, based on access frequency. For a dataset where most of the data isn't accessed on every request (true of almost every real cache), that means the same effective capacity fits on far less hardware: 1× cache.r6gd.16xlarge instead of 4× cache.r6g.16xlarge.

That's not a "you forgot to delete something" finding. It's an architecture-level rightsizing call that requires reading how your own cache is actually used before you touch it — which is exactly why it's flagged as confidence: medium, not high, and comes with an explicit risk note: SSD-resident data has slightly higher latency, so it's a good fit only when a meaningful chunk of your data is cold.

What the next four biggest opportunities have in common

Set aside the $8,057/mo ElastiCache finding and look at what else shows up near the top of this scan: an expiring Savings Plan, an unpurchased Reserved Instance opportunity on production RDS, an oversized analytics database at 12% CPU, and an oversized EC2 fleet at 15% CPU.

None of those are "click delete." Every one of them is a standing decision that has to be made again, deliberately, on some recurring cadence:

• A Savings Plan doesn't renew itself — someone has to decide, before it lapses, whether the workload underneath it still looks the same.
• An RDS instance rightsized today can be wrong again in six months if the workload grows, shrinks, or changes shape.
• "Buy the Reserved Instance" is itself a bet on the next 12 months looking like the last 3 — which is exactly the kind of call CloudWise's Commitment Risk Score exists to check before you make it.

Compare that to the idle-resource findings in this same scan — the bastion host, the unattached EBS volume, the stale snapshots, the disabled accelerators. Those are real money too, and they're the easiest to fix: find it, delete it, done. But they're structurally small, because once you delete something, it stays deleted. It doesn't come back next quarter.

Rightsizing and commitment decisions aren't like that. The right instance size and the right commitment level are correct for right now — and they drift the moment your traffic pattern, team, or architecture changes, which for a growing company is constantly. That's the actual thesis worth taking from a scan like this: waste renews itself. The idle-resource sweep is a one-time cleanup. The rightsizing and commitment layer is a standing job, and it's where most of the money in this particular scan actually lives.

Why this matters for how you should read your scan

If you run a scan and the top finding is "delete this idle volume," fix it and move on — there's nothing recurring about it. But if your biggest findings look more like this account's — an oversized instance, an expiring commitment, a data-tiering opportunity that requires understanding your own traffic — treat that as a signal that the fix isn't a single action, it's a review cadence you don't currently have. That's a different kind of problem, and it's worth naming as one.

---

CloudWise is an AWS cost optimization tool for startups — 191 automated waste checks across 42 AWS services, read-only by design, starting at $19/month. Run a free scan at cloudcostwise.io.