Clean up stopped EC2 instances with attached EBS

When engineers say an EC2 instance is "stopped," most people hear "switched off, no longer costing money." That isn't how the bill works. AWS charges compute and storage on two separate meters — only the compute meter stops. The disk attached to the instance keeps billing every hour at the storage rate, around $0.08 per GB per month, until somebody actively deletes it. A team can stop a workload to save money and still see most of the cost continue showing up on the invoice.

This finding flags instances that have been parked in the stopped state but still hold their disks. In practice these are forgotten test boxes, old experiments, machines belonging to people who have changed teams or left the company, and projects that were paused "for a sprint" two years ago. Each one is a small fixed monthly charge — a 500 GB disk is roughly $40 a month — that recurs forever on no business activity. Across a few hundred of them, the number lands in five figures per month with nothing to show on the other side of the ledger.

From a budgeting and forecasting standpoint, this category is unhelpful in two ways. The cost is unpredictable on the way up — anyone can spin a workload and "pause" it — and sticky on the way down because nobody wants to be the person who deleted the disk that turned out to matter. The right framing is that stopped-with-storage is a governance and ownership signal, not just a cost signal: it means a resource has no clear owner accountable for the spend, and the longer it sits, the harder it becomes to attribute or charge back to a business unit.

Sam is the finance partner embedded with the cloud platform team at a mid-sized SaaS company. At the monthly cost review, the engineering lead is presenting a flat compute line and Sam asks one question that's now standard on the agenda: "How many stopped instances are still holding storage, and what's that costing us a month?" The number on the dashboard is $340 across 23 instances — small in absolute terms, but it's been roughly $340 every month for six months, so the cumulative is closer to $2,000.

The conversation that follows isn't technical. Sam doesn't ask which volume types, which regions, which AZs. She asks three things: who owns each one, how old it is, and whether anyone has touched it in the last 90 days. The engineering lead pulls up the report — every instance has an owner tag, the oldest is from February, no one has restarted any of them since. That's enough to act. Engineering commits to a clean-up sprint with a one-week deadline; Sam adds a recurring line to the next finance pack so the number can't drift back up unnoticed.

Two months later the same dashboard shows $40. Sam knows that's the right floor — a handful of genuinely paused workloads with sign-off — and she also knows that if the number creeps back above $200, ownership tagging is slipping somewhere and that's the conversation, not the dollar amount. The dollar amount is a leading indicator of a governance problem; the cleanup itself is almost incidental.

The direct line-item impact is small per resource and material in aggregate. A typical environment carries somewhere between a few hundred and a few thousand dollars a month in this category — call it 0.5–2% of total cloud spend. That's not enough to move quarterly numbers on its own, but it's enough that every month it lands in "unexplained variance" buckets when budgets are tight, and finance ends up chasing it across teams instead of focusing on the bigger commitments.

The more important impact is on commitment economics. If you're carrying Reserved Instances or Savings Plans against an EC2 family, stopping the workload doesn't release the commitment — you keep paying for the reserved capacity whether anything is using it or not. Storage attached to those same stopped instances continues to bill on the regular meter on top. So the very pattern that engineers reach for when "we need to save money on this workload for a few weeks" actually does nothing on the compute side and quietly accrues on the storage side. The commitment-utilisation number on your monthly report is the place this shows up; if it's below ~95%, this category is one of the first contributors to check.

The third impact is on chargeback credibility. When this category is large and untagged, it's the line item that breaks the chargeback model: the cost is real but it can't be assigned to a business unit because the resource has no clear owner. Every untagged dollar here is a dollar that has to be absorbed centrally or argued about in meetings. Cleaning these up is less about the dollar saving and more about making the chargeback report defensible.

Finally, it's a leading indicator. Sustained growth in this category month over month almost always means tagging policies are slipping or lifecycle conventions aren't being followed — both of which predict bigger waste categories (idle compute, oversized databases, unused load balancers) trending in the same direction six months later. Watch it as a signal, not a target.

"Stopped" in cloud doesn't mean "off." When a workload is paused, the compute charge ends but the storage attached to it keeps billing month after month. The cumulative effect, at scale, is a recurring drag on the cloud bill from infrastructure the business has already stopped using.

This is fundamentally a hygiene and accountability issue. Every flagged resource represents money being spent on something with no clear owner and no active value. Cleaning them up is low-risk, immediate-saving work, and the more important outcome is the discipline it establishes: every running resource has an owner, a purpose, and an expiry date — not just a creation date.

At one company, the quarterly cloud-cost review used to open with a slide that just said "$340/month of stopped-but-billing infrastructure across 23 resources." Small number, but it sat there every quarter, sometimes growing, never shrinking. The exec sponsor stopped asking about the dollar amount and started asking about the shape: "Why do we have any of these? Who is supposed to own this resource? Why is there no expiry date?"

Within two quarters the slide changed. The number was no longer the headline; the headline was "every active workload has a named owner and a documented review date." The $340 dropped to a residual $40 of intentionally-paused systems with sign-off, and the cleanup never had to be discussed again. The exec hadn't asked engineering to chase the dollars — she'd asked them to fix the absence of ownership the dollars were exposing.

That's the right outcome state for this category. "Zero stopped-with-storage" is the wrong goal; "every resource has an owner and a date" is the right one. The cost report stops being an action item and becomes a confidence signal.

The dollar amount in this category is usually small. The reason it's tracked is what its size and trend say about the discipline underneath. A small, flat number means the org has working ownership conventions and a normal cleanup cadence. A growing or large number means the inverse: resources are being created without clear owners or expiry, no one is closing the loop, and the same pattern almost certainly applies to bigger spend categories that won't show up on the dashboard as cleanly.

There's a second-order risk too. Forgotten infrastructure with stale ownership shows up as audit and security findings just as readily as it shows up as cost — old data sitting on disks attached to instances that nobody can confidently say belongs to anyone. So this category sits at the intersection of cost, security posture, and operational hygiene. Most CFOs care about the first, most CIOs about the second; both should care about the underlying pattern.