Remove long-stopped EC2 instances

Stopping an EC2 instance halts compute charges but does not stop the EBS volume billing attached to it. A 250 GB gp3 volume runs roughly $20/month whether the instance it belongs to is on or off. Accounts that accumulate dozens of stopped instances — a common pattern in teams with active development cycles — are often carrying hundreds of dollars a month in volume costs with zero workload behind them. Security Hub EC2.4 surfaces this as a Medium-severity finding after 30 days of stoppage.

The 30-day threshold is the FinOps signal. An instance stopped for more than a month has almost certainly been abandoned rather than deliberately preserved. Every day past that threshold is unnecessary spend on EBS storage, plus the accumulation of stale AMIs, orphaned snapshots, and network interfaces that inflate the inventory and the bill further.

From a chargeback standpoint, long-stopped instances are difficult to allocate — they often outlive the project or person who created them, carry incomplete tags, and sit in accounts with no obvious cost owner. Making EC2.4 a tracked metric gives FinOps practitioners a concrete lever: identify, classify, snapshot-then-terminate, and prevent recurrence. The payback is immediate (EBS billing stops at termination) and the audit trail is clean.

Dana is the FinOps lead for a SaaS company. At the monthly cloud cost review, she notices a persistent EBS line item that hasn't tracked with any workload change. She pulls the EC2.4 findings: 31 instances stopped for more than 30 days across two accounts. The stopped compute costs nothing — but the attached EBS volumes are billing at roughly $18–22 per volume per month. Across 31 instances, many with multiple volumes, the total is over $900/month with zero output.

Dana doesn't treat it as a bulk delete. She asks engineering to tag each instance against a decision: intentional hold with an owner and expiry date, or retire. The goal is a chargeback-ready inventory: every retained instance has a cost centre, an owner, and an explicit expiry. Every retired instance has a snapshot as the audit trail and a termination record so the EBS billing drop is traceable to a decision.

Her takeaway for the next budget review is concrete: terminating the abandoned instances saves approximately $800/month in EBS storage immediately, with the remaining $100/month allocated to two documented holds with expiry dates. The EC2.4 finding count dropped from 31 to 2 — both suppressed with recorded justifications. The saving is realized in the next billing cycle and is easy to show in the unit economics report.

The cost impact of long-stopped instances is almost entirely EBS storage. A gp3 volume bills at $0.08/GB/month regardless of whether its attached instance is running. A 250 GB data volume stopped for six months has cost $120 in storage with zero workload behind it. Multiply that across 30–50 stopped instances — the typical count in an active engineering org — and the monthly waste figure is measurable and eliminable without affecting any running system.

The FinOps insight is that this waste is invisible in standard cost dashboards because it sits in EBS storage spend rather than EC2 compute spend. Teams that monitor "are my EC2 costs down?" after a sprint ends miss the EBS tail entirely. EC2.4 is the signal that makes it visible: each finding represents at least one volume billing with no owner consuming it.

There is also an AMI and snapshot component. Instances stopped for months often have derived AMIs and manual snapshots that are never cleaned up. Those aren't free — snapshots bill at $0.05/GB/month. A 100 GB root volume snapshot left indefinitely costs $5/month forever. Multiply by the number of AMIs and snapshots in a typical account and the number adds up. The safe retire flow — snapshot before terminating, then set a lifecycle policy to expire that snapshot in 90 days — converts an indefinite cost into a bounded one.

From a chargeback standpoint, abandoned instances are the hardest category to allocate: they often lack owner tags, their projects are closed, and their cost centre is ambiguous. Every EC2.4 finding that goes unaddressed is a month of unallocated spend. Clearing the queue and tagging the survivors is the fastest path to clean cost allocation in the EC2 category.

When an EC2 instance is stopped rather than terminated, it sits in your cloud account indefinitely — frozen at the state it was in when someone last touched it. AWS Security Hub flags instances that have been stopped for more than 30 days under control EC2.4. The typical finding is not a one-off edge case; it is a symptom of operational hygiene at scale. Most accounts accumulate these across project endings, team changes, and sprint leftovers.

The governance concern is that a stopped instance is not inert. Its IAM credentials, OS, and packages age without patching. Cloud orchestration tooling can restart it without a human decision. And because its cost sits in EBS storage rather than visible compute spend, it tends to be overlooked in budget reviews. EC2.4 forces an active decision — retire it with an audit trail, or explicitly record that it is being preserved and why.

The right end state is a policy, not a cleanup campaign: instances that are not actively used are terminated on a defined schedule, with snapshots taken for recoverability. That makes every resource in the account an intentional, owned asset rather than an inherited liability.

At one company, the VP of Engineering used to get a quarterly compliance report showing a recurring cluster of EC2.4 findings that never fully cleared. The pattern was always the same: engineers stopped instances at the end of projects and moved on, and nobody made the termination decision because it felt risky — what if someone needed the data back?

After establishing a lifecycle policy — every instance gets an ExpiresAt tag on creation, automated snapshots run before the expiry date, and termination fires automatically — the pattern broke. The EC2.4 queue no longer refills. The few instances that are intentionally held carry an owner's name, a cost-centre tag, and a reviewed expiry date. The ones with no owner and no tag are retired within 72 hours of the policy running.

The VP's question at the quarterly review changed from 'why do we keep having this finding?' to 'how many instances did the policy retire this quarter and how much did we recover?' That's the right question. It means the organisation is governed by a policy, not by individual decisions that accumulate into technical debt.

Long-stopped instances are a proxy for organisational hygiene. In a well-run engineering culture, resources are owned by named teams, have explicit lifecycles, and are terminated when their purpose ends. When EC2.4 shows dozens of instances stopped for months or years, it is evidence that the lifecycle discipline is missing — resources are created on demand and abandoned when the work shifts, with no cleanup norm.

The direct operational risk is the accidental restart. AWS orchestration tools — Auto Scaling Groups, recovery scripts, CI/CD pipelines with stale configuration — can restart a stopped instance without a human making that decision. An instance that has been stopped for 14 months and gets restarted is running an OS and application stack that have missed hundreds of security patches. It joins your production VPC and starts answering traffic before any monitoring system flags it as anomalous. EC2.4 findings are not theoretical; they are a list of assets that could become that unpatched ghost.

The compliance dimension is also direct. EC2.4 is a recurring Security Hub finding. When the same findings appear across multiple quarterly reviews without remediation, auditors treat it as evidence of weak operational control — not just on EC2 lifecycle, but as a proxy for the overall maturity of the cloud governance programme. A finding that has been open for 18 months is a harder conversation than a policy that retires instances within 30 days automatically.