When EC2 instances are provisioned, each attached EBS volume has a `DeleteOnTermination` flag that determines whether it will be deleted when the instance is terminated. If this flag is set to `false` — often unintentionally in custom launch templates, AMIs, or older automation scripts — volumes persist after termination, resulting in orphaned storage. While detached volumes are easy to detect and clean up after the fact, proactively identifying attached volumes with `DeleteOnTermination=false` can prevent future waste before it occurs.

Many environments continue using io1 volumes for high-performance workloads due to legacy provisioning or lack of awareness of io2 benefits. io2 volumes provide equivalent or better performance and durability with reduced cost at scale. Failing to adopt io2 where appropriate results in unnecessary spend on IOPS-heavy volumes.

EBS volumes often remain significantly overprovisioned compared to the actual data stored on them. Because billing is based on the total provisioned capacity—not actual usage—this creates ongoing waste when large volumes are only partially used. Overprovisioning may result from default sizing in templates, misestimated requirements, or conservative provisioning practices. Identifying and remediating these cases can lead to meaningful storage cost reductions without impacting workload performance.

EBS Snapshot Archive is a lower-cost storage tier for rarely accessed snapshots retained for compliance, regulatory, or long-term backup purposes. Archiving snapshots that do not require frequent or fast retrieval can reduce snapshot storage costs by up to 75%. Despite this, many organizations retain large volumes of snapshots in the standard tier long after their operational value has expired.

This inefficiency arises when snapshots are retained long after they’ve served their purpose. Snapshots may have been created for backups, migrations, or disaster recovery plans but were never deleted—even after the related workload or volume was decommissioned. Over time, these unused snapshots accumulate, continuing to incur storage costs without providing operational value.

This inefficiency occurs when legacy volume types such as gp2 or io1 remain in use, even though AWS has released newer types—like gp3 and io2—that offer better performance at lower cost. Gp3 allows users to configure IOPS and throughput independently of volume size, while io2 provides higher durability and more predictable performance than io1. These newer volumes are generally more cost-effective and can be adopted without re-architecting workloads. Many teams continue using outdated types due to default AMIs, automation templates, or simple oversight.

This inefficiency occurs when an EBS volume has provisioned IOPS levels that consistently exceed the actual I/O requirements of the workload it supports. This can happen when performance buffers are estimated too high, usage patterns change over time, or default settings are left unadjusted. Provisioned IOPS above the included baseline generate ongoing charges that may not reflect actual utilization, resulting in avoidable cost.

This inefficiency occurs when an EC2 instance is stopped but still has one or more attached EBS volumes. Although the compute resource is not generating charges while stopped, the attached volumes continue to incur full storage and performance-related costs. These volumes are often overlooked in cost reviews, especially if the instance is temporarily paused or has been left in a stopped state long-term. Without regular validation, these volumes may represent unused capacity that delivers no value.

EBS volumes frequently remain detached after EC2 instances are terminated, replaced, or reconfigured. Some may be intentionally retained for reattachment or backup purposes, but many persist unintentionally due to the lack of automated cleanup. When these detached volumes are also inactive—showing no read or write activity—they represent unnecessary ongoing costs. Identifying and removing these orphaned volumes can produce meaningful savings without affecting running workloads.