The $18,000 Monthly Bill Nobody Noticed: A Cloud Waste Case Study

In June 2026, a read-only scan of a single AWS account produced findings that are easy to summarize but hard to internalize: 668 EBS snapshots older than 90 days, the oldest nearly six years old; ten unattached storage volumes with an average age of 611 days; thirteen running EC2 servers averaging less than four percent CPU utilization over a full week. Total identifiable waste: just over $18,000 per month.

The organization didn’t know. Not because they weren’t paying attention to cloud costs — they had a monthly review process, a cloud infrastructure team, and real budget accountability. The waste had simply grown slowly enough, and in the right places, to stay invisible inside a larger bill.

This is how most cloud waste works. It doesn’t announce itself. It accumulates.

The snapshot problem: waste at scale

The headline finding was the snapshots. EBS snapshots are point-in-time copies of block storage volumes — the AWS equivalent of a backup. They’re cheap to create (a few API calls), cheap to store when small ($0.05 per GB per month), and almost entirely invisible until they’ve been accumulating for years.

In this account, 668 snapshots had passed the 90-day mark with no lifecycle policy to expire them. The oldest dated to 2020. The total storage: 337 terabytes. At $0.05 per GB per month, that’s $16,871 in monthly snapshot costs alone.

The math compounds quickly. A snapshot created in 2020 has been billed every month since. An organization that runs automated daily snapshots without a retention policy is creating one new permanent cost obligation per day, per volume.

The most dangerous thing about snapshot costs is that they grow slowly. An account spending $500/month on snapshots in year one will spend $1,500 in year two if the growth rate continues. Neither number crosses a threshold that triggers an alert. By year five, the $16,900 monthly line item feels like it was always there.

The unattached volume problem: orphans from departed workloads

Ten EBS volumes sat in the account unattached to any instance, with an average age of 611 days — nearly twenty months. These are not volumes that were recently detached. They are the remains of workloads that were shut down, migrated, or decommissioned, where someone deleted the EC2 instance but not the storage underneath it.

When an EC2 instance is terminated in the AWS console, the root volume is typically deleted automatically. But additional data volumes — the ones attached to /dev/sdf or /dev/sdg — are often configured to persist on termination, a default designed to protect against accidental data loss. Without a systematic decommissioning checklist, these volumes survive indefinitely.

The 10 volumes totaled 4,343 GB of storage, representing $342 per month in charges for data that may not be needed by anyone, used by any system, or even known to exist by the current team.

The idle server problem: the team changed

Thirteen running servers showed less than five percent average CPU utilization over a full week. Several showed less than one percent. These are not servers experiencing an unusually quiet period — they are servers that have outlived the workloads they were built to run.

The pattern is consistent across organizations: a workload is deployed, the team that built it moves on, the next team doesn’t know what the server is for, and nobody feels empowered to shut it down because “it might be doing something important.” The instance runs, month after month, because the cost of a wrong decision feels higher than the cost of doing nothing.

At $17 to $126 per server per month, each individual instance doesn’t look significant. The thirteen together represent $870 in monthly waste. More importantly, they represent a governance failure: infrastructure with no current owner, no documented purpose, and no review process.

How five years of waste goes unnoticed

The question that every finance leader asks when presented with findings like these is: how did nobody see this?

The answer is not negligence. It’s a combination of structural factors that are common across AWS environments of any meaningful size.

Slow accumulation doesn’t trigger alerts. AWS Cost Anomaly Detection identifies spikes — sudden deviations from baseline. It’s designed for the “costs doubled overnight” scenario. It is not designed to catch the scenario where costs grow at one to two percent per month over five years. There is no alert for “your snapshot bill has grown from $400 to $16,900 since 2020,” because the baseline grows alongside the spend.

Volume-level detail is buried. Monthly cloud bill reviews typically look at costs by service category — EC2, S3, EBS — not at the resource level. An account with $25,000 in total monthly spend will show “EBS: $17,200” as a line item. That number is large, but not anomalous relative to a $25,000 total. The 668 individual snapshots that compose it are not visible in a service-level review.

Team turnover breaks ownership. The snapshots created in 2020 were created by people who may no longer be at the organization. The context about which snapshots are needed for recovery, which volumes they represent, and which workloads depend on them left when those engineers left. The remaining team doesn’t know whether deleting a five-year-old snapshot is safe.

There is no scheduled review of old resources. Most organizations have a process for reviewing current cloud costs. Very few have a process that specifically asks: what are our oldest resources, and why do they still exist? Age-based reviews are a different query than cost-based reviews, and they catch a different category of waste.

Untagged resources have no owner to notify. Many of the idle and orphaned resources in this account lacked ownership tags. Without a team, owner, or cost-center tag, there is no one to send the finding to. The resource exists in an accountability vacuum.

What a lifecycle policy would have prevented

The single highest-impact control gap was the absence of EBS snapshot lifecycle rules. AWS Data Lifecycle Manager (DLM) allows organizations to define retention policies: keep the last 14 daily snapshots, keep 12 monthly snapshots, delete everything older than 365 days. These policies are free, take minutes to configure, and would have prevented the majority of the $16,900/month finding.

A reasonable snapshot retention policy for most production workloads:

• Daily snapshots retained for 14 days
• Weekly snapshots retained for 8 weeks
• Monthly snapshots retained for 12 months
• Annual snapshots retained for 7 years (for compliance, if required)

Under this policy, the 668 accumulated snapshots would not exist. The maximum snapshot count would be bounded by the retention rules.

The broader pattern

This case is not unusual. The specific numbers — 668 snapshots, 337 terabytes, five years — are larger than typical, but the pattern repeats across virtually every AWS account that has been running for more than two years without a structured resource lifecycle practice.

The insight from this scan is not that this organization was poorly managed. It’s that cloud resources have no natural expiration date, and human attention is finite. Without automated controls and periodic resource-level audits, resources accumulate. The waste is the default outcome, not the exception.

The organizations that avoid this pattern do three things: they enforce lifecycle policies at account level before workloads are deployed, they run regular age-based resource reviews that ask specifically about old resources rather than just expensive ones, and they require ownership tags so that every finding has a clear recipient.

---

CostDefender connected to this account with a read-only cross-account role and surfaced these findings in a single scan — without requiring credentials, write access, or any changes to the customer’s infrastructure. Request early access at CostDefender.io.