Orphaned EBS volume

An unattached EBS volume still incurring storage charges.

Last updated August 12, 2026

What triggers this finding

An EBS volume in the **available** (unattached) state that has been unattached for more than 7 days.

Typical fix

Delete the volume if the data is no longer needed, or attach it to an instance. Paid plans include a delete-volume script with a snapshot warning.

Example savings

100% of volume storage charges — scales with volume size and type (e.g. $0.08–$0.125/GB-month for gp3).

See also: Severity and savings estimates for how Parsivex calculates figures on your report.

Provisioned capacity, not used capacity

EBS bills the size you asked for, not the bytes you wrote. A 500 GB volume holding 4 GB of data costs the same as one that is full, and — this is the part that surprises people — a volume in the available state costs exactly the same as one in in-use. Detaching a volume changes nothing on the invoice. There is no dormant tier and no idle discount; the only states that stop the meter are deleted and converted-to-snapshot.

Parsivex prices volumes from the us-east-1 per-GB-month rates: $0.10 for gp2, $0.08 for gp3, $0.125 for io1 and io2, $0.045 for st1, $0.025 for sc1, and $0.05 for the old standard magnetic type. Size multiplied by rate is both the monthly cost and the estimated saving, because deleting removes all of it.

For io1 and io2 that estimate is conservative. Those types bill provisioned IOPS as a separate line, and the finding does not include it, so an orphaned io2 volume with heavily provisioned IOPS costs more than the number shown and is worth more to remove.

One reporting detail catches people out: when a scan finds several orphaned volumes in a region, Parsivex reports them as a single rolled-up finding covering all of them, with the combined size and combined cost. Seeing one high-severity finding for twelve volumes is the intended behaviour, not a missed detection.

Listing unattached volumes

aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime,AvailabilityZone]' \
  --output table

Compare the output against the finding. Anything created within the last seven days will be missing from the finding but present here — the detector applies a seven-day age floor so that volumes in the middle of a migration are not flagged the moment they are detached.

Volumes attached to a stopped instance do not appear in either list. They stay in the in-use state and are never treated as orphaned, even though they are billing at full rate for a machine that is doing nothing. That cost belongs to the idle EC2 finding instead.

Detached on purpose

An available volume is unambiguous about its state and says nothing about intent. Several perfectly deliberate situations produce one:

  • Forensic holds. A volume detached from a compromised or crashed instance and preserved for investigation. Deleting it destroys evidence.
  • Migrations in flight. Data copied from an old instance and waiting to be attached to its replacement, where the seven-day floor has already elapsed because the cutover slipped.
  • Restore verification. A volume restored from a snapshot and kept detached until someone confirms the data is intact.
  • Multi-Attach volumes between consumers. An io1 or io2 volume configured for Multi-Attach appears available in the window where no instance holds it.
  • Licensed or pre-seeded disks. Volumes built once with reference data and attached to short-lived instances on demand.

The tell is almost always tags and creation time. A volume with no Name, no owner tag, and a creation date measured in months is unlikely to be any of the above.

Deleting, or the cheaper middle step

delete-volume is immediate and irreversible. There is no recycle bin, no retention window, and no undo — once the call returns, the data is gone unless a snapshot of it exists somewhere. Take the snapshot first if there is any doubt at all.

Snapshotting is also the compromise worth knowing about, because it is usually cheaper than the volume it replaces. Snapshot storage bills at $0.05 per GB-month and only for the blocks actually written, while the volume bills at $0.08 to $0.125 per GB-month for its full provisioned size. Converting a mostly-empty 500 GB gp3 volume to a snapshot and deleting the volume can cut that line by an order of magnitude while keeping the data recoverable. The trade is time: restoring a volume from a snapshot takes minutes and produces a new volume ID, so anything that referenced the old one needs updating.

Whichever route you take, check the volume's DeleteOnTermination history first. A volume that outlived its instance because that flag was set to false is usually a deliberate choice by whoever built the instance, and worth one message before it is removed. Once a volume is gone, the corresponding orphaned snapshot finding is what keeps its replacement honest.