Unattached EBS volumes are one of the most common forms of AWS waste. They survive instance termination, keep accruing storage charges, and are easy to ignore because they do not break anything.
Most tools stop at visibility. OpsCurb treats findings like work: identify the resource, assign the owner, and keep follow-through visible until it closes.
Start with the Core Scan Role, add optional capabilities later, and review the public permission mapping before you connect.
Frame the issue in monthly and annual impact so the cleanup gets prioritized and tracked.
Use evidence, guardrails, and handoff language instead of raw AWS screenshots alone.
EBS volumes persist independently from EC2 instances. If an instance is terminated without deleting the disk, that volume continues billing until someone explicitly snapshots or removes it.
This is common after autoscaling changes, temporary environments, one-off incident response instances, and manual console cleanup.
Look for volumes in the available state and audit them region by region. A cross-region review matters because teams often remember their primary region and forget the rest.
Attachment status should be combined with volume age, Name tag, and any snapshot dependency before deciding what is safe to remove.
A single unattached volume might look small in isolation, but several gp2 or gp3 disks across multiple accounts create real recurring waste. Teams usually discover a cluster of forgotten disks rather than one giant offender.
Because storage spend continues quietly, these findings tend to linger for long periods and become easy annual savings wins once surfaced.
The safe workflow is to verify the volume is truly unused, snapshot it when the recovery value matters, and then delete it. For ambiguous disks, capture the evidence and hand it to the last known owner.
Do not treat every unattached volume as instantly disposable. Incident recovery assets and recent migration disks sometimes sit detached for a reason.
OpsCurb flags unattached EBS volumes as a high-confidence waste category, estimates the ongoing storage impact, and keeps the cleanup item visible until someone closes it.
That is useful when your team can fix the issue quickly once found, but does not have time to run manual regional audits every month.
These are the friction points teams usually need to clear before they turn a likely savings opportunity into a real cleanup task.
No. They are often safe candidates, but some are retained for rollback or incident recovery. Verify ownership and snapshot posture first.
Yes. Storage charges continue whether the volume is attached or not.
Because they do not create visible failures. They sit quietly in the account until someone audits attachment state and storage cost.
Move from research to action with a tutorial, a sample brief, a live review, or an ongoing plan.
Related guide: audit EBS waste across regions
Use a repeatable regional checklist and CLI workflow.
Open pageCompare OpsCurb vs CloudZero
See how broader cloud cost intelligence differs from owner-ready AWS cleanup findings.
Open pageSee the sample first-scan report
Preview how OpsCurb summarizes storage findings for leadership.
Open pageSee the product tour
See how storage cleanup findings become an owner-ready accountability queue.
Open page