How to Find and Delete Orphaned EBS Volumes and Snapshots

The storage you already forgot about

Cloud storage is easy to create and easy to leave behind. An EC2 instance is terminated, a test environment is torn down, or an old database is migrated, and the EBS volume that was attached to it stays in the account. It is no longer mounted, but it is still billed.

The same thing happens with snapshots. They start as sensible backups, then the resource they protect disappears and the snapshot becomes the leftover. Over months and years, orphaned volumes and stale snapshots can accumulate into a meaningful line item.

This post shows how to find them, decide whether they are safe to remove, and delete them without touching the live resources that still matter.

Why orphaned EBS storage is worth auditing first

EBS is not the biggest AWS bill category for every account, but it is one of the easiest to clean up:

• Volumes that are not attached are doing almost nothing useful
• Snapshots older than the resource lifetime are rarely needed
• The cost is steady and predictable, so the saving is immediate
• Deletion is usually faster and lower-risk than rightsizing compute

A few orphaned gp3 or gp2 volumes and a couple of hundred old snapshots can add hundreds of dollars per year to an account. That is low-hanging fruit for a first-pass review.

What counts as orphaned

Orphaned EBS volume

• Status is available (not in-use)
• Not attached to any EC2 instance
• No tags that indicate it is reserved for a specific purpose
• Create date is much older than the lifecycle of the workload it came from

Stale EBS snapshot

• Created by a user or a backup process
• The original volume or instance no longer exists
• No recovery, compliance, or retention requirement documented
• Older than your recovery-point objective for the data it protects

Be careful: a snapshot can still be the only copy of data, and an available volume may be kept intentionally for reattachment or forensic review. Do not delete anything until you know what it is for.

Find unattached EBS volumes

Use the AWS CLI to list volumes with available status:

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

Add a Name or created-by tag if your organization tags resources:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,VolumeType,Size,CreateTime,Tags[?Key==`Name`].Value | [0]]' \
  --output table

If the output is long, this is a good moment to sort by CreateTime and start with the oldest volumes. The older a volume is, the more likely nobody remembers why it exists.

Find EBS snapshots that may no longer be needed

List snapshots owned by your account:

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[].[SnapshotId,VolumeId,VolumeSize,StartTime,Description]' \
  --output table

A snapshot is only worth keeping if the data is useful. Two quick checks:

1. Does the source volume still exist? Match VolumeId from the snapshot against your live describe-volumes list.
2. Is the snapshot part of an active backup plan? Check whether it was created by AWS Backup or another scheduled job.

If the source volume is gone and no documented retention policy applies, the snapshot is a strong deletion candidate.

Check for dependencies before deleting

Before you delete a volume or snapshot, confirm it is not required by something else:

• Is it referenced by an AMI? Deleting a snapshot used by an AMI will make that AMI unusable.
• Is it part of a CloudEndure or other DR configuration?
• Does a backup vault or AWS Backup plan expect it to exist?
• Is it referenced in a CloudFormation stack or Terraform state?

For snapshots, check AMI usage:

aws ec2 describe-images \
  --filters Name=owner-id,Values=$(aws sts get-caller-identity --query Account --output text) \
  --query 'Images[].[ImageId,Name,BlockDeviceMappings[].Ebs.SnapshotId]' \
  --output table

If a snapshot is tied to an AMI you still need, keep it.

Delete what you do not need

Delete a single unattached volume:

aws ec2 delete-volume --volume-id vol-0123456789abcdef0

Delete a single snapshot:

aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0

For many resources, use a script that reads a list of IDs and deletes them one at a time. Always include dry-run and confirmation steps. Deletion is permanent.

Automate detection with GreenOps Scan

The ebs-snapshots module in the free GreenOps Scan CLI flags:

• unattached EBS volumes
• old snapshots without a live source volume
• AMIs that reference snapshots for resources that no longer exist

Run it on a dev or sandbox account first:

npx greenops-scan --profile dev --region us-east-1 --modules ebs-snapshots

Or use the Docker image:

docker run --rm -it \
  -v ~/.aws:/home/greenops/.aws:ro \
  -v "$(pwd)/reports:/reports" \
  -e AWS_PROFILE=dev \
  spidgorny/greenops-scan:latest \
  --region us-east-1 --modules ebs-snapshots

Each finding includes the resource ID, the reason it was flagged, an estimated monthly cost, and a confidence level. Review the findings before deleting anything, especially in production accounts.

Make it a habit

One cleanup is useful; a process is better. Consider a recurring review:

• Monthly: review unattached volumes in non-production accounts
• Quarterly: review snapshots older than your retention policy
• After every environment teardown: confirm attached storage was deleted with the instance

If you use Termination Protection or keep test volumes around, document the exception so the next review does not waste time on it.

What to expect from cleanup

The exact saving depends on the number of gp3, gp2, io2, or st1 volumes left behind, plus snapshot storage. A small account might save $20–$100 per month. A larger account with years of backups and test environments can save much more.

The value is not just the dollar amount. It is also the reduction in storage clutter and the lower chance of accidentally keeping sensitive data on forgotten volumes.

Start with the obvious orphans

1. List available volumes.
2. List snapshots whose source volume is gone.
3. Check dependencies, especially AMIs.
4. Delete what is no longer needed.
5. Add the review to your monthly or quarterly cloud hygiene checklist.

For a faster first pass, let GreenOps Scan surface the candidates and review its findings before you delete.

Tags: #AWS #CloudCostOptimization #FinOps #CloudWaste #EBS #SnapshotCleanup #StorageCost #GreenOps