The Unattached EBS Volume: How Ghost Infrastructure Silently Drains Cloud Budgets
When teams decommission EC2 instances, they assume the associated costs immediately drop to zero. In reality, thousands of engineering organizations are unknowingly paying an ongoing monthly tax for ghost storage: orphaned Amazon Elastic Block Store (EBS) volumes. Here is why terminating an EC2 instance often leaves behind expensive running disks, and the automated safeguards to eliminate orphaned storage across your accounts.
The Silent Bleed: Why Terminated Instances Leave EBS Behind
When an EC2 instance launches, it typically creates two types of EBS volumes:
- Root Volume (
/dev/xvdaor/dev/sda1): Holds the operating system and base application code. - Additional Data Volumes (
/dev/sdb,/dev/nvme1n1, etc.): Attached to store database files, persistent logs, or container datasets.
By default, AWS sets the
DeleteOnTermination attribute to true for root volumes. However, for many secondary volumes—especially those created independently, attached via custom scripts, or provisioned through legacy Terraform templates—DeleteOnTermination defaults to false.1
2
[Terminate EC2 Instance] ──► Root Volume Deleted (Free)
└──► Data Volume Retained ──► [Orphaned "Available" State ($0.08–$0.125/GB/month)]Once the instance disappears, the EBS volume shifts to the
available state. It is no longer mounted to any compute resource, generates zero operational utility, yet AWS continues billing the full provisioned storage rate and provisioned IOPS indefinitely.Scale this across dozens of developers spinning up and tearing down environments, and ghost volumes can easily accumulate hundreds or thousands of dollars in pure waste.
3 Steps to Bulletproof Your Storage Hygiene
1. Enforce DeleteOnTermination at Launch Time
Whenever attaching block storage via Infrastructure as Code (IaC), explicitly declare automatic deletion on termination for all non-root block devices:
1
2
3
4
5
6
7
8
9
10
11
resource "aws_instance" "app_server" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.medium"
ebs_block_device {
device_name = "/dev/sdb"
volume_size = 100
volume_type = "gp3"
delete_on_termination = true # Prevents ghost volumes on shutdown
}
}2. Run an Automated AWS Config Rule
Prevent manual console launches from slipping through by enabling the AWS-managed Config rule
ec2-volume-inuse-check.This rule automatically marks any EBS volume in the
available state as non-compliant, alerting your platform team or triggering an automated remediation document via Systems Manager (SSM) after 7 days of inactivity.3. Locate Orphaned Volumes via AWS CLI in 30 Seconds
Run this command across your primary regions to instantly audit all detached volumes currently incurring charges:
1
2
3
4
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query "Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}" \
--output tableIf the output lists gigabytes of unattached disks, review whether a snapshot is required, create the snapshot, and delete the volume.
Snapshot Lifecycle Policy: Don't Trade Ghost Disks for Ghost Snapshots
A common pitfall after deleting orphaned EBS volumes is keeping thousands of historical EBS snapshots forever. Snapshots accrue S3-backed storage charges ($0.05/GB-month).
Pair your cleanup routines with AWS Data Lifecycle Manager (Amazon DLM) to automatically retain snapshots only for compliance windows (e.g., 30–90 days) before aging them out.
Community Audit
How does your organization track detached EBS volumes and snapshot sprawl? Do you run scheduled cleanup Lambdas, or enforce strict Config remediation? Drop your operational tips below! 👇
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article